Hvordan kan jeg kjøre ssh-add automatisk, uten passordmelding?

Dette er et typisk eksempel på en avveining mellom sikkerhet og bekvemmelighet. Heldigvis er det en rekke alternativer. Den mest passende løsningen avhenger av bruksscenariet og ønsket sikkerhetsnivå.

ssh-nøkkel med passordfrase, ingen ssh-agent

Nå må passordfrasen legges inn hver gang nøkkelen brukes til autentisering. Selv om dette er det beste alternativet fra et sikkerhetsmessig synspunkt, gir det den verste brukervennligheten. Dette kan også føre til at en svak passordfrase blir valgt i rekkefølge for å redusere byrden ved å angi den gjentatte ganger.

ssh-tast med passordfrase, med ssh-agent

Å legge til følgende i ~/.bash_profile starter automatisk ssh-agent og last inn ssh-nøkkelen (e) ved pålogging:

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

Nå må passordfrasen legges inn hver Logg Inn. Selv om det er litt bedre fra et brukervennlighetsperspektiv, har dette den ulempen at ssh-agent ber om passordfrasen uansett om nøkkelen skal brukes eller ikke under påloggingsøkten. Hver nye pålogging gyter også en distinkt ssh-agent forekomst som fortsatt kjører med de ekstra nøklene i minnet, selv etter utlogging, med mindre det eksplisitt blir drept.

Å drepe ssh_agent når du logger ut, legg til følgende i ~/.bash_logout

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

eller følgende til ~/.bash_profile

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

Å opprette flere ssh-agent forekomster kan unngås ved opprette en vedvarende kommunikasjonskontakt til agenten på et fast sted i filsystemet, for eksempel i Collin Anderson «svar . Dette er en forbedring i forhold til å gyte flere agenter forekomster, men med mindre eksplisitt drept, forblir den dekrypterte nøkkelen fortsatt i minnet etter avlogging.

På stasjonære datamaskiner er ssh-agenter inkludert i skrivebordsmiljøet, for eksempel > Gnome Keyring SSH Agent , kan være en bedre tilnærming, da de vanligvis kan gjøres for å be om passet setning første gang ssh-nøkkelen brukes under en påloggingsøkt og lagrer den dekrypterte private nøkkelen i minnet til slutten av økten.

ssh- nøkkel med passordfrase, med ssh-ident

ssh-ident er et verktøy som kan administrere ssh-agent på dine vegne og laste inn identiteter etter behov. Den legger til nøkler bare en gang etter behov, uavhengig av hvor mange terminaler, ssh eller påloggingsøkter som krever tilgang til en ssh-agent. Det kan også legge til og bruke en annen agent og forskjellige sett med nøkler, avhengig av verten du er koblet til, eller katalogen ssh blir påkalt fra. Dette muliggjør isolering av nøkler når agentoverføring brukes med forskjellige verter. Det gjør det også mulig å bruke flere kontoer på nettsteder som GitHub.

For å aktivere ssh-ident, installer det og legg til følgende alias til ~/bash_profile:

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

ssh-nøkkel med passordfrase, med keychain

keychain er et lite verktøy som administrerer ssh-agent på dine vegne og lar ssh-agent fortsette å kjøre når påloggingssesjonen avsluttes. Ved påfølgende pålogginger vil keychain koble til den eksisterende ssh-agent forekomsten. I praksis betyr dette at passordfrasen bare må legges inn ved første pålogging etter omstart. På påfølgende pålogginger brukes den ukrypterte nøkkelen fra den eksisterende ssh-agent forekomsten.Dette kan også være nyttig for å tillate passordløse RSA / DSA-autentisering i cron jobber uten passordløse ssh-nøkler.

For å aktivere keychain, installer den og legg til noe sånt som følger til ~/.bash_profile:

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

Fra et sikkerhetspunkt på visning, ssh-ident og keychain er verre enn ssh-agent forekomster begrenset til levetiden til en bestemt økt, men de tilbyr et høyt komfortnivå. For å forbedre sikkerheten til keychain, legger noen til alternativet --clear i ~/.bash_profile nøkkelring påkallelse. Ved å gjøre dette må passord setes inn på nytt ved pålogging som ovenfor, men cron jobber vil fortsatt ha tilgang til de ukrypterte nøklene etter at brukeren logger av. keychain wiki-siden har mer informasjon og eksempler.

