Cum pot rula ssh-add automat, fără o solicitare de parolă?

Acesta este un exemplu tipic de compromis între securitate și comoditate. Din fericire există o serie de opțiuni. Cea mai potrivită soluție depinde de scenariul de utilizare și de nivelul de securitate dorit.

ssh-key cu frază de acces, nu ssh-agent

Acum trebuie introdusă expresia de acces de fiecare dată când cheia este utilizată pentru autentificare. Deși aceasta este cea mai bună opțiune din punct de vedere al securității, aceasta oferă cea mai proastă utilizare. Acest lucru poate duce, de asemenea, la alegerea unei expresii de acces slabe în ordine, pentru a reduce povara introducerii acesteia în mod repetat.

ssh-key cu expresie de acces, cu ssh-agent

Adăugarea următoarelor elemente la ~/.bash_profile va porni automat ssh-agent și încărcați cheia (s) ssh la conectare:

if [ -z "$SSH_AUTH_SOCK" ] ; then eval `ssh-agent -s` ssh-add fi 

Acum trebuie introdusă expresia de acces la fiecare Logare. Deși ușor mai bun din perspectiva utilizabilității, acest lucru are dezavantajul că ssh-agent solicită fraza de acces, indiferent dacă cheia urmează să fie utilizată sau nu în timpul sesiunii de conectare. Fiecare nouă autentificare generează, de asemenea, o instanță distinctă ssh-agent care rămâne în execuție cu cheile adăugate în memorie chiar și după deconectare, cu excepția cazului în care este ucisă în mod explicit.

Pentru a ucide ssh_agent la deconectare, adăugați următoarele la ~/.bash_logout

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

sau următoarele la ~/.bash_profile

trap "test -n "$SSH_AUTH_SOCK" && eval `/usr/bin/ssh-agent -k`" 0 

Crearea mai multor instanțe ssh-agent poate fi evitată de crearea unui socket de comunicare persistent către agent la o locație fixă în sistemul de fișiere, cum ar fi în răspunsul lui Collin Anderson . Aceasta este o îmbunătățire față de generarea mai multor agenți instanțe, cu toate acestea, cu excepția cazului în care a fost ucisă în mod explicit, cheia decriptată rămâne în memorie după deconectare.

Pe desktopuri, agenții ssh incluși în mediul desktop, cum ar fi , poate fi o abordare mai bună, deoarece acestea pot fi făcute de obicei pentru a solicita trecerea frază prima dată când cheia ssh este utilizată în timpul unei sesiuni de conectare și stochează cheia privată decriptată în memorie până la sfârșitul sesiunii.

ssh- cheie cu expresie de acces, cu ssh-ident

ssh-ident este un utilitar care poate gestiona ssh-agent în numele dvs. și poate încărca identitățile după cum este necesar. Acesta adaugă chei o singură dată când sunt necesare, indiferent de câte terminale, ssh sau sesiuni de conectare care necesită acces la un ssh-agent. De asemenea, poate adăuga și utiliza un agent diferit și un set diferit de chei, în funcție de gazda la care este conectat sau din care este invocat directorul ssh. Acest lucru permite izolarea cheilor atunci când se utilizează redirecționarea agentului cu diferite gazde. De asemenea, permite utilizarea mai multor conturi pe site-uri precum GitHub.

Pentru a activa ssh-ident, instalați-l și adăugați următorul alias la ~/bash_profile:

alias ssh="/path/to/ssh-ident" 

ssh-key cu expresie de acces, cu keychain

keychain este un utilitar mic care gestionează ssh-agent în numele dvs. și permite ssh-agent să rămână în funcțiune la sfârșitul sesiunii de conectare. La conectările ulterioare, keychain se va conecta la instanța existentă ssh-agent. În practică, aceasta înseamnă că fraza de acces trebuie introdusă numai în timpul primei autentificări după repornire. La conectările ulterioare, se utilizează cheia necriptată din instanța existentă ssh-agent.Acest lucru poate fi util și pentru a permite autentificarea RSA / DSA fără parolă în lucrările cron fără chei ssh fără parolă.

