Le serveur OpenSSH refuse d'accepter l'authentification par clé tant que l'utilisateur n'est pas connecté localement au serveur

Alors, comme je le pressentais : Votre $HOME se trouve en fait dans un conteneur chiffré qui n'est ouvert qu'au moment de la connexion. Afin de vous laisser accéder au système, le sshd souhaite la clé publique avant de vous laisser entrer, créant ainsi une sorte de problème de l’œuf et de la poule.

Une option pour contourner ce problème est de déplacer le fichier .ssh/authorized_keys vers un autre endroit en apportant la modification suivante au fichier /etc/ssh/sshd_config :

 AuthorizedKeysFile      /home/.ssh/%u

Ainsi, l'utilisateur joe a ses clés publiques dans /home/.ssh/joe, etc.

Une autre idée intéressante à essayer est la suivante :

$> login

$> cp .ssh/authorized_keys /tmp/
$> logout

$> mkdir /home/joe/.ssh/
$> cp /tmp/authorized_keys /home/joe/.ssh/

L'idée est d'extraire le fichier authorized_keys du conteneur chiffré (comme dans la première idée) et de placer ce fichier non chiffré à l'endroit approprié. Lorsque vous vous connectez au système, le système d'exploitation montera ensuite votre home chiffré comme une sorte de 'superposition' sur /home/joe, cachant le .ssh/authorized_keys non chiffré.

La troisième idée pourrait impliquer du port knocking : Vous déclenchez un type de trafic réseau vers certains ports secrets avec des données secrètes qui déverrouillent ensuite votre home chiffré. Après la procédure de knocking, vous pourrez vous connecter au système.

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