#LXC SSH COPY ID WINDOWS#
On Windows there is no sed, hence the best fix probably is to remove the known_hosts file with del %USERPROFILE%\.ssh\known_hosts` The second step then is to re-learn all host keys, which must be done manually by connecting to each IP again using ssh. The first step is to remove all the good old RSA keys ( Warning! This loses protection against MitM): $ sed -i '/ ssh-rsa /d' ~/.ssh/known_hosts I do not know a good fix for this, the only workaround I found is to remove all "good but old rsa keys" such that the client can re-learn the "new more secure ecdsa keys".
It then presents this misleading message!
#LXC SSH COPY ID PASSWORD#
Now, you can connect to the server B without a password or passphrase: ssh my side this happens due to something which I consider an ssh bug of newer ( OpenSSH_7.9p1 and above) clients, when it tries to learn a more secure ecdsa server key where there already is an older rsa type key known. IMPORTANT: Beda is your username on the server which you are connecting, B is your server IP. This command prints the file id_rsa.pub (your public key) into authorized_keys on the server. This command changes the directory to your users home directory. Otherwise, do not print an error message. This command creates the directory, if they do not already exist. This command generates the key and stores the key in the file.
#LXC SSH COPY ID PC#
If you are logged into a local PC like user John and connected to the server B like user and everything is OK, it does not mean that everything is OK if you are logged to local PC like user Jane and connecting to the server B like user you want to login on server B as user Beda from PC A without password, try this command, all from PC A: ssh-keygen -t rsa (and ran service ssh restart)Īre you using the same user for connecting? I read a security.SE q/a on ecdsa and have already removed that line from sshd_config my new Debian server. Ubuntu's shift away from the rock-solid linux OS I counted on is why I installed Debian this time around. So yes, likely, the host started using ecdsa keys recently, which based upon Ubuntu's changes lately, I would blame on an update. UsePrivilegeSeparation yes UsePrivilegeSeparation yes #Privilege Separation is turned on for security #Privilege Separation is turned on for security HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_rsa_key # HostKeys for protocol version 2 # HostKeys for protocol version 2 # Use these options to restrict which interface # Use these options to restrict which interfaces # What ports, IPs and protocols we listen for # What ports, IPs and protocols we listen for # See the sshd(8) manpage for details # See the sshd_config(5) manpage for details # Package generated configuration file # Package generated configuration file I checked backups from a former Ubuntu server and diff'd against my new Debian install: Ubuntu: Debian: That bit about :11122 is the port number I route SSH from on the firewall
Warning: Permanently added ':11122 (:11122)' (ECDSA) to the list of known hosts. The authenticity of host ':11122 (:11122)' can't be established.ĮCDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.Īre you sure you want to continue connecting (yes/no)? yes Then I open up ~/.ssh/known_hosts on the computer initiating the ssh, delete that line, reconnect and this happens: ~ $ ssh work RSA host key for has changed and you have requested strict checking. Offending key in /home/user/.ssh/known_hosts:4 Please contact your system administrator.Īdd correct host key in /home/user/.ssh/known_hosts to get rid of this message. It is also possible that the RSA host key has just been changed. Someone could be eavesdropping on you right now (man-in-the-middle attack)! When all OSs were Ubuntu and I reinstall a server's OS, upon the first SSH in to it, I get this kind of warning, which I prefer over the silent warning above! WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Previously, all of my server OSs were Ubuntu and this time it changed to Debian (and I suspect there is a nuanced difference in permissions). The trigger for my case is: installed new server OS at work and upon installing openssh-server package, a new set of host keys were generated on work's server. Having just resolved this issue and not being happy with the answers, I wanted to really know "why" myself.
I do lots of ssh-ing around between my LAN computers and my two webhosting accounts, so I've sorted out all kinds of odds and ends with SSH, including authentication problems using ssh -v to see where and what went wrong.
0 kommentar(er)
