L'authentification par clé SSH échoue
J'essaie de ssh sur un serveur CentOS sur lequel je n'ai aucun contrôle. L'administrateur a ajouté ma clé publique au serveur et insiste sur le fait que la faute incombe à moi, mais je ne peux pas comprendre ce qui ne va pas.
Configuration en .ssh:
tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa
Permission sur mes fichiers de clés:
tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim 746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub
Journal de connexion que je ne peux pas comprendre:
tim@tim-UX31A:~$ ssh -vvv [email protected]
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: Host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: Host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: [email protected]
debug1: kex: Host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server Host key:
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA Host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
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
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.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
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.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
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
Cela résoudra généralement la plupart des problèmes d'autorisation de clé autorisée par SSH côté serveur , en supposant que quelqu'un n'ait pas apporté de modifications supplémentaires aux autorisations.
Sudo chown yourusername:yourusername /home/yourusername/ -R
Sudo chmod o-rwx /home/yourusername/ -R
Si votre administrateur a créé le répertoire .ssh/ou le fichier .ssh/registered_keys en tant que root (ce qui est généralement le cas), le fichier appartenant à un autre utilisateur (même si root!) N'est pas autorisé.
Userify (disclaimer: co-fondateur) procède automatiquement de la même façon. https://github.com/userify/shim/blob/master/shim.py#L285
J'ai eu exactement le même problème sur deux serveurs: un Linux sous Debian et un NAS (Synology DS715)
il s'est avéré que dans les deux cas, les autorisations du répertoire de base sur le serveur étaient erronées
l'auth.log sur le serveur était très utile
Authentication refused: bad ownership or modes for directory /home/cyril
sur Linux, il y avait le bit write/group sur (drwxrwxr - x), donc je devais supprimer au moins le groupe write on (chmod g-w ~ /), puis cela fonctionnait
sur le Synology, pour une raison quelconque, il y avait un peu collant
drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto
Je devais le changer avec
chmod -t ~/
et je pouvais alors me connecter sans mot de passe
Il semble que les autorisations sur votre dossier .ssh ne soient pas copiées + collées correctement. Pourriez-vous s'il vous plaît l'ajouter à nouveau?
Si le mode strict est activé, nous devons nous assurer que .ssh dispose des autorisations appropriées suivantes:
.ssh/devrait avoir des permanentes0700/rwx------.ssh/*.publes fichiers doivent être644/rw-r--r--.ssh/*(autres fichiers au format .ssh)0600/rw-------
Comment les choses se présentent-elles pour vous?
Juste au cas où quelqu'un tomberait sur cette réponse - aucune des recommandations ne fonctionnait dans mon scénario. En fin de compte, le problème était que j'avais créé un compte sans mot de passe. Une fois que j'ai défini le mot de passe à l'aide de usermod -p "my password" username, puis que j'ai déverrouillé de force le compte usermod -U username, tout était peachy.
Lors de l'utilisation de CentOS 7, et je suis convaincu que cela s'applique également aux autres systèmes d'exploitation Linux utilisant sshd. Avec un accès root, vous pouvez déterminer plus en détail pourquoi l’authentification peut échouer. Pour faire ça:
- Activer la journalisation pour sshd:
vi /etc/ssh/sshd_config - Sous enregistrement décommenter:
SyslogFacility AUTH LogLevel INFO
- Remplacez LogLevel INFO par LogLevel DEBUG.
- Sauvegarder et quitter
- Redémarrez sshd
systemctl restart sshd - Regarder le fichier de messages
tail -l /var/log/messages - En utilisant un autre terminal, essayez de vous connecter avec ssh
- Essayez de vous connecter avec ssh
- Consultez le journal d'authentification pour la cause exacte
Par exemple, je rencontrais certains des problèmes mentionnés ci-dessus.
Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys
En utilisant ces étapes, j'ai pu confirmer que le problème était les autorisations sur le fichier allowed_keys. En fixant chmod à 644 sur le fichier de clés autorisées de mon utilisateur, le problème a été résolu.
J'ai eu un problème similaire , où la connexion SSH essaie la clé ~/.ssh/id_rsa avant de s'arrêter de façon inattendue sur:
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Dans mon cas, c'était dû à un ancien fichier de clé publique qui traînait dans le répertoire .ssh:
[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner 423 Jun 12 13:51 id_rsa.pub --> old public key
Déplacer/supprimer le id_rsa.pub du répertoire .ssh a résolu le problème.
D'après ce que j'ai compris: lorsqu'une clé publique est présente côté client, SSH 1st valide la clé privée en conséquence. Si cela échoue, il n'essaiera pas d'utiliser la clé privée pour se connecter à distance.
J'ai envoyé un courrier électronique à la liste de diffusion openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-avril/035048.html .
Également rencontré ce problème. setroubleshoot ne semble pas fonctionner dans mon environnement, il n'y a donc pas d'enregistrement de journal de ce type dans/var/log/messages. Désactiver SELinux n’était pas une option pour moi, alors j’ai
restorecon -Rv ~/.ssh
Après cela, la connexion par clé rsa a bien fonctionné.
Juste au cas où cela sauverait aussi quelqu'un. J'essayais de copier une clé de ma machine Ubuntu 18.04 sur 2 serveurs CentOS 7. J'ai utilisé ssh-copy-id pour les transférer. On travaillait, on ne travaillait pas. J'ai donc passé en revue toutes les autorisations de débogage sans rien trouver. Alors finalement, j'ai récupéré le fichier /etc/ssh/sshd_config sur les deux serveurs et je les ai parcourus ligne par ligne. Finalement, je l’ai trouvé, probablement quelque chose que quelqu'un a modifié bien avant que je ne commence à travailler.
Une lecture: AuthorizedKeysFile .ssh/authorized_keys
Et une autre lecture: AuthorizedKeysFile ~/.ssh/authorized_keys, qui était sur le serveur qui n’acceptait pas mes clés. Évidemment, en regardant entre les deux fichiers et en notant le commentaire qui indique que les modèles de recherche par défaut n'incluent pas le ~/ en tête, je l'ai supprimé et redémarré sshd. Problème résolu.
Nous avons rencontré ce problème. Les autorisations et la propriété des fichiers .ssh étaient toutes correctes. Dans/var/log/messages, nous avons trouvé:
Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82
SO, la solution pour développeur vm où nous ne nous soucions pas de la sécurité est de désactiver selinux. Éditez/etc/sysconfig/selinux et modifiez SELINUX = disabled et redémarrez.
Un journal des erreurs côté client se terminant comme ceci:
Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:
peut être provoqué par une restriction (à distance) côté serveur sur racine connexion lorsque le fichier de configuration sshd contient:
PermitRootLogin: no
La suggestion de JonCav d'activer la journalisation s'est avérée utile pour résoudre ce problème. Alors que le débogage côté client était remarquablement inutile, placez le texte suivant dans le fichier sshd du serveur sshd_config:
SyslogFacility AUTH
LogLevel DEBUG
fini par produire des messages de journal utiles:
Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...
Dans le cas où seule la connexion racine échouait et si l'utilisation de la seule authentification basée sur une clé était autorisée par votre stratégie de sécurité, une modification du fichier sshd_config peut vous aider:
PermitRootLogin without-password
Votre kilométrage peut varier, bien que cela aide souvent, une autre configuration peut encore interférer selon un commentaire trouvé dans certains fichiers sshd_config:
# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
Même si vous ne pouvez pas modifier facilement la configuration du serveur distant pour déboguer de cette manière, il est possible de vérifier dans une certaine mesure la configuration côté client en utilisant les mêmes fichiers d’identité sur ssh dans un compte non root du même compte. serveur distant.
Je peux voir pourquoi la sécurité peut déranger les gens. Je viens d'avoir à nouveau le problème ssh won't use my key. Je l'ai résolu en me connectant au serveur distant et en exécutant
/usr/sbin/sshd -sDp 23456
puis de mon bureau, (en essayant de ssh au serveur)
ssh -vvvv server -p 23456
J'ai reçu Authentication refused: bad ownership or modes for directory / sur le serveur
Un nouvel administrateur système avait gâché la permission et la propriété, que j'ai corrigées avec:
chmod 0755 / ; chown root:root /
(J'ai l'habitude d'avoir besoin de chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pub, mais sshd vérifie/trouve les autorisations root en est une nouvelle pour moi.) Je vais maintenant rechercher un rootkit, puis effacer et réinstaller de toute façon.
Dans mon cas, le problème concernait l'exécutif de Shell incorrect.
journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because Shell /usr/bin/env /bin/bash does not exist
....
Fichier/etc/passwd modifié pour cet utilisateur
vi /etc/passwd
....
user:x:1000:1000::/home/user:/bin/bash
....
La raison dans mon cas était une option personnalisée AuthorizedKeysFile dans le fichier /etc/ssh/sshd_config. Il était défini sur le répertoire personnel d'un autre utilisateur (/home/webmaster/.ssh/authorized_keys), de sorte que l'utilisateur que je tentais de me connecter n'avait pas accès à ce fichier/répertoire.
Après l'avoir changé et redémarré ssh-server (service ssh restart), tout est revenu à la normale. Je peux maintenant me connecter avec ma clé privée.