Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I am trying to SSH to my raspberry pi which is connected under the same router as my computer. It is running the latest version of raspbian lite. I enabled the ssh service on the pi using the command: systemctl enable ssh. However when I try to SSH to my raspberrypi from my personal computer, I get this message:
fahd#Fahd-PC:~$ ssh pi#192.168.1.23
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:***************************************************
Please contact your system administrator.
Add correct host key in /home/fahd/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/fahd/.ssh/known_hosts:1
remove with:
ssh-keygen -f "/home/fahd/.ssh/known_hosts" -R "192.168.1.23"
ECDSA host key for 192.168.1.23 has changed and you have requested strict checking.
Host key verification failed.
fahd#Fahd-PC:~$
And I'm not entirely sure whether this is something real I should be worried about or just me not knowing how to use SSH properly.
For some reason, your terminal has a different key in storage for your Pi. This can be due to several reasons (for example, the ssh package was updated and the SSH host key re-generated on the Pi. Or you changed the IPs on your network. Or you have DHCP and two different clients, and you got the addresses swapped. Or...).
So, it warns you.
Unless you have reasons to believe otherwise, I'd just follow the suggestion:
remove with:
ssh-keygen -f "/home/fahd/.ssh/known_hosts" -R "192.168.1.23"
This communicates inform you that RSA keys on the device has changed it happen when you:
reinstall OS on device
generate new / remove old RSA keys
someone is trying to do MITM attack (very rare in these days)
How to fix it:
Remove saved information about raspberry pi host
sudo vim ~/.ssh/known_hosts
or
sudo vim /etc/ssh/known_hosts
Use ssh-keygen
ssh-keygen -R host_ip
or
ssh-keygen -R host_ip -f path_to_known_hosts
Remove known_hosts
If you have only one host in "known_hosts" file you can just remove it.
sudo rm .ssh/known_hosts
I'm getting the standard
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
error message. However, the system (Appworx) that executes the command (sftp I think, not that it matters) is automated and I can't easily accept the new key, even after checking with the third party vendor that it is a valid change. I can add a new shell script that I can execute from the same system (and user), but there doesn't seem to be a command or command-line argument that will tell ssh to accept the key. I can't find anything in the man page or on Google. Surely this is possible?
The answers here are terrible advice. You should never turn off StrictHostKeyChecking in any real-world system (e.g. it's probably okay if you're just playing on your own local home network – but for anything else don't do it).
Instead use:
ssh-keygen -R hostname
That will force the known_hosts file to be updated to remove the old key for just the one server that has updated its key.
Then when you use:
ssh user#hostname
It will ask you to confirm the fingerprint – as it would for any other "new" (i.e. previously unseen) server.
While common wisdom is not to disable host key checking, there is a built-in option in SSH itself to do this. It is relatively unknown, since it's new (added in Openssh 6.5).
This is done with -o StrictHostKeyChecking=accept-new.
WARNING: use this only if you absolutely trust the IP\hostname you are going to SSH to:
ssh -o StrictHostKeyChecking=accept-new mynewserver.example.com
Note, StrictHostKeyChecking=no will add the public key to ~/.ssh/known_hosts even if the key was changed.
accept-new is only for new hosts. From the man page:
If this flag is set to “accept-new” then ssh will automatically add
new host keys to the user known hosts files, but will not permit
connections to hosts with changed host keys. If this flag
is set to “no” or “off”, ssh will automatically add new host keys
to the user known hosts files and allow connections to hosts with
changed hostkeys to proceed, subject to some restrictions.
If this flag is set to ask (the default), new host keys will be
added to the user known host files only after the user has confirmed
that is what they really want to do, and ssh will refuse to
connect to hosts whose host key has changed.
The host keys of known hosts will be verified automatically in all cases.
Why -o StrictHostKeyChecking=no is evil?
When you do not check the host key you might land with an SSH session on a different computer (yes, this is possible with IP Hijacking). A hostile server, which you don't own can be then used to steal a password and all sort of data.
Accepting a new unknown key is also pretty dangerous.
One should only do it if there is an absolute trust in the network or that the server was not compromised.
Personally, I use this flag only when I boot machines in a cloud environment with cloud-init immediately after the machine started.
Here's how to tell your client to trust the key. A better approach is to give it the key in advance, which I've described in the second paragraph. This is for an OpenSSH client on Unix, so I hope it's relevant to your situation.
You can set the StrictHostKeyChecking parameter. It has options yes, no, and ask. The default is ask. To set it system wide, edit /etc/ssh/ssh_config; to set it just for you, edit ~/.ssh/config; and to set it for a single command, give the option on the command line, e.g.
ssh -o "StrictHostKeyChecking no" hostname
An alternative approach if you have access to the host keys for the remote system is to add them to your known_hosts file in advance, so that SSH knows about them and won't ask the question. If this is possible, it's better from a security point of view. After all, the warning might be right and you really might be subject to a man-in-the-middle attack.
For instance, here's a script that will retrieve the key and add it to your known_hosts file:
ssh -o 'StrictHostKeyChecking no' hostname cat /etc/ssh/ssh_host_dsa_key.pub >>~/.ssh/known_hosts
Since you are trying to automate this by running a bash script on the host that is doing the ssh-ing, and assuming that:
You don't want to ignore host keys because that's an additional security risk.
Host keys on the host you're ssh-ing to rarely change, and if they do there's a good, well-known reason such as "the target host got rebuilt"
You want to run this script once to add the new key to known_hosts, then leave known_hosts alone.
Try this in your bash script:
# Remove old key
ssh-keygen -R $target_host
# Add the new key
ssh-keyscan $target_host >> ~/.ssh/known_hosts
You just have to update the current fingerprint that's being sent from server. Just Type in the following and you'll be good to go :)
ssh-keygen -f "/home/your_user_name/.ssh/known_hosts" -R "server_ip"
Just adding the most 'modern' approach.
Like all other answers - this means you are BLINDLY accepting a key from a host. Use CAUTION!
HOST=hostname ssh-keygen -R $HOST && ssh-keyscan -Ht ed25519 $HOST >> "$HOME/.ssh/known_hosts"
First remove any entry using -R, and then generate a hashed (-H) known_hosts entry which we append to the end of the file.
As with this answer prefer ed25519.
Get a list of SSH host IPs (or DNS name) output to a file > ssh_hosts
Run a one-liner to populate the ~/.ssh/known_hosts on the control node (often do this to prepare target nodes for Ansible run)
NOTE: Assume we prefer ed25519 type of host key
# add the target hosts key fingerprints
while read -r line; do ssh-keyscan -t ed25519 $line >> ~/.ssh/known_hosts; done<ssh_hosts
# add the SSH Key('s) public bit to target hosts `authorized_keys` file
while read -r line; do ssh-copy-id -i /path/to/key -f user#$line; done<ssh_hosts
ssh -o UserKnownHostsFile=/dev/null user#host
Add following file
~/.ssh/config
and this in the file as content
StrictHostKeyChecking no
This setting will make sure that ssh will never ask for fingerprint check again.
This should be added very carefully as this would be really dangerous and allow to access all fingerprints.
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 months ago.
Improve this question
I've reinstalled my server and I am getting these messages:
[user#hostname ~]$ ssh root#pong
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
6e:45:f9:a8:af:38:3d:a1:a5:c7:76:1d:02:f8:77:00.
Please contact your system administrator.
Add correct host key in /home/hostname /.ssh/known_hosts to get rid of this message.
Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
RSA host key for pong has changed and you have requested strict checking.
Host key verification failed.
I have tried various solutions that I found on the Internet. My known_hosts file (normally in ~/.ssh/known_hosts) is in /var/lib/sss/pubconf/known_hosts. I've tried to edit it, but it remains in one state. I have installed ipa-client and have Fedora 19. How do I resolve this warning?
All the answers answered so far work only if you do not have Freeipa installed.
The right answer for freeipa in comments below from adrin is here.
Here is the simplest solution:
ssh-keygen -R <host>
For example,
ssh-keygen -R 192.168.3.10
From the ssh-keygen man page:
-R hostname Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts (see the -H option above).
Use
ssh-keygen -R [hostname]
Example with an ip address/hostname would be:
ssh-keygen -R 168.9.9.2
This will update the offending of your host from the known_hosts. You can also provide the path of the known_hosts with -f flag.
I had this same error occur after I recreated a Digital Ocean Ubuntu image. I used the following command with my server IP in place of [IP_ADDRESS]
ssh-keygen -R [IP_ADDRESS]
The sledgehammer is to remove every known host in one fell swoop:
rm ~/.ssh/known_hosts
On Monterey
sudo rm /var/root/.ssh/known_hosts
I come up against this as we use small subnets of short-lived servers from a jump box, and frequently have internal IP address reuse of servers that share the same ssh key.
When you reinstall the server its identity changes, and you'll start to get this message. Ssh has no way of knowing whether you've changed the server it connects to, or a server-in-the-middle has been added to your network to sniff on all your communications - so it brings this to your attention.
Simply remove the key from known_hosts by deleting the relevant entry:
sed '4d' -i /var/lib/sss/pubconf/known_hosts
The 4d is on the account of Offending RSA ...known_hosts:4
The problem is that you've previously accepted an SSH connection to a remote computer and that remote computer's digital fingerprint or SHA256 hash key has changed since you last connected. Thus when you try to SSH again or use github to pull code, which also uses SSH, you get an error. Why? Because you're using the same remote computer address as before but the remote computer is responding with a different fingerprint. Therefore, it's possible that someone is spoofing the computer you previously connected to. This is a security issue.
If you're 100% sure that the remote computer isn't compromised, hacked, being spoofed, etc then all you need to do is delete the entry in your known_hosts file for the remote computer. That will solve the issue as there will no longer be a mismatch with SHA256 fingerprint IDs when connecting.
On Mac here's what I did:
1) Find the line of output that reads RSA host key for servername:port has changed and you have requested strict checking. You'll need both the servername and potentially port from that log output.
2) Back up the SSH known hosts file cp /Users/yourmacusername/.ssh/known_hosts /Users/yourmacusername/.ssh/known_hosts.bak
3) Find the line where the computer's old fingerprint is stored and delete it. You can search for the specific offending remote computer fingerprint using the servername and port from step #1. nano /Users/yourmacusername/.ssh/known_hosts
4) CTRL-X to quit and choose Y to save changes
Now type ssh -p port servername and you will receive the original prompt you did when you first tried to SSH to that computer. You will then be given the option to save that remote computer's updated SHA256 fingerprint to your known_hosts file. If you're using SSH over port 22 then the -p argument is not necessary.
Any issues you can restore the original known_hosts file: cp /Users/yourmacusername/.ssh/known_hosts.bak /Users/yourmacusername/.ssh/known_hosts
As many have already said, use ssh-keygen, i.e.
ssh-keygen -R pong
Also, you may like to consider temporarily turning off host key checking:
ssh -oStrictHostKeyChecking=no root#pong
Works for me!
Error: Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
This indicates you have an offending RSA key at line no. 4
Solution 1:
1. vi /var/lib/sss/pubconf/known_hosts
2. remove line no: 4.
3. Save and Exit, and Retry.
Solution 2:
ssh-keygen -R "you server hostname or ip"
OR
Solution 3:
sed -i '4d' /root/.ssh/known_hosts
This will remove 4th line of /root/.ssh/known_hosts in place(-i).
I used the solution of mockinterface, though the sed -i didn't quite work
I solved it by deleting the line by hand with vim:
sudo vim /var/lib/sss/pubconf/known_hosts
You can use any other text editor you want, but probably you'll need to show your administrative privileges
FINAL Solution!
It is showing due to the stored invalid ECDSA key. So we have to remove the ECDSA key from our master/controller machine by using the below command:
ssh-keygen -R 192.168.0.132
Here 192.168.0.132 is the remote system IP.
Edit /home/hostname /.ssh/known_hosts,and delete the 4 lines, and save it.
Then run ssh root#pong again, you will see message like this:Are you sure you want to continue connecting (yes/no)? yes, just print yes.
Note: If you got some problem, read the hints first, it will help.
The other answers here are good and working, anyway, I solved the problem by deleting ~/.ssh/known_hosts. This certainly solves the problem, but it's probably not the best approach.
updated your ssh key, getting the above message is normal.
Just edit ~/.ssh/known_hosts and delete line 4, as the message pointed you
Offending RSA key in /Users/isaacalves/.ssh/known_hosts:4
or use ssh-keygen to delete the invalid key
ssh-keygen -R "you server hostname or ip"
This is because your remote computer settings have changed. Remove your current keys for that.
vim /root/.ssh/known_hosts
Delete the line of the IP you are connecting.
In my case it happened because I previously had ssh connection with a machine with same ip(say 192.152.51.10) and the system was considering the RSA key(stored in /home/user_name/.ssh/known_hosts) of the previous host which resulted in mismatch.
To resolve this issue, you have to remove previously stored RSA key for the ip 192.152.51.10.
ssh-keygen -f "/home/user_name/.ssh/known_hosts" -R 192.152.51.10
Simple one-liner solution, tested on mac:
sed '/212.156.48.110/d' ~/.ssh/known_hosts > ~/.ssh/known_hosts
Deletes only the target ssh host IP from know hosts.
where 212.156.48.110 is replaced by the target host IP address.
Cause: Happened because the target IP was already known for a different machine due to port forwarding. Deleting the target IP before connecting will fix the issue.
I use PowerShell in Windows 10 for ssh.
My problem was in the Windows directory: C:\Users\youruser\.ssh
Delete the file known_hosts in that directory to forget the old value.
You may also use use File Explorer to locate and delete the file.
If you are trying to connect to running docker container on port 2222 with the command and you get the error
mian#tdowrick2~$ ssh pos#localhost -p 2222
Then to solve this problem, on your local computer (i.e. host machine not container) go to cd ~/.ssh/ and open known_hosts file with text editor. Remove the line starting with [localhost]:2222 and save the file. Now try to ssh again
mian#tdowrick2~$ ssh pos#localhost -p 2222
Error will disappear but you have to do it each time the container restart.
My solution is:
vi ~/.ssh/known_hosts
delete the line that contains your want connected ip.
This is better than delete all of the known_hosts
Remove that the entry from known_hosts using:
ssh-keygen -R *ip_address_or_hostname*
This will remove the problematic IP or hostname from known_hosts file and try to connect again.
From the man pages:
-R hostname
Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts (see the -H option
above).
Sometimes, if for any reason, you need to reinstall a server, when connecting by ssh we will find that you server say that the identification has changed.
If we know that it is not an attack, but that we have reinstated the system, we can remove the old identification from the known_hosts using ssh-keygen:
ssh-keygen -R <host/ip:hostname>
root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
When connecting again we will ask you to validate the new fingerprint:
ssh -l user <host/ip:hostname>
The authenticity of host '<host/ip:hostname>' can't
be established.
RSA key fingerprint is 3f:3d:a0:bb:59:24:35:6d:e5:a0:1a:3f:9c:86:81:90.
Are you sure you want to continue connecting (yes/no)? yes
Use this command:
truncate -s 0 /home/SYSTEM_NAME/.ssh/known_hosts
I had this problem, and the reason is very simple, I have a duplicated IP address to ssh login, so after modify this problem, everthing is solved.
Only client side problem(duplicate key for ip):
Solve variants:
For clear one ip(default port 22):
ssh-keygen -f -R 7.7.7.7
For one ip(non default port):
ssh-keygen -f -R 7.7.7.7:333
Fast clear all ips:
cd ~; rm .ssh/known_hosts
7.7.7.7 - ssh your server ip connect
333 - non standart port
Just do:
cd /home/user/.ssh/ -> here user will be your username, i.e. /home/jon/ for example.
Then
gedit known_hosts & and delete the contents inside it.
Now ssh again, it should work.
I had the same error in my machine, and I clear the known_hosts file, and after that, it works fine.
Simply clear the known_hosts which is present in /home/{username}/.ssh/known_hosts
vi /home/{username}/.ssh/known_hosts
remove every line inside known hosts and exit after that you will be able to login.
OR
run this command
ssh-keygen -R "hostname/ip_address"
SOLUTION:
1- delete from "$HOME/.ssh/known_hosts" the line referring to the host towards which is impossible to connect.
2- execute this command: ssh-keygen -R "IP_ADDRESSorHOSTNAME" (substitute "IP_ADDRESSorHOSTNAME" with your destination ip or destination hostname)
3- Retry ssh connection (if it fails please check permission on .ssh directory, it has to be 700)
My solution on UBUNTU (linux):
1.You have to delete the content from "known_hosts" file which is in "/home/YOUR_USERNAME/.ssh/known_hosts"
2.Generate a new ssh key like "ssh-keygen -t rsa -C "your.email#example.com" -b 4096"
3.Copy-paste your new ssh key in your git repository (gitlab in my case) SSH keys.
It works for me !
AWS EC2.
Find the ip in the message it gives you.
run
vim /home/ec2-user/.ssh/known_hosts
Use the arrow keys to find the ip from the message and click.
dd
This will delete that line then run escape
:wp
This will save then you are good to go.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Is there a way to specifically ssh into a particular directory in remote location, specifically using the local ssh config file (not terminal)? Something like Dir option in the paragraph below, for example,
Host remote_dir
Hostname remote_server
User username
Dir path/to/remote_dir/
So, if I, ssh using the Host value from above paragraph,
ssh remote_dir
Then, I would like to be logged in and the terminal to be ready for me at path/to/remote_dir/ of the remote server,
username#remote_server: path/to/remote_dir/ > pwd
/home/username/path/to/remote_dir/
In this post on ServerFault, they say you can't do it all through the ssh config file. But you can do it with the ssh config and your .bash_profile or whatever the terminal nerds call it.
in the ssh config file add
Host dev
Hostname server.com
User joe
then in your .bash_profile add an alias
alias domain1="ssh dev -t 'cd domains/domain1; bash'"
Here the dev refers to what you set up in the config file.
In the Terminal, just type domain1, you will be asked to put in your password and will go straight to the directory. Make a new alias for all your domains and it will make logging in to each one super easy.
Take a look at
https://serverfault.com/questions/167416/change-directory-automatically-on-ssh-login
This is the accepted answer:
LocalCommand isn't what you want, anyway. That's run on your machine. You want RemoteCommand. Something like this worked for me:
Host example.net
RemoteCommand cd / && exec bash --login
RequestTTY yes
(Old answer) For a similar use case, ssh -t is also an option:
ssh server -t "cd /my/remote/directory; bash --login"
It is not the same, as it does not use ssh config. But you can define an alias for the command and end up with a similar effect.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I would like to automate the rsync task as a cron job. Since it needs the passphrase I am not able to do the cronjob. I need to specify the passphrase along with the rsync command or I will store the passphrase in a file and I will read from it. My command will look like this:
rsync -aPe "ssh -i ' . $server->{'ssh_key'} . '" ' . $server_lock_dir;
So where do I put the password ?
You don't need to do that - just need to set up a pair of ssh keys and put the public key in the remote system's .ssh directory.
Then you just do this:
rsync -a -e ssh /local/path/ server:/remote/path/
(Note that -e ssh has been the default for quite a few years now, so you can probably omit it, unless you're using a very old version.)
There's a "how to" guide on setting up the keys here.
If you want this to work from cron, you have several possibilities:
setup password-less ssh keys - not very secure
setup password-less ssh keys, but combine them with ssh ForceCommand in the authorized_keys file to limit the commands that can be run with that ssh key. See man sshd, google on "ssh ForceCommand"
setup passworded ssh keys, but combine them with keychain to keep the key in memory between sessions. I've written a blog post on this: ssh, ssh-agent, keychain and cron notes
If you want to copy files remotely:
Make sure you have a public key on your local machine that can log into the remote machine.(in this case the my ssh-key is "/home/myaccount/.ssh/id_rsa"
Specify local folder you want to sync with the remote, in my case "/home/myaccount/mysourcefolder"
Specify the destination folder full path in the remote server, in my case remoteaccount#remoteserver:"/home/remoteaccount/mydestinationfolder/"
Note:
--progress is to show progress for each file being copied
-a to transfer recusively all files in the mysourcefolder
-v for verbosity
-z to compress data portions for small files
My command will look like below:
rsync -avz --progress -e "ssh -i /home/myaccount/.ssh/id_rsa"
/home/myaccount/mysourcefolder
remoteaccount#remoteserver:"/home/remoteaccount/mydestinationfolder/"