2

Context: ssh:ing to my ssh server from somewhere with key (i.e. not passwd), and sometimes it doesn't work.

Server: Ubuntu 16.04 LTS, fully patched. OpenSSH server. Passwords and root login disabled.

Clients: Tried with OSX OpenSSH client and Ubuntu 17.10 OpenSSH client.

Trailing output of ssh -vvv "server" when failing (from OSX):

debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:xxxx/E /Users/xxx/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51 <-- HERE, diff from success
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
xxx@yyy.zzz: Permission denied (publickey).

Trailing output of ssh -vvv "server" when succeeding (from OSX, this one a couple of min later than the failing one above):

debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:xxx/E /Users/xxx/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60 <-- HERE, success, diff from fail
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:xxx/E
debug3: sign_and_send_pubkey: RSA SHA256:xxx/E
Enter passphrase for key '/Users/xxx/.ssh/id_rsa': 
debug1: identity added to agent: /Users/xxx/.ssh/id_rsa
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to yyy.zzz ([123.456.789.012]:22).

And they are quite similar, the difference is at this line:

debug3: receive packet: type 51 (when failing)
debug3: receive packet: type 60 (when succeeding)

This leads me to believe it is a server side issue. In /var/log/auth.log I find these entries:

Feb  7 09:30:59 server-name sshd[48527]: Connection closed by (client public IP) port 64050 [preauth] (the only mention of this connection attempt)
Feb  7 09:34:17 server-name sshd[48725]: Accepted publickey for yyy from (client public IP) port 64134 ssh2\: RSA SHA256:xxx/E (the succeeding attempt)

So there is something happening, but now I'm stumped? Any ideas on how to solve this?

Could be relevant info: The ssh server has a public IP, and there are roughly ten (10) bad ssh connection attempts a minute (only port 22 is open). It seems that for a couple of minutes after I've logged onto the server locally it is always possible to log on remote via ssh. The server sits behind a physical firewall, with port 22 forwarded, and the behaviour is the same from my local subnet.

2

After messing around a bit I've found the issue to be connected to an encrypted home-directory (which I completely missed during setup since I was setting up 10+ VMs through scripts).

Still confusing that the server did not log that it was not able to access /home/userdir/.ssh/authorized_keys, and only showed:

Feb  7 09:30:59 server-name sshd[48527]: Connection closed by (client public IP) port 64050 [preauth] (the only mention of this connection attempt)

In general there are two solutions:

  1. Decrypt the home directory (this is messy, I would not recommend it). Google it for instructions. ecryptfs permanent decrypt gets good results.
  2. Move the authorized_keys outside of your encrypted home folder so it is accessible.

Since 1) is messy I would recommend 2).

Moving authorized_keys

I would recommend creating a directory structure under /etc/ssh/ like /etc/ssh/keys/%user/authorized_keys and changing the AuthorizedKeyFile line in /etc/ssh/sshd_config to match. I.e.:

#original (%h expands to /home/userdir, which is encrypted)
AuthorizedKeysFile     %h/.ssh/authorized_keys
#new (%u expands to username)
AuthorizedKeysFile     /etc/ssh/keys/%u/authorized_keys

After logging in now you should be in a minimalistic home-folder with no contents, run ecryptfs-mount-private to decrypt home-folder (you will need to enter passphrase, by default your password). Easiest way to get around this is adding a .profile in your minimalistic home-folder which decrypts and sends you on to your real home-folder.

# place in minimalistic .profile
ecryptfs-mount-private
# if below doesn't work, replace with static cd /home/userdir
cd $HOME

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.