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


470

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.


5
sortie de la commande que vous donnez à ssh avec le drapeau -v? devrait être semblable à ceci pastebin.com/xxe57kxg
Rob

14
Assurez-vous également que votre dossier .ssh est bien placéchmod 700
Rob

8
en supposant que vous ayez un accès root au serveur, /var/log/auth.logvous saurez pourquoi la connexion échoue.
UtahJarhead

5
@UtahJarhead: Sur le serveur CentOS, il est probable qu'il soit en mode /var/log/secure.
Dennis Williamson

3
Intéressant, le chmod 0700était la réponse, mais quand je l'ai fait ssh -vcôté client, cela n'indiquait pas d'erreur liée à la raison pour laquelle la clé n'avait pas été acceptée. Comment s'attendent-ils à ce que nous diagnostiquions les problèmes sans informations d'erreur du serveur?
void.pointer le

Réponses:


557

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.


29
Merci beaucoup d'avoir signalé restorecon. Je me gratte la tête précisément à cette question depuis un moment maintenant.
Richard Barrell

19
Curieusement, je rencontrais des problèmes avec un compte qu'un ami avait configuré sur son VPS pour obtenir l'autorisation de publication sur clé publique. Je pensais que toutes les autorisations étaient correctes, mais il est important de se rappeler que cela /home/USERdoit être 700ou755
Rob

2
Rappelez-vous également de vérifier les paramètres du propriétaire et du groupe. J'ai utilisé RSYNC pour copier un fichier allowed_keys et je n'ai pas remarqué que propriétaire / groupe était défini sur 1000 au lieu de root!
Nak

11
Ajoutez également -v à votre commande ssh pour voir ce qui se passe avec cette clé. ssh -v user@host.
tedder42

14
chmod -R 700 ~/.sshtravaillé pour moi pour répondre aux contraintes de cette réponse (RHEL 7)
scottyseus

147

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.)


5
Je viens d'essayer ça ... et ça marche bien quand je cours sshd -d, mais ça échoue une fois que je cours service sshd start. Je suis sûr que c'est simple, mais je ne suis pas un gourou de Linux. Des pensées?
N Rohler

3
Pour référence, cet article explique la solution SELinux qui a résolu mon problème.
N Rohler

2
J'avais également du mal à faire en sorte que l'authentification par clé publique fonctionne et j'étais à peu près sûr que les autorisations de répertoire n'étaient pas le problème. Après avoir exécuté SSH en mode débogage, j'ai rapidement découvert que je m'étais trompé et que les autorisations posaient problème.
ub3rst4r

3
Bon conseil, mon dossier utilisateur était avec les mauvaises autorisations.
gdfbarbosa

2
Je vous remercie. Parmi toutes les raisons, mon utilisateur n'était pas autorisé à se connecter car le shell spécifié par ansible (/ bin / zsh) lors de la création de l'utilisateur n'existait pas. Je n'aurais jamais deviné ça.
Chishaku

53

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.



3
Cette réponse est essentielle et m'a aidé - pour tous ceux qui se demandent si c'est là le problème - vous pouvez voir "pam_ecryptfs: fichier de phrase secrète encapsulé" dans votre auth.log; d'une manière ou d'une autre, cela ne m'a pas incité à me rappeler que l'homedir était crypté. Vous pouvez également trouver que la première connexion demande un mot de passe, contrairement aux sessions suivantes (car il est décrypté pendant que les autres sessions sont ouvertes).
pacifiste

Putain de merde, j'ai trop cherché pour résoudre ce problème, merci beaucoup!
h3.

33

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

1
En fait non vous ne faites pas. ssh utilise automatiquement ~ / .ssh / id_rsa (ou id_dsa) sans avoir à utiliser un agent de clé.
Patrick

7
Cela peut toujours être un conseil utile si vous deviez spécifier une clé de nom différent dans ~ / .ssh / config (par exemple, sur l’hôte * .mydomain.org ... IdentityFile ~ / .ssh / some_limited_use.pub - ssh-add ~ / .ssh / some_limited_use.pub).
89c3b1b8-b1ae-11e6-b842-48d705

Cela a résolu mon problème d'obtention d'invite de mot de passe après l'ajout d'une clé. Comme 89c3b1b8-b1ae-11e6-b842-48d705 l'a fait remarquer, la raison de l'exécution manuelle de ces commandes était le nom non standard d'un fichier de clé.
Михаил Лисаков

Comme indiqué ci-dessus dans les commentaires, si vous utilisez une clé autre que la clé par défaut, celle-ci n'est pas ajoutée par défaut à l'agent ssh. Assurez-vous donc que la clé que vous souhaitez utiliser se trouve bien dans le trousseau de l'agent:ssh-add -L
James

30

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


1
Sur quel serveur?
Amalgovinus

@ Amalgovinus Évidemment, vous exécutez ceci sur le client, pas sur la machine à laquelle vous vous connectez - vous ne voulez pas de copie de votre clé privée sur le serveur! :)
nevelis

