57 votes

Comment faire pour que screen se connecte automatiquement à l'agent ssh actuel lorsqu'il se rattache à un screen existant ?

Si vous démarrez une session écran pendant que ssh-agent est en cours d'exécution (à partir de ssh -A agent forwarding), l'accès à ssh-agent fonctionne bien. Cependant, si vous vous détachez de cette session, que vous vous déconnectez, que vous vous reconnectez (avec le transfert de ssh-agent) et que vous vous reconnectez à votre session écran, l'accès à ssh-agent ne fonctionne pas.

Comment peut-on y remédier ?

1voto

Arcege Points 2033

J'ai l'habitude de maintenir des sessions à long terme (6+ mois) sur différents serveurs sur mon lieu de travail. Ainsi, le fait de rattacher à plusieurs reprises et d'avoir un agent de transfert ssh viable a été problématique. Voici ce que j'ai mis en place sur mes systèmes :

if [ -z "${STY}" -a -t 0 -a X${USER} = Xmyusername ]; then
    reattach () {
        if [ -n "${SSH_AUTH_SOCK}" ]; then
            ln -snf "${SSH_AUTH_SOCK}" "${HOME}/.ssh/agent-screen"
            SSH_AUTH_SOCK="${HOME}/.ssh/agent-screen" export SSH_AUTH_SOCK
        fi
        exec screen -A -D -RR ${1:+"$@"} ;
    }

    screen -wipe
    echo 'starting screen... (type Cntl-C to abort)'
    sleep 5 && reattach
fi

Si je me connecte simplement au serveur distant sans démarrer/reattacher l'écran, il y aura alors deux "sockets", l'un utilisé par screen et un autre par le nouveau Shell. Il ne devrait pas y avoir deux sessions de "démarrage", mais une deuxième session pourrait toujours être lancée en utilisant reattach -S new ; dans cette situation, l'agent serait partagé avec la ~/.ssh/agent-screen valeur. Pour récupérer un transitaire fonctionnel, il faut le détacher et se reconnecter. Le site X${USER} = Xmyusername assure que le code ne sera pas appelé par le biais de sudo sur le même serveur.

1voto

J'utilise une variante de ce que @apinstein utilise pour mon .bashrc .

case "$TERM" in
    screen)
           export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock
        ;;
         *)
           if [[ -n "$SSH_AUTH_SOCK" ]]; then
               ln -sf $SSH_AUTH_SOCK ~/.ssh/ssh_auth_sock
           fi
        ;;
esac

Cela fonctionne pour toutes les applications exécutées dans ma session d'écran. Cela fonctionnerait pour tous les nouveaux shells dans votre session écran. Pour les shells existants, vous devez exécuter export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock sur l'hôte Shell pour que cela fonctionne.

P.S. Désolé d'avoir ajouté ceci comme une réponse indépendante, alors qu'il s'agit juste d'une construction sur la réponse de @apinstein. J'ai dû faire cela car les commentaires dans stackoverflow ne supportent pas les blocs de code.

0voto

tpgould Points 1114

Ce sont toutes de très bonnes réponses. Je le fais de manière légèrement différente. Après avoir démarré une nouvelle session ssh et rattaché l'écran, je réinitialise la fonction SSH_AUTH_SOCK basée sur le contenu de l'environnement root bash. Je n'ai besoin de l'accès à l'agent ssh qu'occasionnellement lorsque j'utilise svn, donc je réinitialise simplement la variable d'environnement SSH_AUTH_SOCK comme requis dans ces coquilles.

Il utilise le système de fichiers proc et est donc spécifique à linux. Je ne l'ai testé que sur une machine linux sans tête à laquelle je suis le seul à accéder, il faudra peut-être quelques ajustements pour que cela fonctionne dans d'autres environnements.

Pour réinitialiser SSH_AUTH_SOCK (on pourrait en faire un alias).

$ . ~/bin/screen_auth.sh

screen_auth.sh ressemble à ceci

# Find the pid of putty's bash shell
tty=`who | awk '/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/ { print substr($2, 5) }'`
pid=`ps -t $tty | grep bash | awk '{print $1}'`
# Find the SSH_AUTH_SOCK variable in its enviornment
auth_sock=`xargs --null --max-args=1 echo < /proc/$pid/environ | grep SSH_AUTH_SOCK`
eval "export $auth_sock"

0voto

DanH Points 181

J'ai essayé ce simple "one liner" comme suggéré sur Faisons de screen et de ssh-agent des amis et ça marche pour moi.

C'est la première fois que vous vous connectez à Target. Il faut le faire une seule fois.

ssh -o StrictHostKeyChecking=no -C <userid>@<server>

Lancer l'écran pour la première fois Ne doit être fait qu'une seule fois.

eval `ssh-agent`; /usr/bin/screen -D -R -h 10000
ssh-add

Si vous êtes détaché ou déconnecté, utilisez cette commande pour vous connecter ultérieurement à l'écran sortant.

ssh -o StrictHostKeyChecking=no -C -t <userid>@<server> ssh-agent /usr/bin/screen -D -R -h 10000

0voto

midenok Points 240

Toutes les solutions ci-dessus souffrent de conditions de course (soit dans des sessions SCREEN multiples, soit dans des connexions SSH multiples). La seule solution universelle à laquelle je peux penser est de pousser d'abord SSH_AUTH_SOCK au processus du serveur SCREEN sur screen -r et ensuite le tirer à l'intérieur de la session BASH avant chaque commande interactive non-builtin. Malheureusement, SCREEN et BASH ont été conçus sans tenir compte de ce genre de problèmes, il est donc assez difficile de les mettre en œuvre correctement (bien qu'il ne soit jamais trop tard pour envoyer des demandes de fonctionnalités aux deux projets). J'ai essayé de surmonter ce problème pour les sessions BASH, que vous pouvez trouver ici :

Pour l'installer :

  1. mettez les deux scripts en $HOME/bin , ajouter le bit exécutable ;

  2. s'assurer que $HOME/bin va avant /usr/bin dans PATH :

    PATH=$HOME/bin:$PATH

  3. ajoutez ceci à votre .bashrc :

    source $HOME/bin/screen-helper setup

Maintenant vous pouvez essayer de créer une session SCREEN à l'intérieur de la session SSH, détacher, déconnecter, connecter et rattacher et avec un peu de chance ssh-add -l devrait montrer correctement vos clés.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X