Comment éviter de demander à la phrase secrète chaque fois que j'appuie sur Bitbucket

J’ai mis en place mes fichiers SSH à l’aide de ce guide , qui fonctionnait bien auparavant (je pouvais courir hg pushsans demander de phrase secrète). Qu'est-ce qui aurait pu se passer entre maintenant et maintenant, étant donné que j'utilise toujours le même répertoire de base.

$ cat .hg/hgrc 
[paths]
default = ssh://hg@bitbucket.org/tshepang/bloog

$ hg push
Enter passphrase for key '/home/wena/.ssh/id_rsa': 
pushing to ssh://hg@bitbucket.org/tshepang/bloog
searching for changes
...

Vous devez utiliser un agent SSH. Réponse courte: essayez

$ ssh-add

avant de pousser. Fournissez votre phrase secrète à la demande.

Si vous n'exécutez pas déjà d'agent ssh, vous recevrez le message suivant:

Could not open a connection to your authentication agent.

Dans cette situation, vous pouvez en démarrer un et configurer ainsi votre environnement.

eval $(ssh-agent)

Puis répétez la ssh-addcommande.

Il vaut la peine de consulter la page de manuel de l'agent ssh .

Une façon de résoudre ceci est avec ssh-agentet ssh-add:

$ exec ssh-agent bash
$ ssh-add
Enter passphrase for ~/.ssh/id_rsa: 

Ensuite, la phrase secrète est enregistrée pour la session en cours. et ne sera plus demandé.

J'utilise Keychain pour gérer les clés SSH. Il est également disponible dans Debian et donc vraisemblablement Ubuntu avec

apt-get install keychain

Voici la page du paquet du trousseau Debian . Comme vous pouvez le constater, le projet n’est pas très actif, mais fonctionne pour moi. J'ai également commenté un peu à ce sujet dans une autre réponse ici

Créez (ou éditez s'il existe) le fichier ~ / .ssh / config suivant:

Host *
    UseKeychain yes
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_rsa

Pour plus de commodité, la méthode optimale est une combinaison des réponses de jmtd et de Faheem .

Utiliser ssh-agentseul signifie qu'une nouvelle instance de ssh-agentdoit être créée pour chaque nouveau terminal que vous ouvrez. keychainune fois initialisé, il demandera le mot de passe composé pour la ou les clés privées et le stockera. De cette façon, votre clé privée est protégée par un mot de passe, mais vous n’aurez pas à entrer votre mot de passe encore et encore.

Le wiki Arche recommande de l' initialisation porte - clés /etc/profile.d/ou votre profil de shell, comme .bash_profileou .bashrc. Cela a pour inconvénient d’initialiser votre trousseau dès que vous ouvrez un terminal.

Une approche plus flexible consiste à combiner keychainavec une tmuxsession spécifique . Donc, dans .bash_profile:

tsess=$(tmux ls 2>&1)

if [[ "${tsess%%:*}" = "secured" ]] && 
   [[ -f $HOME/.keychain/$HOSTNAME-sh ]]; then
    # start keychain
    /usr/bin/keychain -Q -q --nogui ~/.ssh/id_rsa
    . $HOME/.keychain/$HOSTNAME-sh
fi

... et il ne vous reste plus qu'à démarrer la tmuxsession sécurisée au fur et à mesure des besoins (lancée à partir d'un raccourci clavier):

#!/bin/bash
PID=$(pgrep tmux)
new="tmux -f $HOME/.tmux/conf new -s secured"
old="tmux attach -t secured -d"

if [[ -z "$SSH_AUTH_SOCK" ]]; then
    eval `ssh-agent`
    trap "kill $SSH_AGENT_PID" 0
fi

if [[ -z "$PID" ]]; then
    urxvtc -title "SSH" -e sh -c "${new}"
else
    urxvtc -title "SSH" -e sh -c "${old}"
fi

ssh-add

Désormais, votre trousseau ne sera initialisé qu'une fois lorsque vous démarrez cette tmuxsession spécifique . Tant que cette session persiste, vous pourrez accéder à ces sshclés et accéder à vos référentiels distants.

Vous pouvez utiliser sshpass:

$ sudo apt-get install sshpass
$ sshpass -p 'password' ssh username@server

Vous avez juste besoin d'ajouter sshpass -p yourpassphraseavant d'ajouter votre sshcommande habituelle .