Hvordan kan jeg køre ssh-add automatisk uden en adgangskode?

Dette er et typisk eksempel på en afvejning mellem sikkerhed og bekvemmelighed. Heldigvis er der en række muligheder. Den mest passende løsning afhænger af brugsscenariet og det ønskede sikkerhedsniveau.

ssh-nøgle med adgangssætning, ingen ssh-agent

Nu skal adgangssætningen indtastes hver gang nøglen bruges til godkendelse. Selvom dette er den bedste mulighed ud fra et sikkerhedsmæssigt synspunkt, tilbyder det den værste anvendelighed. Dette kan også føre til, at en svag adgangssætning vælges i rækkefølge for at mindske byrden ved at indtaste den gentagne gange.

ssh-nøgle med adgangssætning, med ssh-agent

Tilføjelse af følgende til ~/.bash_profile starter automatisk ssh-agent og indlæs ssh-key (s) ved login:

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

Nu skal adgangssætningen indtastes for hver Log på. Selvom det er lidt bedre set fra et brugervenligt perspektiv, har dette den ulempe, at ssh-agent beder om adgangskoden, uanset om nøglen skal bruges eller ikke under login-sessionen. Hvert nyt login gyder også en særskilt ssh-agent forekomst, der forbliver kørende med de tilføjede nøgler i hukommelsen, selv efter logout, medmindre det eksplicit dræbes.

At dræbe ssh_agent ved logout, tilføj følgende til ~/.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 

Oprettelse af flere ssh-agent forekomster kan undgås ved oprettelse af et vedvarende kommunikationsstik til agenten på et fast sted i filsystemet, f.eks. i Collin Anderson “svar . Dette er en forbedring i forhold til at gyde flere agenter tilfælde, medmindre den dekrypterede nøgle stadig eksplicit dræbes, forbliver stadig i hukommelsen efter logout.

På desktops er ssh-agenter inkluderet i skrivebordsmiljøet, såsom Gnome Keyring SSH Agent , kan være en bedre tilgang, da de typisk kan fås til at bede om pasningen sætning første gang ssh-nøglen bruges under en login-session og gem den dekrypterede private nøgle i hukommelsen indtil slutningen af sessionen.

ssh- nøgle med adgangssætning, med ssh-ident

ssh-ident er et værktøj, der kan administrere ssh-agent på dine vegne og indlæse identiteter efter behov. Det tilføjer kun nøgler, når de er nødvendige, uanset hvor mange terminaler, ssh eller login-sessioner, der kræver adgang til en ssh-agent. Det kan også tilføje og bruge en anden agent og forskellige sæt nøgler afhængigt af værten, der er tilsluttet, eller kataloget ssh påberåbes fra. Dette giver mulighed for at isolere nøgler, når du bruger agentvideresendelse med forskellige værter. Det giver også mulighed for at bruge flere konti på websteder som GitHub.

For at aktivere ssh-ident skal du installere det og tilføje følgende alias til dit ~/bash_profile:

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

ssh-tast med adgangssætning med keychain

keychain er et lille hjælpeprogram, der administrerer ssh-agent på dine vegne og tillader ssh-agent at køre, når login-sessionen slutter. Ved efterfølgende logins vil keychain oprette forbindelse til den eksisterende ssh-agent -forekomst. I praksis betyder dette, at adgangssætningen kun skal indtastes under det første login efter en genstart. Ved efterfølgende logins bruges den ukrypterede nøgle fra den eksisterende ssh-agent forekomst.Dette kan også være nyttigt til at tillade adgangskodeløs RSA / DSA-godkendelse i cron job uden adgangskodeløse ssh-nøgler.

For at aktivere keychain, installer det og tilføj noget i retning af følgende til ~/.bash_profile:

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

Fra et sikkerhedspunkt på visning, ssh-ident og keychain er værre end ssh-agent forekomster begrænset til levetiden for en bestemt session, men de tilbyder et højt niveau af bekvemmelighed. For at forbedre sikkerheden ved keychain tilføjer nogle mennesker indstillingen --clear til deres ~/.bash_profile nøglering påkaldelse. Ved at gøre dette skal adgangssætninger indtastes igen ved login som ovenfor, men cron job vil stadig have adgang til de ukrypterede nøgler, efter at brugeren logger af. keychain wiki-siden har flere oplysninger og eksempler.

