Linux – Can’t ssh into remote server unless I login locally on the server first

I find the best thing to do in these circumstances is to run the SSH daemon in debug mode. If you have access as root on the machine you can run:

# /usr/sbin/sshd -d -p 2222

and then you can use:

# ssh -p 2222 postgres@java7

and see what reason the server gives for rejecting the key.

So, just as i guessed: Your $HOME is actually within an encrypted container whic is only opened upon login. In order to let you into the system the sshd wants the public-key before it lets you in and thus is some kind of egg-chicken problem.

One option to dance around the problem is to put the .ssh/authorized_keys file into some other place via the following change to the /etc/ssh/sshd_config:

 AuthorizedKeysFile      /home/.ssh/%u

So, user joe has his public-keys in /home/.ssh/joe etc etc.

Another idea worth trying is to do something like this:

$> login
<os unlocks encrypted /home/joe>
$> cp .ssh/authorized_keys /tmp/
$> logout
<os locks encrypted /home/joe again>
$> mkdir /home/joe/.ssh/
$> cp /tmp/authorized_keys /home/joe/.ssh/

The idea is to pull the authorized_keys file out of the encrypted container (just like the first idea) and then place that unencrypted file at the right place. When you log into the system the OS then will mount your encrypted home as some kind of 'overlay' ontop of /home/joe, hiding the unencrypted .ssh/authorized_keys.

The third idea might involve some port-knocking: You trigger some kind of network-traffic to some secret port(s) with some secret data which then triggers the OS to unlock your encrypted home. After the knocking procedure you will be able to log into the system.

General disadvantage / things to consider: these ideas depend on how you have encrypted your $HOME. If the encryption needs your password to unencrypt the data then you have to provide it somehow.