2 votes

"Parfois, j'obtiens "Permission denied (publickey)".

Contexte : ssh:ing à mon serveur ssh à partir de quelque part avec une clé (c.-à-d. pas de mot de passe), et parfois cela ne fonctionne pas.

Serveur : Ubuntu 16.04 LTS, entièrement patché. Serveur OpenSSH. Mots de passe et login root désactivés.

Clients : Essai avec le client OpenSSH OSX et le client OpenSSH Ubuntu 17.10.

La sortie de l'écran d'affichage de ssh -vvv "server" en cas d'échec (à partir d'OSX) :

debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:xxxx/E /Users/xxx/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51 <-- HERE, diff from success
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
xxx@yyy.zzz: Permission denied (publickey).

La sortie de l'écran d'affichage de ssh -vvv "server" lorsqu'il réussit (à partir d'OSX, cette fois-ci quelques minutes plus tard que l'échec ci-dessus) :

debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:xxx/E /Users/xxx/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60 <-- HERE, success, diff from fail
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:xxx/E
debug3: sign_and_send_pubkey: RSA SHA256:xxx/E
Enter passphrase for key '/Users/xxx/.ssh/id_rsa': 
debug1: identity added to agent: /Users/xxx/.ssh/id_rsa
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to yyy.zzz ([123.456.789.012]:22).

Et ils sont assez similaires, la différence se situe au niveau de cette ligne :

debug3: receive packet: type 51 (when failing)
debug3: receive packet: type 60 (when succeeding)

Cela m'amène à penser qu'il s'agit d'un problème au niveau du serveur. Dans l'article /var/log/auth.log Je trouve ces entrées :

Feb  7 09:30:59 server-name sshd[48527]: Connection closed by (client public IP) port 64050 [preauth] (the only mention of this connection attempt)
Feb  7 09:34:17 server-name sshd[48725]: Accepted publickey for yyy from (client public IP) port 64134 ssh2\: RSA SHA256:xxx/E (the succeeding attempt)

Il se passe donc quelque chose, mais je ne sais plus où j'en suis ? Des idées sur la façon de résoudre ce problème ?

Il pourrait s'agir d'une information pertinente : Le serveur ssh a une IP publique, et il y a environ dix (10) mauvaises tentatives de connexion ssh par minute (seul le port 22 est ouvert). Il semble que pendant quelques minutes après m'être connecté au serveur localement, il soit toujours possible de se connecter à distance via ssh. Le serveur se trouve derrière un pare-feu physique, avec le port 22 transféré, et le comportement est le même depuis mon sous-réseau local.

3voto

flindeberg Points 143

Après quelques essais, j'ai découvert que le problème était lié à un répertoire personnel crypté (que je n'avais pas du tout remarqué lors de l'installation, puisque je configurais plus de 10 VM par le biais de scripts).

Le fait que le serveur n'ait pas signalé qu'il n'était pas en mesure d'accéder au site est toujours déroutant. /home/userdir/.ssh/authorized_keys et n'a montré que :

Feb  7 09:30:59 server-name sshd[48527]: Connection closed by (client public IP) port 64050 [preauth] (the only mention of this connection attempt)

En général, il existe deux solutions :

  1. Décrypter le répertoire personnel (c'est compliqué, je ne le recommande pas). Cherchez des instructions sur Google. ecryptfs permanent decrypt obtient de bons résultats.
  2. Déplacer le authorized_keys en dehors de votre dossier personnel crypté afin qu'il soit accessible.

Puisque 1) est désordonné, je recommande 2).

Déménagement authorized_keys

Je recommande de créer une structure de répertoire sous /etc/ssh/ comme /etc/ssh/keys/%user/authorized_keys et en modifiant la ligne AuthorizedKeyFile dans le fichier /etc/ssh/sshd_config pour correspondre. Par exemple :

#original (%h expands to /home/userdir, which is encrypted)
AuthorizedKeysFile     %h/.ssh/authorized_keys
#new (%u expands to username)
AuthorizedKeysFile     /etc/ssh/keys/%u/authorized_keys

Après vous être connecté, vous devriez vous trouver dans un dossier personnel minimaliste sans contenu, exécutez ecryptfs-mount-private pour décrypter le dossier personnel (vous devrez entrer une phrase de passe, par défaut votre mot de passe). La façon la plus simple de contourner ce problème est d'ajouter un fichier .profile dans votre dossier personnel minimaliste qui se décrypte et vous envoie vers votre vrai dossier personnel.

# place in minimalistic .profile
ecryptfs-mount-private
# if below doesn't work, replace with static cd /home/userdir
cd $HOME

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X