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.
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.
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.
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:
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
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
~/.ssh/id_rsa.pub contents matches Server2's
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='/usr/sbin/sshd' debug1: rexec_argv='-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:
Permission denied (publickey,password)
- After rebooting the host
- After the host terminal crashes
- After establishing a
- After restarting the ssh service (only works sometimes)
The only possible method for achieving a successful login is to authenticate via password first.
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.