Pourquoi ai-je toujours une invite de mot de passe avec ssh avec authentification par clé publique?

Je travaille à partir de l'URL que j'ai trouvé ici:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

Mon client ssh est un ordinateur de 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 ~/.sshrépertoire et son contenu sont correctes. Lorsque j'ai configuré pour la première fois l'authentification de ma clé ssh, le ~/.sshdossier n'était pas correctement configuré et il m'a hurlé dessus.

• Votre répertoire ~, votre ~/.sshrépertoire et le ~/.ssh/authorized_keysfichier sur la machine distante doit être accessible en écriture que par vous: rwx------et rwxr-xr-xsont très bien, mais rwxrwx---est pas good¹, même si vous êtes le seul utilisateur de votre groupe (si vous préférez les modes numériques: 700ou 755, non 775) .
  Si ~/.sshou authorized_keysest un lien symbolique, le chemin canonique (avec les liens symboliques développés) est vérifié .
• Votre ~/.ssh/authorized_keysfichier (sur la machine distante) doit être lisible (au moins 400), mais vous aurez besoin qu'il soit également accessible en écriture (600) si vous voulez y ajouter d'autres clés.
• Votre fichier clé privée (sur la machine locale) doit être lisible et modifiable uniquement par vous: rw-------, par exemple 600.
• De plus, si SELinux est configuré pour être appliqué, vous devrez peut-être exécuter restorecon -R -v ~/.ssh(voir par exemple le bogue Ubuntu 965663 et le rapport de bogue Debian n ° 658675 ; cela est corrigé dans CentOS 6 ).

