Comment utiliser la clé privée SSH pour vous connecter sans saisir de phrase secrète à chaque fois sur Mac OS X Lion?

Question

J'utilise Mac OS X Lion et je me connecte tous les jours aux hôtes distants via SSH. Bien que j'utilise la paire de clés SSH pour l'authentification à distance et que je n'ai pas besoin de motoriser la phrase de connexion de chaque hôte, il est toujours très ennuyant que le terminal demande la phrase secrète pour accéder à ma clé privée SSH.

Pour des raisons de sécurité, je pense qu’une phrase secrète permettant d’accéder à la clé privée SSH est indispensable. Existe-t-il un moyen qui oblige le terminal à demander la phrase exactement une fois au démarrage, puis à la mémoriser et à utiliser automatiquement ma clé privée lors de sessions SSH ultérieures?

Il existe un script appelé keychain qui fonctionne très bien sous Gentoo Linux. Mais je ne l'ai jamais compris avec Mac OS X Lion. De plus, il existe de nombreux termes intimidants, tels que ssh-agent, ssh-add. Après avoir lu divers documents sur ces boîtes à outils SSH et fait des expériences frustrantes, je suis devenu plus confus.

Je suis donc venu sur StackExchange, à la recherche de conseils sur les questions suivantes.

Quels sont ssh-agent, ssh-add, keychain, Keychain Access.app et comment ils interagissent les uns avec les autres?
Comment puis-je saisir le mot de passe de ma clé privée SSH une fois lors de la connexion et l'utiliser librement lors de la création d'une session SSH ultérieure?
Errr ... Quel est le problème avec Keychain Access.app? Il ne stocke pas la phrase SSH comme auparavant.

J'énumère ce que j'ai fait ici. J'espère qu'il y a des indices sur les étapes que j'ai manquées.

Étape 1. Créez une paire de clés SSH sur mon Mac.

$ ssh-keygen -t rsa -C "me@email.com" # Set a passphrase for accessing the private key.

Étape 2. Copiez ma clé publique SSH sur l'hôte distant. Pour prendre un exemple, je copie la clé sur localhost, Mac.

$ ssh-copy-id USER@localhost # Enter the login password for USER at localhost, not my SSH passphrase

Étape 3. Essayez ensuite de vous connecter à l'hôte distant (localhost here), via l'authentification par paire de clés SSH.

$ ssh USER@locahost Enter passphrase for key '/Users/YOUR_ACCOUNT/.ssh/id_rsa': # Enter my SSH passphrase, not the login password.

Étape 4. Déconnectez-vous de l'hôte distant et essayez à nouveau de vous y connecter. Bon sang, le terminal demande à nouveau la phrase SSH.

Une question fréquemment posée est la suivante: "Est-ce que ssh-agent fonctionne bien sur votre Mac?". Franchement, je n'ai aucune idée de ce qui se passe. Ici montrer quelques résultats en cours.

$ echo $SSH_AUTH_SOCK /tmp/launch-M48niA/Listeners $ echo $SSH_AUTH_PID (EMPTY) $ ssh-add -l Could not open a connection to your authentication agent. $ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-Z54zXukQiP/agent.26769; export SSH_AUTH_SOCK; SSH_AGENT_PID=26770; export SSH_AGENT_PID; echo Agent pid 26770; $ ssh-add -l Could not open a connection to your authentication agent. $ echo $SSH_AUTH_SOCK /tmp/launch-M48niA/Listeners $ echo $SSH_AUTH_PID (STILL EMPTY) $ ssh-agent # Oh no, anther ssh-agent with different PID SSH_AUTH_SOCK=/tmp/ssh-cx0B4FUX8B/agent.26898; export SSH_AUTH_SOCK; SSH_AGENT_PID=26899; export SSH_AGENT_PID; echo Agent pid 26899; $ ps -e | grep -i ssh 26769 ?? 0:00.03 ssh-agent 26899 ?? 0:00.02 ssh-agent

Tous les commentaires sont les bienvenus. Merci!

KutuluMike · Accepted Answer

ssh-agent est l'élément sur lequel vous voulez travailler, car il fait exactement ce que vous demandez. L'agent s'exécute en tant que démon et, lorsque vous "ajoutez" une clé privée à celui-ci, il s'en souvient et le fournit automatiquement à la sshd distante lors de la connexion initiale. (ssh-add est simplement la commande que vous exécutez pour ajouter manuellement une clé privée à ssh-agent).

