Ajouter une clé publique à ~ / .ssh / authorized_keys ne me connecte pas automatiquement

J’ai ajouté la clé ssh publique au fichier authorized_keys. ssh localhost doit 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 saisir le mot de passe. Y a-t-il un autre paramètre que je dois suivre pour que cela fonctionne?

J’ai suivi les instructions pour modifier les permissions:

Voici le résultat si je 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 ssortingng 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  

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

Vous devez vérifier les permissions du fichier authorized_keys et des dossiers de dossiers / parents dans lesquels il se trouve.

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

Pour plus d’informations, voir cette page .

Vous devrez peut-être également modifier / vérifier les permissions de votre répertoire personnel pour supprimer l’access en écriture pour le groupe et les autres.

 chmod go-w ~ 

SELinux peut également empêcher Author_keys de fonctionner. Surtout pour root dans CentOS 6 et 7. Inutile de le désactiver. Une fois que vous avez vérifié que vos permissions 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 

régler ssh authorized_keys semble être simple mais cache certains pièges que j’essaie de comprendre

– SERVEUR –

dans / etc / ssh / sshd_config set passwordAuthentication yes pour permettre au serveur d’accepter temporairement l’authentification par mot de passe

— CLIENT —

considérez cygwin comme une émulation linux et installez & lancez openssh

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

en appuyant simplement sur ENTRÉE, vous obtenez les fichiers DEFAULT 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 fichier pwd

2. placez le fichier your_key.pub sur la machine cible ssh-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. journalisation ssh user_name@host_name ne fonctionnera que par défaut id_rsa, donc voici le deuxième piège dont vous avez besoin pour ssh -i path/to/key_name user@host

(utilisez l’option ssh -v … pour voir ce qui se passe)

Si le serveur demande toujours un mot de passe, vous avez donné Entrer la phrase secrète: quand vous avez créé des clés (donc c’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 

(insignifiant si cas)

Cela indique à ssh d’accepter authored_keys et de rechercher dans le répertoire utilisateur le nom de la clé nom-sting écrit dans le fichier .ssh / authorized_keys

5 permissions de définition dans la machine cible

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

Éteignez également le mot de passe

passwordAuthentication no

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

6 Assurez-vous que la propriété et la propriété du 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. TUNNEL ssh supplémentaire pour accéder à un serveur MySQL (bind = 127.0.0.1)

Assurez-vous également que votre répertoire personnel n’est pas accessible en écriture pour d’autres personnes.

 chmod gw,ow /home/USERNAME 

La réponse est volée d’ ici

L’inscription d’une clé publique dans .ssh / authorized_keys est nécessaire mais pas suffisante pour que sshd (server) l’accepte. Si votre clé privée est protégée par une phrase secrète, vous devrez donner la phrase secrète à ssh (client) à chaque fois. Ou vous pouvez utiliser ssh-agent ou un équivalent de gnome.

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

Attention, SELinux peut également déclencher cette erreur, même si toutes les permissions semblent correctes. Sa désactivation a fait l’affaire (insérez les avertissements habituels sur la désactivation).

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

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 

La chose qui a fait le tour pour moi a finalement été de m’assurer que le propriétaire / groupe n’était pas root mais utilisateur:

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

Essayez “ssh-add” qui a fonctionné pour moi.

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 

Un autre conseil à 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é n’est pas ssh-dss .

Si vous êtes bloqué avec les clés DSA, vous pouvez réactiver le support localement en mettant à jour vos sshd_config et ~/.ssh/config avec les lignes suivantes: PubkeyAcceptedKeyTypes=+ssh-dss

Assurez-vous que l’utilisateur cible dispose d’un mot de passe défini. Exécutez le passwd username d’ passwd username pour en définir un. Cela était nécessaire pour moi même si le mot de passe de connexion SSH était désactivé.

Un autre problème que vous devez prendre en compte. 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.

Exemple est ici:

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

Dans mon cas, je devais mettre mon fichier .openssh dans .openssh .

Cet emplacement est spécifié dans /etc/ssh/sshd_config sous l’option AuthorizedKeysFile %h/.ssh/authorized_keys .

J’ai publié sudo chmod 700 ~/.ssh et chmod 600 ~/.ssh/authorized_keys et chmod go-w $HOME $HOME/.ssh d’en haut et j’ai corrigé mon problème sur une boîte CentOS7 sur laquelle j’avais déréglé les permissions pendant essayer de faire fonctionner les partages de samba. Merci

Cela semble être un problème de permission. Habituellement, cela se produit si la permission de certains fichiers / répertoires n’est pas correctement configurée. Dans la plupart des cas, ils sont ~/.ssh et ~/.ssh/* . Dans mon cas, ils sont /home/xxx .

Vous pouvez modifier le niveau de journalisation de sshd en modifiant /etc/ssh/sshd_config (recherchez LogLevel , définissez-le sur DEBUG ), puis vérifiez la sortie dans /var/log/auth.log pour voir ce qui est arrivé exactement.

cela résout mon problème

ssh-agent bash

ssh-add

Assurez-vous d’avoir copié la clé publique entière dans authorized_keys ; le préfixe ssh rsa est nécessaire pour que la clé fonctionne.

vous devez vérifier les propriétés des fichiers. pour atsortingbuer l’utilisation de la propriété requirejse:

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

sur cette note, assurez-vous que sshd config a -;

 PermitRootLogin without-password 

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

déconnectez-vous et essayez à nouveau de vous connecter!

Je crois que le défaut est -;

 PermitRootLogin no 

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.

Mon problème était un AuthorizedKeysFile modifié, lorsque 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 

J’ai le répertoire personnel dans un emplacement non standard et dans les journaux sshd j’ai cette ligne:

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

même si toutes les permissions étaient correctes (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:

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

    • c’est la ligne d’origine pour les répertoires de base réguliers:

      /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 redémarrage de sshd

Il suffit de regarder /var/log/auth.log sur le serveur . Définir de la verbosité supplémentaire avec -vv côté client n’aidera pas, car il est peu probable que le serveur offre trop d’informations à un éventuel attaquant.

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 répertoire /root lui-même (pas par exemple /root/.ssh ) ne disposait pas des permissions /root/.ssh . J’ai eu besoin:

 chown root.root /root chmod 700 /root 

Bien sûr, ces permissions devraient être similaires (peut-être chmod 770 ). Cependant, cela empêchait spécifiquement sshd de fonctionner, même si /root/.ssh et /root/.ssh/authorized_keys possédaient tous deux des permissions et des propriétaires corrects.