Comment puis-je exécuter ssh-add automatiquement, sans invite de mot de passe?

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 à 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 des lignes au bash_profilefichier, mais je dois tout de même taper 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

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é.

Ajoutez ceci à votre ~/.bashrc, puis déconnectez-vous et reconnectez-vous pour prendre effet.

if [ ! -S ~/.ssh/ssh_auth_sock ]; then
  eval `ssh-agent`
  ln -sf "$SSH_AUTH_SOCK" ~/.ssh/ssh_auth_sock
fi
export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock
ssh-add -l > /dev/null || ssh-add

Cela ne devrait vous demander un mot de passe que la première fois que vous vous connectez après chaque redémarrage. Il continuera à réutiliser le même ssh-agenttant qu'il reste en marche.

Pas étroitement lié à la question du PO, mais cela pourrait être utile à d'autres: depuis la version 7.2.0, ssh (1) dispose d'une option permettant d'ajouter une clé à ssh-agent lors de la première authentification; l'option est AddKeysToAgentet peut être réglé sur yes, no, askou confirm, ou sur votre systemwide personnel .ssh/configfichier.

Référence: https://www.openssh.com/txt/release-7.2

ssh-agent met en cache différentes clés ssh déverrouillées, de sorte que vous pouvez protéger les clés ssh par un mot de passe, sans avoir à les saisir à chaque fois.

Afin de mettre en cache les clés déverrouillées, il doit évidemment les déverrouiller. Pour déverrouiller des clés verrouillées avec une phrase secrète, il est évidemment nécessaire de connaître ces phrases secrètes.

Toute méthode qui ne nécessite pas l'autorisation d'un être humain (par exemple, "taper un mot de passe") ne rendra pas seulement votre système peu sûr; cela va également vider de son sens tout le but de ssh-agent.