Pentru a activa keychain, instalați-l și adăugați ceva de genul următor la ~/.bash_profile:

eval `keychain --agents ssh --eval id_rsa` 

Din punctul de securitate al vizualizare, ssh-ident și keychain sunt mai slabe decât ssh-agent instanțe limitate la durata de viață a unui anumit sesiune, dar oferă un nivel ridicat de confort. Pentru a îmbunătăți securitatea keychain, unii oameni adaugă opțiunea --clear la brelocul lor ~/.bash_profile invocare. Procedând astfel, trebuie introduse din nou expresiile de acces la autentificare, ca mai sus, dar lucrările cron vor avea în continuare acces la cheile necriptate după ce utilizatorul se deconectează. keychain pagina wiki conține mai multe informații și exemple.

ssh-key fără expresie de acces

Din punct de vedere al securității, aceasta este cea mai proastă opțiune, deoarece cheia privată este complet neprotejată în cazul în care este expus. Totuși, acesta este singurul mod de a vă asigura că nu trebuie introdusă din nou fraza de acces după o repornire.

ssh-key cu expresie de acces, cu ssh-agent, trecând expresia de acces la ssh-add din script

Deși s-ar putea pare o idee simplă de a trece fraza de acces către ssh-add dintr-un script, de ex. echo "passphrase\n" | ssh-add, acest lucru nu este la fel de simplu pe cât pare ca ssh-add nu citește expresie de acces din stdin, dar deschide /dev/tty direct pentru citire .

Aceasta poate fi a lucrat cu expect , un instrument pentru automatizarea interactivului aplicații. Mai jos este un exemplu de script care adaugă o cheie ssh utilizând o expresie de acces stocată în 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 

Rețineți că, deoarece expresia de acces este stocată în text simplu în scriptul, dintr-o perspectivă de securitate, este cu greu mai bun decât să ai o cheie ssh fără parolă. Dacă această abordare urmează să fie utilizată, este important să vă asigurați că scriptul expect care conține fraza de trecere are setate permisiunile corespunzătoare, făcându-l lizibil, scriibil și rulabil numai de cheie proprietar.

Comentarii

• Bine, dar când pun codul dvs. la ~ / .bash_profile trebuie să introduc parola de fiecare dată când mă autentific, Nici ‘ nu vrei asta. Nu mă preocupă deloc securitatea. echo ” pass \ n ” | ssh-add ‘ nu funcționează
• @ user1607072 Da, așa este fragmentul ssh-agent din ~/.bash_profile se comportă așa cum se explică în răspuns. Poate doriți să vă uitați la utilitarul keychain. Cu keychain trebuie să introduceți parola la prima autentificare după repornire, dar la conectările ulterioare keychain vă veți conecta la un ssh-agent instanță cu cheia decriptată în memorie. În afară de aceasta, există ‘ opțiunea de a genera o cheie ssh fără o expresie de acces, dar aceasta nu este, desigur, recomandată.
• @ user1607072 sugerează una dintre abordările mai sigure, există o modalitate de a transmite fraza de acces către ssh-add dintr-un script. Motivul pentru care echo "pass\n" | ssh-add nu funcționează este că ssh-add nu citește parola din stdin, dar deschide /dev/tty direct pentru citire. S-a actualizat răspunsul pentru a include o soluție pentru acest lucru, utilizând un utilitar numit expect.
• @ user1607072 S-ar putea să fie un pic excesiv pentru cazul dvs. de utilizare, dar Kerberos în combinație cu ssh Asistența GSSAPI poate fi utilizată și pentru conectările ssh fără parolă. Metoda de autentificare corespunzătoare din ssh se numește gssapi-with-mic. Acest lucru este de obicei utilizat în rețele mai mari, dar, bineînțeles, dacă sunteți interesat de acest lucru, ar merita să îl căutați.
• @ErickBrown: Ați răspuns deja aici . Unitatea SSH Agent ar trebui să fie oprită la deconectare dacă aveți un utilizator persistent dezactivat în managerul de conectare systemd . Dacă utilizatorul persistă este activat, instanța de utilizator systemd și unitatea Agent SSH sunt continuate să ruleze chiar și după închiderea ultimei sesiuni de conectare.