¹ _{Sauf sur certaines distributions (Debian et dérivés) qui ont corrigé le code pour permettre l'écriture des groupes si vous êtes le seul utilisateur de votre groupe.}

Si vous avez un accès root au serveur, le moyen le plus simple de résoudre de tels problèmes consiste à exécuter sshd en mode débogage, en émettant quelque chose comme /usr/sbin/sshd -d -p 2222sur le serveur (chemin complet de l'exécutable sshd requis, which sshdpeut aider), puis en vous connectant à partir du client 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 arrêter temporairement le démon SSH et le remplacer par un en mode débogage. L'arrêt du démon SSH ne supprime pas les connexions existantes. Il est donc possible d'effectuer cette opération via un terminal distant, mais présente des risques. Si la connexion est interrompue au moment où le remplacement du débogage ne s'exécute pas, vous êtes bloqué 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/ à la systemctl start sshd.serviceplace.)

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é auth. Si tel est le cas, vous pouvez déplacer votre authorized_keysfichier dans un répertoire non chiffré et modifier le chemin ~/.ssh/config.

Ce que j'ai fini par faire est de créer un /etc/ssh/usernamedossier, appartenant à un nom d'utilisateur, avec les autorisations appropriées, et d'y placer le authorized_keysfichier. Puis modifié la directive AuthorizedKeysFile en /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 à l'intérieur, authorized_keysvous devez faire quelque chose comme ceci:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Essayez juste ces commandes suivantes

1. ssh-keygen

   Appuyez sur la touche Entrée jusqu'à ce que vous obteniez l'invite.

2. ssh-copy-id -i root@ip_address

   (Il vous sera demandé une fois le mot de passe du système hôte)

3. ssh root@ip_address

   Maintenant, vous devriez pouvoir vous connecter sans mot de passe

J'ai rencontré des difficultés lorsque le répertoire de base de la télécommande n'a pas les privilèges appropriés. Dans mon cas, l'utilisateur a changé le répertoire d'accueil en 777 pour un accès local avec dans l'équipe. La machine ne pouvait plus se connecter avec les clés SSH. J'ai changé l'autorisation à 744 et cela a recommencé à fonctionner.

SELinux sur RedHat / CentOS 6 a un problème d’authentification des clés publiques , probablement lorsque certains des fichiers sont créés, mais selinux ne configure pas correctement ses listes de contrôle d’accès.

Pour corriger manuellement les listes de contrôle d'accès SElinux pour l'utilisateur root:

restorecon -R -v /root/.ssh

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 avec un client mais pas avec un autre (le répertoire .ssh était monté sur 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 commenté, vous obtenez beaucoup d'informations.

ssh -vv user@host

Nous avons découvert que la clé par défaut (id_rsa) n'était pas acceptée et que le client ssh offrait 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                  

Évidemment, cela ne fonctionnera avec aucun autre client.

La solution dans notre cas a donc été de basculer la clé rsa par défaut sur celle contenant l'utilisateur @ myclient. Lorsqu'une clé est définie 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 l'erreur suivante apparaît dans le journal de débogage:

'Agent admitted failure to sign using the key'

Cela a été résolu en rechargeant les clés sur l'agent ssh:

ssh-add

Ce serait une configuration manquante SSH à la fin 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 les AuthorizedKeysFilepoints pointent au bon endroit, utilisez-le %ucomme espace réservé pour le nom d'utilisateur:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

Il se peut que vous deviez simplement commenter la ligne:

AuthorizedKeysFile .ssh / registered_keys

Notez que vous devez recharger le service ssh pour que les modifications aient lieu:

service sshd reload

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

Ceci ajoutera la clé que vous souhaitez utiliser à la liste de clés préexistante. De plus, certains systèmes utilisent le fichier authorized_keys2, il est donc judicieux d’établir un lien solide pointant entre authorized_keyset authorized_keys2, juste au cas où.

Ma solution a été que le compte était verrouillé. Message trouvé dans / var / log / secure: utilisateur non autorisé car le compte est verrouillé Solution: donnez un nouveau mot de passe à l'utilisateur.

J'ai rencontré un problème similaire et 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é afin que d'autres ne disposent pas d'autorisations.

[root@sys-135 ~]# chmod 750 /root

L'authentification par clé a commencé à fonctionner.

Dans le fichier / etc / selinux / config, modifier SELINUX en désactivant l’application de ssh sans mot de passe fonctionne correctement.

Plus tôt, je suis capable de le faire d'une manière. Maintenant, à partir de tous les deux, je suis capable de faire du SSH sans mot de passe.

Une des choses que j'ai eu tort est la propriété de mon répertoire personnel sur le système serveur. Le système du serveur était réglé sur default: default donc je:

chown -R root:root /root

Et ça a fonctionné. Une autre solution avantageuse consiste à désactiver StrictModes: StirctModes no. dans sshd_config. Cela vous indiquera au moins si l'échange de clés et les protocoles de connexion sont bons. Ensuite, vous pouvez aller chasser les mauvaises autorisations.

Pour moi, la solution était opposée à celle de Wojtek Rzepala : je n’avais pas remarqué que j’utilisais encore authorized_keys2, ce qui est devenu obsolète . Ma configuration ssh a cessé de fonctionner à un moment donné, probablement lorsque le serveur a été mis à jour. Renommer .ssh/authorized_keys2comme .ssh/authorized_keysrésolu le problème.

D'oh!

Dans le passé, je suis tombé sur des tutoriels décrivant comment réaliser une configuration ssh sans mot de passe, mais certains ont malheureusement tort.
Recommençons et vérifions chaque étape:

1. FROM CLIENT - Generate key: ssh-keygen -t rsa
   Les clés publique et privée ( id_rsa.pubet id_rsa) seront automatiquement stockées dans le ~/.ssh/répertoire.
   La configuration sera plus facile si vous utilisez une phrase secrète vide. Si vous ne le souhaitez pas, suivez quand même ce guide, mais vérifiez également le point ci-dessous.
   
   
2. FROM CLIENT - Copier la clé publique sur le serveur : ssh-copy-id user@server
   la clé publique du client sera copiée à l'emplacement du serveur ~/.ssh/authorized_keys .
   
   
3. 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érifiez les ~/sshautorisations de dossier sur le client et le serveur .
• Vérifiez /etc/ssh/sshd_configle serveur pour vous assurer que RSAAuthentication, PubkeyAuthenticationet que les UsePAMoptions ne sont pas désactivées, elles peuvent être activées par défaut avec yes.
• Si vous avez entré un mot de passe tout en générant la clé de votre client, vous pouvez essayer ssh-agentet ssh-addpour obtenir des connexions sans mot de passe de votre session.
• Vérifiez le contenu de /var/log/auth.logsur le serveur pour trouver la question pourquoi l' authentification par clé est ignorée du tout.

J'avais exactement le même problème avec PuTTY qui se connecte à une machine Ubuntu 16.04. C'était étonnant, car le programme psc de PuTTY fonctionnait correctement 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 découvert ce qui suit:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

Il s'avère que les versions plus récentes 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-authentication?lq = 1

Ces étapes devraient vous aider. Je l’utilise régulièrement sur 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 quelques invites et l'invoquer comme

script_name username remote_machine

J'ai eu le même problème avec SSH. Dans mon cas, le problème était que j'avais installé hadoop cloudera (à partir de rpm sur centos 6) et créé un utilisateur hdfs avec un répertoire personnel.

/var/lib/hadoop-hdfs(pas standard /home/hdfs).

J'ai changé dans / etc / passwd /var/lib/hadoop-hdfsen /home/hdfs, j'ai déplacé le répertoire de base vers un nouvel emplacement et je peux maintenant me connecter avec une authentification par clé publique.

Je viens d'avoir ce même problème, et pour moi la solution était de régler UsePAMà no. Vous voyez, même avec PasswordAuthenticationset to no, vous obtiendrez toujours keyboard-interactive, et dans mon cas, mon programme ssh local a continué à utiliser ce paramètre par défaut, pour une raison quelconque.

Contexte supplémentaire pour aider les personnes dans la même situation: je me connecte depuis un hôte exécutant Dropbear vers un hôte exécutant OpenSSH. Avec PasswordAuthenticationet UsePAMtous les deux nosur la machine distante, je recevrai le message suivant si j'entre ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

En fournissant le fichier d'identité avec -i, tout fonctionne comme prévu.

Il peut y avoir un peu plus d'informations ici.

Après avoir vérifié les autorisations et essayé plusieurs des solutions répertoriées ici, j'ai finalement supprimé le répertoire ssh du serveur, puis à nouveau configuré ma clé publique.

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

Au serveur:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

C'était directory permission issue. Il était 777 au serveur, donc I changed it back to 700. C'est fixedmon problème avec ssh password less login failuremême après la copie $USER/.ssh/id_rsa.pubsur le serveur $USER/.ssh/authorized_keys.

Une autre option est une variante de l » @Jagadish réponse : au stracedémon ssh.

Il a l'avantage important de ne pas avoir besoin d'arrêter sshd, ce qui peut entraîner un verrouillage complet si quelque chose se passe mal.

Premièrement, nous trouvons le pid du processus sshd principal. Ici nous pouvons le voir en exécutant un fichier 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 est de 633, on peut stracele suivre, à la suite de 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 intégré dans le fichier nommé suxdans le répertoire local.

Puis reproduisez le problème.

Il y aura une liste massive de journaux d'appels dans le noyau, ce qui est pour la plupart incompréhensible / non pertinent pour nous, mais pas partout. Dans mon cas, l’important était le suivant:

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

Sshd a essayé de consigner le message. L' utilisateur cica n'est pas autorisé car le compte est verrouillé . Il ne pouvait pas le faire, car la journalisation n'est pas assez détaillée pour cela. Mais nous savons déjà que la clé publique a été rejetée car le compte était bloqué.

Ce n'est pas encore une solution - il faut maintenant google, ce qui signifie un "compte verrouillé" dans le cas de sshd. Ce sera probablement de la magie triviale /etc/passwd, /etc/shadowmais l’essentiel est fait: le problème n’est pas mystérieux, mais facile à mettre au point et à mettre au point.

Dans mon cas, j'avais toutes les autorisations nécessaires et même en exécutant ssh avec l'option -vvv, je ne pouvais pas comprendre le problème.

J'ai donc généré un nouveau certificat sur l'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 / allowed_keys sur l'hôte distant

cat id_rsa.pub >> authorized_keys

L'utilisation des clés générées à partir d'une connexion à une machine hôte distante fonctionne désormais. Donc, si d'autres solutions échouent, c'est une autre chose à essayer.

Mon scénario était que j'ai un serveur NAS sur lequel j'ai créé un backupbotutilisateur, après la création de mon compte principal, qui a été capable de se connecter pour créer initialement l' backupbotutilisateur. Après avoir manipulé sudo vim /etc/ssh/sshd_configet créé l' backupbotutilisateur, vous vimpouvez créer, au moins sur Ubuntu 16.04, et en fonction de votre ~/.vimrcconfiguration, un fichier d'échange laissé par l'édition de votre session vim/etc/ssh/sshd_config .

Vérifiez si: /etc/ssh/.sshd_config.swpexiste, et s'il le supprime et redémarrez le sshddémon:

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

Cela a résolu mon problème comme par magie. J'avais précédemment vérifié toutes mes autorisations et même les empreintes RSA des clés publique et privée. C'est étrange et probablement un bug avec sshd, en particulier cette version:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 mars 2016