ssh-key uden adgangssætning

Fra et sikkerhedsmæssigt synspunkt er dette den værste mulighed, da den private nøgle er helt ubeskyttet i tilfælde af at den er udsat. Dette er dog den eneste måde at sikre, at adgangssætningen ikke behøver at blive indtastet efter en genstart.

ssh-nøgle med adgangssætning, med ssh-agent, videregiver adgangssætning til ssh-add fra script

Mens det måske virker som en ligetil idé at videregive adgangssætningen til ssh-add fra et script, f.eks. echo "passphrase\n" | ssh-add, dette er ikke så let som det ser ud til, at ssh-add ikke læser adgangssætning fra stdin, men åbner /dev/tty direkte til læsning .

Dette kan være arbejdede rundt med expect , et værktøj til automatisering af interaktiv applikationer. Nedenfor er et eksempel på et script, der tilføjer en ssh-nøgle ved hjælp af en adgangssætning, der er gemt i scriptet:

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

Bemærk, at da adgangssætningen er gemt i almindelig tekst i fra et sikkerhedsperspektiv er scriptet næppe bedre end at have en adgangskodeløs ssh-nøgle. Hvis denne fremgangsmåde skal bruges, er det vigtigt at sikre, at expect scriptet, der indeholder adgangsfrasen, har de rette tilladelser, hvilket gør det læsbart, skrivbart og kun kan køres med nøglen ejer.

Kommentarer

• Okay, men når jeg sætter din kode til ~ / .bash_profile, skal jeg indtaste adgangskoden hver gang jeg logger ind, jeg vil ikke ‘ heller ikke have det. Jeg er slet ikke bekymret for sikkerhed. ekko ” pass \ n ” | ssh-add fungerer ikke ‘ t
• @ user1607072 Ja, det er sådan ssh-agent uddrag i ~/.bash_profile opfører sig som forklaret i svaret. Du kan muligvis se på keychain -værktøjet. Med keychain skal du indtaste adgangskoden ved første login efter genstart, men ved efterfølgende login vil keychain oprette forbindelse til en eksisterende ssh-agent instans med den dekrypterede nøgle i hukommelsen. Bortset fra det er der ‘ muligheden for at generere en ssh-nøgle uden en adgangssætning, men det anbefales naturligvis ikke.
• @ user1607072 Mens jeg meget foreslå en af de mere sikre tilgange, der er en måde at videregive adgangssætningen til ssh-add fra et script. Årsagen til, at echo "pass\n" | ssh-add ikke fungerer, er, at ssh-add ikke læser adgangskoden fra stdin, men åbner /dev/tty direkte til læsning. Opdateret svaret for at inkludere en løsning til dette ved hjælp af et hjælpeprogram kaldet expect.
• @ user1607072 Det kan være lidt overkill for din brugssag, men Kerberos i kombination med ssh GSSAPI understøttelse kan også bruges til adgangskodeløs ssh-login. Den tilsvarende godkendelsesmetode i ssh kaldes gssapi-with-mic. Dette bruges normalt i større netværk, men hvis du har interesse for dette, kan det naturligvis være værd at undersøge.
• @ErickBrown: Allerede besvaret her . SSH Agent-enheden skal stoppes ved aflogning, hvis du har deaktiveret brugerdrivende i systemd login manager . Hvis bruger-dvæling er aktiveret, holdes systemd-brugerforekomsten og SSH Agent-enheden kørende, selv efter den sidste login-session er lukket.

Føj dette til din ~/.bashrc, og log derefter ud og ind igen for at træde 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 kun bede om en adgangskode første gang du logger ind efter hver genstart. Det fortsætter med at genbruge den samme ssh-agent så længe den forbliver i gang.

Kommentarer

