0

I have had key-paired logins "working" on my servers for a while now, however one of them has always had problems and it has finally gotten to the point where it is interfering with certain tasks.

The situation:

Host is my PC that I am using to ssh to the servers. Server1 was set up first and has a working ssh public-key authentication setup. Server2 was set up after Server1 and has had login issues from the start. The same username is used for all three. All three computers have encrypted home directories.

The problem:

When you attempt to SSH into Server2 from Host, after Host has been rebooted/restarted you will be prompted for a password, if you enter the password and continue you will be able to ssh without any problems as long as Host does not reboot. After any reboot you will need to re-enter the password.

This can sometimes be avoided if you ssh with the -vvv tag. Under this condition you do not need to enter a password on the first login, but all subsequent SSH attempts require a password.

Testing:

I have been using: ssh -o PreferredAuthentications=publickey Server2 to test connectivity using publickey access only between Host and Server2. I will use the results of these test rather than the -vvv output tests since it is shorter. I have compared the -vvv output of sshing to Server2 and the functioning Server1 and the only noticable area of divergence is in the following area:

For Server1:

debug1: Offering RSA public key: /home/USER/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279

For Server2:

debug1: Offering RSA public key: /home/USER/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password

The Host ~/.ssh/id_rsa.pub contents matches Server2's ~/.ssh/authorized_keys file.

The ssh_config and sshd_config files are identical between Server1 and 2.

The contents and permissions of ~/.ssh on Server2:

total 56
drwx------ 2 USER USER 4096 Jul  1 17:59 .
drwx------ 6 USER USER 4096 Jun 30 11:50 ..
-rw------- 1 USER USER  391 Apr 28 17:31 authorized_keys
-rw------- 1 USER USER 1679 Jun 30 14:51 id_rsa
-rw-r--r-- 1 USER USER  394 Jun 30 14:51 id_rsa.pub
-rw-r--r-- 1 USER USER  442 Jun 30 10:32 known_hosts

The last three files are there because this server needs to be able to ssh to another server.

The results of /usr/sbin/sshd -d on Server2 are:

debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: key_load_private: Permission denied
Could not load host key: /etc/ssh/ssh_host_rsa_key
debug1: key_load_private: Permission denied
Could not load host key: /etc/ssh/ssh_host_dsa_key
debug1: key_load_private: Permission denied
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
debug1: key_load_private: Permission denied
Could not load host key: /etc/ssh/ssh_host_ed25519_key
debug1: setgroups() failed: Operation not permitted
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Permission denied.
debug1: Bind to port 22 on ::.
Bind to port 22 on :: failed: Permission denied.
Cannot bind any address.

This is identical to the output for Server1.

The results of the tests using ssh -o PreferredAuthentications=publickey Server2 are as follows:

Failed login: Permission denied (publickey,password)

  • After rebooting the host
  • After the host terminal crashes
  • After establishing a -vvv ssh connection
  • After restarting the ssh service (only works sometimes)

The only possible method for achieving a successful login is to authenticate via password first.

Solution attempts:

Encrypted home directory workaround. Failed. User was able to ssh in without providing a password, however the session required the home directory to be unencrypted (which Server1 does not require), and the .profile and associated files were not properly used.

How do I allow this server to accept key-paired ssh sessions? It should be setup identical to Server1 in regards to the ssh service. I've been looking over logs and outputs for a while now so maybe a fresh set of eyes can spot something I've missed.

EDIT: Now the first login after rebooting the machine is successful, but a subsequent login attempt requires a password. If the password is provided on the second attempt all following attempts will work.

  • look perhaps at /etc/ssh/config_sshd – Pascal Fares Jul 2 '17 at 7:01
  • Have you maybe set a password to unlock the key itself while generating it? – derHugo Jul 2 '17 at 8:06
  • @PascalFares /etc/ssh/sshd_config is identical between Server1 and 2. @derHugo That doesn't seem to be the case. Running ssh-keygen -y does not prompt me for a password. – K G Jul 2 '17 at 19:07
1

Because of your encrypted home, you should modify your sshd_config from Server2 like this:

Set

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

And put your authorized_keys file under /etc/ssh/USERNAME/

When you want this only be valid for special user, than you can combine it with Match like this:

Match User myuser
  AuthorizedKeysFile    /etc/ssh/my_authorized_keys

One note left: your home directory get not decrypted without password. Hope this helps ;-) But your pam module should query you for the password.

  • I've tried this solution already, while it does allow me to ssh without a password, it doesn't automatically unencrypt my home directory like my connection to Server1. I did use USER rather than %u in the sshd_config file so that may have something to do with it? – K G Jul 2 '17 at 20:12
  • Well ... obvikously. You can decrypt the home only with your password and if you skip this step, it is still encrypted. The %u is just a substitution for username in ssh configuration. The easiest solution is to disable home encryption. – Jakuje Jul 3 '17 at 7:38
  • Disabling the home folder encryption ended up being the key. I had accidentally set it up on Server2 and forgot to note it. Thank you for the help. – K G Jul 29 '17 at 16:27

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.