ssh-agent et écran

8

Il y a quelque temps, sur StackOverflow, j'ai posé cette question sur ssh-agent et crontab . J'ai maintenant une question similaire sur ssh-agent et screen sur les systèmes Linux.

Donc, sur mon Mac, ssh-agent se lance au démarrage du système, il est donc toujours à ma disposition. Je pense que ce serait vrai sous mon linux (redhat el5 / fedora) si j'utilisais X-Windows. Cependant, il s'agit d'une machine serveur distante et je me connecte toujours via ssh.

J'adorerais que les clés ssh soient correctement configurées, je n'ai donc pas eu à saisir mon mot de passe plusieurs fois lors d'une mise à jour ou d'un commit svn. Je suis heureux de taper ma phrase secrète une fois par session et je décourage notre équipe d'avoir des clés ssh sans mot de passe.

Pendant un bref instant, il semblait que faire "eval` ssh-agent -s` "dans mon .bash_profile, associé à une commande pour tuer l'agent ssh lorsque je me déconnectais, fonctionnerait. Cependant, nous utilisons beaucoup l' écran pour gérer des programmes interactifs de longue durée et des environnements de développement. Si vous démarrez et arrêtez ssh-agent comme je viens de le décrire, alors il est tué lorsque vous quittez le terminal, et les sous-sessions de l'écran qui faisaient référence à cette instance de ssh-agent sont abandonnées.

Alors ... comment puis-je être un utilisateur de console, qui utilise l'écran, qui utilise un mot de passe avec ses clés ssh, qui n'a pas à taper constamment la phrase secrète?

Michael H.
la source

Réponses:

4

Avec la configuration suivante, vous n'aurez besoin d'aucun wrapper pour l'invoquer screen. De plus, il évite l'utilisation /tmp(avec les risques de sécurité qui en découlent).

  1. Assurez-vous d'avoir un répertoire ~ / tmp:

    mkdir ~/tmp
    
  2. Ajoutez à .screenrcla ligne suivante:

    setenv SSH_AUTH_SOCK "$HOME/tmp/ssh-agent-screen"
    
    • Cela garantit qu'à l'intérieur screen, sshle socket est toujours au même endroit, plutôt qu'un chemin changeant.
    • Vous devez utiliser setenvle shell que vous utilisez, car il s'agit d'un écran et non d'une commande de shell.
  3. Ajoutez à .bash_profilela ligne suivante:

    [ -n "$SSH_AUTH_SOCK" ] && [ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ] && ln -sf "$SSH_AUTH_SOCK" "$HOME/tmp/ssh-agent-screen"
    
    • Cela liera de l'emplacement fixe (où sshse trouve) au vrai, et doit apparaître après le démarrage ssh-agent.
    • L'utilisation [ -n "$SSH_AUTH_SOCK" ]empêchera correctement les erreurs lorsqu'elle SSH_AUTH_SOCKn'est pas définie.
    • [ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ]empêchera les sessions d'écran de lier $ HOME / tmp / ssh-agent-screen à lui-même, si les sources d'écran .bash_profile.
  4. Au lieu de commencer ssh-agentà .bash_profile, vous pouvez envisager de connecter avec ssh -A(à utiliser le transfert d'agent et rendre l'utilisation de la machine à distance de votre agent).

Après cette configuration, vous pouvez simplement utiliser la commande d'écran standard. Vous n'aurez qu'à recréer les sessions existantes ou définir manuellement SSH_AUTH_SOCK à l'intérieur de celles-ci à l'emplacement fixe de l'étape 2.

Crédits à ce site Web pour l'idée; J'ai évité d'utiliser /tmp. Cette réponse est similaire mais utilise des alias supplémentaires.

Blaisorblade
la source
2

Pouvez-vous lancer ssh-agent à partir d'un initscript au lieu de .bash_profile? Par exemple, je pourrais mettre

su -c 'ssh-agent -s > ~/.ssh_agent_env' myusername

dans la partie appropriée de /etc/conf.d/local, bien que RHEL / Fedora utilise probablement un système différent. Comme vous l'avez souligné dans votre commentaire, les sessions de terminal devront pouvoir se connecter à l'agent, c'est pourquoi cette commande crée le fichier .ssh_agent_envdans le répertoire personnel de l'utilisateur. Ensuite, vous pouvez ajouter

[ -f ~/.ssh_agent_env ] && source ~/.ssh_agent_env >/dev/null

dans .bash_profile.

Une autre chose que vous pourriez faire est de mettre ce qui suit dans .bash_profile

ps -U myusername | grep -q ssh-agent || ssh-agent -s > ~/.ssh_agent_env
source ~/.ssh_agent_env >/dev/null

qui ne démarrera ssh-agentque s'il n'est pas déjà en cours d'exécution. Ensuite, vous n'avez pas à le tuer.

