Ceci est un exemple typique de compromis entre sécurité et commodité. Heureusement, il existe un certain nombre d'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 secrète, non ssh-agent
Maintenant, la phrase secrète doit être entrée chaque fois que la clé est utilisée pour l'authentification. Bien que ce soit la meilleure option du point de vue de la sécurité, elle offre la pire utilisabilité. Cela peut également conduire à choisir une phrase secrète faible dans l'ordre afin d'alléger le fardeau de la saisie répétée.
ssh-key avec mot de passe, avec ssh-agent
Ajouter ce qui suit pour ~/.bash_profiledémarrer automatiquement ssh-agentet charger la / les clé (s) ssh lors de la connexion:
if [ -z "$SSH_AUTH_SOCK" ] ; then
eval `ssh-agent -s`
ssh-add
fi
Maintenant, la phrase secrète doit être entrée à chaque connexion. Bien que légèrement meilleur du point de vue de la convivialité, cela présente l'inconvénient de ssh-agentdemander la phrase secrète, que la clé soit utilisée ou non au cours de la session de connexion. Chaque nouvelle connexion génère également une ssh-agentinstance distincte qui reste en cours d'exécution avec les clés ajoutées en mémoire, même après la déconnexion, à moins d'être explicitement tué.
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 pour ~/.bash_profile
trap 'test -n "$SSH_AUTH_SOCK" && eval `/usr/bin/ssh-agent -k`' 0
La création de plusieurs ssh-agentinstances peut être évitée en créant un socket de communication persistante avec l'agent à un emplacement fixe dans le système de fichiers, comme dans la réponse de Collin Anderson . Il s'agit toutefois d'une amélioration par rapport à la création d'instances d'agents multiples, sauf si la clé déchiffrée est explicitement détruite, elle reste en mémoire après la déconnexion.
Sur les ordinateurs de bureau, les agents ssh inclus dans l’environnement de bureau, tels que l’ agent SSH Gnome Keyring , peuvent constituer une meilleure approche, car ils peuvent généralement être invités à demander la phrase secrète lors de la première utilisation de la clé ssh au cours d’une session de connexion. stockez la clé privée déchiffrée en mémoire jusqu'à la fin de la session.
ssh-key avec mot de passe, avec ssh-ident
ssh-identest un utilitaire qui peut gérer ssh-agenten votre nom et charger les identités si nécessaire. Il n’ajoute les clés qu’une fois selon les besoins, quel que soit le nombre de terminaux, de sessions SSH ou de sessions de connexion nécessitant l’accès à un ssh-agent. Il peut également ajouter et utiliser un agent différent et un ensemble de clés différent en fonction de l'hôte auquel vous êtes connecté ou du répertoire à partir duquel ssh est appelé. Cela permet d'isoler les clés lors de l'utilisation du transfert d'agent avec différents hôtes. Cela permet également d'utiliser plusieurs comptes sur des sites tels que GitHub.
Pour l'activer ssh-ident, installez-le et ajoutez l'alias suivant à votre ~/bash_profile:
alias ssh='/path/to/ssh-ident'
ssh-key avec mot de passe, avec keychain
keychainest un petit utilitaire qui gère ssh-agenten votre nom et permet ssh-agentde rester actif à la fin de la session de connexion. Lors des connexions suivantes, keychainse connectera à l' ssh-agentinstance existante . En pratique, cela signifie que le mot de passe doit être saisi uniquement lors de la première connexion après un redémarrage. Lors des connexions suivantes, la clé non chiffrée de l' ssh-agentinstance existante est utilisée. Cela peut également être utile pour permettre une authentification RSA / DSA cronsans mot de passe dans des travaux sans clé ssh sans mot de passe.
Pour l'activer keychain, installez-le et ajoutez quelque chose comme ce qui suit ~/.bash_profile:
eval `keychain --agents ssh --eval id_rsa`
D'un point de vue de la sécurité, ssh-identet keychainsont pires que des ssh-agentcas limités à la durée de vie d'une session particulière, mais ils offrent un haut niveau de confort. Pour améliorer la sécurité de keychain, certaines personnes ajoutent l' --clearoption à leur ~/.bash_profileinvocation de trousseau. En procédant ainsi, vous devez saisir à nouveau les mots de passe lors de la connexion, comme indiqué ci-dessus, mais les crontâches auront toujours accès aux clés non chiffrées après la déconnexion de l'utilisateur. La keychain page wiki contient plus d'informations et d'exemples.
clé ssh sans phrase secrète
Du point de vue de la sécurité, il s’agit de la pire des solutions car la clé privée n’est totalement pas protégée au cas où elle serait exposée. C’est toutefois le seul moyen de s’assurer que la phrase secrète n’a pas besoin d’être saisie à nouveau après un redémarrage.
ssh-key avec phrase secrète, avec ssh-agent , en passant la phrase secrète à ssh-add partir du script
Bien que cela puisse sembler une idée simple de passer la phrase secrète à ssh-addpartir d'un script, par exemple echo "passphrase\n" | ssh-add, ce n'est pas aussi simple qu'il n'y paraît, car ssh-add cela ne lit pas la phrase secrète stdin, mais s'ouvre /dev/ttydirectement à la lecture .
Ceci peut être contourné avec expect, un outil pour automatiser des applications interactives. Voici un exemple de script qui ajoute une clé ssh à l'aide d'une phrase secrète 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 secrète est stockée en texte brut dans le script, du point de vue de la sécurité, cela 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 vous assurer que les expectautorisations appropriées sont attribuées au script contenant la phrase secrète, de manière à ce qu'il soit lisible, inscriptible et exécutable uniquement par le propriétaire de la clé.