Picky SSH

I recently deployed a production support app on Digital Ocean and I had it all working in root using this guide. Once done I could SSH into my server, or droplet as Digital Ocean likes to call it, and configure the server remotely.

However since this app relies on a git repo which might be used by other people in the future, the best practice is to setup another user on the droplet and let them access the droplet using the new user.

Oh no... Cut & paste, and your in trouble

My initial brilliant idea was to simply copy and paste my existing ./ssh directory from root user into the new user's directory, lets call the new user demo. The folder has the authorized_keys file which contains all the public keys for clients who will accessing demo on the droplet. So I can have root's ~/.ssh/authorized_keys containing my public key only (removing other clients keys) - which will only allow me to SSH into the droplet via ssh root@, and have demo's ~/.ssh/authorized_keys contain other people's keys (also mine) so that they can only access the droplet via ssh demo@ and not ssh root@ Very elegant, simple and straight forward.

Once I've pasted my ./ssh folder to demo and tried to SSH into demo and it kept asking me for a password. Turns out SSH could not read my .ssh folder because it belonged to some one else, root.

# ls -al
drwx------  2 root root 4096 Jul 16 03:42 .ssh

The same could be said about authorized_keys as well.

~/.ssh# ls -al
-rw------- 1 root root  796 Jul 16 03:42 authorized_keys

So after I changed the owner and group using chown -R demo .ssh and chgrp -hR demo .ssh, I SSHed into the droplet using demo@ and I meet with another error.

Permission denied (publickey).

Then I tried to see what was going on with the connection

 > ssh -v demo@
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/me/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/me/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

From the looks of things it is using the right authentication, my public key, and it keeps on trying to authenticate with it but can't... hmmm.

Then I had to SSH into the droplet via root to see /var/log/auth/log to have a clearer picture what was wrong. Then I found this line each time I tried connecting via demo@

Jul 16 20:50:45 droplet sshd[925]: error: key_read: uudecode AAA.... failed

When I did a more or cat on the authorized_keys it looked alright.

~/.ssh# more authorized_keys 
ssh-rsa AAAAB387dasfdJBHYGOY&(^R#(&^@N"KO!#"))
... me@notebook

ssh-rsa QABAA5@#($*JFSHHfwfhwoi)*U&#()QmJWQO34
... friend@notebook

But when I did a nano authorized_keys it looked like this:

ssh-rsa AAAAB387dasfdJBHYGOY&(^R#(&^@N"KO!#"))
... me@notebook

ssh-rsa QABAA5@#($*JFSHHfwfhwoi)*U&#()QmJWQO34... friend@notebook

As you can see the first key is text wrap while the second key continues on and is a single long line, in other words no text wrapping.

The solution

I simple deleted all the keys and recopied by keys from root's authorized_keys and paste it in (also added other clients keys as well). I had to use 2 open terminal for this, but if your savvy with Linux you could just use cat.

Now both keys are in 2 seperate lines in nano and I can SSH into the droplet using demo@

ssh-rsa AAAAB387dasfdJBHYGOY&(^R#(&^@N"KO!#"))... me@notebook

ssh-rsa QABAA5@#($*JFSHHfwfhwoi)*U&#()QmJWQO34... friend@notebook

Note: Doing a more will still show keys in text wrapped format. So the secret is to check it using nano.

- comments -

comments powered by Disqus