« Connection closed by UNKNOWN port 65535 » lors de la connexion SSH avec des identifiants AD sur une machine RHEL

Windows Server & IT Pro Active Directory & Entra ID
1

Récemment, j’ai installé PAM et tous les paquets nécessaires pour activer l’authentification SSH via AD sur mes machines RHEL 7.5.

Quand j’essaie de me connecter en SSH avec « ssh utilisateur@nomdomaine@nomhôte », il me demande mon mot de passe et dès que je le tape, j’obtiens l’erreur : Connection closed by UNKNOWN port 65535.

Cela se produit sur plusieurs machines sous RHEL 7.5. sssd est utilisé pour se lier à AD, il n’y a pas de pare-feu, l’heure système est synchronisée avec le serveur AD, les groupes appropriés sont ajoutés à permitted_groups et le compte n’est pas verrouillé. L’examen de /var/log/secure montre les erreurs ci-dessous :

sshd[12752]: reprocess config line 145: Deprecated option RhostsRSAAuthentication
sshd[12752]: pam_krb5[12752]: account checks fail for 'user@domainname': user disallowed by .k5login file for 'user@domainname'
sshd[12752]: Failed password for user@domainname from ip port 53166 ssh2
sshd[12752]: fatal: Access denied for user user@domainname by PAM account configuration [preauth]

J’ai redémarré sssd et sshd sans succès.

Toute aide sera appréciée.

2

L’erreur SSH peu utile Connection closed by UNKNOWN port 65535 peut être signalée par votre client ssh dans plusieurs situations différentes lorsque le sshd distant ne peut pas du tout être atteint en raison de quelque chose qui se passe « au milieu ».

Cela peut être particulièrement difficile à déboguer car dans certains cas, le sshd distant n’a aucune idée que quelqu’un a essayé de s’y connecter.

(Aparté : 65535 est un nombre « spécial » pour les informaticiens car c’est 2^16 - 1, alias 0xFFFF – le nombre entier non signé maximum sur 16 bits (et aussi le numéro de port maximum))

Cas A – Interférence avant sshd

(De la question originale de @doug) - Dans ce cas, le sshd distant a reçu la connexion entrante et a délégué l’authentification aux bibliothèques Linux pour PAM (Pluggable Authentication Modules). PAM transmet à KRB5 ou SSS et cela échoue. Donc tout ce que le pauvre sshd distant reçoit est un gros NON de PAM. …il n’est jamais entré dans son analyse de protocole « normale » et la vérification d’erreurs qui lui aurait permis de retourner un message d’erreur plus utile.

(Il est possible que d’anciennes options de configuration Kerberos comme gssapiauthentication puissent se comporter de manière similaire)

De même, les tcp_wrappers (avec les fichiers hosts.allow et hosts.deny) sur le serveur peuvent « interférer » avec la connexion avant que sshd ne la voie.

Cas B – Pare-feu

Dans notre cas, nous avons vu cela lorsque les pare-feu réseau empêchaient les connexions depuis les machines de développement/test vers les machines de staging/production.
Selon votre réseau, vous pourriez obtenir plus d’informations de diagnostic avec tcping 22 $remote_hostname, ou (moins utile) : des tests réseau UDP comme ping $remote_hostname, traceroute $remote_hostname, ou les versions IPv6 de ces commandes. Vos ingénieurs réseau locaux peuvent aider à confirmer et corriger.

L’indice dans ce cas est que ssh -vvv $remote_hostname arrive à ce point :

debug1: identity file /home/ddickinson/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.6

…pause de 60 secondes (ou le délai configuré), puis :

kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535

Cas C – ProxyCommand

Certains types de défaillances du ProxyCommand auquel votre ssh local délègue peuvent également échouer de manière peu utile. Vérifiez les options liées à « proxy* » ou « tunnel* » dans la sortie de :

ssh -G $remote_hostname

Cas D – ControlPath / ControlMaster

(h/t @shockburner) Ces options de configuration du client SSH peuvent être merveilleuses quand elles fonctionnent, mais peuvent rendre le débogage plus douloureux quand elles échouent. Vérifiez ces valeurs dans la sortie de :

ssh -G $remote_hostname

Si Control Path/Master est configuré, le répertoire existe-t-il ? Est-il accessible en écriture ?

Nettoyage des ControlPaths ouverts :

ssh -O exit $remote_hostname

Recherche de ControlPaths orphelins/zombies :

ps -x -o 'pid,command' | grep -E '\bssh:? ' | grep -v grep
kill -s HUP <process id found above>

Supprimez tous les fichiers socket orphelins des emplacements ControlPath trouvés ci-dessus.