Pourquoi est-ce que je reçois toujours une invite de mot de passe avec ssh avec authentification par clé publique?
Je travaille à partir de l'URL que j'ai trouvée ici:
Mon client ssh est le bureau Ubuntu 64 bits 11.10 et mon serveur est Centos 6.2 64 bits. J'ai suivi les instructions. Je reçois toujours une invite de mot de passe sur ssh.
Je ne sais pas quoi faire ensuite.
Assurez-vous que les autorisations sur le ~/.ssh répertoire et son contenu sont corrects. Lorsque j'ai configuré pour la première fois l'authentification par clé ssh, je n'avais pas le ~/.ssh dossier correctement configuré, et il m'a crié dessus.
- Votre répertoire personnel
~, votre~/.sshrépertoire et le~/.ssh/authorized_keysle fichier sur la machine distante doit être accessible en écriture uniquement par vous:rwx------etrwxr-xr-xvont bien, maisrwxrwx---n'est pas bon¹, même si vous êtes le seul utilisateur de votre groupe (si vous préférez les modes numériques:700ou755, ne pas775).
Si~/.sshouauthorized_keysest un lien symbolique, le chemin canonique (avec les liens symboliques développés) est vérifié . - Votre
~/.ssh/authorized_keysle fichier (sur la machine distante) doit être lisible (au moins 400), mais vous aurez besoin qu'il soit également accessible en écriture (600) si vous y ajoutez d'autres clés. - Votre fichier de clé privée (sur la machine locale) doit être lisible et inscriptible uniquement par vous:
rw-------, c'est à dire.600. - De plus, si SELinux est défini sur l’application, vous devrez peut-être exécuter
restorecon -R -v ~/.ssh(voir par exemple bogue Ubuntu 96566 et rapport de bogue Debian # 658675 ; c'est corrigé dans CentOS 6 ).
¹ Sauf sur certaines distributions (Debian et dérivés) qui ont corrigé le code pour permettre l'écriture en groupe si vous êtes le seul utilisateur de votre groupe.
Si vous disposez d'un accès root au serveur, le moyen le plus simple de résoudre ces problèmes consiste à exécuter sshd en mode débogage, en émettant quelque chose comme /usr/sbin/sshd -d -p 2222 sur le serveur (chemin complet vers l'exécutable sshd requis, which sshd peut vous aider), puis vous connecter à partir du client avec ssh -p 2222 user@Host. Cela forcera le démon SSH à rester au premier plan et à afficher des informations de débogage sur chaque connexion. Cherchez quelque chose comme
debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/
S'il n'est pas possible d'utiliser un autre port, vous pouvez temporairement arrêter le démon SSH et le remplacer par un en mode débogage. L'arrêt du démon SSH ne tue pas les connexions existantes, il est donc possible de le faire via un terminal distant, mais quelque peu risqué - si la connexion est interrompue d'une manière ou d'une autre lorsque le remplacement du débogage n'est pas en cours d'exécution, vous êtes verrouillé hors de la machine jusqu'à ce que vous puissiez le redémarrer. Les commandes requises:
service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start
(Selon votre distribution Linux, la première/dernière ligne peut être systemctl stop sshd.service/systemctl start sshd.service au lieu.)
Votre répertoire personnel est-il crypté? Si oui, pour votre première session ssh, vous devrez fournir un mot de passe. La deuxième session ssh sur le même serveur fonctionne avec la clé d'authentification. Si tel est le cas, vous pouvez déplacer votre authorized_keys dans un répertoire non chiffré et modifiez le chemin dans ~/.ssh/config.
J'ai fini par créer un /etc/ssh/username dossier, appartenant au nom d'utilisateur, avec les autorisations appropriées, et placé le authorized_keys fichier là-dedans. Puis changé la directive AuthorizedKeysFile dans /etc/ssh/config à :
AuthorizedKeysFile /etc/ssh/%u/authorized_keys
Cela permet à plusieurs utilisateurs d'avoir cet accès ssh sans compromettre les autorisations.
Après avoir copié les clés sur la machine distante et les avoir placées dans le authorized_keys vous devez faire quelque chose comme ceci:
ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa
Essayez simplement ces commandes suivantes
ssh-keygenAppuyez sur la touche Entrée jusqu'à ce que vous obteniez l'invite
ssh-copy-id -i root@ip_address(Il vous demandera une fois le mot de passe du système hôte)
ssh root@ip_addressVous devriez maintenant pouvoir vous connecter sans mot de passe
J'ai rencontré des difficultés lorsque le répertoire personnel de la télécommande n'a pas les privilèges corrects. Dans mon cas, l'utilisateur a changé le répertoire personnel en 777 pour un accès local avec dans l'équipe. La machine n'a plus pu se connecter avec les touches ssh. J'ai changé l'autorisation en 744 et cela a recommencé à fonctionner.
Nous avons rencontré le même problème et nous avons suivi les étapes de la réponse. Mais cela n'a toujours pas fonctionné pour nous. Notre problème était que la connexion fonctionnait à partir d'un client mais pas d'un autre (le répertoire .ssh était monté NFS et les deux clients utilisaient les mêmes clés).
Nous avons donc dû aller plus loin. En exécutant la commande ssh en mode verbeux, vous obtenez beaucoup d'informations.
ssh -vv user@Host
Ce que nous avons découvert, c'est que la clé par défaut (id_rsa) n'a pas été acceptée et que le client ssh a proposé une clé correspondant au nom d'hôte du client:
debug1: Offering public key: /home/user/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
De toute évidence, cela ne fonctionnera pas à partir d'un autre client.
Donc la solution dans notre cas était de changer la clé rsa par défaut à celle qui contenait user @ myclient. Lorsqu'une clé est par défaut, il n'y a pas de vérification du nom du client.
Ensuite, nous avons rencontré un autre problème, après le changement. Apparemment, les clés sont mises en cache dans l'agent ssh local et nous avons obtenu l'erreur suivante dans le journal de débogage:
'Agent admitted failure to sign using the key'
Cela a été résolu en rechargeant les clés de l'agent ssh:
ssh-add
SELinux sur RedHat/CentOS 6 a un problème avec l'authentification pubkey , probablement lorsque certains fichiers sont créés selinux ne définit pas ses ACL correctement.
Pour corriger manuellement les ACL SElinux pour l'utilisateur root:
restorecon -R -v /root/.ssh
Ce serait une configuration manquante SSH à l'extrémité du serveur. Le fichier sshd_config côté serveur doit être modifié. Situé dans /etc/ssh/sshd_config. Dans ce fichier, changez les variables
"oui" à "non" pour ChallengeResponseAuthentication, PasswordAuthentication, UsePAM
"non" à "oui" pour PubkeyAuthentication
Basé sur http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/
Assurez-vous que AuthorizedKeysFile pointe vers le bon emplacement, utilisez %u comme espace réservé pour le nom d'utilisateur:
# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys
Il se peut que vous ayez juste besoin de décommenter la ligne:
AuthorizedKeysFile .ssh/authorized_keys
N'oubliez pas que vous devez recharger le service ssh pour que les modifications aient lieu:
service sshd reload
J'ai rencontré un problème similaire et j'ai suivi les étapes en utilisant le mode débogage.
/usr/sbin/sshd -d
Cela a montré le résultat suivant
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic
C'était vraiment déroutant
[root@sys-135 ~]# ls -l /
drwxrwxrwx. 2 root root 4096 Dec 14 20:05 bin
drwxrwxrwx. 5 root root 1024 May 6 2014 boot
drwxrwxrwx. 2 root root 4096 Dec 2 2013 cgroup
drwxrwxrwx. 10 root root 1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root 12288 Dec 16 10:26 etc
drwxrwxrwx. 11 root root 4096 Jan 14 2014 lib
drwxrwxrwx. 9 root root 12288 Dec 14 20:05 lib64
drwxrwxrwx. 2 root root 16384 Jan 10 2014 lost+found
drwxrwxrwx. 2 root root 4096 Jun 28 2011 media
drwxr-xr-x. 2 root root 0 Dec 10 14:35 misc
drwxrwxrwx. 2 root root 4096 Jun 28 2011 mnt
drwxrwxrwx. 4 root root 4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root 0 Dec 10 14:35 proc
drwxrwxrwx. 45 root root 4096 Dec 16 10:26 root
Il a montré que le répertoire racine avait des autorisations pour chacun. Nous l'avons modifié pour que les autres n'aient pas d'autorisations.
[root@sys-135 ~]# chmod 750 /root
L'authentification par clé a commencé à fonctionner.
Ma solution était que le compte était verrouillé. Message trouvé dans/var/log/secure: utilisateur non autorisé car le compte est verrouillé Solution: donnez à l'utilisateur un nouveau mot de passe.
Deux commentaires: cela écrasera le fichier d'origine. Je copierais simplement la clé publique générée et ferais quelque chose comme:
cat your_public_key.pub >> .ssh/authorized_keys
Cela ajoutera la clé que vous souhaitez utiliser à la liste de clés préexistante. De plus, certains systèmes utilisent le fichier authorized_keys2, c'est donc une bonne idée de créer un lien dur pointant entre authorized_keys et authorized_keys2, Au cas où.
Une chose que j'avais mal était la propriété de mon répertoire personnel sur le système serveur. Le système du serveur a été défini sur default: default, donc je:
chown -R root:root /root
Et ça a marché. Une autre solution de contournement bon marché consiste à désactiver StrictModes: StirctModes no. dans sshd_config. Cela vous indiquera au moins si les protocoles d'échange de clés et de connexion sont bons. Ensuite, vous pouvez aller chasser les mauvaises autorisations.
Dans le fichier/etc/selinux/config, changer SELINUX en désactivé pour appliquer correctement le fonctionnement de ssh sans mot de passe.
Plus tôt, je suis capable de le faire dans un sens. Maintenant, dans les deux sens, je peux faire du ssh sans mot de passe.
Dans le passé, je suis tombé sur des didacticiels qui décrivent comment réaliser une configuration sans mot de passe ssh, mais certains se trompent malheureusement.
Recommençons et vérifions chaque étape:
- FROM CLIENT - Générer la clé:
ssh-keygen -t rsa
Clé publique et privée (id_rsa.pubetid_rsa) sera automatiquement stocké dans le~/.ssh/répertoire.
La configuration sera plus facile si vous utilisez une phrase secrète vide. Si vous n'êtes pas disposé à le faire, suivez toujours ce guide, mais vérifiez également la puce ci-dessous. - FROM CLIENT - Copiez la clé publique dans serveur:
ssh-copy-id user@server
La clé publique du client sera copiée dans emplacement du serveur~/.ssh/authorized_keys. - FROM CLIENT - Connectez-vous au serveur:
ssh user@server
Maintenant, si cela ne fonctionne toujours pas après les 3 étapes décrites, essayons ce qui suit:
- Vérifier
~/sshautorisations de dossier dans client et serveur machine. - Vérifier
/etc/ssh/sshd_configdans serveur pour vous assurer que les optionsRSAAuthentication,PubkeyAuthenticationetUsePAMne sont pas désactivées, elles peuvent être activées par défaut avecyes. - Si vous avez entré une phrase secrète lors de la génération de votre clé client, vous pouvez essayer
ssh-agent&ssh-addpour établir des connexions sans mot de passe dans votre session. - Vérifiez le contenu de
/var/log/auth.logsur le serveur pour trouver le problème pour lequel l'authentification par clé est ignorée.
Pour moi, la solution était opposée Wojtek Rzepala : Je n'ai pas remarqué que j'utilisais toujours authorized_keys2, qui est déconseillé . Ma configuration ssh a cessé de fonctionner à un moment donné, probablement lorsque le serveur a été mis à jour. Renommer .ssh/authorized_keys2 comme .ssh/authorized_keys a résolu le problème.
Oh!
J'avais exactement le même problème avec PuTTY se connectant à une machine Ubuntu 16.04. C'était déroutant car le programme pscp de PuTTY fonctionnait bien avec la même clé (et la même clé fonctionnait dans PuTTY pour se connecter à un autre hôte).
Grâce au précieux commentaire de @UtahJarhead, j'ai vérifié mon fichier /var/log/auth.log et j'ai trouvé ce qui suit:
sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]
Il s'avère que les nouvelles versions d'OpenSSH n'acceptent pas les clés DSA par défaut. Une fois que je suis passé d'un DSA à une clé RSA, cela a bien fonctionné.
Une autre approche: cette question explique comment configurer le serveur SSH pour accepter les clés DSA: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less -authentification? lq = 1
Après avoir vérifié les autorisations et essayé plusieurs autres solutions répertoriées ici, j'ai finalement supprimé le répertoire ssh sur le serveur, la configuration de ma clé publique à nouveau.
Commandes serveur:
# rm -rf ~/.ssh
Commandes locales:
# ssh-copy-id [email protected] # where <user> is your username and <192.168.1.1> is the server IP
J'ai eu un problème similaire avec ssh. Dans mon cas, le problème était que j'avais installé hadoop cloudera (à partir de rpm sur centos 6) et créé des hdfs utilisateur avec le répertoire home
/var/lib/hadoop-hdfs (non standard /home/hdfs).
J'ai changé dans/etc/passwd /var/lib/hadoop-hdfs à /home/hdfs, déplacé le répertoire personnel vers un nouvel emplacement et maintenant je peux me connecter avec l'authentification par clé publique.
Au serveur:
$ ls -lh /home
$ Sudo chmod 700 /home/$USER
C'était directory permission issue. C'était 777 sur le serveur, donc I changed it back to 700. Ce fixed mon problème avec ssh password less login failure même après la copie $USER/.ssh/id_rsa.pub au serveur $USER/.ssh/authorized_keys.
Je viens d'avoir ce même problème, et pour moi, la solution était de définir UsePAM sur no. Vous voyez, même avec PasswordAuthentication réglé sur no, vous obtiendrez toujours keyboard-interactive, et dans mon cas, mon programme ssh local a continué à faire défaut, pour une raison quelconque.
Contexte supplémentaire pour aider toute personne dans la même situation: je me connecte d'un hôte exécutant Dropbear à un exécutant OpenSSH. Avec PasswordAuthentication et UsePAM tous deux définis no sur la machine distante, j'obtiendrai le message suivant si j'entre ssh user@server:
ssh: Connection to user@server:22 exited: Disconnect received
Fourniture du fichier d'identité avec -i, tout fonctionne comme prévu.
Ces étapes devraient vous aider. Je l'utilise régulièrement parmi de nombreuses machines Ubuntu 10.04 64 bits.
[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'
vous pouvez mettre cela dans un script avec des invites et l'invoquer comme
script_name username remote_machine
Mon scénario était que j'ai un serveur NAS sur lequel j'ai créé un utilisateur backupbot, après la création de mon compte principal, qui a pu se connecter pour créer initialement le backupbot utilisateur. Après avoir joué avec Sudo vim /etc/ssh/sshd_config, et en créant l'utilisateur backupbot, vim peut créer, au moins sur Ubuntu 16.04, et en fonction de votre ~/.vimrc config, un fichier d'échange à gauche de l'édition de votre session vim de /etc/ssh/sshd_config.
Vérifiez si: /etc/ssh/.sshd_config.swp existe, et s'il le supprime et redémarrez le démon sshd:
$ Sudo rm /etc/ssh/.sshd_config.swp
$ Sudo service sshd restart
Cela a résolu comme par magie mon problème. J'avais précédemment vérifié toutes mes autorisations et même les empreintes digitales RSA des clés publiques et privées. C'est étrange et probablement un bogue avec sshd, en particulier cette version:
OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 mars 2016
Encore une autre option est une variante de answer de @Jagadish: strace le démon ssh.
Il a l'avantage significatif, que nous n'avons pas besoin d'arrêter le sshd, ce qui peut entraîner un verrouillage complet en cas de problème.
Tout d'abord, nous trouvons le pid du processus sshd principal. Ici, nous pouvons le voir en exécutant un pstree -pa|less.
|-sshd,633 -D <-- THIS IS WHAT WE WANT!
| `-sshd,21973
| `-sshd,21996
| `-bash,22000
| `-screen,638 -r
Après avoir su que le pid vaut 633, on peut strace, en suivant ses enfants:
strace -p 633 -s 4096 -f -o sux
Le résultat sera que tout ce que ce sshd, et ses processus enfants ont fait, sera strace-ed dans le fichier nommé sux dans le répertoire local.
Reproduisez ensuite le problème.
Il aura une liste massive de journaux d'appels du noyau, ce qui est pour la plupart incompréhensible/non pertinent pour nous, mais pas partout. Dans mon cas, l'important était ceci:
6834 sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84
C'était méchant, que le sshd a essayé de consigner le message L'utilisateur cica n'est pas autorisé car le compte est verrouillé - il n'a pas pu, car la journalisation n'est pas suffisante verbeux pour cela. Mais nous savons déjà que la clé de pub a été rejetée car le compte était verrouillé.
Ce n'est pas encore une solution - maintenant nous devons google, ce qui signifie un "compte verrouillé" dans le cas du sshd. Ce sera très probablement un peu trivial /etc/passwd, /etc/shadow la magie, mais l'important est fait - le problème n'est pas mystérieux, mais facilement débogable/googlable.
Dans mon cas, j'avais toutes les autorisations et même lors de l'exécution de ssh avec l'indicateur -vvv, je ne pouvais pas comprendre quel était le problème.
J'ai donc généré un nouveau certificat sur hôte distant
ssh-keygen -t rsa -C "[email protected]"
et copié les clés générées sur la machine locale et ajouté une nouvelle clé publique à ~/.ssh/authorized_keys sur l'hôte distant
cat id_rsa.pub >> authorized_keys
L'utilisation des clés générées à partir de la connexion à la machine hôte distante fonctionne désormais. Donc, si d'autres solutions échouent, c'est une autre chose à essayer.