Le serveur OpenSSH refuse d'accepter l'authentification par clé à moins d'être connecté au serveur localement

Mon serveur exécute Ubuntu-Server et OpenSSH-Server y est installé. J'ai configuré le fichier / etc / ssh / sshd_config pour qu'il accepte et exige des clés rsa. Il recherche les clés dans le fichier 'AuthorizedKeys ~ / .ssh / registered_keys'. Dans ce fichier, j'ai deux clés publiques distinctes, une créée à l'aide de mastic que j'utilise avec WinSCP et une créée à partir du client Secure Shell.

Mon problème est que je dois me connecter en tant qu'utilisateur sur le serveur avant que l'authentification ne fonctionne. Si je dois redémarrer le serveur à distance, puis essayer de ssh, je reçois une erreur me disant que ma clé n'a pas pu être authentifiée et que mon accès est refusé. Dès que j'arrive et que je me connecte au serveur localement, je peux ensuite entrer ssh à distance tant que cet utilisateur reste connecté.

Avez-vous une idée de ce que je peux faire de mal ici? Je pense avoir mal configuré mon paramètre Authorized_Keys dans le fichier / etc / ssh / sshd_config

Donc, comme je l’ai bien deviné: votre $ HOME est en fait dans un conteneur crypté qui n’est ouvert que lors de la connexion. Afin de vous laisser entrer dans le système, sshd veut la clé publique avant de vous laisser entrer et constitue donc un problème de type œuf-poulet.

Une option pour danser sur le problème est de mettre le .ssh/authorized_keys déposer dans un autre endroit via le changement suivant à la /etc/ssh/sshd_config:

 AuthorizedKeysFile      /home/.ssh/%u

Alors, utilisateur joe a ses clés publiques dans /home/.ssh/joe etc.

Une autre idée à essayer est de faire quelque chose comme ceci:

$> 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/

L'idée est de tirer le authorized_keys fichier hors du conteneur chiffré (comme la première idée), puis placez ce fichier non chiffré au bon endroit. Lorsque vous vous connectez au système, le système d’exploitation monte alors votre maison cryptée comme une sorte de «superposition» de /home/joe, cachant le non crypté .ssh/authorized_keys.

La troisième idée pourrait impliquer un portage de port: vous déclenchez une sorte de trafic réseau vers un ou plusieurs ports secrets contenant des données secrètes qui déclenchent ensuite le système d'exploitation pour déverrouiller votre domicile crypté. Après la procédure de frappe, vous pourrez vous connecter au système.

Inconvénient général / points à prendre en compte: ces idées dépendent de la manière dont vous avez crypté votre $ HOME. Si le cryptage nécessite votre mot de passe pour crypter les données, vous devez le fournir d'une manière ou d'une autre.