Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

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

ayi

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 :
<pre><code class="lang-auto">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]

</code></pre>
J’ai redémarré sssd et sshd sans succès.
Toute aide sera appréciée.

ayi_2

L’erreur SSH peu utile <code>Connection closed by UNKNOWN port 65535</code> peut être signalée par votre client <code>ssh</code> dans plusieurs situations différentes lorsque le <code>sshd</code> 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 <code>2¹⁶ - 1</code>, alias <code>0xFFFF</code> – le nombre entier non signé maximum sur 16 bits (et aussi le numéro de port maximum))
<h2><a name="p-33016-cas-a-interfrence-avant-sshd-1" class="anchor" href="#p-33016-cas-a-interfrence-avant-sshd-1" aria-label="Heading link"></a>Cas A – Interférence avant <code>sshd</code></h2>
(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 <code>hosts.allow</code> et <code>hosts.deny</code>) sur le serveur peuvent « interférer » avec la connexion avant que sshd ne la voie.
<h2><a name="p-33016-cas-b-pare-feu-2" class="anchor" href="#p-33016-cas-b-pare-feu-2" aria-label="Heading link"></a>Cas B – Pare-feu</h2>
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 <code>tcping 22 $remote_hostname</code>, ou (moins utile) : des tests réseau UDP comme <code>ping $remote_hostname</code>, <code>traceroute $remote_hostname</code>, 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 <code>ssh -vvv $remote_hostname</code> arrive à ce point :
<pre><code class="lang-auto">debug1: identity file /home/ddickinson/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.6

</code></pre>
…pause de 60 secondes (ou le délai configuré), puis :
<pre><code class="lang-auto">kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535

</code></pre>
<h2><a name="p-33016-cas-c-proxycommand-3" class="anchor" href="#p-33016-cas-c-proxycommand-3" aria-label="Heading link"></a>Cas C – ProxyCommand</h2>
Certains types de défaillances du <code>ProxyCommand</code> auquel votre <code>ssh</code> 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 :
<pre><code class="lang-auto">ssh -G $remote_hostname

</code></pre>
<h2><a name="p-33016-cas-d-controlpath-controlmaster-4" class="anchor" href="#p-33016-cas-d-controlpath-controlmaster-4" aria-label="Heading link"></a>Cas D – <code>ControlPath</code> / <code>ControlMaster</code></h2>
(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 :
<pre><code class="lang-auto">ssh -G $remote_hostname

</code></pre>
Si Control Path/Master est configuré, le répertoire existe-t-il ? Est-il accessible en écriture ?
Nettoyage des ControlPaths ouverts :
<pre><code class="lang-auto">ssh -O exit $remote_hostname

</code></pre>
Recherche de ControlPaths orphelins/zombies :
<pre><code class="lang-auto">ps -x -o 'pid,command' | grep -E '\bssh:? ' | grep -v grep
kill -s HUP <process id found above>

</code></pre>
Supprimez tous les fichiers socket orphelins des emplacements ControlPath trouvés ci-dessus.