L'ajout de la clé publique à ~ / .ssh / allowed_keys ne me connecte pas automatiquement

StackOverflow https://stackoverflow.com/questions/6377009

  •  28-10-2019
  •  | 
  •  

Question

J'ai ajouté la clé publique ssh au fichier allowed_keys.ssh localhost devrait me connecter sans demander le mot de passe.

J'ai fait cela et j'ai essayé de taper ssh localhost, mais il me demande quand même de taper le mot de passe.Dois-je passer par un autre paramètre pour que cela fonctionne?

J'ai suivi les instructions pour modifier les autorisations:

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 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 phase de passe après le journal ci-dessus.Pourquoi ne me connecte-t-il pas sans mot de passe?

Était-ce utile?

La solution

Vous devez vérifier les autorisations du fichier authorized_keys et du dossier / des dossiers parents dans lesquels 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 d'autres. 

chmod go-w ~

Autres conseils

SELinux peut également empêcher le fonctionnement de Authorized_keys.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

La configuration de ssh authorized_keys semble simple mais cache certains pièges que j'essaie de comprendre

- SERVEUR -

dans / etc / ssh / sshd_config , définissez 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 et exécutez openssh

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

ici, en appuyant simplement sur ENTER, vous obtenez DEFAULT 2 fichiers " 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 le 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 se tromper ... vous devriez utiliser

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

3. la journalisation ssh user_name@host_name ne fonctionnera que pour id_rsa par défaut, voici donc le 2ème piège pour que vous ayez besoin de ssh -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. pour Saisir la phrase secrète: lorsque vous avez créé des clés (c'est donc 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

(sans commentaire si cas)

Cela indique à ssh d'accepter les clés_autorisées et de rechercher dans le répertoire personnel de l'utilisateur le sting de nom_clé écrit dans le fichier .ssh / authorized_keys

5 définir les autorisations sur la machine cible 

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

Désactivez également l'authentification de passe

passwordAuthentication no

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

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

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

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

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

8. supplémentaire ssh TUNNEL 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 par d'autres 

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

La réponse a été volée à ici

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 d'un terminal confus.

Lister une clé publique dans .ssh / allowed_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 de passe, vous devrez donner la phrase de passe à ssh (client) à chaque fois.Ou vous pouvez utiliser ssh-agent, ou un équivalent gnome.

Votre trace UPDATE est cohérente avec une clé privée protégée par mot de passe.Voir ssh-agent ou ssh-keygen -p.

Attention, SELinux peut également déclencher cette erreur, même si toutes les permissions semblent correctes.Le désactiver a fait l'affaire pour moi (insérez les avertissements habituels pour le désactiver).

user 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 finalement fait l'affaire pour moi a été de m'assurer que le propriétaire / groupe n'était pas root mais utilisateur: 

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

Commande d'écriture: 

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

Après avoir fait 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

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

Dans mon cas, j'avais besoin de mettre mon fichier authorized_keys dans .openssh.

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

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

cela résout mon problème

ssh-agent bash

ssh-add

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 le fichier .ssh / config et définir manuellement le fichier d'identifiant 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

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

Cela semble être un problème d'autorisation.Cela se produit généralement si l'autorisation d'un fichier / répertoire n'est pas correctement configurée.Dans la plupart des cas, il s'agit de ~/.ssh et ~/.ssh/*.Dans mon cas, ils sont /home/xxx.

Vous pouvez changer 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 s'est passé exactement.

Mon problème était un AuthorizedKeysFile modifié, alors que l'automatisation pour remplir / etc / ssh / allowed_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

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

Assurez-vous d'avoir copié toute la clé publique 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 attribuer l'utilisation de la propriété requise: 

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

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 réessayez de vous connecter!

Je crois que la valeur par 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.

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 autorisations é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:

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

    • voici la ligne originale pour les répertoires de base normaux:

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

    • voici ma nouvelle ligne:

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

  • suivi d'un restorecon -r /data/ et d'un sshd restart

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

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

chown root.root /root
chmod 700 /root

Bien sûr, ces permissions devraient être quelque chose comme ça (peut-être chmod 770) quoi qu'il en soit.Cependant, cela empêchait spécifiquement sshd de fonctionner, même si /root/.ssh et /root/.ssh/authorized_keys avaient tous les deux les autorisations et les propriétaires corrects.

Regardez /var/log/auth.log sur le serveur pour les erreurs d'auth sshd.

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

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

Puis connectez-vous depuis le 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 ces informations, j'ai réalisé que mon sshd_config limitait les connexions aux membres du groupe ssh.La commande suivante a corrigé cette erreur d'autorisation: 

sudo usermod -a -G ssh NEW_USER

J'ai eu ce problème lorsque j'ai ajouté le groupe de l'utilisateur de connexion à un autre utilisateur. Supposons 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.Le plomb 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é.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top