Adăugați acest lucru la ~/.bashrc, apoi deconectați-vă și înapoi pentru a intra în vigoare.

 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  

Acest lucru ar trebui să solicite doar o parolă prima dată când vă conectați după fiecare repornire. Va continua să refolosească același ssh-agent atâta timp cât rămâne în funcțiune.

Comentarii

• foarte îngrijit , în acest fel aveți doar un agent ssh care rulează (: agenți multipli ca în @thomasNyman ‘ a doua soluție mi se pare un risc de securitate …
• După ce am cercetat în diverse site-uri și am citit diverse soluții, acesta pare a fi cel mai clar, direct la subiect. Foarte frumos. +1
• mai bine să faceți acest lucru: `alias ssh = ssh-check-agent ” și faceți ca versiunea check-agent să facă cele de mai sus. în acest fel: a) primiți un singur agent și b) primiți agentul doar dacă aveți nevoie de el
• Cred că -s este valoarea implicită, deci ‘ o facem deja.
• Rețineți că ssh-add fără argumente adaugă ~/.ssh/id_rsa. S-ar putea să doriți să transmiteți ssh-add argumente dacă cheile dvs. private se află într-un alt fișier.

Nu este strâns legat de întrebarea OP, dar ar putea fi util pentru alții: deoarece 7.2.0 ssh (1) are o opțiune care permite adăugarea unei chei la ssh-agent la prima autentificare; opțiunea este AddKeysToAgent și poate fi setată la yes, no, ask sau confirm, la nivel de sistem sau pe fișierul dvs. personal .ssh/config.

Referință : https://www.openssh.com/txt/release-7.2

Comentarii

• Aplicabil celor care sunt noi în fișierul .ssh/config: acest lucru se aplică pentru ssh și pentru orice lucru care utilizează ssh în spatele acestuia, de exemplu scp, și poate fi realizat pe bază de gazdă.
• Îmi cere totuși parola de fiecare dată când mă autentific și încerc să git pull de exemplu.
• @trainosis Problema este că probabil nu aveți o instanță ssh-agent care să ruleze cheia (codurile) decriptate în memorie pentru o utilizare ulterioară. Ar trebui să introduceți parola pentru o anumită cheie o singură dată la fiecare sesiune de conectare atunci când utilizați ssh-agent.

ssh-agent memorează în cache diverse chei ssh deblocate, astfel încât să puteți avea cheile ssh protejate prin parole, dar fără a fi nevoie să le tastați de fiecare dată.

Pentru a memora în cache cheile deblocate, este evident că trebuie să le deblocheze. Pentru deblocarea cheilor care sunt blocate cu o expresie de acces, este evident că trebuie să cunoască aceste expresii de acces.

Orice metodă care nu necesită autorizarea unei ființe umane (de exemplu „introducerea unei parole”) sistem nesigur; de asemenea, va face ca întregul scop al agentului ssh să fie lipsit de sens.

După ce am spus toate acestea, puteți utiliza pur și simplu cheile ssh care nu sunt protejate prin parolă (apăsați Enter când vi se solicită pentru o parolă în timpul generării de chei). Deoarece nu există nicio parolă, ssh-agent nu trebuie să vă ceară una pentru a o (nu) memora în cache.

Comentarii

• Sunt de acord, atâta timp cât cheile dvs. sunt permise numai de către utilizator, există un avantaj mic pentru ssh-agent față de cheile fără permisiune. Îmi place să intru într-un server de conectare, iar apoi, acel server are o grămadă de chei fără permisiuni, fiecare dintre acestea putând fi folosite doar pentru a debloca un alt server. serverul de autentificare nu face nimic altceva, deci este ‘ mult mai greu de piratat / falsificat, etc … celelalte servere nu au acces cu parolă, sunt doar chei.

Iată o soluție pentru automatizarea expresiei dvs. de acces SSH.

1. Creați un script cu o singură linie care imprimă fraza de acces la ieșirea standard, de exemplu:

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

   Important: Asigurați-vă copiați spațiul principal în împiedicați stocarea parolei în istoricul dvs. .

Și utilizați una dintre metodele de mai jos.

• utilizând o abordare standard de intrare:

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

• sau abordare denumită :

  1. Creați un pipe denumit (ați putea încerca, de asemenea, o substituire proces ):

     mkfifo --mode 0600 ~/.ssh_fifo 

  2. Executați ssh-add prin specificarea programului utilizat pentru autentificare:

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

  A se vedea: man ssh-add pentru a citi mai multe despre SSH_ASKPASS.

Comentarii

• echo my_passphrase este o mare gaură de securitate. Mai întâi după ce ați tastat-o, parola se află în text clar în fișierul istoric al shell-ului pe care îl folosiți vreodată. Și al doilea argument de linie de comandă este lizibil în întreaga lume pe Unix (ps -ef). Nu puneți niciodată parole în argumentele din linia de comandă!
• @ceving Adăugarea unui spațiu de conducere suplimentar rezolvă problema cu fișierul istoric. S-au adăugat informații suplimentare.
• @kenorb: Aceasta nu rezolvă problema mai mare a parolei vizibile în ps ‘ ieșire. Fișierul istoric este oricum citibil doar de către utilizatorul proprietar, dar liniile de comandă sunt lizibile de către toți utilizatorii unui sistem.

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 

Obișnuiam să folosesc scriptul menționat de Steampowered, acum l-am făcut pe cel de mai jos, deoarece nu lasă fișiere culcat în jur.

Lucrul la zsh numai shell.

#!/usr/bin/env zsh 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 

Comentarii

• ” Lucrul la zsh shell numai „, bine, dar de ce linia dvs. shebang declară că necesită doar ” sh „?

Dacă rulați seahorse ca manager de parole … Ceea ce probabil sunteți; D

O altă soluție care atinge obiectivul pe care îl căutați este pur și simplu adăugarea cheilor ssh la seahorse pentru deblocare automată la conectare . Avantajul major este că nu trebuie să introduceți niciodată o parolă pentru chei după ce v-ați conectat prin gdm sau orice altceva cu care v-ați conectat, chiar dacă cheile au o parolă. Acest lucru CERE atât cheia privată, cât și cheia publică. De asemenea, aceștia TREBUIE să urmeze o convenție de numire a calului de mare. Valoarea implicită este acceptabilă (id_rsa pentru cheia privată și id_rsa.pub pentru cheia publică … Într-adevăr orice este privatekeyname și privatekeyname.pub )

Pentru a vă adăuga cheia ssh la seahorse pentru deblocare automată la conectare; (pe fedora25, nu sunt sigur unde este calea pe alte distribuții, deși este foarte probabil foarte asemănătoare)

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

Pentru mine, a fost

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

(seahorse va presupune automat că cheia publică în cazul meu a fost id_rsa.pub)

După executarea comenzii, seahorse va deschide un câmpul de parolă gtk mic drăguț pentru a introduce parola pentru cheia privată. sau pur și simplu lăsați-l necompletat dacă ați generat cheia fără o parolă.

Seahorse a câștigat „nu vă solicită dacă totul a mers bine. Va trebui să încercați să intrați în mașina țintă.Apoi, seahorse vă va solicita să deblocați cheia cu o parolă grafic (ACEASTA SE VA ÎNTÂMPLA O singură dată) din nou, dar ar trebui să arate puțin diferit de data aceasta; P (aceasta este, de asemenea, partea în care Seahorse face ceva Seahorse pentru a adăuga magie, cred că ) și oferiți OPTION pentru a debloca cheia la conectare, trebuie să bifați această opțiune pentru a atinge-ți obiectivul.

Doar pentru că nu am citit toate răspunsurile, ți-aș recomanda să anulezi ceea ce ți-a spus toată lumea cu ssh-add înainte de a încerca acest răspuns. În caz contrar, s-ar putea să se întâmple ceva rău la cheile dvs., idk.

Soluția de conectare simplă pentru SSH m-ar putea duce la pam_ssh .

Conform acest articol , conceptul este:

Dacă lucrați cu mai multe mașini bazate pe * nix prin ssh, probabil că v-ați săturat de contra trebuind să introduceți parola de fiecare dată când doriți să accesați o altă casetă. Există o modalitate sigură de a vă permite să accesați fiecare mașină, la care aveți acces ssh, fără a fi nevoie să introduceți o altă parolă (alta decât cea cu care v-ați autentificat inițial.)

Acest lucru este de fapt destul de simplu de făcut, în principiu, trebuie doar să creați o pereche de chei publice / private pentru a vă autentifica pe celelalte mașini, apoi aveți PAM generează un agent pentru a vă încărca cheile după ce v-ați conectat, oferind o soluție de conectare unică pentru accesarea tuturor mașinilor dvs. la distanță. Acest ghid vă va ajuta să configurați acest lucru.

Nu am verificat că acest lucru ar funcționa efectiv.

Adăugați acest lucru la fișierul ~/.bashrc:

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

Comentarii

• Nu ‘ nu văd ce legătură are aceasta cu întrebarea, despre care nu este solicitată parola la conectările ulterioare.

Pentru a adăuga o cheie (posibil fără parolă) și a vă asigura că ssh-add nu va solicita o parolă, indiferent de ce, chiar și atunci când rulează sub X :

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

Starea de ieșire indică succesul sau eșecul.

Iată definitiv scenariu.

Actualizați $ PASSW, apoi copiați-lipiți-l în 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 

Cel mai bun mod pe care îl știu este să folosesc un script de conectare PAM pe care l-am adaptat din lucrările anterioare, deoarece nu am putut găsi un răspuns satisfăcător în această întrebare.

stocată criptată cu parola de sistem și o funcție de derivare grea. La conectare, parola de sistem este utilizată pentru a decripta fraza de acces și a o adăuga la agent.

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

Avantajul față de orice altă soluție prezentată este că combină securitatea echivalentă cu rularea manuală a ssh-add la pornire cu efort zero. nu există instrumente suplimentare și are o dependență suplimentară care este deja instalată implicit pe majoritatea sistemelor (OpenSSL).

My configurarea pe macOS este după cum urmează (în .zshrc sau .bash_profile pentru oamenii bash):

Partea || [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]] este necesară pe macOS deoarece valoarea implicită este /private/tmp/com.apple.launchd.SOMETHINGHERE/Listeners. În caz contrar, răspunsul complet @Thomas Nyman eșuează deoarece $SSH_AUTH_SOCK este întotdeauna setat la ceva.

Apoi în .zlogout (sau .bash_logout pentru bash):

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

Testat pe macOS Mojave 10.14.5

Acest lucru a fost foarte bine explicat de GitHub pe Auto-lansare ssh-agent pe Git pentru Windows , care la rândul său funcționează și pentru Linux.

Puteți rula ssh-agent automat când deschideți bash sau Git shell. Copiați următoarele rânduri și lipiți-le în fișierul ~/.profile sau ~/.bashrc în shell Git:

 env=~/.ssh/agent.env agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; } agent_start () { (umask 077; ssh-agent >| "$env") . "$env" >| /dev/null ; } agent_load_env # agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?) if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then agent_start ssh-add elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then ssh-add fi unset env  

Dacă cheia dvs. privată nu este stocată într-una dintre locațiile implicite (cum ar fi ~/.ssh/id_rsa), va trebui să-i spuneți agentului de autentificare SSH unde îl găsiți. Pentru a adăuga cheia la agentul ssh, tastați ssh-add ~/path/to/my_key.

Sfat: Dacă doriți ca ssh-agent să vă uite cheia după ceva timp, puteți configurați-l pentru a face acest lucru executând ssh-add -t <seconds>.