4
Veuillez noter qu'en général, autoriser des connexions à distance root n'est pas une pratique de sécurité recommandée.
arielf

27

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.


7
Nous avons eu ce problème aussi - 755 à la maison ont corrigé
davidfrancis

J'avais les permissions réglées à 777 et ça a été ignoré, merci !!!
ka_lin

Pareil ici. Merci. Je me suis gratté la tête pendant un moment, wtf se passait.
Marcin

Oui, voyez la réponse ici pour plus de détails unix.stackexchange.com/questions/205842/…
Tim

Cela pourrait bien être la solution pour les personnes qui ont correctement généré la clé tout en étant invité à saisir un mot de passe.
Fergie le

14

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

en utilisant le client openssh sur Windows, j’ai pu me ssh root@mymachineconnecter mymachineà CentOS6 sans problème, mais j’ai un utilisateur de privilège inférieur que je préférerais utiliser, mais ssh regularUser@mymachinequi m’invite toujours à entrer un mot de passe. pensées?
Groostav

13

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

9

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/


1
Comme dans les commentaires, vérifiez dans / var / log / secure ou /var/log/auth.log. Dans mon cas, je vois "Utilisateur xxx de xxx non autorisé car non répertorié dans AllowUsers" "input_userauth_request: utilisateur non valide xxx [preauth]" (et "rexec ligne 35: Option obsolète ServerKeyBits" dans / var / log / messages alors que je ne savais pas quoi C'est). Pour résoudre le problème vi /etc/ssh/sshd_config, ajoutez l'utilisateur xxx à la liste AllowUsers, service sshd restart*** BEWARE qui redémarre le service sshd avec un fichier sshd_config incorrect peut vous empêcher de sortir de la boîte!? *** Ça a marché.
Gaoithe le

6

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

4

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ù.


Oui, j'ai aussi remarqué cela à propos de l'écrasement, mais je n'en avais pas, alors ça n'avait pas d'importance. J'ai créé un lien symbolique vers autorisé_keys2 mais cela n'a pas aidé.
Thom

Vérifiez également les autorisations de fichier / répertoire. Ils sont décrits sur le site Web que vous avez fourni.
Wojtek Rzepala le

3
votre répertoire ~ / .ssh doit être 700 votre fichier de clé privée doit être 600 votre fichier de clé publique doit être 644 votre fichier auth (sur la télécommande) doit être 644
Rob

@Rob c'était le problème. Si vous publiez cela comme réponse, je l'accepterais.
Thom

4

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.


Je l'ai corrigé en changeant le champ mot de passe /etc/shadowpour cet utilisateur de !à *. Après cela, l'authentification par mot de passe est toujours impossible, mais l'utilisateur n'est plus verrouillé.
user3132194

4

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.


J'ai le même problème. Hier, j’ai autorisé rsync -av ./root/ root@THE_HOST:/rootà télécharger des fichiers de mon répertoire de travail local. Ce problème se produit (en fait, au début, je ne l’avais pas remarqué. Après l’échec des tâches périodiques d’autres hôtes le lendemain matin, j’ai commencé à chercher la raison.) . La rsync -av ./root/ root@THE_HOST:/rootcommande a changé le propriétaire et l'autorisation du /rootrépertoire de l'hôte distant. Correction de l'autorisation, problème résolu.
LiuYan le

Failed publickey for root from 135.250.24.32 port 54553 ssh2Je reçois le même message et le même problème lorsque j'ai oublié d'ajouter la clé publique à un hôte authorized_keys. Ajoutant ce commentaire comme dans mon cas, je réalise généralement mon erreur après avoir vérifié le débogage et toutes les autorisations plus les fichiers de configuration n °: o <
tuk0z

3

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.


3

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.


Moi aussi. Regardez les messages dans / var / log / secure. J'ai vu un message: "Authentification refusée: mauvaise propriété ou modes de répertoire" ($ HOME). Assurez-vous que $ HOME n’est pas accessible en écriture au groupe ou à un autre. Je ne l'aurais jamais trouvé si je n'avais pas d'accès root non autorisé au serveur ....
SoloPilot

2

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!


C'est aussi une option de configuration dans / etc / ssh / sshd_config, bien que je pense que je le renommerais comme vous l'avez fait.
Rick Smith

2

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.

Merci d'avoir énuméré les étapes! Je suis arrivé à "ssh-copy-id utilisateur @ serveur" et je me suis rendu compte que j'avais initialement copié la mauvaise clé publique.
mattavatar le

2

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


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

Il existe déjà ssh-copy-idqui fait les deux dernières étapes automatiquement.
jofel

2
@jofel gardez à l'esprit que dans de nombreux systèmes, ssh-copy-id n'existe pas. @Sriharsha après le, mkdirvous devriez aussi ajouter là chmod 700 .sshet d'ailleurs, vous n'avez pas besoin d'être aussi prolixe ~/.ssh, .sshc'est suffisant puisque les commandes sont exécutées dans le répertoire personnel quand même
janos

1

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.


1

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.


1

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 user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP


0

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.


0

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 "your_email@example.com"

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.


0

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.