L'ajout d'une clé publique à ~ / .ssh / authorized_keys ne me connecte pas automatiquement


446

J'ai ajouté la clé SSH publique au fichier authorized_keys . ssh localhostdevrait me connecter sans demander le mot de passe.

Je l'ai fait et j'ai essayé de taper ssh localhost, mais il me demande toujours de taper le mot de passe. Existe-t-il un autre paramètre que je dois suivre pour que cela fonctionne?

J'ai suivi les instructions pour modifier les autorisations:

Voici le résultat si je le fais ssh -v localhost.

debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

Ensuite, il demande une phrase de passe après le journal ci-dessus. Pourquoi ne me connecte-t-il pas sans mot de passe?


5
Bien que ce ne soit pas le cas ici, si vous venez de Google et que vous utilisez un répertoire personnel chiffré, sshd ne pourra pas y accéder et ne pourra donc pas lire votre fichier authorized_keys. Voici une solution: bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/…
Daniel Schaffer

Réponses:


1097

Vous devez vérifier les autorisations du authorized_keysfichier et du dossier / dossiers parents dans lequel il se trouve.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Pour plus d'informations, consultez cette page .

Vous devrez peut-être également modifier / vérifier les autorisations de votre répertoire personnel pour supprimer l'accès en écriture pour le groupe et les autres.

chmod go-w ~

6
Eh bien, quelque chose dans ce qui précède a fonctionné, mais "chmod -R go-wrx foobar" n'est-il pas plutôt dramatique? Pourquoi le besoin de récursif?
joachim

9
Pour la deuxième partie, il n'est pas nécessaire de le rendre récursif, il suffit de faire le chmod go-wrx foobar. Le faire récursivement pourrait sérieusement endommager certaines applications si vous avez un groupe ou un autre accès aux fichiers, surtout s'il s'agit d'un répertoire Web.
StingeyB

24
Comme mentionné dans la FAQ OpenSSH, le répertoire home & .ssh de l'utilisateur n'a besoin que d'écrire la permission supprimée pour le groupe / autre (ainsi chmod go-w $HOME $HOME/.sshfera l'affaire). Ainsi, les autorisations peuvent être aussi «ouvertes» que 755 pour les deux répertoires, si vous êtes si enclin. Les commandes les plus simples / les moins invasives se trouvent dans la FAQ: openssh.org/faq.html#3.14
davidjb

3
Pourquoi cela n'a-t-il pas fonctionné pour moi jusqu'à ce que je le fasse chmod 700 ~/.ssh && chmod 644 ~/.ssh/authorized_keys? 600 n'a pas fonctionné là où 644 a fonctionné ...
ficuscr

3
J'en avais également besoin sudo chown -R {$USER}:{$USER} ~/.ssh/car j'avais écrit le authorized_keysfichier en tant que root.
Zane Hooper

155

SELinux peut également empêcher les clés autorisées de fonctionner. Surtout pour root dans CentOS 6 et 7. Pas besoin de le désactiver cependant. Une fois que vous avez vérifié que vos autorisations sont correctes, vous pouvez résoudre ce problème comme suit:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

7
C'est restoreconce dont vous avez besoin après avoir copié les fichiers à la main, par exemple sur un nouveau disque dur. (Vous devriez probablement l'exécuter sur tous les fichiers dans ce cas. Pourrait résoudre d'autres problèmes étranges.)
ospalh

Un autre campeur heureux ici. C'était mon problème dans RHEL 6.5
Antonio Ortells

2
9/10 fois, un problème "pourquoi ça ne marche pas, ça marche toujours" est un problème selinux.
Andrew White

résolu le problème pour moi sur le serveur 1and1 (1und1)
musicman

104

définition de ssh authorized_keys semble être simple mais cache des pièges que j'essaie de comprendre

- SERVEUR -

dans / etc / ssh / sshd_config défini passwordAuthentication yespour permettre au serveur d'accepter temporairement l'authentification par mot de passe

-- CLIENT --

considérer cygwin comme une émulation linux et installer et exécuter openssh

1. générer des clés privées et publiques (côté client) # ssh-keygen

