web-dev-qa-db-fra.com

Déconnecté: aucune méthode d'authentification prise en charge disponible

J'ai exactement le même problème que décrit dans ce fil , mais la réponse a été acceptée, ce n'est pas le bon pour moi, car le répertoire personnel de l'utilisateur est local.

Je pense que j'ai tout configuré correctement côté client (Windows 7, PAGEANT, PUTTYGEN et PLINK de PuTTY), mais je ne semble pas faire fonctionner le mécanisme de clé publique (la connexion SSH par mot de passe fonctionne). J'ai suivi toutes les étapes, indices et astuces dans:

Je soupçonne maintenant que quelque chose manque sur le côté serveur (Linux, sshd), alors je poste le contenu actuel de /etc/ssh/sshd_config:

Protocol 2
SyslogFacility AUTHPRIV
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
Subsystem       sftp    /usr/libexec/openssh/sftp-server

Une idée de ce que je fais mal?

UPDATE: J'ai trouvé une astuce pour exécuter sshd en mode débogage , et voici le résultat:

/home/winwin> /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.2p1
debug1: read PEM private key done: type RSA
debug1: private Host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private Host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.1.8 port 49828
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60
debug1: no match: PuTTY_Release_0.60
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done

debug1: userauth-request for user winwin service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "winwin"
debug1: PAM: setting PAM_RHOST to "win7client"
debug1: PAM: setting PAM_TTY to "ssh"
Failed none for winwin from 192.168.1.8 port 49828 ssh2
debug1: userauth-request for user winwin service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
Failed publickey for winwin from 192.168.1.8 port 49828 ssh2
Received disconnect from 192.168.1.8: 14: No supported authentication methods available
debug1: do_cleanup
debug1: PAM: cleanup
debug1: do_cleanup
debug1: PAM: cleanup

Maintenant, je remarque les deux messages bad ownership or modes for directory /home/winwin mais j'ai vérifié la propriété ou les modes pour directory/home/winwin et AFAICT, ils sont OK:

/home> ls -lad winwin
drwxrwxr-x  21 winwin winwin 4096 Jul 13 21:24 winwin

Et:

/home/winwin> ls -lad .ssh
drwxr-xr-x  2 winwin winwin 4096 Jul 14 12:06 .ssh

Et:

/home/winwin/.ssh> ls -lad *
-rw-r--r--  1 winwin winwin 210 Jul 14 12:06 authorized_keys
-rw-r--r--  1 winwin winwin 210 Jul 14 01:58 authorized_keys.pub
-rw-r--r--  1 winwin winwin 394 Jul 14 01:57 authorized_keys.pub.orig

Qu'est-ce qui pourrait éventuellement être faux?

UPDATE II: J'ai essayé chmod 600 comme suggéré dans la réponse ci-dessous:

/home/winwin> ls -lad .ssh
drw-------  2 winwin winwin 4096 Jul 14 13:13 .ssh

Et:

/home/winwin/.ssh> ls -lad *
-rw-------  1 winwin winwin 210 Jul 14 12:06 authorized_keys

Mais ça ne marche toujours pas. Pourquoi ai-je toujours l'erreur Authentication refused: bad ownership or modes for directory /home/winwin?

puttyauthenticationsshdssh-keys
12
WinWin

Succès!

Tout ce que je devais faire était de changer StrictModes en no .

Par section 3.14 dans OpenSSH FAQ et http://blogs.nullvision.com /? p = 114 .

Sensationnel.

5
WinWin

Essayez de prendre les autorisations d'écriture de groupe de votre répertoire de base:

chmod g-w ~/

Rendez votre dossier .ssh lisible/accessible en écriture/exécutable uniquement par vous :

chmod 700 ~/.ssh

Rendez votre fichier de clés autorisé en lecture/écriture uniquement par vous :

chmod 600 ~/.ssh/authorized_keys

Cela devrait supprimer les erreurs d'autorisations.

9
John T

Avait un problème similaire. En fouillant, j'ai remarqué que mes répertoires personnels étaient chiffrés et je pensais que c'était là le problème. J'ai copié le fichier de clés autorisé dans un répertoire situé en dehors du répertoire de départ chiffré et modifié les autorisations en conséquence (chmod 700 [dir], chmod 600 [dir]/registered_keys, etc.).

Ensuite, éditez votre sshd_config pour indiquer à sshd le nouvel emplacement du fichier de clés autorisé, redémarrez sshd, et c'est tout.

Semble avoir résolu mon problème.

3
red

Il semble que vos autorisations pour le répertoire de base (ou éventuellement votre dossier .ssh/registered_keys) soient incorrectes. Corriger ces problèmes devrait résoudre le problème de connexion. Essayez chmod 600 /home/winwin/.ssh/*
Vous devrez peut-être aussi chmod 700 /home/winwin/.ssh.

SSHd refusera de charger votre fichier authorized_keys s'il peut être écrit par une personne autre que votre utilisateur (en tant que propriétaire) car cela pose un risque pour la sécurité.

2
Darth Android

J'ai eu du mal à résoudre ce problème et j'ai finalement trouvé une solution qui ne cause pas de faille de sécurité potentielle comme StrictModes Non Est-ce que.

Assurez-vous que vos paramètres sont les suivants:

chmod 0755/home/ {userdir}

chmod 0700 /home/{userdir}/.ssh

chmod 0600 /home/{userdir}/.ssh/authorized_keys

Où {userdir} est le répertoire en question.

La clé est chmod 0755 qui garantit que seul l'utilisateur peut écrire sur le lecteur home. J'ai copié ceci de ma configuration d'utilisateur qui a fonctionné, et, presto! Les autres noms d'utilisateur ont commencé à fonctionner aussi!

J'espère que cela aide les autres, comme cela m’a été fait, et vous fait gagner quelques heures.

2
smcjones

Ce message d'erreur peut également être causé par SELinux empêchant sshd d'accéder à authorized_keys. Essaye ça:

restorecon -FRvv ~/.ssh

(de cette réponse )

1
RomanSt

Dans mon cas, c’était le répertoire personnel qui avait un autre propriétaire (racine) que l’utilisateur auquel ce répertoire personnel appartient (ma stupidité lors de la création du répertoire de base avec racine pour un autre utilisateur).

Chown [user]:[group] /home/[user]

a résolu ce problème (et bien sûr, tenez-vous-en aux autorisations file/dir telles que partagées dans d'autres réponses).

0
Philippe
chown -R winwin.winwin /home/winwin/
chmod 700 /home/winwin/
find /home/winwin/ -type d -exec chmod 700 {} \;
find /home/winwin/ -type f -exec chmod 600 {} \;
0
Uncle Bob