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

12

J'ai le même problème exact décrit dans ce fil , mais la réponse acceptée n'est pas la bonne 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 basée sur mot de passe fonctionne). J'ai suivi toutes les étapes, indices et indices dans:

Je soupçonne maintenant que je manque peut-être quelque chose du côté serveur (Linux, sshd), donc je publie le /etc/ssh/sshd_configcontenu actuel :

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?

MISE À JOUR: J'ai trouvé une astuce pour exécuter sshd en mode débogage , et voici la sortie:

/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 bad ownership or modes for directory /home/winwinmessages mais j'ai vérifié la propriété ou les modes de répertoire / 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 être faux?

MISE À JOUR II: J'ai essayé chmod 600comme 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' Authentication refused: bad ownership or modes for directory /home/winwinerreur?

— WinWin
source

9

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

chmod g-w ~/

Rendez votre dossier .ssh lisible / inscriptible / exécutable uniquement par vous :

chmod 700 ~/.ssh

Rendez votre fichier de clés autorisé lisible / inscriptible uniquement par vous :

chmod 600 ~/.ssh/authorized_keys

Cela devrait supprimer les erreurs d'autorisation.

— John T
source

J'ai fait comme vous l'avez suggéré pour ~/.sshet ~/.ssh/authorized_keys. Toujours pas de chance. En ce qui concerne la prise des autorisations d'écriture de groupe à partir du répertoire personnel lui-même, je ne peux pas le faire car cela minerait le but de cet utilisateur / groupe a été créé pour. Le répertoire personnel de cet utilisateur doit être accessible en écriture par le groupe (avec le même nom et le même identifiant!). +1 pour avoir tenté d'aider.

— WinWin

Je vous remercie! chmod g-w ~/m'a sauvé après des heures de folie et de cheveux tirés alors que je ne pouvais pas chuter avec du mastic au nom de l'un des utilisateurs, avec d'autres utilisateurs qui fonctionnaient bien ...

— PavelS

Gah ya merci, j'ai créé mon répertoire personnel avec mon autre utilisateur, et il me manquait chmod gw ~ /

— Clarence Liu

5

Succès!

Tout ce que j'avais à faire était de passer StrictModesà non .

Selon la section 3.14 de la FAQ OpenSSH et http://blogs.nullvision.com/?p=114 .

Sensationnel.

— WinWin
source

Hmm, c'est plus une solution de contournement qu'une solution, cependant. Permettez-moi de vérifier quelque chose sur ma boîte.

— Rob

Mon ls -lad .sshmontre drwx, donc chmod 700 ~/.sshet les fichiers à l'intérieur sont tous -rw, donc chmod 600 ~/.ssh/*-SHOULD- fonctionnent.

— Rob

Peu importe, vu Le répertoire personnel de cet utilisateur doit être accessible en écriture par le groupe (ayant le même nom exact et le même identifiant!) Ci

— Rob

Cette façon est inutile!

— Love

3

Eu un problème similaire. En fouillant, j'ai remarqué que mes répertoires personnels étaient cryptés et je soupçonnais que c'était le problème. J'ai copié le fichier des clés autorisées dans un répertoire en dehors du répertoire personnel chiffré, j'ai modifié les autorisations de manière appropriée (chmod 700 [dir], chmod 600 [dir] / authorized_keys, etc.).

Modifiez ensuite 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.

— rouge
source

2

Il semble que vos autorisations pour le répertoire de base (ou éventuellement votre dossier .ssh / authorized_keys) sont incorrectes. Les corriger devrait résoudre le problème de connexion. Essayez chmod 600 /home/winwin/.ssh/*
Vous devrez peut-être chmod 700 /home/winwin/.sshaussi.

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

— Dark Android
source

Merci +1. Voir ma mise à jour ci-dessus, car je ne parviens toujours pas à déterminer quelles devraient être les bonnes autorisations / propriété.

— WinWin

Je viens d'essayer chmod 600 /home/winwin/.ssh/*. Ça n'a pas aidé. : - /

— WinWin

1

@WinWin l'avez-vous également placé dans le .sshrépertoire? (J'ai mis à jour ma réponse).

— Dark Android

Oui je l'ai fait. Toujours pas de chance.

— WinWin

2

Je me suis battu à travers ce et a finalement trouvé une solution qui ne provoque pas une atteinte à la sécurité potentielle comme StrictModes Non fait.

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

chmod 0755 / home / {rép_utilisateur}

chmod 0700 / home / {rép_utilisateur} /.ssh

chmod 0600 / home / {rép_utilisateur} /.ssh/authorized_keys

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

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

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

— smcjones
source

1

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

restorecon -FRvv ~/.ssh

(à partir de cette réponse )

— RomanSt
source

0

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 {} \;

— Oncle Bob
source

3

Bienvenue sur Super User! Ce serait bien si vous pouviez expliquer ce que font ces commandes.

— slhck

0

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

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

a résolu ce problème (et bien sûr, respectez les autorisations de fichier / dir partagées dans d'autres réponses).

— Philippe
source