Google Site SearchFN Site Search FN Blog Login FN Blog Login
Site Navigation:
 
 

SSH Troubleshooting

by Rick Stout on Sep 30, 2004

Introduction

Recently, a project I was working on was heavily dependent on SSH and keys, and due to the multitude of errors and requests I recieved, I felt it was necessary to pull together some helpful information for troubleshooting SSH connections and their corresponding keys. If you are having problems connecting to an SSH server, this guide should help you track down your problem, as well as prevent future problems. Follow the guide, while testing your connection after every step.

Check the Logs

less /var/log/secure
This will contain the logs pertaining to ssh authentication. It might be a good idea to turn on debuging in /etc/ssh/sshd_config to better clarify the problem. Add the following line to /etc/ssh/sshd_config
LogLevel DEBUG3
After making any change to the config file, restart the service.
service sshd restart
You can now view the connection attempts in the console by issuing:
tail -f /var/log/secure
To exit, just do a control+C

Verify the Keypair

ssh-keygen -y
This can be used to generate the public key for a known private key. By comparing the output of this command to what you believe to be the public key, you can determine if the key's match. For Example:
[user@linux .ssh]$ ssh-keygen -y
Enter file in which the key is (/home/user/.ssh/id_rsa): /home/user/.ssh/id_dsa
[KEY Here......................................
.
.
.................................. ]
[user@linux .ssh]$ cat /home/user/.ssh/id_dsa.pub
[KEY Here......................................
.
.
.................................. ] user@linux
Verify that most of the numbers look ok. The odds of two keys being off by only a few numbers are very small. The error would be blatant. If the key's do not match (or do not exist), generate new key's. See Generating New Key's at the end of this article.

Check Your Permissions!

SSH is very picky about permissions, so be sure that your user has the correct rights to the files. The most important files are located in ~/.ssh
# Do these as root. This assumes that your user's name is user,
# so you should change the name accordingly.
chown user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chown user:user /home/user/.ssh/*
chmod 640 /home/user/.ssh/*
# These files may not exist
chmod 600 /home/user/.ssh/identity
chmod 600 /home/user/.ssh/id_dsa
chmod 600 /home/user/.ssh/id_rsa

Check the Settings in sshd_config

nano -w /etc/ssh/sshd_config
This file contains the settings used by the SSH Daemon. Any line preceded by a "#" is commented out and shows the default setting. For Example:
#Port 22
Means that no change has been made from the default, and the default is Port 22 for SSH connections. Look through the file for the following settings, and note their values. The defaults are listed here.
#AuthorizedKeysFile   .ssh/authorized_keys2
#PasswordAuthentication   yes
For troubleshooting purposes you should comment out the lines. Also look for:
AllowUsers
If that line is present, make sure that your user's name is listed. (If its not listed, you can add it for extra security.) For Example:
AllowUsers user user1 user2
Remember to restart the service:
service sshd restart

Problems Still?

These steps should help you get an SSH session up and running using key authentication. You should be able to track any further problems from the log file, but if you follow these directions, most problems you could face should be mitigated.


Generating New Keys

# This is to be done as a normal user. I'm using DSA keypairs for an example.
ssh-keygen -t DSA
# This will create two files: ~/.ssh/id_dsa and ~/.ssh/id_dsa.pub
# You can optionally create a passphrase for the keys, as an added level of security.
# Copy the public key to your authorized_keys2 file.
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys2
# Copy the id_dsa to your client machine
# mv id_dsa .ssh/id_dsa
# chmod 600 .ssh/id_dsa