2 votes

Problème SSH étrange - Un seul hôte ne me permet pas de me connecter par nom

Quelqu'un peut-il m'expliquer cela, car j'ai tout fait, de la régénération des clés à la "sortie" et à la réintégration du domaine (Centrify) pour un hôte SSH auquel je ne parviens pas à accéder avec un seul client. Tous les autres clients sont capables d'accéder à cet hôte, sauf un. Pourtant, bizarrement, je peux accéder à l'hôte par SSH depuis le client si j'utilise l'adresse IP :

$ ssh ddecker@host
Connection closed by 10.0.0.250
$ ssh ddecker@10.0.0.250
Password:
[ddecker@host ~]$

La seule chose que j'ai sur ce sujet est dans /var/log/messages sur l'hôte, j'obtiens ce qui suit lorsque j'essaie d'utiliser le nom d'hôte :

fatal: accept_ctx died [preauth]

J'ai essayé de supprimer /etc/krb5.keytab, mais Centrify ne démarre pas ; j'ai donc rétabli la situation. Je ne sais vraiment pas ce qui se passe et pourquoi tous les autres clients peuvent se connecter par leur nom alors que ce client ne peut se connecter que par IP.

UPDATE #1 :

Voici la sortie de ssh -v ddecker@host :

debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config
debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to host [10.0.0.250] port 22.
debug1: Connection established.
debug1: identity file /home/ddecker/.ssh/id_rsa type 1
debug1: identity file /home/ddecker/.ssh/id_rsa-cert type -1
debug1: identity file /home/ddecker/.ssh/id_dsa type -1
debug1: identity file /home/ddecker/.ssh/id_dsa-cert type -1
debug1: identity file /home/ddecker/.ssh/id_ecdsa type -1
debug1: identity file /home/ddecker/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: Offering GSSAPI proposal: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Doing group exchange

debug1: Calling gss_init_sec_context
debug1: Delegating credentials
Connection closed by 10.0.0.250

1voto

snowdude Points 2790

Déboguer AD/Kerberos Centrify est toujours ennuyeux.

Vous pouvez essayer d'activer le débogage Centrify sur votre serveur avec /usr/share/centrifydc/bin/addebug on . Sachez que cela peut créer des fichiers journaux très volumineux, et potentiellement conduire à des volumes pleins s'ils restent activés trop longtemps.

Vérifiez les SPN et les KVNO.

Obtenir la liste des principes et des KVNO à partir du keytab local sur votre serveur. Ceci peut nécessiter que le paquet RPM des utilitaires du client Kerberos soit installé sur un serveur Linux (yum install krb5-workstation).

klist -kte 

Comparez cela avec le KVNO Kerberos tel que déterminé par votre AD. A partir d'un autre système Centrify enebales Linux : (Nécessite une session de connexion Kerberos active initiée avec "kinit", vérifiez avec klist si vous avez un ticket kerberos valide (granting ticket)) Le mieux est de le faire depuis un autre hôte que celui qui rencontre des problèmes. SSH utilise le principal de l'hôte.

kvno host/hostname
kvno host/hostname.domain.name

Si les deux commandes ci-dessus renvoient des KVNO différents de ceux trouvés avec klist pour le même principe, alors typiquement le fichier keytab local sur le serveur UNIX nécessite une réinitialisation. La réinitialisation du fichier keytab local lorsqu'il n'est pas synchronisé avec le KDC dans AD se fait à partir de la ligne de commande de l'hôte concerné et nécessite les privilèges root.

adkeytab -r -u <username>

ou utiliser les informations d'identification du compte de l'ordinateur local au lieu de l'utilisateur AD privilégié ci-dessus.

adkeytab -r -m

1voto

Jim B Points 3121

Les symptômes suggèrent que kerberos est cassé pour un client. Si vous utilisez un ssh via IP, kerberos n'est généralement pas impliqué.

La cause la plus courante d'un échec de Kerberos pour un client est que l'heure n'est pas synchronisée sur ce client. Kerberos exige que tous les hôtes concernés aient leurs horloges système à peu près synchronisées.

/bin/date 

sur le client et le serveur doivent être à quelques secondes l'un de l'autre.

1voto

Vladimir Points 123

Alors merci à tous ceux qui m'ont donné des recommandations. Mais j'ai fini par trouver le problème. J'avais écrit une simple attente script qui copie essentiellement ma clé SSH sur chaque serveur, et il sait quels sont les serveurs par un simple fichier.

Je n'ai vu aucune erreur, mais pour cet hôte, il semble qu'une entrée de "known_hosts" soit entrée en conflit avec ma clé SSH, et la connexion a été interrompue. J'ai supprimé le fichier known_hosts (tout ce que j'avais à faire était de supprimer le seul élément dans known_hosts), puis j'ai réessayé ma connexion - et l'accès m'a été accordé.

Une réparation simple, mais les erreurs ne m'aidaient pas ou ne me dirigeaient pas vers une réparation évidente.

Merci !

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