Ceci dit, vous pouvez simplement utiliser des clés ssh qui ne sont pas protégées Enterpar un mot de passe (appuyez sur la touche lorsqu'un mot de passe est demandé lors de la génération de la clé). Comme il n'y a pas de mot de passe, il ssh-agentn'est pas nécessaire de vous en demander un pour le (ne pas) le mettre en cache.

Voici une solution de contournement pour automatiser votre phrase secrète SSH.

1. Créez un script à une ligne qui imprime votre phrase secrète sur la sortie standard, par exemple:

    echo 'echo MY_SSH_PASSWORD' > ~/.print_ssh_password && chmod 700 ~/.print_ssh_password
   

   Important: Assurez-vous de copier le premier espace pour éviter de stocker votre mot de passe dans votre historique .

Et utilisez l'une des méthodes ci-dessous.

• en utilisant une approche d'entrée standard:

  cat ~/.ssh/id_rsa | SSH_ASKPASS=~/.print_ssh_password ssh-add -
  

• ou approche de conduite nommée :

  1. Créez un canal nommé (vous pouvez également essayer une substitution de processus ):

     mkfifo --mode 0600 ~/.ssh_fifo
     

  2. Exécuter ssh-adden spécifiant le programme utilisé pour l'authentification:

     cat ~/.ssh/id_rsa >~/.ssh_fifo | SSH_ASKPASS=~/.print_ssh_password ssh-add ~/.ssh_fifo
     

  Voir: man ssh-addpour en savoir plus sur SSH_ASKPASS.

Je ne vous recommanderai pas ssh-add (qui doit ouvrir un agent ssh) à la connexion. En effet, vous ne pouvez pas contrôler le moment auquel la section ssh-agent se termine et créer un risque pour la sécurité lorsque vous n'avez pas besoin d'utiliser les fichiers de clés dans une section de connexion.

Je recommande plutôt d'écrire un script qui ouvre un sous-shell de section de ssh-agent, avec tous les fichiers de clés automatiquement ajouté, et d'être appelé en cas de besoin pour utiliser ssh. Si vous pouviez l’adopter, lisez la suite.

Vous auriez deux choix:

1. Supprimez toutes les phrases secrètes de vos clés, qui ont une sécurité faible cas de vol de vos fichiers de clés. (donc pas recommandé )

2. Utilisez le même mot de passe pour vos clés. Puis quand tussh-add keyfile1 keyfile2 ... aurez besoin de saisir la phrase secrète une seule fois, par section.

Dans les deux cas, vous pouvez écrire le fichier de script "ssh_keys_section.sh" comme ci-dessous:

#!/bin/bash
# This script run a ssh-agent on a sub-shell and automatically ssh-add all keyfiles at once.
# This agent ends when you type `exit` to close the sub-shell.
exec ssh-agent bash -c "ssh-add /path/to/keyfile1 /path/to/keyfile2 ...; exec bash"

Remarques:

• Commande pour changer ou supprimer le mot de passe: ssh-keygen -p -f keyfile
• Dans le sous-shell, vous pouvez même créer un nombre plus important de terminaux partageant les mêmes clés non verrouillées, en utilisant peut-être une commande du type /path/to/yourterminal &(dépend du système d'exploitation).

if [ ! -S ${HOME}/.ssh/ssh_auth_sock ]; then
  eval $(ssh-agent)
  ln -sf "${SSH_AUTH_SOCK}" ${HOME}/.ssh/ssh_auth_sock
fi
export SSH_AUTH_SOCK=${HOME}/.ssh/ssh_auth_sock

ssh_keys=$(find -E ~/.ssh -type f -regex '.*(rsa$|pem)')
ssh_agent_keys=$(ssh-add -l | awk '{key=NF-1; print $key}')

for k in "${ssh_keys}"; do
    for l in "${ssh_agent_keys}"; do
        if [[ ! "${k}" = "${l}" ]]; then
            ssh-add "${k}" > /dev/null 2>&1
        fi
    done
done

J'avais l'habitude d'utiliser le script mentionné par steampowered, j'ai créé celui ci-dessous maintenant, car il ne laisse pas traîner de fichiers.

Travailler sur la zshcoquille seulement.

#!/bin/sh

AGENT_BIN=`which ssh-agent`
AGENT_ADD_BIN=`which ssh-add`
AGENT_PID=`ps -fe | grep ${AGENT_BIN} | awk -vuser=$USER -vcmd="$AGENT_BIN" '$1==user && $8==cmd{print $2;exit;}'`
if [ -z "$AGENT_BIN" ]; then
    echo "no ssh agent found!";
    return
fi
if [ "" -eq "$AGENT_PID" ]; then
    if read -sq "YN?Do you want to unlock your ssh keys?"; then
        echo ""
        output=`$AGENT_BIN | sed 's/echo/#echo/g'`
        eval $output
        $AGENT_ADD_BIN
    fi
else
    for f in "/proc/"*
    do
        cmdline=`cat "$f/cmdline"`
        if [ "${AGENT_BIN}" -ef "${cmdline}" ]; then
            export SSH_AUTH_SOCK=`cat $f/net/unix | grep --binary-file=text -oP '((/[^/]*?)+/ssh-[^/]+/agent\.\d+$)'`
            export SSH_AGENT_PID=${f##*/}
            break;
        fi
    done
fi

SSH_ENV="$HOME/.ssh/environment"

function start_agent {
     echo "Initialising new SSH agent..."
     /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
     echo succeeded
     chmod 600 "${SSH_ENV}"
     . "${SSH_ENV}" > /dev/null
     /usr/bin/ssh-add;
}

# Source SSH settings, if applicable

if [ -f "${SSH_ENV}" ]; then
     . "${SSH_ENV}" > /dev/null
     #ps ${SSH_AGENT_PID} doesn't work under cywgin
     ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
         start_agent;
     }
else
     start_agent;
fi

Donner du crédit ici: https://www.cygwin.com/ml/cygwin/2001-06/msg00537.html

Cette solution est également approuvée ici: http://mah.everybody.org/docs/ssh

La solution d'authentification unique pour SSH pourrait me mener à pam_ssh.

Selon cet article , le concept est:

Si vous travaillez avec plusieurs machines basées sur * nix via ssh, vous en avez probablement marre de devoir constamment entrer votre mot de passe chaque fois que vous souhaitez accéder à une autre boîte. Il existe un moyen sécurisé de vous permettre d'accéder à toutes les machines auxquelles vous avez accès ssh, sans avoir à entrer un autre mot de passe (autre que celui avec lequel vous vous êtes connecté à l'origine).

C’est en fait assez simple. En fait, vous créez simplement une paire de clés publique / privée pour vous authentifier auprès de vos autres machines, puis faites en sorte que PAM envoie un agent pour charger vos clés après votre connexion, fournissant ainsi une solution de connexion unique pour accéder à tous vos périphériques distants. Machines. Ce guide vous guidera à travers l’installation.

Je n'ai pas vérifié si cela fonctionnerait réellement.

Ajoutez ceci à votre ~/.bashrcfichier:

ssh-add -L|grep identities > /dev/null && ssh-add /path/to/ssh/private/key

Afin d’ajouter une clé (éventuellement sans mot de passe) et s’assurer que ssh-addle mot de passe ne sera pas demandé, quoi qu’il en soit, même sous X :

DISPLAY= ssh-add -k /path/to/key </dev/null &>/dev/null

L'état de sortie indique le succès ou l'échec.

Si vous utilisez seahorse comme gestionnaire de mot de passe ... ce que vous êtes probablement; D

Une autre solution permettant d’atteindre l’objectif que vous recherchez consiste simplement à ajouter les clés ssh à seahorse pour un déverrouillage automatique lors de la connexion. Le principal avantage est que vous ne devez jamais entrer de mot de passe pour les clés après vous être connecté via gdm, ou quelle que soit votre connexion, même si les clés ont un mot de passe. Cela nécessite la clé privée et la clé publique. Ils doivent également suivre une convention de nommage pour les hippocampes. La valeur par défaut est acceptable (id_rsa pour la clé privée et id_rsa.pub pour la clé publique ... vraiment tout ce qui est privatekeyname et privatekeyname.pub )

Pour ajouter votre clé ssh à seahorse pour le déverrouillage automatique lors de la connexion; (sur fedora25, je ne suis pas sûr de savoir où se trouve le chemin sur d'autres distributions, même s'il est très probablement très similaire)

/lib64/seahorse/seahorse-ssh-askpass /path/to/keys/here

Pour moi, c'était

/lib64/seahorse/seahorse-ssh-askpass ~/.ssh/id_rsa

(Seahorse supposera automatiquement que la clé publique dans mon cas était id_rsa.pub)

Après avoir exécuté la commande, Seahorse ouvrira un joli champ de mot de passe gtk dans lequel entrer le mot de passe de la clé privée. ou laissez simplement le champ vide si vous avez généré la clé sans mot de passe.

Seahorse ne vous demandera pas si tout va bien. Vous devrez essayer de ssh sur la machine cible. Seahorse vous demandera ensuite de déverrouiller graphiquement la clé avec un mot de passe (CECI NE SE PRODUIRA QU'UNE FOIS), mais cela devrait être un peu différent cette fois-ci; P (c'est aussi la partie où l'hippocampe fait des hippocampes pour ajouter de la magie, je crois ), et offre l' OPTION pour déverrouiller la clé lors de la connexion, vous devez cocher cette option pour atteindre votre objectif.

Juste parce que je n'ai pas lu toutes les réponses, je recommanderais d'annuler ce que tout le monde vous a dit de faire avec ssh-add avant de tenter cette réponse. Autrement, vos clés pourraient être endommagées, idk.

Voici le script définitif.

Mettez à jour $ PASSW, puis copiez-le dans votre terminal

# <sshpass> via typinator
# Updated: 2017-01-18_21h36
#
# apt-get update -y; apt-get install expect -qy

# Pass this value to ssh-add
PASSW="myfancypass123"

# Define a name for this script
THIS_SCRIPT="$(date +%Y-%m-%d_%H-%M-%S-%N)".sh

# Create a fresh directory to work from / Clean up
rm -rf ~/temp; mkdir -p ~/temp; cd ~/temp; ls -la


# Output our bash script file - BEGIN
cat <<< '
#!/bin/bash

set -u     # Stop if an unbound variable is referenced
set -e     # Stop on first error
export HISTIGNORE="expect*";

# Normal CMDs
echo && echo "The process should take about 10 seconds:" && echo
eval "$(ssh-agent -s)"; sleep 0.5;

# Define VAR passed when this bash-script was launched
password="$@"

# Launch the expect magic
expect -c "
    spawn ssh-add /root/.ssh/id_rsa
    expect "?assword:"
    send \"$password\r\"
    expect "?password:"
    send \"$password\r\"
    expect eof"

export HISTIGNORE="";
export password="";
' > $THIS_SCRIPT
# Output our bash script file - END


# Ensure we are in the right path
cd ~/temp; ls -la; sleep 1;

# Run the bash script
chmod +x ./$THIS_SCRIPT; ./$THIS_SCRIPT "$PASSW"; unset password;

# Clean up
rm -rf ~/temp; mkdir -p ~/temp; cd ~/temp; ls -la

Le meilleur moyen que je connaisse consiste à utiliser un script de connexion PAM que j'ai adapté à partir de travaux précédents, car je ne trouvais pas de réponse satisfaisante à cette question.

Votre phrase secrète est stockée cryptée avec votre mot de passe système et une fonction de dérivation lourde. Lors de la connexion, votre mot de passe système est utilisé pour déchiffrer votre phrase secrète et l'ajouter à l'agent.

https://github.com/capocasa/systemd-user-pam-ssh

L'avantage par rapport à toutes les autres solutions présentées est de combiner une sécurité équivalente à l'exécution de ssh-add manuellement au démarrage sans aucun effort. Il ne nécessite aucun outil supplémentaire et a une dépendance supplémentaire qui est déjà installée par défaut sur la plupart des systèmes (OpenSSL).

Ma configuration sur macOS est la suivante (dans .zshrc, ou .bash_profilepour les bash):

# Kill then Load the ssh-agent and set the necessary env variables it outputs
sshRestart() {
    # if all else fails
    # pkill -u $(whoami) ssh-agent;

    if [ -n "$SSH_AUTH_SOCK" ] ; then
        eval `/usr/bin/ssh-agent -k`
    fi
    eval `ssh-agent -s`
    ssh-add ~/.ssh/YOUR_KEY_FILE
    echo "Restarted SSH agent"
}

if [ -z "$SSH_AUTH_SOCK" ] || [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]] ; then
    eval `ssh-agent -s` > /dev/null 2>&1
    ssh-add ~/.ssh/YOUR_KEY_FILE > /dev/null 2>&1
fi

La || [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]]partie est nécessaire sur macOS car la valeur par défaut est /private/tmp/com.apple.launchd.SOMETHINGHERE/Listeners. Sinon, la réponse globale de @Thomas Nyman échoue car elle $SSH_AUTH_SOCKest toujours définie sur quelque chose.

Puis dans .zlogout(ou .bash_logoutpour les bash):

if [ -n "$SSH_AUTH_SOCK" ] ; then
    eval `/usr/bin/ssh-agent -k`
fi

Testé sur macOS Mojave 10.14.5