Je souhaite communiquer entre plusieurs ordinateurs de mon réseau (Ethernet statique), via SSH. Pour ce faire, je dois exécuter ssh-add chaque fois que je me connecte sur une machine spécifique, comment puis-je le faire pour qu'il soit configuré une fois et qu'il ne me demande pas la phrase secrète à chaque fois que je me connecte ou redémarre ma machine ?
Je sais qu'il existe un moyen d'ajouter quelques lignes au bash_profile fichier, mais je dois toujours saisir le mot de passe chaque fois que je redémarre/me connecte à une machine spécifique.
if [ -z "$SSH_AUTH_SOCK" ] ; then
eval `ssh-agent -s`
ssh-add
fi
Réponse acceptée :
Il s'agit d'un exemple typique de compromis entre sécurité et commodité. Heureusement, il existe plusieurs options. La solution la plus appropriée dépend du scénario d'utilisation et du niveau de sécurité souhaité.
clé ssh avec phrase de passe, non ssh-agent
Maintenant, la phrase de passe doit être saisie à chaque fois que la clé est utilisée pour l'authentification. Bien qu'il s'agisse de la meilleure option du point de vue de la sécurité, elle offre la pire convivialité. Cela peut également conduire à choisir une phrase de passe faible afin de réduire le fardeau de la saisir à plusieurs reprises.
clé ssh avec phrase de passe, avec ssh-agent
Ajout de ce qui suit à ~/.bash_profile démarrera automatiquement ssh-agent et chargez la ou les clés ssh lors de la connexion :
if [ -z "$SSH_AUTH_SOCK" ] ; then
eval `ssh-agent -s`
ssh-add
fi
Désormais, la phrase secrète doit être saisie à chaque connexion. Bien que légèrement meilleur du point de vue de la convivialité, cela présente l'inconvénient que ssh-agent demande la phrase secrète, que la clé soit utilisée ou non pendant la session de connexion. Chaque nouvelle connexion génère également un ssh-agent distinct instance qui reste en cours d'exécution avec les clés ajoutées en mémoire même après la déconnexion, sauf si elle est explicitement supprimée.
Pour tuer ssh_agent à la déconnexion, ajoutez ce qui suit à ~/.bash_logout
if [ -n "$SSH_AUTH_SOCK" ] ; then
eval `/usr/bin/ssh-agent -k`
fi
ou le suivant à ~/.bash_profile
trap 'test -n "$SSH_AUTH_SOCK" && eval `/usr/bin/ssh-agent -k`' 0
Création de plusieurs ssh-agent Les instances peuvent être évitées en créant un socket de communication persistant vers l'agent à un emplacement fixe dans le système de fichiers, comme dans la réponse de Collin Anderson. Il s'agit d'une amélioration par rapport à la génération d'instances d'agents multiples, cependant, à moins qu'elle ne soit explicitement supprimée, la clé déchiffrée reste en mémoire après la déconnexion.
Sur les ordinateurs de bureau, les agents ssh inclus avec l'environnement de bureau, tels que l'agent Gnome Keyring SSH, peuvent être une meilleure approche car ils peuvent généralement être amenés à demander la phrase secrète la première fois que la clé ssh est utilisée lors d'une session de connexion et stocker la clé privée déchiffrée en mémoire jusqu'à la fin de la session.
clé ssh avec phrase de passe, avec ssh-ident
ssh-ident est un utilitaire qui peut gérer ssh-agent en votre nom et chargez les identités si nécessaire. Il ajoute les clés une seule fois selon les besoins, quel que soit le nombre de terminaux, de sessions ssh ou de connexion nécessitant l'accès à un ssh-agent . Il peut également ajouter et utiliser un agent différent et un jeu de clés différent en fonction de l'hôte auquel il est connecté ou du répertoire à partir duquel ssh est invoqué. Cela permet d'isoler les clés lors de l'utilisation du transfert d'agent avec différents hôtes. Il permet également d'utiliser plusieurs comptes sur des sites comme GitHub.
Pour activer ssh-ident , installez-le et ajoutez l'alias suivant à votre ~/bash_profile :
alias ssh='/path/to/ssh-ident'
clé ssh avec phrase de passe, avec keychain
keychain est un petit utilitaire qui gère ssh-agent en votre nom et
autorise le ssh-agent pour rester en cours d'exécution lorsque la session de connexion se termine. Lors des connexions suivantes, keychain se connectera au ssh-agent existant exemple. En pratique, cela signifie que la phrase secrète doit être saisie uniquement lors de la première connexion après un redémarrage. Lors des connexions suivantes, la clé non chiffrée du ssh-agent existant instance est utilisée. Cela peut également être utile pour autoriser l'authentification RSA/DSA sans mot de passe dans cron travaux sans clés ssh sans mot de passe.
Pour activer le keychain , installez-le et ajoutez quelque chose comme ceci à ~/.bash_profile :
eval `keychain --agents ssh --eval id_rsa`
Du point de vue de la sécurité, ssh-ident et keychain sont pires que ssh-agent instances limitées à la durée de vie d'une session particulière, mais elles offrent un haut niveau de commodité. Pour améliorer la sécurité de keychain , certaines personnes ajoutent le --clear option à leur ~/.bash_profile invocation du trousseau. En faisant cela, les phrases de passe doivent être ressaisies lors de la connexion comme ci-dessus, mais cron les tâches auront toujours accès aux clés non chiffrées après la déconnexion de l'utilisateur. Le keychain La page wiki contient plus d'informations et d'exemples.
clé ssh sans mot de passe
Du point de vue de la sécurité, c'est la pire option car la clé privée n'est pas du tout protégée au cas où elle serait exposée. C'est cependant le seul moyen de s'assurer que la phrase de passe n'a pas besoin d'être ressaisie après un redémarrage.
clé ssh avec phrase de passe, avec ssh-agent , transmettre la phrase secrète à ssh-add du script
Bien que cela puisse sembler une idée simple de transmettre la phrase secrète à ssh-add à partir d'un script, par ex. echo "passphrase\n" | ssh-add , ce n'est pas aussi simple qu'il n'y paraît que ssh-add ne lit pas la phrase secrète de stdin , mais ouvre /dev/tty directement pour la lecture.
Cela peut être contourné avec expect , un outil d'automatisation d'applications interactives. Vous trouverez ci-dessous un exemple de script qui ajoute une clé ssh à l'aide d'une phrase de passe stockée dans le script :
#!/usr/bin/expect -f
spawn ssh-add /home/user/.ssh/id_rsa
expect "Enter passphrase for /home/user/.ssh/id_rsa:"
send "passphrase\n";
expect "Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)"
interact
Notez que comme la phrase de passe est stockée en clair dans le script, du point de vue de la sécurité, ce n'est guère mieux que d'avoir une clé ssh sans mot de passe. Si cette approche doit être utilisée, il est important de s'assurer que le expect le script contenant la phrase de passe dispose des autorisations appropriées, ce qui le rend lisible, inscriptible et exécutable uniquement par le propriétaire de la clé.