![]() 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. ![]() So this allows one to validate the configuration file prior to - potentially - cutting off ones access to a remote server (for example I have that for some VPS and even for physical servers where I need to pay extra to get out-of-band access to the machine).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. Normally this should not interfere with existing SSH-connections, but I've seen it. The main advantage of this method is that it allows you to check the sshd configuration without having to restart the sshd on the default port. For more debugging goodness check man sshd. To get really verbose output to stdout, use $(which sshd) -Ddddp 10222 (note the added dd to increase verbosity). Make sure to choose a free port here.įinally: connect to the alternative port ( ssh -p 10222 method has helped me many many times in finding issues, be it authentication issues or other types. The -p 10222 makes sshd listen on that alternative port, overriding the configuration file - this is so that it doesn't clash with potentially running sshd instances. Otherwise you'll get the following error: sshd re-exec requires execution with an absolute path. NB: at least on Ubuntu the $(which sshd) is the best method to satisfy sshd requirement of an absolute path. Neither of the log files contained this output. Much better! This error message allowed me to see what's wrong and fix it. etc/ssh/sshd_config line 8: address family must be specified before ListenAddress. When I started it from the terminal I got: # $(which sshd) -Ddp 10222 ![]() The problem in my case was that neither syslog nor auth.log showed anything meaningful. What I find generally very useful in any such cases is to start sshd without letting it daemonize. So while this doesn't directly answer your question, it may help tracking down the error cause. If you have ruled out any "external" factors, the following set of steps usually helps to narrow it down. Permissions appear to be fine (same on the server).Īlso tried without configuring /etc/ssh/ssh_config with the same result except for a lot of auto-configuration going on in the client which ends up with the same error. rw-r-r- 1 torxed users 170 May 11 11:21 known_hosts No conflicts with the firewall settings (for now). So that leads to the conclusion that this must be an issue with my local ArchLinux laptop. On the windows machine, everything works fine, so I checked the security logs and the lines in there are identical, the server treats the two different "machines" no different and they are both allowed via public-key authentication. Ssh_exchange_identification: read: Connection reset by peer I'm not using hosts.allow or ny, furthermore SSH works from my windows-machine (same laptop, different hard drive) but not my Linux machine.ĭebug1: Reading configuration data /etc/ssh/ssh_configĭebug1: /etc/ssh/ssh_config line 20: Applying options for *ĭebug1: identity file /home/torxed/.ssh/id_dsa type -1ĭebug1: identity file /home/torxed/.ssh/id_dsa-cert type -1ĭebug1: Enabling compatibility mode for protocol 2.0ĭebug1: Local version string SSH-2.0-OpenSSH_6.6
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |