ssh demande un mot de passe malgré ssh-copy-id

J'utilise l'authentification par clé publique sur un serveur distant depuis un certain temps maintenant pour une utilisation du shell distant ainsi que pour les montages sshfs. Après avoir forcé un umount de mon répertoire sshfs, j'ai remarqué que ssh a commencé à me demander un mot de passe. J'ai essayé de purger le .ssh / authorized_keys distant de toute mention de la machine locale, et j'ai nettoyé la machine locale des références à la machine distante. J'ai ensuite répété mon ssh-copy-id, il m'a demandé un mot de passe et est revenu normalement. Mais voilà, quand je ssh vers le serveur distant, on me demande toujours un mot de passe. Je suis un peu confus quant à ce que le problème pourrait être, des suggestions?

sshd devient bizarre à propos des autorisations sur $ HOME, $ HOME / .ssh (les deux répertoires) et sur $ HOME / .ssh / authorized_keys.

Une de mes boîtes Linux s'est retrouvée avec des autorisations drwxrwxrwx sur mon répertoire $ HOME. Une boîte Linux Arch ne voulait absolument pas se connecter en utilisant des clés publiques jusqu'à ce que j'aie supprimé l'autorisation «w» pour le groupe, autre sur mon répertoire $ HOME.

Essayez de faire en sorte que $ HOME et $ HOME / .ssh / aient des autorisations plus restrictives pour le groupe et les autres. Voyez si cela ne permet pas à sshd de faire son travail.

Les autorisations suivantes sont nécessaires:

• Le .sshdossier:700 (drwx------)
• La clé publique: 644 (-rw-r--r--)
• La clé privée: 600 (-rw-------)

J'ai également récemment rencontré ce problème.

Il a été corrigé en modifiant les autorisations du $HOMErépertoire. Cependant, la simple exécution chmod g-w ~/n'a pas résolu le problème. En plus, chmod g-w ~/j'avais également besoin de modifier les autorisations de otherssur le $HOMErépertoire en exécutantchmod o-wx ~/

Ensemble:

chmod g-w ~/
chmod o-wx ~/

Notez que je ne sais pas si o-xc'était nécessaire, je l'ai simplement exécuté par précaution.

La modification des autorisations pour le dossier ~ / .ssh a résolu mon problème selon cet article sur Super User SE .

Le problème se produit-il également sur les connexions parallèles, c'est-à-dire si vous essayez de monter sshfs tout en ayant une session ssh ouverte? Sinon, je suppose que votre répertoire personnel est chiffré? Dans ce cas $HOME/.ssh/authorized_keys, ne deviendrait utilisable sur la machine distante qu'après votre première connexion (en utilisant votre mot de passe).

Consultez https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Troubleshooting pour une explication et la solution de contournement requise.

Je posterais ceci en tant que commentaire, mais ce serait probablement trop long. Je voulais juste ajouter qui ssh-copy-idessaie d'envoyer la clé publique à partir de l' /.sshemplacement dans votre $HOMEdossier.

Si vous essayez en sshtant que root avec une clé publique (enregistrez les commentaires liés à la sécurité), ssh-copy-idessayez de vous connecter avec la mauvaise clé publique si votre $HOMEvariable est définie sur autre chose que /root(par exemple, être défini sur le répertoire personnel de votre utilisateur normal ), l'utilisateur root serait donc invité car la clé publique de root n'est pas installée sur le système distant.

Vous pouvez utiliser la ligne unique suivante pour spécifier la clé publique exacte:

pub="$(cat /root/.ssh/id_rsa.pub)"; ssh user@remotehost "echo $pub >> .ssh/authorized_keys; chmod 700 .ssh; chmod 600 .ssh/authorized_keys"

J'ai rencontré ce scénario à plusieurs reprises dans la nature (y compris ce matin) et j'ai pensé que j'essaierais de mettre mes 2 cents, au cas où quelqu'un se retrouverait dans la même situation.

Comme d'autres contributeurs l'ont mentionné, il s'agit probablement d'un problème d'autorisation.

La meilleure façon de diagnostiquer cela est de redémarrer le démon SSH sur le serveur distant avec l'option de débogage activée - généralement l'option "-d". Le message du démon OpenSSH est très explicite. Par exemple, vous verrez des messages tels que:

Authentication refused: bad ownership or modes for directory /some/path

La raison pour laquelle la clé publique n'a pas survécu après le redémarrage est que le répertoire personnel de mon serveur a été chiffré. (vous faites cela lors de l'installation du serveur)

Un autre problème possible est que le serveur ne prend pas en charge votre algorithme de clé. Dans mon cas, j'ai trouvé les messages suivants dans mes sshdjournaux ( /var/log/auth.logdans mon cas):

userauth_pubkey: unsupported public key algorithm: ssh-ed25519 [preauth]

Si tel est le cas, vous devez soit activer la prise en charge de cet algorithme dans votre sshdconfiguration (ce qui peut nécessiter une mise à jour vers une sshdversion plus récente ), soit passer votre clé à un algorithme pris en charge par celui auquel sshdvous essayez de vous connecter. .

Comme cette question apparaît parmi les premiers résultats de recherche lors de la recherche de ce comportement sur Google, j'ajouterai également ma solution:

Dans mon cas, cela n'avait rien à voir avec les autorisations. Pour une raison quelconque (je n'ai pas pris la peine de savoir pour quelle raison en fait, car j'ai trouvé une solution rapide) lors de l'exécution de la commande ssh, le programme n'a pas recherché le bon fichier d'identité. Une solution consistait à ajouter manuellement sur le serveur distant une clé SSH que le programme SSH a essayé d'utiliser. Vous pouvez observer ce que fait le programme SSH lors de l'exécution de la commande en ajoutant -v à la commande:

ssh -v username@your-host-ip-or-domain 

Ensuite, il vous suffit de saisir sur votre ordinateur local toute clé publique pour laquelle le programme SSH essaie de trouver un fichier d'identité / clé privée pour, sur un Mac par exemple:

cat ~/.ssh/id_rsa.pub

... et ajoutez-le au fichier authorized_keys de la télécommande dans:

~/.ssh/authorized_keys

Une autre, dans mon cas, une meilleure solution était d'ajouter un hôte personnalisé dans mon fichier de configuration ssh local. Sur mon Mac c'est:

/Users/my-user-name/.ssh/config

Ici, vous pouvez par exemple ajouter quelque chose comme ceci:

Host mynewserver
        HostName some.IP.number.or.domain
        Port 20000 #if custom port is used and not the default 22
        User the_root
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa_for_my_new_server

Il vous suffit ensuite d'exécuter:

ssh mynewserver

... et Voilà