ssh-key uten passfrase

Fra et sikkerhetsmessig synspunkt er dette det verste alternativet siden den private nøkkelen er helt ubeskyttet i tilfelle den er utsatt. Dette er imidlertid den eneste måten å sikre at passordfrasen ikke trenger å legges inn på nytt etter en omstart.

ssh-nøkkel med passordfrase, med ssh-agent, passerer frase til ssh-add fra skript

Selv om det kan virker som en grei ide om å sende passordfrasen til ssh-add fra et skript, f.eks. echo "passphrase\n" | ssh-add, dette er ikke så rett frem som det virker som ssh-add ikke leser passfrase fra stdin, men åpner /dev/tty direkte for lesing .

Dette kan være jobbet rundt med expect , et verktøy for automatisering av interaktive applikasjoner. Nedenfor er et eksempel på et skript som legger til en ssh-nøkkel ved hjelp av en passordfrase som er lagret i skriptet:

#!/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 

Merk at passordfrasen er lagret i ren tekst i fra et sikkerhetsperspektiv er dette neppe bedre enn å ha en passordløs ssh-nøkkel. Hvis denne tilnærmingen skal brukes, er det viktig å sørge for at skriptet expect som inneholder passordfrasen, har de riktige tillatelsene, noe som gjør det lesbart, skrivbart og bare kan kjøres av nøkkelen. eier.

Kommentarer

• Ok, men når jeg legger koden din til ~ / .bash_profile, må jeg skrive inn passord hver gang jeg logger inn, jeg ikke vil ‘ heller ikke det. Jeg er ikke bekymret for sikkerhet i det hele tatt. ekko » pass \ n » | ssh-add fungerer ikke ‘ t
• @ user1607072 Ja, det er slik ssh-agent kodebiten i ~/.bash_profile oppfører seg som forklart i svaret. Det kan være lurt å se på keychain verktøyet. Med keychain må du oppgi passordet ved første innlogging etter omstart, men ved påfølgende pålogginger vil keychain koble til en eksisterende ssh-agent forekomst med den dekrypterte nøkkelen i minnet. Bortsett fra det er ‘ muligheten for å generere en ssh-nøkkel uten passordfrase, men dette anbefales selvfølgelig ikke.
• @ user1607072 Mens jeg vil sterkt foreslå en av de sikrere tilnærmingene, det er en måte å overføre passordfrasen til ssh-add fra et skript. Årsaken til at echo "pass\n" | ssh-add ikke fungerer, er at ssh-add ikke leser passordet fra stdin, men åpner /dev/tty direkte for lesing. Oppdaterte svaret for å inkludere en løsning for dette ved hjelp av et verktøy som heter expect.
• @ user1607072 Det kan være litt overkill for din brukstilfelle, men Kerberos i kombinasjon med ssh GSSAPI -støtte kan også brukes til passordløse ssh-pålogginger. Den tilsvarende autentiseringsmetoden i ssh kalles gssapi-with-mic. Dette brukes vanligvis i større nettverk, men selvfølgelig, hvis du har interesse for dette, kan det være verdt å se nærmere på det.
• @ErickBrown: Har allerede svart her . SSH Agent-enheten bør stoppes ved avlogging hvis du har deaktivert brukerdroende i systemd login manager . Hvis brukerdroende er aktivert, blir systemd-brukerforekomsten og SSH Agent-enheten kjørt selv etter at den siste påloggingsøkten er lukket.

Legg til dette i ~/.bashrc, og logg deretter av og tilbake for å tre i kraft.

 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  

Dette skal bare be om passord første gang du logger inn etter hver omstart. Det vil fortsette å bruke den samme ssh-agent så lenge den fortsetter å kjøre.

Kommentarer

