SSH sans mot de passe ne fonctionne qu'une fois

Question

Je veux configurer SSH pour l'utiliser sans avoir à écrire le mot de passe. J'utilise Ubuntu 18.04 LTS sous Windows 10. J'en ai besoin pour exécuter Hadoop 3.1.1 ( https://hadoop.Apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-common/ SingleCluster.html # Standalone_Operation ) en utilisant le mode pseudo-distribué.

J'ai essayé beaucoup de solutions différentes mais sans aucun résultat. J'ai obtenu que la première fois que j'ai utilisé la commande ssh localhost, je n'ai pas besoin d'écrire la phrase secrète, mais lorsque je réécris, je dois écrire la phrase secrète.

J'explique les différentes étapes que j'ai suivies:

J'ai créé une clé avec ssh-keygen -t rsa
J'ajoute la clé publique aux fichiers allowed_keys: cat ~/.ssh/id_rsa.pub >> ~/.ssh/allowed_keys
J'ajoute la clé qui exécute: exec ssh-agent bash et ssh-add id_rsa (Il y a des années, j'avais parfois des problèmes différents et j'utilisais différentes solutions: https://superuser.com/questions/1147145/ quelles-sont-les-différences-entre-les-ces-manières-d'utiliser-l'agent-ssh )
J'exécute: ssh localhost

À ce stade, tout va bien, mais lorsque je relance ssh localhost, je dois alors écrire la phrase secrète. Ces étapes ont bien fonctionné dans Ubuntu d’AWS il ya 3 ans.

J'ai essayé au point 3 cette autre méthode: https://www.ssh.com/ssh/copy-id

Toutes les solutions possibles que j'ai trouvées sont identiques à celles que j'ai essayées au point 3 ou que je pense. J'ai essayé de modifier les autorisations de allowed_keys et .ssh, comme dans d'autres solutions, mais sans succès.

earthmeLon · Answer

Vous devriez jeter un oeil à cette réponse qui décrit la configuration de ssh pour votre utilisateur (édition de ~/.ssh/config) et d'autres détails.

Les étapes sont les suivantes:

Générez votre clé ssh.
Ajoutez l'hôte à votre fichier ~/.ssh/config.
Ajoutez votre clé publique (.pub) au ~/.ssh/authorized_keys De l'utilisateur distant.
- Cela se fait plus facilement avec la commande ssh-copy-id.
- ssh est très particulier sur les autorisations de ~/.ssh/ et les fichiers qu'il contient. ssh-copy-id gère tout pour vous.
Essayez de vous connecter à l'hôte:
- ssh Host
- ssh Host -vvv # Verbose output for troubleshooting

Essayez-vous d'utiliser ssh-agent parce que vos clés sont protégées par un mot de passe? Je recommanderais de travailler manuellement en se connectant sans ssh-agent et de le faire fonctionner. Une fois que votre clé fonctionne, vous pouvez résoudre tous les problèmes spécifiques de ssh-agent.

Pour résoudre ce problème, veillez à utiliser ssh en mode commenté et à surveiller (tail -f) le fichier /var/log/auth.log du serveur distant. Sur les systèmes plus récents, vous devrez peut-être utiliser journalctl (journalctl -u sshd | tail -f).

Une fois que la clé fonctionne, vous pouvez consulter la documentation de ssh-agent, telle que cet ensemble d'instructions de configuration . Les étapes sont généralement les suivantes:

Générez vos clés (comme vous l'avez déjà fait).
Installez les clés (comme vous l'avez déjà fait).
Démarrer ssh-agent
- eval ssh-agent
- Une seule fois, pas chaque connexion ou quoi que ce soit.
- Cela peut se faire automatiquement, en fonction du moment et de l'utilisateur.
Ajoutez votre clé à ssh-agent:
- ssh-add ~/.ssh/private_key

Veillez à consulter les autres options de configuration ssh-agent, telles que la durée pendant laquelle vos clés resteront déverrouillées.

En résumant un peu, votre problème est probablement l'un de ceux-ci:

Vous dites que vous avez ajouté ssh-agent à partir de, et l'ajout de votre clé id_rsa (dans le passé), mais maintenant que vous avez généré une nouvelle clé, cette clé devra également être ssh-add '.
- Vérifiez que ssh-agent est en cours d'exécution sur votre système si vous rencontrez des problèmes après l'ajout de la clé.
- ps aux | ssh-agent
Vous ajoutez la clé à votre fichier local, pas au fichier de l'utilisateur distant.
- Pensez-y comme si vous ajoutiez un mot de passe. Vous devez donc ajouter le mot de passe sur le système qui devrait l'accepter.
- Votre hôte distant est localhost, mais cela suppose que vous souhaiterez pouvoir travailler sur des hôtes distants ultérieurement. Toutefois, il doit toujours figurer dans le répertoire correct $HOME pour le bon utilisateur.
Vous dites que ça marche une seule fois? Cela fonctionne-t-il deux fois si vous essayez deux fois dans un délai plus court, disons une minute? J'essaie de comprendre si votre ssh-agent est simplement configuré pour verrouiller votre clé dans un délai plus court que celui que vous avez testé.
Lors de l’ajout au fichier ~/.ssh/authorized_keys (>>), vous avez initialement créé le fichier, avec des autorisations incorrectes.
- Ne procédez pas comme suit sans sécuriser l'accès et effectuer des sauvegardes sur des fichiers distants.
- Si votre 'hôte distant' est localhost, il y a très probablement des fichiers que vous souhaitez conserver, tels que vos clés, et qui doivent être sauvegardés avant d'être supprimés.
- Supprimez le répertoire ~/.ssh/ complet et utilisez ssh-copy-id pour saisir correctement votre utilisateur sur l'hôte distant.
- Cela s'afficherait sur auth.log de l'hôte distant et indiquerait que les autorisations de fichier sont incorrectes.
- Si vous continuez à rencontrer des problèmes après avoir utilisé ssh-copy-id pour créer le répertoire et les fichiers, envoyez les autorisations de ~/.ssh et vos fichiers de clés générés.
Après avoir ssh dans l'hôte distant, vous perdez ssh-agent, sauf si vous avez configuré ssh-agent, et ssh via ~/.ssh/config en ForwardAgent yes. Si vous souhaitez transférer ssh-agent, vous devrez le configurer pour autoriser cela et comprendre les implications en termes de sécurité de cette décision. Il convient également de noter que ForwardAgent peut être conçu pour fonctionner sur différentes machines et qu'il peut ne pas être possible de faire fonctionner le transfert localement en raison de complications avec ssh-agent en cours d'exécution.