ssh-agent e schermo


8

Qualche tempo fa su StackOverflow, ho posto questa domanda su ssh-agent e crontab . Ho una domanda simile ora su ssh-agent e sullo schermo sui sistemi Linux.

Quindi, sul mio Mac, ssh-agent si avvia all'avvio del sistema, quindi è sempre disponibile per me. Penso che sarebbe vero sotto il mio linux (redhat el5 / fedora) se usassi X-Windows. Tuttavia, si tratta di un server remoto e accedo sempre tramite ssh.

Mi piacerebbe avere i tasti ssh impostati correttamente, quindi non ho dovuto inserire la mia password più volte durante un aggiornamento svn o un commit. Sono felice di digitare la mia passphrase una volta per sessione e scoraggio il nostro team dall'avere chiavi ssh senza password.

Per un breve momento brillante, sembrava che fare "eval` ssh-agent -s` "nel mio .bash_profile, associato a un comando per uccidere l'agente ssh quando mi disconnettevo, avrebbe funzionato. Tuttavia, facciamo ampio uso dello schermo per gestire programmi interattivi di lunga durata e ambienti di sviluppo. Se avvii e interrompi ssh-agent come ho appena descritto, viene ucciso quando esci dal terminale e le sottosessioni dello schermo che si riferivano a quell'istanza di ssh-agent vengono abbandonate.

Quindi ... come posso essere un utente della console, che usa lo schermo, che usa una password con i suoi tasti ssh, che non deve digitare la passphrase costantemente?

Risposte:


4

Con la seguente configurazione, non sarà necessario alcun wrapper per invocare screen. Inoltre, evita l'utilizzo /tmp(con i conseguenti rischi per la sicurezza).

  1. Assicurati di avere una directory ~ / tmp:

    mkdir ~/tmp
    
  2. Aggiungi alla .screenrcseguente riga:

    setenv SSH_AUTH_SOCK "$HOME/tmp/ssh-agent-screen"
    
    • Questo assicura che all'interno screen, sshcerca il socket sempre nella stessa posizione, anziché un percorso che cambia.
    • Devi usare setenvqualunque shell tu usi, dato che è uno schermo e non un comando di shell.
  3. Aggiungi alla .bash_profileseguente riga:

    [ -n "$SSH_AUTH_SOCK" ] && [ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ] && ln -sf "$SSH_AUTH_SOCK" "$HOME/tmp/ssh-agent-screen"
    
    • Questo si collegherà dalla posizione fissa (dove sshappare) a quella reale e deve apparire dopo l' avvio ssh-agent.
    • L'uso [ -n "$SSH_AUTH_SOCK" ]previene correttamente gli errori quando SSH_AUTH_SOCKnon è impostato.
    • [ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ]impedirà le sessioni dello schermo che collegano $ HOME / tmp / ssh-agent-screen a se stesso, se le fonti dello schermo .bash_profile.
  4. Invece di iniziare ssh-agenta .bash_profile, si può considerare il collegamento con ssh -A(per utilizzare l'inoltro agente e rendere l'uso della macchina a distanza il vostro agente).

Dopo questa configurazione, puoi semplicemente usare il comando schermo standard. Dovrai solo ricreare sessioni esistenti o impostare manualmente SSH_AUTH_SOCK al loro interno nella posizione fissa del passaggio 2.

Crediti a questo sito Web per l'idea; Ho evitato di usare /tmp. Questa risposta è simile ma utilizza alias extra.


2

Puoi avviare ssh-agent da un initscript invece che .bash_profile? Ad esempio, potrei dire

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

nella parte appropriata di /etc/conf.d/local, sebbene RHEL / Fedora probabilmente utilizzi un sistema diverso. Come hai indicato nel tuo commento, le sessioni del terminale dovranno essere in grado di connettersi all'agente, motivo per cui quel comando crea il file .ssh_agent_envnella home directory dell'utente. Quindi puoi aggiungere

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

in .bash_profile.

Un'altra cosa che potresti fare è inserire quanto segue .bash_profile

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

che inizierà ssh-agentsolo se non è già in esecuzione. Quindi non devi ucciderlo.

Come alternativa leggermente diversa al secondo suggerimento, invece di verificare l'esistenza di un ssh-agentprocesso, è possibile verificare l'esistenza del file ~/.ssh_agent_env,

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

Se tutto funziona correttamente, non dovrebbero esserci differenze significative tra i due modi.


L'idea di initscript è interessante - in pratica, basta avviarlo all'avvio del sistema per tutti gli utenti che lo vogliono? Potrebbe funzionare. Non abbiamo molti utenti a cui importa. Che sia significativamente meglio che non avere affatto una passphrase è una domanda interessante, dal momento che sospetto che ciò significhi che dovresti inserirlo solo una volta per riavvio della macchina. Hmm. Sia quello che il secondo suggerimento si basano sul fatto che le nuove sessioni terminal sono in grado di connettersi all'agente ssh se è già in esecuzione. Non sono del tutto sicuro che sia così facile, ma non ci ho ancora provato. Grazie per le idee!
Michael H.

@khedron: Sì, ma dovresti inserire una riga /etc/conf.d/local(o il tuo equivalente) per ogni utente che utilizza l'agente, per avviare un ssh-agentprocesso separato per utente. Se, come dici, non hai un numero enorme di utenti, non sarebbe male. Sollevi un buon punto (che ho dimenticato di considerare) sulle sessioni terminali associate all'agente; vedi la mia modifica alla risposta.
David Z,


2

Un approccio migliore consiste nell'utilizzare l' inoltro dell'agente ssh ( -Aopzione). Ciò consente alla persona che utilizza ssh di utilizzare le chiavi dell'agente ssh in esecuzione sulla macchina da cui provengono, presumibilmente la workstation in cui si trovano effettivamente.


Ciò consente inoltre a un utente malintenzionato che compromette il tuo account di compromettere gli account su altre macchine a cui tale agente può accedere. Cerco quindi di ridurre al minimo l'inoltro dell'agente ssh.
Paul Price,

2

per seguire l'inoltro dell'agente ssh, scoprirai che le credenziali ssh inoltrate non saranno disponibili per la sessione dello schermo una volta che ti sei disconnesso, riconnesso e riconnetti alla tua sesssion.

Per ovviare a questo, però, avendo lo schermo impostato la variabile di ambiente SSH_AUTH_SOCK su qualcosa di ben noto e facendo sì che quella posizione ben nota sia aggiornata al socket di autenticazione corrente.

Uso questa funzione di shell per accedere nuovamente allo schermo e correggere la calza 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
}

e ho questo nel mio .screenrc:

setenv SSH_AUTH_SOCK /tmp/screenssh/socket

Spero che sia di aiuto.


L'uso di / tmp significa che chiunque altro sulla macchina può bloccare qualsiasi file, se ne conosce il percorso.
Blaisorblade,

1

Se ti ho capito bene, vuoi solo una sessione schermo, che a volte scolleghi e ricolleghi, ma non vorrai mai più inserire nuovamente le password per l'agente ssh (la tua password della chiave privata).

Penso che il modo più semplice sia quello di avviare lo schermo, piuttosto che avviare ssh-agent con una sub shell e poi rimanere in quella sub shell. ie

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

Questo è essenzialmente quello che faccio. Uso lo schermo per etichettare una delle "schede" all'interno come avente i poteri di ssh-agent, e lo uso per svn lavoro, ecc. C'è un'altra ruga in cui costringo ssh-agent a autorizzare nuovamente dopo un certo numero di ore, ma sì, questo è fondamentalmente dove sono io.
Michael H.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.