Pourquoi la connexion automatique via ssh avec des clés autorisées ne fonctionne-t-elle pas?

12

J'ai créé une paire de clés Dsa privée / publique. J'ai mis la clé publique sur le serveur

~/.ssh/authorized_keys

Tout est configuré comme mon autre serveur, mais il semble que le serveur ignore simplement mes efforts.

security ssh login

— Magnar
source

Vérifiez /etc/ssh/ssh_configet /etc/ssh/sshd_configvérifiez que rien de ce que vous voulez n'est désactivé.

— Kristopher Johnson

Vous voudrez également vérifier sshd_config.

— Vagnerr

Merci. J'ai mis à jour la réponse (qui ne mentionnait à l'origine que ssh_config).

— Kristopher Johnson

Toutes les discussions ci-dessus sont parfaites si vous utilisez un style openssh de ssh. Si votre système utilise ssh2, il a une façon complètement loufoque de gérer les clés. Cet article explique les façons et les quoi. burnz.wordpress.com/2007/12/14/…

— chris

1

Habituellement, la vérification des /var/log/auth.logsystèmes Debian ou /var/log/secureRedHat devrait vous donner des conseils clairs sur ce qui est mal configuré (généralement des problèmes d'autorisations)

— Giovanni Toraldo

15

Bien que votre problème ait peut-être déjà été résolu par d'autres réponses, je me suis verrouillé sur suffisamment de machines pour ne pas valider les modifications de sshd_config avant de vous déconnecter.Nous avons donc proposé le processus ci-dessous qui pourrait être utile pour le débogage futur des modifications de configuration de sshd:

NE DÉBRANCHEZ PAS une connexion ssh active jusqu'à ce qu'APRÈS que le test ait vérifié que le comportement est conforme à vos attentes.

une. vérifiez ce que vous pensez que sshd est censé faire

b. vérifiez que la configuration est valide en utilisant "-t"

c. démarrer une version «test» détaillée du serveur que vous pouvez surveiller en direct

ré. démarrer une connexion client "test" détaillée que vous pouvez surveiller en direct

une. vérifiez ce que vous pensez que sshd est censé faire

Passez en revue le fichier de configuration sshd sans tous les commentaires avec quelque chose comme ci-dessous (en supposant que sshd_config est le fichier correct et dans / etc / ssh)

$ grep -v "^ #" / etc / ssh / sshd_config | grep -v "^ $"

Cela efface simplement les choses afin que nous vérifions ce que nous pensons que nous changeons (pas nécessairement si c'est correct ou non.)

b. vérifiez que la configuration est valide en utilisant "-t"

Depuis la page de manuel des sshd que j'utilise,

-t Mode test. Vérifiez uniquement la validité du fichier de configuration et l'intégrité des clés. Ceci est utile pour mettre à jour sshd de manière fiable car les options de configuration peuvent changer.

D'autres changements peuvent avoir des circonstances plus subtiles. Par exemple, ne désactivez pas l'authentification par mot de passe tant que vous n'êtes pas sûr que l'authentification par clé publique fonctionne correctement.

c. démarrer une version «test» détaillée du serveur que vous pouvez surveiller en direct

$ sudo / usr / sbin / sshd -ddd -p 9999

Cela maintient votre session de travail existante active, mais vous donne une autre instance de sshd pour vérifier vos nouvelles modifications de configuration. SSHD s'exécute maintenant au premier plan sur un port défini par l'utilisateur (9999 dans notre exemple.) Et pousse de nombreuses informations de débogage bruyantes que vous pouvez suivre dans / var / log / authlog (ou éventuellement /var/log/auth.log selon sur votre système d'exploitation.)

ré. démarrer une connexion client "test" détaillée que vous pouvez surveiller en direct

Exécutez la connexion client ssh en mode verbeux pour afficher sur votre écran plus d'informations susceptibles de vous aider à mieux déboguer votre erreur.

$ ssh -vvv -p 9999 nom-serveur

Vous devez maintenant avoir suffisamment d'informations dans les fichiers journaux du serveur ou dans l'écran de connexion du client pour isoler votre problème.

La solution se résume généralement aux autorisations de fichiers (comme le montrent Magnar et setatakahashi)

Bonne chance

— samt
source

Je suppose que vous devriez également vérifier le fichier ssh_config du côté client pour vous assurer qu'il fait ce que vous attendez. Utilisez quelque chose comme ci-dessous pour extraire les commentaires:> grep -v "^ #" / etc / ssh / ssh_config | grep -v "^ $"

— samt

Eh bien, la configuration ssh du client peut être corrigée à tout moment, c'est le serveur dont vous êtes verrouillé si vous l'avez mal configuré.

— Soviero

33

Le serveur ignorera votre fichier authorized_keys si les propriétés du propriétaire sont incorrectes. Le changer en ceci le corrige:

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys

— Magnar
source

6

ssh -vvv -l nom d'utilisateur server.domain vous dira si vous envoyez une clé valide

— Dave Cheney

Parfois, j'ai vu sshd se plaindre de mauvaises autorisations sur le répertoire personnel - alors j'ajoutais "chmod o-rwx ~" (ou au moins "chmod ow ~") à la liste comme l'a fait setatakahashi. Cela devient généralement évident lorsque le fichier journal est surveillé - les messages d'erreur que j'ai vus là-bas pointaient toujours dans la bonne direction.

— Olaf

Cette réponse semble la plus probable, mais le commentaire de Dave Cheney est le seul moyen de voir ce qui se passe réellement. Vérifiez également les journaux du serveur.

— dwc

C'était mon problème. Je me suis battu la tête pendant des heures. Merci beaucoup!

— Sam Soffes

1

Cela a fait l'affaire, mais mes autorisations précédentes étaient 0775et 0644respectivement. Pourquoi la réduction des autorisations a-t-elle aidé? Est-ce une précaution de sécurité configurée quelque part?

— Dean

11

$ chmod 700 ~

$ chmod 700 ~ / .ssh

$ chmod 600 ~ / .ssh / authorized_keys

Vérifiez ces attributs dans / etc / ssh / sshd_config

$ sudo grep PubkeyAuthentication / etc / ssh / sshd_config

$ sudo grep Protocol / etc / ssh / sshd_config

— setatakahashi
source

2

Excellent point à propos de ~, vous devez vous assurer que personne d'autre que vous ne peut écrire dans votre répertoire personnel, sinon il pourrait renommer votre répertoire ~ / .ssh

— Dave Cheney

ce dernier chmod devrait être: $ chmod 600 ~/.ssh/authorized_keysnot$ chmod 600 ~/.sHh/authorized_keys

— SooDesuNe

3

quelles devraient être les valeurs d'attributs être ?

— Michael

0

Un autre écueil important ..

Si votre répertoire personnel est chiffré, sshd n'aura pas accès à ~ / .ssh / authorized_keys ..

Voir cette réponse

— A priori
source