I have commonly had a few problems when I’m setting up my SSH public keys on a new server. Here is a collection of steps to troubleshoot ssh key connectivity issues.
1. Check client-side permissions
The minimum permissions requirements for your ~/.ssh folder should be:
drwx—— 8 owner group 272 Sep 29 13:17 .
drwxr-xr-x 38 owner group 1292 Oct 2 04:47 ..
-rwx—— 1 owner group 2472 Dec 14 2009 authorized_keys
-rwx—— 1 owner group 1227 Mar 30 2010 config
-rw——- 1 owner group 1675 Dec 12 2009 id_rsa
-rw-r–r– 1 owner group 417 Dec 12 2009 id_rsa.pub
-rwx—— 1 owner group 18317 Oct 2 04:23 known_hosts
-rw-r–r– 1 owner group 45 Mar 16 2010 ssh_config
The maximum strictness recommend is:
chmod 700 ~/.ssh
chmod 600 *
To make all the files in .ssh read/write by owner. That’s about as strict as I would make it. I once read a suggestion to do chmod 400 * but then, if the target host doesn’t exist in the known_hosts file for your user, you will not be able to add to the known_hosts file unless your user is root and you use sudo or if you add it manually with sudo.
2. Funky formatting in authorized_keys
If you see this in your log file: buffer_get_ret: trying to get more bytes 4 than in buffer 0
Aug 12 14:39:07 admin sshd: error: buffer_get_ret: trying to get more bytes 4 than in buffer 0
Aug 12 14:39:07 admin sshd: fatal: buffer_get_int: buffer error
…Then all you have to do is remove the line break after ssh-rsa or ssh-dsa in the first line of your authorized keys file on the server for that pub key. It should NOT look like this:
Instead the entry should all be on a “single line” like this:
3. Check for SSH version mismatches
You can test the version of any SSH install from inside the server dialing in to localhost port 22 (unless sshd is running on a non-default port # which you will have to know beforehand by looking at the /etc/ssh/sshd_config) with telnet:
telnet localhost 22
or use the server hostname or IP address from the outside:
telnet server 22
Use Control + ] then type quit to get out of telnet.
4. Read Log Files
Logs are an excellent source of information for troubleshooting.
If you have server access without the key, then you can run tail -f /var/log/secure.log /var/log/auth.log
(which will get you the sshd logs for debian and centos – location has got to be one or the other) and you can actually watch the logs update if you leave that window open while you try to ssh from another window.
5. Check Config files
The least common place that I’ve had problems has been in the config files which are commonly located in /etc/ssh/
For one, you would want to check your sshd_config on the server to make sure that the server is configured to accept keys and you can turn up log level to DEBUG from INFO to get more information on the server side. Another good thing to check is to make sure that you know the port that sshd is listening on – default is port 22.
If all else fails… Make the ssh keys from scratch.
Now, if you’re really having trouble. Start from scratch. Clear out the ~/.ssh folders on your server and client. Then create a new .ssh folder and change the permissions to 700.
chmod ~/.ssh 700
On your client machine, generate a new ssh key and specify the .ssh directory in your home folder (every server should be using SSH 2.0 by now and everyone should be using at least 2048 bit long RSA keys instead of 1024 bit limited DSA keys):
ssh-keygen -t rsa -b 2048 -f ~/.ssh/
This will give you 2 key files – a public key (id_rsa.pub) which you will copy to the server’s authorized_hosts file and a private key (id_rsa) which you will keep in your .ssh folder with minimum permissions of 600.
You can avoid the funky formatting problem I mentioned above by transferring your key to the server first with SCP (…instead of being lazy and copying from one terminal window or program window to a server terminal.):
scp ~/.ssh/id_rsa.pub [email protected]:~/
And then running the following command to append the contents of your public key to the authorized keys file for your user:
chmod 700 ~/.ssh/authorized_keys
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
If that doesn’t work, generate the keys on the server using the same command as above, cat the contents of the public key you made into the server’s .ssh/authorized_keys file and then secure copy (scp) the private key (id_rsa) back to your client machine’s .ssh folder for your user. That’s gotta do the trick!