"Connexion fermée par [Host IP]" à l'aide de l'authentification par clé dsa
J'ai une configuration partagée/à la maison utilisant le logiciel Perceus Cluster ( http://perceus.org ) pour notre cluster. Les nœuds utilisent CentOS 6.1 x86_64. /Home est partagé de la tête vers les nœuds par nfs (NFSv4).
root@head~]$ cat /etc/exports
/var/lib/perceus/ 10.10.10.0/255.255.255.0(ro,no_root_squash,async)
/home/ 10.10.10.0/255.255.255.0(rw,no_root_squash,no_all_squash,async)
Voici le fichier/etc/fstab sur chaque nœud (tous identiques).
...
10.10.10.2:/var/lib/perceus/ /var/lib/perceus/ nfs ro,soft,bg 0 0
10.10.10.2:/home/ /home nfs rw,soft,bg 0 0
/ etc/fstab sur les nœuds est une copie de l’en-tête/maître avec un UID identique: GID.
J'ai créé des paires de clés en utilisant la méthode suivante:
$ cd ~
$ rm -rf .ssh
$ mkdir .ssh
$ chmod 700 .ssh
$ ssh-keygen -t dsa -P ""
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa):
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
[SNIPPED] user@head
The key's randomart image is:
+--[ DSA 1024]----+
[SNIPPED]
$ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
$ chmod 400 ~/.ssh/authorized_keys
Voici le problème. Lorsque j'essaie de ssh dans chaque nœud, je reçois une "connexion fermée" erreur. Voici la sortie de débogage.
$ ssh node01
Connection closed by 10.10.10.101
$ ssh node01 -vvv
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to node01 [10.10.10.101] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug3: Not a RSA1 key file /home/user/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
.... SNIPPED ...
debug2: dh_gen_key: priv key bits set: 139/256
debug2: bits set: 482/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: Wrote 144 bytes for a total of 981
debug3: check_Host_in_hostfile: filename /home/user/.ssh/known_hosts
debug3: check_Host_in_hostfile: match line 1
debug3: check_Host_in_hostfile: filename /home/user/.ssh/known_hosts
debug3: check_Host_in_hostfile: match line 1
debug1: Host 'node01' is known and matches the RSA Host key.
debug1: Found key in /home/user/.ssh/known_hosts:1
debug2: bits set: 501/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: Wrote 16 bytes for a total of 997
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug3: Wrote 48 bytes for a total of 1045
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user/.ssh/identity ((nil))
debug2: key: /home/user/.ssh/id_rsa ((nil))
debug2: key: /home/user/.ssh/id_dsa (0x7f79b940f650)
debug3: Wrote 64 bytes for a total of 1109
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
... [SNIPPED]...
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug3: no such identity: /home/user/.ssh/identity
debug1: Trying private key: /home/user/.ssh/id_rsa
debug3: no such identity: /home/user/.ssh/id_rsa
debug1: Offering public key: /home/user/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 528 bytes for a total of 1637
debug1: Server accepts key: pkalg ssh-dss blen 434
debug2: input_userauth_pk_ok: SHA1 fp 46:a2:c3:86...........
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type DSA
debug3: Wrote 592 bytes for a total of 2229
Connection closed by 10.10.10.101
Je me suis assuré que/etc/ssh/sshd_config permet l’authentification basée sur une clé (PubkeyAuthentication yes). Je me suis assuré que les autorisations sur/home (une fois monté sur les nœuds) étaient correctes. Les utilisateurs sont correctement authentifiés. J'ai essayé le montage nfs avec et sans "no_all_squash" en redémarrant nfs, rpcidmap, rpcbind et nfslock.
J'ai eu ce travail avec CentOS5 installé sur les nœuds avec un nœud maître/tête différent. CentOS6 semble juste me donner des problèmes supplémentaires avec ceci.
Si je ne crée pas la clé, je suis bien sûr invité à saisir un mot de passe.
Mes hosts.allow/deny sont vides sur les clients et le serveur.
L'utilisateur root peut se connecter. Perceus gère la génération de clé pour l'utilisateur root car elle fait partie du système de fichiers virtuel. Je devine que quelque chose ne va pas avec la génération de ma clé mais je ne peux pas comprendre quel est le problème.
La solution correcte consiste à résoudre le problème, pas à désactiver l’utilisation de pam, car vous pourriez cacher un problème de sécurité.
ssh échoue parce que PAM refuse la connexion de l'utilisateur en échouant. Vérifiez le /etc/pam.d/sshd pour connaître les règles que vous avez et ce qui pourrait échouer.
le problème le plus courant est un utilisateur sans mot de passe (comparez le /etc/passwd avec le /etc/shadow ou vérifiez votre /etc/nsswitch et votre /etc/pam.d/* pour voir d'où viennent les utilisateurs et l'auth), mais aussi sans répertoire de base, il manque une configuration d'auth supplémentaire, un UID trop bas ou trop haut, etc.
Si c'est le mot de passe manquant, assurez-vous au moins que cela est indiqué dans le /etc/ssh/sshd_config
PermitEmptyPasswords no
Cela bloque ssh pour autoriser la connexion sur les utilisateurs sans mot de passe (mais ne fait rien aux autres protocoles, tels que telnet, ftp, http et login).
SOLUTION:
En suivant les conseils ci-dessous, j'ai vérifié /var/log/security sur le nœud (hôte). Cela montrait:
fatal: Access denied for user user by PAM account configuration
J'ai ensuite édité /etc/ssh/sshd_config en changeant:
UsePAM yes
à
UsePAM no
J'ai redémarré le nœud et je peux maintenant effectuer des connexions sans mot de passe.
Merci!
J'ai eu un problème très similaire au vôtre.
Il s’avère que mon problème, et peut-être le vôtre, a été causé par le fait que mon répertoire personnel est un montage NFS et que selinux (sur CentOS 7) génère des erreurs (assez difficiles à détecter). La solution était simple cependant.
setsebool -P use_nfs_home_dirs 1
Il n'est pas bon d'utiliser une autorisation sans mot de passe. Selinux est-il activé sur ces serveurs? Si tel est le cas, vous devez soit désactiver Selinux, soit restaurer les stratégies Selinux par défaut avec "restorecon -R -v /home/user/. Ceci est un problème connu
Pour moi, j'avais des fichiers pam.d corrompus. J'ai copié dans un nouvel ensemble à partir d'un serveur similaire et tout allait bien à nouveau. Je n'ai pas pris le temps de rechercher la corruption spécifique, mais j'ai pensé ajouter mes 2 bits au cas où quelqu'un lirait cela à l'avenir et aurait besoin de quelques idées supplémentaires.
Dans mon cas, je n'ai pas créé l'utilisateur à l'aide de useradd, j'ai plutôt ajouté l'utilisateur dans le fichier/etc/passwd et créé le répertoire de base de l'utilisateur avec tous les fichiers requis.
Après l'utilisation de useradd pour créer l'utilisateur et l'ajout de la clé de publication au fichier registered_keys après la création du répertoire .ssh dans le répertoire de base de l'utilisateur, le problème a été résolu.
En passant, j'utilise centos 7
J'espère que cela aide quelqu'un.