$ ssh server.example.com ssh: connect to host server.example.com port 22: Connection refused
$ telnet server.example.com 22 Trying 172.16.121.6... Connected to server.example.com Escape character is '^]'. SSH-2.0-OpenSSH_3.4p1
If you do not see the OpenSSH version string and/or receive "Connection refused", proceed with the following checks.
$ ssh server.example.com -p 1212
$ ssh server.example.com firstname.lastname@example.org's password: ******** Permission denied, please try again. email@example.com's password: ********
$ ssh server.example.com firstname.lastname@example.org's password:
$ ssh server.example.com Enter passphrase for key '/home/sshuser/.ssh/id_rsa':
(Keep in mind, OpenSSH by default tries public key authentication before it tries host-based (i.e. UNIX password) authentication “ so, as long as you know the UNIX password, you should still be able to connect in a secure manner, assuming that password authentication is still enabled. See the man page for the ssh command)
$ pwd /home/sshuser $ cd .ssh $ chmod 744 . $ chmod 644 ./authorized_keys $ ls -l total 6 -rw-r--r-- 1 sshuser admin 223 Apr 14 16:44 authorized_keys -rw-r--r-- 1 sshuser admin 230 Apr 6 01:17 known_hosts -rw------- 1 sshuser admin 1024 Apr 6 01:28 prng_seed $ ls -ld drwxr--r-- 2 sshuser admin 512 Apr 6 01:17 .
( applicable to SSHv1)
(applicable to SSHv2)
By default each of these entries is commented out and ignored, as indicated by the "#" preceding each entry. The OpenSSH default is to allow public key authentication (and to use it first), so if this file has not been modified since the install, then your problem is not here. However, if either of the first two entries has been set to "no" or the default location of the authorized_keys file has been changed, this may be the source of the problem.
It should be noted that the "RSAAuthentication" setting applies for SSHv1, while "PubkeyAuthentication" applies for SSHv2 ” both can be allowed independently.
$ ssh server.example.com Connection closed by 192.168.121.6
$ ssh server.example.com Enter passphrase for key '/home/sshuser/.ssh/id_rsa': Enter passphrase for key '/home/sshuser/.ssh/id_rsa': email@example.com's password:
The first time your SSH client connects with an OpenSSH server you will be prompted to verify the authenticity of the server host key. If this is the first time the client system has connected to the specific server as the current user , then the message should be expected. If the message appears at a subsequent connection time, this may indicate some form of malicious activity.
It is recommended that the host key be verified via an alternate trusted communication channel, such as contacting a local administrator by phone, connecting to the same server from a different and already verified communication channel, or checking the cache of other client systems which have verified the host key. UNIX SSH clients typically store the cache in $HOME/.ssh/known_hosts (although this can be changed in the OpenSSH configuration) while PuTTY stores the cache in the Windows registry under the current user hive.
The SSH protocol cannot fully protect you if you fail to verify that you are connecting to the correct server with the authentic host key. It is important that administrators explain that connecting to server.example.com doesn't necessarily result in a connection to the expected server, if an attacker has succeeded in corrupting the IP routing or the DNS cache. Action 5.2.7 provides additional information and references.
Sample UNIX OpenSSH client:
$ ssh server.example.com The authenticity of host 'server.example.com (192.168.1.10)' can't be established. RSA key fingerprint is dd:7b:0d:55:f3:ca:b7:ad:2c:7f:d1:a5:ab:17:b5:67. Are you sure you want to continue connecting (yes/no)?
If this is not the first time you have connected to the server, you should consider the following questions, then re-verify the authenticity of the server host key, as if it were a first time connection.
It is strongly encouraged that you disable the usage of the SSHv1 protocol on all clients and server configurations and force usage of the SSHv2 protocol. The SSHv1 protocol has known deficiencies that increase the risk of insertion and man-in-the-middle attacks.
If you connect to an OpenSSH server and get a message indicating that the cached host key does not match, there are several things to consider carefully . Here is an example of one such occurrence:
$ ssh server.example.com @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 dd:7b:0d:55:f3:ca:b7:ad:2c:7f:d1:a5:ab:17:b5:67. Please contact your system administrator. Add correct host key in /home/sshuser/.ssh/known_hosts to get rid of this message. Offending key in /home/sshuser/.ssh/known_hosts:5 RSA host key for server.example.com has changed and you have requested strict checking. Host key verification failed.
It is possible that you are experiencing what is known as a man-in-the-middle (MITM) attack; however there are other possibilities. In any case, it is important that SSH users be aware of the possibilities and know how to respond to this message. It is also important that the answer be verified rather than assumed. Here are some other possibilities to consider when this message occurs:
See Julian Beling's GSEC practical for an excellent introduction to SSH MITM attacks. http://www.giac.org/practical/Julian_Beling_GSEC.doc Richard Silverman's reply to Dug Song's dsniff release is also good reading. http://sysadmin.oreilly.com/news/silverman_1200.html