Here is another short one which was a gotcha to me: in my thread about user with network homedir in boot2docker, when I first tried to connect to it using ssh key pair authentication, it did not work:
raub@desktop:~$ ssh docker ducker@boot2docker.example.com's password: raub@desktop:~$
As you can see it tried to use password authentication, which was something I did not want it to do. I mean, I took the time to add an entry in my .ssh/config file to connect to that box. Why was it ignoring it? I tried cranking up the verbose in the ssh client,
ssh -vvv dockerand still did not see any clues... at least nothing that made sense to me. So, I decided to crank up verbose in the server (boot2docker) side:
docker@boot2docker:~$ sudo /usr/local/sbin/sshd -ddd -p 10022 debug2: load_server_config: filename /usr/local/etc/ssh/sshd_config debug2: load_server_config: done config len = 216 debug2: parse_server_config: config /usr/local/etc/ssh/sshd_config len 216 debug3: /usr/local/etc/ssh/sshd_config:50 setting AuthorizedKeysFile .ssh/autho$ ized_keys debug3: /usr/local/etc/ssh/sshd_config:115 setting Subsystem sftp /usr/lo$ al/libexec/sftp-server debug3: /usr/local/etc/ssh/sshd_config:122 setting UseDNS no [...]
And, yes, it will be spitting out all the verbose messages on that terminal. Those of you who had enough caffeine have noticed I am starting a sshd service on port 10022 so I can keep the standard sshd session running on 22. Then I just connect
ssh -p 10022 dockerto the new service and see what garbage comes back. To make a long story short (I said this was going to be a short article), the line we are interested on is
User ducker not allowed because account is locked
OK, why does it say ducker is locked? Well, the ducker entry in /etc/shadow looks like this
ducker:!:16834:0:99999:7:::
Note the exclamation mark. I originally created the ducker user by doing
adduser -D -u 1003 duckerbut did not create a password to the user; I thought I would not need it at that moment because I just wanted to try the key authentication. Now, take a look at other entries in /etc/shadow. The root one looks something like
root:*:13525:0:99999:7:::
As ducker, it has no password (very different than having a blank password), but instead of ! it has an *. If you change the ducker entry to
ducker:*:16834:0:99999:7:::it will still have no password but now you can login using ssh key authentication. And, setting a password for the same account will also work.
So, what is going on? It turns out the ! means the account is disabled/locked, which is why the ssh key pair authentication failed. Fun, huh?
Bottom Line
- We can create accounts (say, to run backup scripts) without password that can be reached using ssh key pair authentication. All we need to do is to remember to use * instead of !.
- Running sshd in debug mode can sometimes answer questions neither the log files nor ssh -vvv can.