Comme alternative légèrement différente à la deuxième suggestion, au lieu de vérifier l'existence d'un ssh-agentprocessus, vous pouvez vérifier l'existence du fichier ~/.ssh_agent_env,

[ -f ~/.ssh_agent_env ] || ssh-agent -s > ~/.ssh_agent_env
source ~/.ssh_agent_env >/dev/null

Si tout fonctionne correctement, il ne devrait pas y avoir de différence significative entre les deux façons.

David Z
la source
L'idée initscript est intéressante - en gros, il suffit de la démarrer au démarrage du système pour tous les utilisateurs qui le souhaitent? Ça pourrait marcher. Nous n'avons pas beaucoup d'utilisateurs qui s'en soucieraient. Que ce soit ou non significativement mieux que de ne pas avoir de phrase secrète du tout est une question intéressante, car je suppose que cela signifie que vous n'auriez à la saisir qu'une fois par redémarrage de la machine. Hmm. Cela et la deuxième suggestion reposent sur de nouvelles sessions de terminal pouvant se connecter à l'agent ssh s'il est déjà en cours d'exécution. Je ne suis pas tout à fait sûr que c'est facile, mais je ne l' ai pas encore essayé. Merci pour les idées!
Michael
@khedron: Oui, mais vous devez mettre une ligne /etc/conf.d/local(ou votre équivalent) pour chaque utilisateur qui utilise l'agent, pour lancer un ssh-agentprocessus distinct par utilisateur. Si, comme vous le dites, vous n'avez pas un grand nombre d'utilisateurs, ce ne serait pas trop mal. Vous soulevez un bon point (que j'ai oublié de prendre en compte) au sujet des sessions de terminal attachées à l'agent; voir ma modification de la réponse.
David Z
2

Découvrez le trousseau . Il fait tout ce qui précède. Regardez en particulier les options --clearet --timeout.

Neil Mayhew
la source
2

Une meilleure approche consiste à utiliser le transfert d'agent ssh ( -Aoption). Cela permet à la personne utilisant ssh d'utiliser les clés de l'agent ssh s'exécutant sur la machine d'où ils viennent, probablement le poste de travail sur lequel ils sont réellement assis.

Neil Mayhew
la source
Cela permet également à un attaquant qui compromet votre compte de compromettre des comptes sur d'autres machines auxquelles l'agent peut accéder. J'essaie donc de garder le transfert d'agent ssh au minimum.
Paul Price
2

pour suivre le transfert de l'agent ssh, vous constaterez que par défaut, les informations d'identification ssh transférées ne seront pas disponibles pour votre session d'écran une fois que vous vous déconnectez, reconnectez-vous et reconnectez-vous à votre session.

Vous pouvez contourner cela, cependant, en configurant screen la variable d'environnement SSH_AUTH_SOCK sur quelque chose de bien connu, et en mettant cet emplacement connu à jour sur votre socket d'authentification actuel.

J'utilise cette fonction shell pour rentrer dans l'écran et réparer la chaussette ssh auth:

function sr () { 
    if [ ${+STY} = 1 ] ;then 
            echo already in screen\!
    else
            if [ "${SSH_AUTH_SOCK}x" != "x" ]; then
                    if [ ! -d /tmp/screenssh ]; then
                            mkdir /tmp/screenssh 
                    fi
                    rm -f /tmp/screenssh/socket
                    ln -s $SSH_AUTH_SOCK /tmp/screenssh/socket
                    echo $REMIP > /tmp/screenssh/remip
            fi                
            screen -DR
    fi
}

et je l'ai dans mon .screenrc:

setenv SSH_AUTH_SOCK /tmp/screenssh/socket

J'espère que cela t'aides.

Dan Pritts
la source
L'utilisation de / tmp signifie que n'importe qui d'autre sur la machine peut encombrer n'importe lequel de vos fichiers s'il connaît leur chemin.
Blaisorblade
1

Si je vous ai bien compris, vous voulez juste une session d'écran, que vous détachez et rattachez parfois mais ne voulez plus jamais ressaisir les mots de passe pour l'agent ssh (votre mot de passe de clé privée).

Je pense que le moyen le plus simple est de démarrer l'écran, que de démarrer ssh-agent avec un sous-shell, puis de rester dans ce sous-shell. C'est à dire

screen
ssh-agent bash
ssh-add   # enter your password once

# some commands, some logins and logouts to remote servers via ssh public key

# <ctrl>+<a>, <ctrl>+<d> to detach screen
# you can now logout from this computer
# login again

# reattach to your screen
screen -r
# ssh-agent is still running
erik
la source
C'est essentiellement ce que je fais. J'utilise screen pour étiqueter l'un des "onglets" à l'intérieur comme ayant les pouvoirs de ssh-agent, et l'utiliser pour le travail svn, etc. Il y a une ride supplémentaire où je force ssh-agent à réautoriser après un certain nombre d'heures, mais oui, c'est essentiellement là où j'en suis.
Michael H.