Sous OS X, à partir de Leopard, vous ne devriez jamais avoir à exécuter ssh-agent ou ssh-add manuellement. Cela devrait "se produire" lorsque vous essayez de vous connecter à un serveur. Une fois par clé, il vous proposera une boîte de dialogue de mot de passe d'interface utilisateur, qui vous permettra (entre autres) d'ajouter automatiquement la clé au ssh-agent afin de ne plus recevoir d'invite.

Ceci est géré en ayant une configuration launchd qui écoute les connexions sur le socket $SSH_AUTH_SOCK et lance automatiquement ssh-agent quand il le faut pour la première fois; Ensuite, ssh-agent vous invite à entrer vos informations d'identification uniquement lorsqu'il doit ouvrir une nouvelle clé.

Si cela ne fonctionne pas, assurez-vous que le fichier de configuration launchd correct est présent:

/System/Library/LaunchAgents/org.openbsd.ssh-agent.plist

Si cela ne fonctionne toujours pas pour vous pour une raison quelconque, voici la "vieille" façon de faire fonctionner les choses à la main:

http://timesinker.blogspot.com/2007/08/getting-ssh-agent-going-on-mac-osx.html

Il y a aussi cette application, que j'ai cessé d'utiliser depuis la publication de Leopard, mais qui a essentiellement fait la même chose dans les versions précédentes de Mac OS X:

http://www.sshkeychain.org/

Jianwen W. · Answer

Au cours du processus de résolution du "problème", j'ai consulté certains sujets connexes sur Google et noté quelques notes sur le fonctionnement de ssh-agent, ssh-add, keychain, KeyChain Access.app. Finalement, il s’avère que ce problème n’est pas du tout un problème, mais que tout le monde est autour de moi, et ainsi appelé ssh-login-sans-demander-phrase-phrase-à-tout-coup fonctionne parfaitement sur Mac en boîte.

Cependant, ce processus me rapporte des expériences. J'écris mes notes ici dans l'espoir qu'elles aident quelqu'un qui confond avec ces termes.

Deux termes de mot de passe:

passphrase fait référence à la phrase requise lors de l'accès à votre clé privée SSH.
password fait référence à la phrase requise pour vous connecter à votre Mac.

Maintenant, je peux comprendre ce que font ces boîtes à outils, à savoir ssh-agent, ssh-add, keychain, Keychain Access.app sur Mac.

ssh-agent est le service critique pour permettre l'utilisation de la clé privée SSH sans saisir le mot de passe composé SSH. ssh-agent fonctionne de cette façon. Premièrement, il stocke ou en cache votre clé privée SSH dans la mémoire principale. Ensuite, plus tard dans cette session, lorsque votre clé SSH privée SSH sera nécessaire pour l'authentification à distance, ssh-agent trouvera votre clé privée dans la mémoire principale et la remettra au processus distant. La seule chance que vous soyez invité à saisir votre phrase secrète SSH est lorsque votre clé privée est ajoutée par ssh-agent initialement.
ssh-add fait partie de la collection ssh-agent, ce qui facilite la gestion de vos clés SSH dans ssh-agent. Nous utilisons la commande ssh-add pour lister, ajouter, supprimer des clés privées dans le trousseau de clés de ssh-agent. Ensuite, ssh-add communique avec le service ssh-agent pour exécuter les tâches.
keychain est un script permettant de rechercher le service ssh-agent (s'il n'existe pas, en créer un nouveau) et d'appeler ssh-add pour ajouter des clés privées SSH. keychain a une idée simple et directe, fonctionnant parfaitement sous Linux où ssh-agent ne démarre généralement pas automatiquement.
Keychain Access.app semble être le composant le plus compliqué. Il s'agit du service de stockage de jetons universel de Mac OS X. Il stocke divers jetons, tels que mots de passe, certs, etc., et sert d'agent de jeton pour les applications qui demandent les jetons. Dans notre cas de clé privée SSH, il comprend d’abord la demande d’accès à la clé privée SSH et ouvre une fenêtre vous demandant de stocker le mot de passe composé SSH, qui est une sorte de jeton, dans le trousseau de clés de Keychain Access.app. Ensuite, la prochaine fois que vous utiliserez des clés privées pour l'authentification, Keychain Access.app ouvrira une nouvelle fenêtre et vous demandera si vous accordez le privilège. Après avoir obtenu un grand oui, keychain Access.app ajoute votre clé privée dans la mémoire de ssh-agent.

Deux choses méritent votre attention:

Mac OS X Lion démarre automatiquement un service ssh-agent au démarrage en écoutant sur un socket sous /tmp.
Keychain Access.app stocke votre phrase secrète SSH afin qu'il puisse ajouter votre clé privée dans ssh-agent sans vous interrompre. Oui, pas besoin de saisir votre phrase SSH, mais de saisir le mot de passe de connexion de votre compte Mac pour accorder des privilèges lors de la création de cette entrée pour la première fois.