• veldig pent , på denne måten har du bare en ssh-agent som kjører (: Flere agenter som i @thomasNyman ‘ sin andre løsning virker en sikkerhetsrisiko for meg …
• Etter å ha undersøkt på forskjellige nettsteder og lest forskjellige løsninger, synes denne her å være den klareste, rett til poenget. Veldig hyggelig. +1
• bedre å gjøre dette: `alias ssh = ssh-check-agent «, og la sjekkagentversjonen gjøre det ovenfor. på den måten: a) du får bare en agent og b) du får bare agenten hvis du trenger det
• Jeg tror -s er standard, så vi ‘ gjør det allerede.
• Merk at ssh-add uten argumenter legger til ~/.ssh/id_rsa. Det kan være lurt å sende ssh-add argumenter hvis de private nøklene er i en annen fil.

ssh-agent cacher forskjellige ulåste ssh-nøkler, slik at du kan ha ssh-nøkler beskyttet av passord, men uten å måtte skrive dem hver eneste gang.

For å cache ulåste nøkler, må det åpenbart låse opp disse nøklene. For å låse opp nøkler som er låst med en passordfrase, trenger det åpenbart å kjenne disse passordene.

Enhver metode som ikke krever autorisasjon fra et menneske (f.eks. «Å skrive inn et passord») vil ikke bare gjøre din usikker på systemet; det vil også gjøre hele formålet med ssh-agenten meningsløs.

Når du har sagt alt dette, kan du ganske enkelt bruke ssh-nøkler som ikke er passordbeskyttet (trykk Enter når du blir spurt for passord under nøkkelgenerering). Siden det ikke er noe passord, trenger ssh-agent ikke be deg om et for å (ikke) cache det.

Kommentarer

• Jeg er enig, så lenge nøklene dine er skikkelig brukertillatelse, er det liten fordel med ssh-agent fremfor tillatelsesløse nøkler. Jeg liker å ssh inn på en påloggingsserver, og så har den serveren en haug med permless nøkler, som hver kun kan brukes til å låse opp en annen server. påloggingsserveren gjør ingenting annet, så det ‘ er mye vanskeligere å hacke / spoofe osv … de andre serverne har ingen passordtilgang, er bare nøkkel.

Her er en løsning for å automatisere SSH-passordsetningen.

1. Lag et one-liner-skript som skriver ut passordfrasen til standardutdata, f.eks:

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

   Viktig: Sørg for du kopierer det ledende området til forhindrer lagring av passordet i historikken din .

Og bruk en av metodene nedenfor.

• ved å bruke en standard inngangsmetode:

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

• eller tilnærmet rør tilnærming:

  1. Opprett en navngitt rør (du kan også prøve en prosessubstitusjon ):

     mkfifo --mode 0600 ~/.ssh_fifo 

  2. Kjør ssh-add ved å spesifisere programmet som brukes til autentiseringen:

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

  Se: man ssh-add for å lese mer om SSH_ASKPASS.

Kommentarer

• echo my_passphrase er et stort sikkerhetshull. Først etter at du har skrevet det, er passordet i klar tekst i historikkfilen til hvilket skjell du bruker. Og andre kommandolinjeargumenter er lesbare på Unix (ps -ef). Sett aldri passord i kommandolinjeargumenter!
• @ceving Å legge til ekstra ledende plass løser problemet med historikkfilen. Lagt til ekstra info.
• @kenorb: Det løser ikke ‘ t det større problemet med passordet som er synlig i ps produksjon. Historikkfilen kan vanligvis bare leses av den eier som bruker uansett, men kommandolinjene kan leses av alle brukere på et system.

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 

Jeg brukte skriptet som er nevnt av steampowered, jeg har laget nedenstående nå, fordi det ikke etterlater filer liggende.

Arbeider med zsh bare skall.

#!/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 

Kommentarer

• » Arbeider med bare zsh shell «, ok, men hvorfor sier shebang-linjen din at den bare krever » sh «?

Hvis du kjører sjøhest som passordadministrator … Som du sannsynligvis er; D

En annen løsning som oppnår målet du leter etter, er å bare legge til ssh-tastene til sjøhest for automatisk opplåsing ved pålogging . Den største fordelen med dette er at du aldri trenger å angi et passord for nøklene etter at du har logget inn via gdm, eller hva du logger på med, selv om nøklene har et passord. Dette KREVER både den private nøkkelen og den offentlige nøkkelen. De MÅ også følge en navnekonvensjon for sjøhest. Standard er akseptabelt (id_rsa for privat nøkkel og id_rsa.pub for offentlig nøkkel … Egentlig alt som er privatnavnnavn og privatnavn_navn.pub )

For å legge til din ssh-nøkkel til sjøhest for automatisk opplåsing ved pålogging; (på fedora25 er jeg ikke sikker på hvor stien er på andre distroer, selv om den mest sannsynlig er veldig lik)

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

For meg var det

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

(sjøhest vil automatisk anta at den offentlige nøkkelen i mitt tilfelle var id_rsa.pub)

Etter at kommandoen er utført, åpner sjøhesten en søtt lite gtk-passordfelt for å skrive inn passordet for den private nøkkelen. eller bare la det være tomt hvis du genererte nøkkelen uten passord.

Seahorse vil ikke be deg om alt gikk bra. Du må prøve å ssh inn i målmaskinen.Så vil sjøhest be deg om å låse opp nøkkelen med et passord grafisk (DET SKJER KUN EN gang) igjen, men det skal se litt annerledes ut denne gangen; P (dette er også den delen der sjøhest gjør litt sjøhest for å ssh-add magi tror jeg ), og tilbyr ALTERNATIV for å låse opp nøkkelen ved pålogging, må du merke av dette alternativet for oppnå målet ditt.

Bare fordi jeg ikke leste alle svarene, vil jeg anbefale å angre det alle ba deg om å gjøre med ssh-add før jeg prøvde dette svaret. Hvis du gjør det ellers, kan det føre til at noe skjer til nøklene dine, idk.

Enkel påloggingsløsning for SSH kan føre meg til pam_ssh .

I henhold til denne artikkelen , konseptet er:

Hvis du jobber med flere * nix-baserte maskiner via ssh, er du sannsynligvis lei av ulemper å måtte angi passordet hver gang du vil ha tilgang til en annen rute. Det er en sikker måte å gi deg tilgang til alle maskiner, som du har ssh-tilgang til, uten å måtte oppgi et annet passord (annet enn det du opprinnelig logget på.)

Dette er faktisk ganske enkelt å gjøre, du oppretter i utgangspunktet bare et offentlig / privat nøkkelpar for å autentisere deg selv til de andre maskinene dine, så har du PAM gyter en agent for å laste nøklene etter at du har logget på, og gir en enkelt påloggingsløsning for å få tilgang til alle eksterne maskiner. Denne guiden vil lede deg gjennom å sette opp dette.

Jeg har ikke bekreftet at dette faktisk ville fungere.

Legg til dette i ~/.bashrc -filen:

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

Kommentarer

• Jeg ser ikke ‘ t hvordan dette forholder seg til spørsmålet, som handler om å ikke bli bedt om passordet på påfølgende pålogginger.

For å legge til en (muligens passordløs) nøkkel og sikre at ssh-add vil ikke be om passord, uansett hva, selv når du kjører under X :

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

Utgangsstatus indikerer suksess eller fiasko.

Her er den definitive manus.

Oppdater $ PASSW, kopier og lim den inn i terminalen din

# <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 

Mitt oppsett på macOS er som følger (i .zshrc, eller .bash_profile for bash-folk):

|| [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]] -delen er nødvendig på macOS fordi standardverdien er /private/tmp/com.apple.launchd.SOMETHINGHERE/Listeners. Ellers mislykkes @Thomas Nymans omfattende svar fordi $SSH_AUTH_SOCK alltid er satt til noe.

Så i .zlogout (eller .bash_logout for bash-folk):

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

Testet på macOS Mojave 10.14.5

Dette har blitt veldig godt forklart av GitHub på Automatisk lansering av ssh-agent på Git for Windows , som igjen fungerer for Linux også.

Du kan kjøre ssh-agent automatisk når du åpner bash eller Git shell. Kopier følgende linjer og lim dem inn i ~/.profile eller ~/.bashrc -filen i Git shell:

 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  

Hvis din private nøkkel ikke er lagret på en av standardplasseringene (som ~/.ssh/id_rsa), må du fortelle SSH-autentiseringsagenten din hvor du finner den. For å legge til nøkkelen til ssh-agent, skriv ssh-add ~/path/to/my_key.

Tips: Hvis du vil at ssh-agent glemmer nøkkelen etter en stund, kan du konfigurer den til å gjøre det ved å kjøre ssh-add -t <seconds>.