Step 5 2 Troubleshooting Common OpenSSH Errors Problems

Action 5 2 1 Receiving Connection refused error when attempting to connect

$ ssh server.example.com
 ssh: connect to host server.example.com port 22: Connection refused

1. Make sure that the sshd daemon is running on the OpenSSH server and that it is functional on the network. For example, to verify from an SSH client that the sshd daemon is functional:

   $ 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.

2. Make sure that the OpenSSH Server is listening on the standard port 22. If possible, check the /usr/local/etc/sshd_config on the OpenSSH server to determine if a different port is being used to run the sshd daemon. If the default port 22 has been changed on the OpenSSH server, you will also need to modify the default port in the client's /usr/local/etc/ssh_config file. If you don't want to change the ssh_config file permanently, another option is to specify the OpenSSH server's port number as a flag to the client's ssh command. For example:

   $ ssh server.example.com -p 1212
   

3. Check to see if the OpenSSH server is also running TCP Wrappers “ and perhaps you have been denied access? If this is the case, there should be messages in the OpenSSH server's syslog indicating so. Also, check for the presence and contents of /etc/host.deny and /etc/host.allow files.

Action 5 2 2 Receiving permission denied error when attempting to connect using standard UNIX authentication

$ ssh server.example.com
 [e-mail]'s password: ********
 Permission denied, please try again.
 [e-mail]'s password: ********

1. Did you mistype the account or password name ? Is the "Caps Lock" key toggled on?
2. Verify that the account to which you are attempting to connect on the OpenSSH server is active on the server and that the password has not expired or the account deactivated for whatever reason.
3. Did anyone else use this account and/or know the password? If so, verify that it has not been changed.

Action 5 2 3 Receiving password prompt when expecting public key passphrase prompt

Receiving:

$ ssh server.example.com
 [e-mail]'s password:

Expecting:

$ 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)

1. Make sure that the authorized_keys file is in the proper location, $HOME/.ssh/authorized_keys , on the OpenSSH server (if the $HOME/.ssh/authorized_keys file exists, the OpenSSH server will, by default, try public key authentication first - see man page for sshd).
2. Make sure that the corresponding private key exists on the client from which you are connecting.
3. Make sure the owner of the $HOME/.ssh/authorized_keys file is the account to which you are attempting to connect.
4. Make sure that the permissions of the $HOME/.ssh directory and the authorized_keys file do NOT allow "write" privileges by " group " or "other". For example:

   $ 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 .
   

5. Check the OpenSSH server's sshd_config file, located by default in /usr/local/etc/sshd_config . There are 3 entries in this file that can affect the availability/functionality of public key authentication:

   RSAAuthentication yes	( applicable to SSHv1)
   PubkeyAuthentication yes	(applicable to SSHv2)
   AuthorizedKeysFile	.ssh/authorized_keys

   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.

Action 5 2 4 Getting immediate disconnect when attempting connection

$ ssh server.example.com
 Connection closed by 192.168.121.6

1. Check the OpenSSH servers' $HOME/.ssh/authorized_keys file and make sure that there are no carriage -returns imbedded within the individual public key string - each public key entry must be one-continuous line. The only carriage-returns should be between public key entries.

Action 5 2 5 Passphrase is no longer valid and you know you didn t change it

$ ssh server.example.com
 Enter passphrase for key '/home/sshuser/.ssh/id_rsa':
 Enter passphrase for key '/home/sshuser/.ssh/id_rsa':
 [e-mail]'s password:

1. Do others share this account with you? (Hopefully not!)
2. Check the $HOME/.ssh/authorized_keys file to make sure it has not been tampered with or accidentally modified. If the file has been modified, you will need to remove or correct any wrong entries or in worst case, you may need to use "ssh-keygen" to generate a new public/private key pair.

Action 5 2 6 Unexpected Host Key not cached

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.

1. Is it possible previous connections were from a different client?
2. Is it possible previous connections were from a different user login on the client?
3. Is it possible the SSH key cache has been cleared for legitimate administrative reasons such as the user account being recreated, or the home directory or user registry has been cleaned out?
4. Has the name or IP address of the server changed?
5. Is the SSH client connecting with a different protocol (SSHv1 vs. SSHv2) than previously? This could be happening incidentally, as specified by the user, or forced as part of an attack. To verify, check the PuTTY event logs or re-run the UNIX SSH client with the “v (verbose) option.

Important Recommendation  

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.

Action 5 2 7 Cached Host Key does not match

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:

1. Someone has upgraded the OpenSSH server and regenerated the host keys in the process.
2. A different server is answering to the name and/or IP address due to intentional administrative changes or server load balancing.
3. The SSH connection has been redirected to another server, possibly with malicious intent. The MITM attack can be accomplished by attacks at different protocol levels, including DNS, IP routing and ARP.

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