Donc, en résumé, SSH-login-sans-demandeur-phrase secrète devrait fonctionner sous Mac OS X en dehors de la boîte.

rowatt · Answer

Au cas où d’autres solutions ne fonctionneraient pas pour les gens, les solutions suivantes ont fonctionné pour moi.

Pour chaque clé privée de votre répertoire ~/.ssh, assurez-vous que la clé publique correspondante est également présente. Assurez-vous que la clé publique porte exactement le même nom que la clé privée mais avec .pub à la fin. Si vous avez déjà une clé publique appropriée, essayez de la régénérer.

Si vous avez besoin de recréer les clés publiques, vous pouvez le faire facilement: -

ssh-keygen -y -f ~/.ssh/my_key > ~/.ssh/my_key.pub

en remplaçant my_key par le nom de votre clé.

Après cela, MacOS se souvient de la phrase secrète de la clé dans le trousseau comme il se doit.

Remarque: entrer la phrase secrète et l'enregistrer dans le trousseau est désormais une action unique (et non pas une seule fois par session de connexion car l'OP est voulu), mais en supposant que la connexion au mac en question soit protégée par mot de passe, votre phrase secrète est protégée par ce mot de passe. De plus, cette solution n'a aucun sens pour moi… une clé publique ne devrait pas être nécessaire en plus de la clé privée, mais pour une raison quelconque, MacOSX l'exige.

(originellement de répondre à une question similaire sur Apple Stack Exchange)

Don Wood · Answer

La seule chose rarement mentionnée concernant la configuration du dossier ~/.ssh est la limitation des autorisations de répertoire.

Pour permettre à ssh d'éviter de demander le mot de passe, j'ai toujours dû définir les autorisations du répertoire de base de l'utilisateur sur 700 et les autorisations du dossier ~/.ssh sur 700.

Sinon, il continue à me demander un mot de passe même lorsque toutes les clés sont générées et copiées correctement. Un message d'erreur est généré dans les journaux d'authentification, mais il est généralement invisible pour l'utilisateur final.

Benoit Duffez · Answer

Cette réponse est légèrement pas la solution à cette question; cependant c'est très proche (j'ai fini sur cette question en cherchant une solution à mon problème).

Je fais également beaucoup de SSH sur des serveurs distants sur mon Mac, comme décrit dans cette question. Cependant, l'application Keychain Access.app a stocké la phrase clé et je n'ai pas besoin de la saisir à chaque fois que j'ai besoin de la clé pour m'authentifier sur un serveur SSH.

Cependant, j'ai activé le serveur SSH sur mon Mac afin de pouvoir me connecter à distance. Lorsque je me connectais à distance sur mon Mac, la phrase clé était toujours demandée quand je voulais SSH pour un autre hôte.

J'ai trouvé une solution qui permet de stocker la phrase clé pour la session en cours. J'ai pensé que cela pourrait être utile à quelqu'un, d'où ce post/réponse.

Lri · Answer

Une autre chose que vous auriez pu essayer aurait été de remplacer ssh-copy-id par quelque chose comme k="$(cat ~/.ssh/id_rsa.pub)"; ssh username@somehost.com "umask 0077; mkdir -p ~/.ssh; echo "$k" >> ~/.ssh/authorized_keys2".

Bob Hyatt · Answer

J'ai été perplexe sur ce problème. ssh s’applique à toutes les machines de notre département, SAUF les pommes (les MacBook et les iMac n’a pas d’importance). Je suis finalement fatigué de taper les mots de passe et décide de résoudre ce problème.

Je suis allé sur mon iMac et j'ai désactivé sshd dans le panneau des préférences de partage. Je me suis ensuite rendu à la racine et ai tapé "/ usr/sbin/sshd -d" pour lancer sshd en mode débogage. J'ai ensuite essayé de ssh sur cette machine et elle a rapidement essayé d'utiliser le protocole 2, que tout semble bien utiliser, mais sshd a rapidement signalé qu'il ne pouvait pas trouver "allowed_keys". J'avais un fichier registered_keys2 que toutes mes boîtes linux, solaris, vous nommez-le unix acceptent très bien. J'ai simplement copié registered_keys2 vers allowed_keys et BOOM. Fonctionne parfaitement maintenant.

Pourquoi * keys plutôt que * keys2 est inconnu. Surtout quand os x est assez content de known_hosts2.

Dans tous les cas, toutes nos boîtes Apple peuvent maintenant être connectées ou avoir des commandes à distance exécutées sans le mot de passe erroné: Invite ...