• meget pæn , på denne måde har du kun en ssh-agent, der kører (: Flere agenter som i @thomasNyman ‘s anden løsning virker en sikkerhedsrisiko for mig …
• Efter at have undersøgt forskellige steder og læst forskellige løsninger, synes denne her at være den klareste, lige til sagen. Meget flot. +1
• bedre at gøre dette: `alias ssh = ssh-check-agent “, og få check-agentversionen til at gøre ovenstående. på den måde: a) du får kun en agent og b) du får kun agenten, hvis du har brug for det
• Jeg tror -s er standard, så vi ‘ gør det allerede.
• Bemærk at ssh-add uden argumenter tilføjer ~/.ssh/id_rsa. Du vil muligvis sende ssh-add argumenter, hvis dine private nøgler er i en anden fil.

ssh-agent caches forskellige ulåste ssh-nøgler, så du kan have ssh-nøgler beskyttet af adgangskoder, men uden at skulle skrive dem hver eneste gang.

For at cache ulåste nøgler skal den naturligvis låse op for disse nøgler. For at låse op for nøgler, der er låst med en adgangssætning, skal den naturligvis kende disse adgangssætninger.

Enhver metode, der ikke kræver autorisation fra et menneske (f.eks. “At indtaste et kodeord”), gør ikke kun din usikker på systemet; det vil også gøre hele formålet med ssh-agenten meningsløs.

Når det er sagt, kan du simpelthen bruge ssh-nøgler, der ikke er adgangskodebeskyttet (tryk Enter , når du bliver spurgt for en adgangskode under generering af nøgler). Da der ikke er nogen adgangskode, behøver ssh-agent ikke at bede dig om en for at (ikke) cache den.

Kommentarer

• Jeg er enig, så længe dine nøgler er korrekt kun til brugertilladelse, er der lille fordel ved ssh-agent frem for tilladelsesfri nøgler. Jeg kan godt lide at ssh ind på en login-server, og derefter har denne server en masse permssionless nøgler, som hver kun kan bruges til at låse op for en anden server. login-serveren gør intet andet, så det ‘ er meget sværere at hacke / spoofe osv … de andre servere har ingen adgangskodeadgang, er kun nøgle.

Her er en løsning til automatisering af din SSH-adgangskode.

1. Opret et one-liner-script, der udskriver din adgangssætning til standardoutput, fx:

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

   Vigtigt: Sørg for du kopierer det ledende mellemrum til forhindrer lagring af din adgangskode i din historie .

Og brug en af nedenstående metoder.

• ved hjælp af en standard inputmetode:

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

• eller benævnt rør tilgang:

  1. Opret en navngivet rør (du kan også prøve en proceserstatning ):

     mkfifo --mode 0600 ~/.ssh_fifo 

  2. Kør ssh-add ved at specificere det program, der bruges til godkendelsen:

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

  Se: man ssh-add for at læse mere om SSH_ASKPASS.

Kommentarer

• echo my_passphrase er et stort sikkerhedshul. Først efter at du har skrevet det, er adgangskoden i klar tekst i historikfilen for den shell, du nogensinde bruger. Og anden kommandolinjeargument er verdenslæsbare på Unix (ps -ef). Sæt aldrig adgangskoder i kommandolinjeargumenter!
• @ceving Tilføjelse af ekstra ledende plads løser problemet med historikfilen. Tilføjet ekstra info.
• @kenorb: Det ‘ t løser det større problem med adgangskoden, der er synlig i ps produktion. Historikfilen kan typisk kun læses af den ejer, der bruger, alligevel, men kommandolinjerne kan læses af alle brugere 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 brugte det script, der er nævnt af steampowered, jeg har lavet nedenstående nu, fordi det ikke efterlader filer ligger rundt.

Arbejder kun med zsh 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 

Kommentarer

• ” Arbejder med kun zsh shell “, okay men hvorfor angiver din shebang-linje kun at kræve ” sh “?

Hvis du kører søhest som din adgangskodeadministrator … Som du sandsynligvis er; D

En anden løsning, der opnår det mål, du leder efter, er blot at tilføje ssh-tasterne til søhest til automatisk oplåsning ved login . Den største fordel ved dette er, at du aldrig behøver at indtaste en adgangskode til nøglerne, når du har logget ind via gdm, eller hvad du end logger ind med, selvom nøglerne har en adgangskode. Dette KRÆVER både den private nøgle og den offentlige nøgle. De SKAL også følge en navngivningskonvention for søhest. Standard er acceptabel (id_rsa for privat nøgle og id_rsa.pub for offentlig nøgle … Virkelig alt, hvad der er privat navnnavn og privat navnnavn.pub )

For at tilføje din ssh-nøgle til søhest til automatisk oplåsning ved login; (på fedora25 er jeg ikke sikker på, hvor stien er på andre distroer, selvom det sandsynligvis er meget ens)

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

For mig var det

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

(søhest antager automatisk, at den offentlige nøgle i mit tilfælde var id_rsa.pub)

Efter udførelse af kommandoen åbner søhest en søde lille gtk-adgangskodefelt for at indtaste adgangskoden til den private nøgle i. eller bare lade den være tom, hvis du genererede nøglen uden en adgangskode.

Seahorse vil ikke bede dig om alt gik okay. Du bliver nødt til at prøve at ssh ind på målmaskinen.Derefter beder søhest dig om at låse nøglen op med en adgangskode grafisk (DET SKAL KUN GÅ EN GANG) igen, men det skal se lidt anderledes ud denne gang; P (dette er også den del, hvor søhest gør noget søhest for at ssh-tilføje magi, tror jeg ), og tilbyder OPTION for at låse nøglen op ved login, skal du kontrollere denne mulighed for at nå dit mål.

Bare fordi jeg ikke læste alle svarene, vil jeg anbefale at fortryde, hvad alle har bedt dig om at gøre med ssh-add, før jeg prøver dette svar. Hvis du gør det ellers, kan det resultere i, at der sker noget dårligt til dine nøgler, idk.

Enkelt tilmeldingsløsning til SSH kan føre mig til pam_ssh .

I henhold til denne artikel , konceptet er:

Hvis du arbejder med flere * nix-baserede maskiner via ssh, er du sandsynligvis træt af ulemper behøver at indtaste din adgangskode hver gang du vil have adgang til et andet felt. Der er en sikker måde at give dig adgang til enhver maskine, som du har ssh-adgang til, uden at skulle indtaste en anden adgangskode (bortset fra den, du oprindeligt loggede på.)

Dette er faktisk ret simpelt at gøre, du opretter stort set bare et offentligt / privat nøglepar for at autentificere dig selv til dine andre maskiner, så har PAM gyder en agent til at indlæse dine nøgler, når du har logget på, hvilket giver en enkelt logonløsning til at få adgang til alle dine eksterne maskiner. Denne guide fører dig gennem opsætningen af dette.

Jeg har ikke bekræftet, at dette rent faktisk fungerer.

Føj dette til din ~/.bashrc -fil:

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

Kommentarer

• Jeg kan ikke ‘ ikke se, hvordan dette vedrører spørgsmålet, som handler om ikke at blive bedt om adgangskoden ved efterfølgende logins.

For at tilføje en (muligvis adgangskodeløs) nøgle og sikre, at ssh-add beder ikke om en adgangskode, uanset hvad, selv når den kører under X :

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

Status for udgang angiver succes eller fiasko.

Her er den endelige manuskript.

Opdater $ PASSW, og kopier og indsæt den derefter i din 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 

Min opsætning 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 standardværdien er /private/tmp/com.apple.launchd.SOMETHINGHERE/Listeners. Ellers mislykkes @Thomas Nymans omfattende svar, fordi $SSH_AUTH_SOCK altid er indstillet til noget.

Derefter 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 er meget godt forklaret af GitHub på Automatisk lancering af ssh-agent på Git til Windows , som igen også fungerer for Linux.

Du kan køre ssh-agent automatisk, når du åbner bash eller Git shell. Kopier følgende linjer og indsæt dem i din ~/.profile eller ~/.bashrc fil 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øgle ikke er gemt et af standardplaceringerne (som ~/.ssh/id_rsa), skal du fortælle din SSH-godkendelsesagent, hvor du finder den. Hvis du vil føje din nøgle til ssh-agent, skal du skrive ssh-add ~/path/to/my_key.

Tip: Hvis du vil have ssh-agent til at glemme din nøgle efter et stykke tid, kan du konfigurer det til at gøre det ved at køre ssh-add -t <seconds>.