ici en appuyant simplement sur ENTRÉE, vous obtenez les fichiers PAR DÉFAUT 2 " id_rsa " et " id_rsa.pub " dans ~ / .ssh / mais si vous donnez un nom_pour_la_ clé, les fichiers générés sont enregistrés dans votre pwd

2. placez votre_key.pub sur la machine ciblessh-copy-id user_name@host_name

si vous n'avez pas créé de clé par défaut, c'est la première étape pour vous tromper ... vous devez utiliser

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. la journalisation ssh user_name@host_namene fonctionnera que pour id_rsa par défaut, voici donc le deuxième piège pour vousssh -i path/to/key_name user@host

(utilisez l' option ssh -v ... pour voir ce qui se passe)

Si le serveur demande toujours le mot de passe, vous avez donné smth. à Enter passphrase: lorsque vous avez créé des clés (il est normal)

si ssh n'écoute pas, le port par défaut 22 doit utiliser ssh -p port_nr

- SERVEUR -----

4. modifiez / etc / ssh / sshd_config pour avoir

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(déconseillé si cas)

Cela indique à ssh d'accepter les clés autorisées et de rechercher dans le répertoire de base de l'utilisateur la piqûre nom_clé écrite dans le fichier .ssh / authorized_keys

5 Définir les autorisations sur la machine cible

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Également désactiver l'authentification par passe

passwordAuthentication no

pour fermer la porte à toutes les tentatives root / admin /....@ your_domain ssh

6 Assurez-vous que la propriété et la propriété de groupe de tous les répertoires personnels non root sont appropriées.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user 

================================================

7. considérez l'excellent http://www.fail2ban.org

8. extra ssh TUNNEL pour accéder à un serveur MySQL (bind = 127.0.0.1)


5
Notez que "juste 4 sécurité" n'est pas seulement pour la sécurité! SSH ignorera le fichier s'il ne dispose pas d'autorisations restrictives.
Navin

Assurer la propriété serait un excellent ajout à cette liste
steviejay

1
Je n'en avais aucune idée ssh-copy-id! Cette étape à elle seule serait une excellente réponse.
James Marble

1
chmod 755 ~ / .ssh au lieu de 700 que je vois ailleurs semblait le faire
Jim W dit réintégrer Monica

36

Assurez-vous également que votre répertoire personnel n'est pas accessible en écriture pour les autres

chmod g-w,o-w /home/USERNAME

La réponse est volée d' ici


4
Faire a chmod 700 ~/.ssh ; chmod 600 ~/.ssh/authorized_keys ; chmod g-w,o-w ~fonctionné pour moi. Merci.
gbraad

1
pourquoi ne pas utiliser juste à la chmod og-w /home/USERNAMEplace?
Paramvir Singh Karwal

13

les désespérés peuvent également s'assurer qu'ils n'ont pas de nouvelles lignes supplémentaires dans le fichier authorized_keys en raison de la copie du texte id_rsa.pub hors d'un terminal confus.


2
C'est exactement ce qui m'est arrivé! les deux terminaux ont la même largeur, il est donc difficile de comprendre jusqu'à ce que j'active les numéros de ligne pour voir deux lignes dans le fichier authorized_keys.
Shawn

1
Cette. Je viens de perdre une heure à cause de cela. Et ce n'est pas la première fois. La réponse de @ bortunac mentionne l'outil ssh-copy-id, que j'utiliserai à l'avenir pour éviter cela.
xdhmoore

J'ai obtenu le contenu de l' id_rsa.pubutilisation à la moreplace de cat, ce qui était fatal à cause des sauts de ligne invisibles.
Dan Halbert

8

l'utilisateur est votre nom d'utilisateur

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

Mieux pour root:mkdir -p /home/$USER/.ssh && chown -R $USER:$USER /home/$USER/.ssh && sudo -u $USER ssh-keygen -t rsa && touch /home/$USER/.ssh/authorized_keys && touch /home/$USER/.ssh/known_hosts && chmod 700 /home/$USER/.ssh && chmod 600 /home/$USER/.ssh/id* && chmod 644 /home/$USER/.ssh/id*.pub && chmod 644 /home/$USER/.ssh/authorized_keys && chmod 644 /home/$USER/.ssh/known_hosts && vim /home/$USER/.ssh/authorized_keys # paste keys here!
Odysseus

7

Sachez que SELinux peut également déclencher cette erreur, même si toutes les autorisations semblent correctes. Le désactiver a fait l'affaire pour moi (insérer les clauses de non-responsabilité habituelles concernant la désactivation).


Vous pouvez voir SELinux interférer /var/log/audit/audit.log. restorecon -R -v /root/.sshcorrigé mon cas spécifique.
Dave Goodell

7

Lister une clé publique dans .ssh / authorized_keys est nécessaire, mais pas suffisant pour que sshd (serveur) l'accepte. Si votre clé privée est protégée par une phrase secrète, vous devrez donner à ssh (client) la phrase secrète à chaque fois. Ou vous pouvez utiliser ssh-agent , ou un équivalent GNOME.

Votre trace mise à jour est cohérente avec une clé privée protégée par une phrase secrète. Voir ssh-agent ou utiliser ssh-keygen -p.


5

Commande d'écriture:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Après cela, assurez-vous que votre répertoire est comme ça:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

1
en quoi votre réponse est différente de celle acceptée? Vous l'avez écrit 3 ans plus tard en utilisant votre commande Ctrl + C Ctrl-V?
stinger

5

La chose qui a finalement fait l'affaire pour moi était de s'assurer que le propriétaire / groupe n'était pas root mais utilisateur:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 

chown: utilisateur invalide: '/home/lsa/.ssh/'
Stepan Yakovenko

3

Essayez "ssh-add" qui a fonctionné pour moi.


3

Une autre astuce à retenir. Depuis la version 7.0, OpenSSH désactive les clés ssh DSS / DSA par défaut en raison de leur faiblesse héritée. Donc, si vous avez OpenSSH v7.0 +, assurez-vous que votre clé ne l'est pas ssh-dss.

Si vous êtes bloqué avec des clés DSA, vous pouvez réactiver la prise en charge localement en mettant à jour vos fichiers sshd_configet ~/.ssh/configavec des lignes comme ceci:PubkeyAcceptedKeyTypes=+ssh-dss


3

Dans mon cas, je devais mettre mon authorized_keysdossier.openssh .

Cet emplacement est spécifié dans /etc/ssh/sshd_configsous l'option AuthorizedKeysFile %h/.ssh/authorized_keys.


Il y a toute une classe de problèmes qui peuvent survenir sur le serveur (lorsque vous essayez de vous connecter à partir d'un client) qui sont impossibles à déboguer sans accès au serveur ... déboguer.
qneill

2

Assurez-vous que l'utilisateur cible dispose d'un mot de passe. Courez passwd usernamepour en définir un. Cela était nécessaire pour moi même si la connexion SSH par mot de passe était désactivée.


2

cela résout mon problème

ssh-agent bash

ssh-add


Expliquez ce que cela fait, s'il vous plaît.
lyuboslav kanev

L'agent ssh stocke vos clés ssh .. la commande bash démarre une nouvelle instance de son shell. et ssh-add déverrouille vos clés et les charge
Julian

2

Un autre problème auquel vous devez faire attention. Si votre fichier généré n'est pas par défaut id_rsa et id_rsa.pub

Vous devez créer un fichier .ssh / config et définir manuellement le fichier id que vous allez utiliser avec la connexion.

L'exemple est ici:

host remote_host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

2
Le fichier d'identité doit être la clé privée
Ken H

@KenH ouais bien sûr. c'est typo. Désolé.
Kunthar

1

J'ai émis sudo chmod 700 ~/.sshet chmod 600 ~/.ssh/authorized_keyset chmod go-w $HOME $HOME/.sshd'en haut et cela a résolu mon problème sur une boîte CentOS7 sur laquelle j'avais foiré les autorisations en essayant de faire fonctionner les partages de samba. Merci


1

Cela semble être un problème de permission. Habituellement, cela se produit si l'autorisation d'un fichier / répertoire n'est pas correctement configurée. Dans la plupart des cas, ils le sont ~/.sshet ~/.ssh/*. Dans mon cas, ils le sont /home/xxx.

Vous pouvez changer le niveau de journalisation de sshd en le modifiant /etc/ssh/sshd_config(recherchez LogLevel, réglez-le sur DEBUG), puis vérifiez la sortie /var/log/auth.logpour voir ce qui s'est passé exactement.


3
Cela semble sensiblement identique à la réponse acceptée et aurait probablement dû être un commentaire, pas une réponse. Avec un peu plus de rep, vous pourrez poster des commentaires . D'ici là, veuillez ne pas utiliser les réponses comme solution de contournement.
Nathan Tuggy

Désolé, je pensais que c'était le moyen de résoudre toutes sortes de questions. Maintenant, je sais comment le faire maintenant, merci.
Joey

1

Mon problème était un fichier AuthorizedKeys modifié, alors que l'automatisation pour remplir / etc / ssh / authorized_keys n'avait pas encore été exécutée.

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

1

Regardez simplement /var/log/auth.log sur le serveur . La définition d'une verbosité supplémentaire avec -vv du côté client n'aidera pas, car il est peu probable que le serveur offre trop d'informations à un attaquant potentiel.


1

Assurez-vous d'avoir copié l'intégralité de la clé publique dans authorized_keys; le ssh rsapréfixe est nécessaire pour que la clé fonctionne.


2
utilisé ssh-copy-id
vishnu

1

vous devez vérifier les propriétés des fichiers. pour affecter l'utilisation de la propriété requise:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

1

Regardez /var/log/auth.logsur le serveur pour les sshderreurs d'authentification.

Si tout le reste échoue, exécutez le sshdserveur en mode débogage:

sudo /usr/sbin/sshd -ddd -p 2200

Connectez-vous ensuite à partir du client:

ssh user@host -p 2200

Dans mon cas, j'ai trouvé la section d'erreur à la fin:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

Avec cette information, j'ai réalisé que je sshd_configrestreignais les connexions aux membres du sshgroupe. La commande suivante a corrigé cette erreur d'autorisation:

sudo usermod -a -G ssh NEW_USER

0

sur cette note, assurez-vous que votre configuration sshd a -;

PermitRootLogin without-password

défini comme ci-dessus, puis redémarrez sshd (/etc/init.d/sshd restart)

déconnectez-vous et essayez de vous reconnecter!

par défaut, je crois est -;

PermitRootLogin no

0

Dans mon cas, c'est parce que le groupe de l'utilisateur n'est pas défini dans AllowGroups du fichier de configuration / etc / ssh / sshd_config. Après l'avoir ajouté, tout fonctionne bien.


0

J'ai le répertoire personnel dans un emplacement non standard et dans les sshdjournaux, j'ai cette ligne:

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

même si toutes les autorisations étaient très bien (voir les autres réponses).

J'ai trouvé une solution ici: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

Dans mon cas particulier:

  • a ajouté une nouvelle ligne dans /etc/selinux/targeted/contexts/files/file_contexts.homedirs:

    • il s'agit de la ligne d'origine pour les répertoires personnels habituels:

      /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

    • c'est ma nouvelle ligne:

      /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

  • suivi d'un restorecon -r /data/et d'un sshdredémarrage


0

J'ai eu ce problème et aucune des autres réponses ne l'a résolu, bien que les autres réponses soient bien sûr correctes.

Dans mon cas, il s'est avéré que le /rootrépertoire lui-même (pas par exemple /root/.ssh) avait les mauvaises autorisations. J'ai eu besoin:

chown root.root /root
chmod 700 /root

Bien sûr, ces autorisations devraient être quelque chose comme ça (peut-être chmod 770) indépendamment. Cependant, spécifiquement empêché sshdde travailler, même si /root/.sshet les /root/.ssh/authorized_keysdeux avaient des autorisations correctes et les propriétaires.


0

J'ai rencontré ce problème lorsque j'ai ajouté le groupe de l'utilisateur connecté à un autre utilisateur. Disons qu'il existe un utilisateur ssh-login appelé userA et un utilisateur non-ssh-login userB. userA a également le groupe userA. J'ai modifié userB pour avoir également le groupe userA. Cela a conduit au comportement décrit, de sorte que userA n'a pas pu se connecter sans invite. Après avoir supprimé le groupe userA de userB, la connexion sans invite a de nouveau fonctionné.

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.