Hoe kan ik ssh-add automatisch uitvoeren, zonder een wachtwoordprompt?

Dit is een typisch voorbeeld van een afweging tussen en gemak. Gelukkig zijn er een aantal mogelijkheden. De meest geschikte oplossing hangt af van het gebruiksscenario en het gewenste beveiligingsniveau.

ssh-key met wachtwoordzin, geen ssh-agent

Nu moet de wachtwoordzin worden ingevoerd elke keer dat de sleutel wordt gebruikt voor authenticatie. Hoewel dit vanuit beveiligingsoogpunt de beste optie is, biedt het de slechtste bruikbaarheid. Dit kan er ook toe leiden dat een zwakke wachtwoordzin in de juiste volgorde wordt gekozen, om de last van het herhaaldelijk invoeren ervan te verminderen.

ssh-key met wachtwoordzin, met ssh-agent

Het volgende toevoegen aan ~/.bash_profile zal automatisch starten ssh-agent en laad de ssh-sleutel (s) bij het inloggen:

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

Nu moet de wachtwoordzin bij elke Log in. Hoewel iets beter vanuit het oogpunt van bruikbaarheid, heeft dit het nadeel dat ssh-agent om de wachtwoordzin vraagt, ongeacht of de sleutel moet worden gebruikt of niet tijdens de inlogsessie. Elke nieuwe login brengt ook een aparte ssh-agent instantie voort die actief blijft met de toegevoegde sleutels in het geheugen, zelfs na het uitloggen, tenzij expliciet gestopt.

Om ssh_agent voeg bij het uitloggen het volgende toe aan ~/.bash_logout

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

of het volgende aan ~/.bash_profile

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

Het maken van meerdere ssh-agent instanties kan worden vermeden door het creëren van een permanente communicatiesocket met de agent op een vaste locatie in het bestandssysteem, zoals in het antwoord van Collin Anderson . Dit is een verbetering ten opzichte van het uitzetten van meerdere agents gevallen echter, tenzij expliciet uitgeschakeld, blijft de gedecodeerde sleutel in het geheugen na het uitloggen.

Op desktops, ssh-agents die zijn opgenomen in de desktopomgeving, zoals de Gnome Keyring SSH Agent , kan een betere benadering zijn, omdat ze meestal kunnen worden gevraagd om de pas zin de eerste keer dat de ssh-sleutel wordt gebruikt tijdens een inlogsessie en sla de gedecodeerde privésleutel in het geheugen op tot het einde van de sessie.

ssh- sleutel met wachtwoordzin, met ssh-ident

ssh-ident is een hulpprogramma dat ssh-agent namens u kan beheren en indien nodig identiteiten kan laden. Het voegt sleutels slechts één keer toe als ze nodig zijn, ongeacht hoeveel terminals, ssh of login-sessies toegang tot een ssh-agent vereisen. Het kan ook een andere agent en een andere set sleutels toevoegen en gebruiken, afhankelijk van de host waarmee verbinding wordt gemaakt, of de directory ssh wordt aangeroepen. Dit maakt het mogelijk om sleutels te isoleren bij het gebruik van agentforwarding met verschillende hosts. Het maakt het ook mogelijk om meerdere accounts te gebruiken op sites zoals GitHub.

Om ssh-ident in te schakelen, installeer het en voeg de volgende alias toe aan je ~/bash_profile:

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

ssh-key met wachtwoordzin, met keychain

keychain is een klein hulpprogramma dat ssh-agent namens u beheert en ervoor zorgt dat de ssh-agent actief blijft wanneer de inlogsessie eindigt. Bij volgende logins zal keychain verbinding maken met de bestaande ssh-agent instantie. In de praktijk betekent dit dat de wachtwoordzin alleen moet worden ingevoerd tijdens de eerste keer inloggen na een herstart. Bij volgende logins wordt de niet-versleutelde sleutel van de bestaande ssh-agent -instantie gebruikt.Dit kan ook handig zijn om wachtwoordloze RSA / DSA-authenticatie toe te staan in cron taken zonder wachtwoordloze ssh-sleutels.

Om keychain, installeer het en voeg iets als het volgende toe aan ~/.bash_profile:

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

Vanaf een beveiligingspunt van weergave, ssh-ident en keychain zijn slechter dan ssh-agent instanties beperkt tot de levensduur van een bepaalde sessie, maar ze bieden een hoog niveau van gemak. Om de beveiliging van keychain te verbeteren, voegen sommige mensen de --clear optie toe aan hun ~/.bash_profile sleutelhanger aanroeping. Door dit te doen, moeten wachtzinnen opnieuw worden ingevoerd bij het inloggen zoals hierboven beschreven, maar cron -taken hebben nog steeds toegang tot de niet-versleutelde sleutels nadat de gebruiker uitlogt. De keychain wikipagina bevat meer informatie en voorbeelden.

ssh-key zonder wachtwoordzin

Vanuit beveiligingsoogpunt is dit de slechtste optie aangezien de privésleutel volledig onbeschermd is voor het geval deze blootgesteld. Dit is echter de enige manier om ervoor te zorgen dat de wachtwoordzin niet opnieuw hoeft te worden ingevoerd na het opnieuw opstarten.

ssh-key met wachtwoordzin, met ssh-agent, geeft wachtwoordzin door aan ssh-add uit script

Hoewel het zou kunnen lijkt een eenvoudig idee om de wachtwoordzin door te geven aan ssh-add vanuit een script, bijv. echo "passphrase\n" | ssh-add, dit is niet zo eenvoudig als het lijkt als ssh-add de wachtwoordzin van stdin, maar opent /dev/tty rechtstreeks om te lezen .

Dit kan werkte rond met expect , een tool voor het automatiseren van interactieve toepassingen. Hieronder ziet u een voorbeeld van een script dat een ssh-sleutel toevoegt met een wachtwoordzin die in het script is opgeslagen:

#!/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 op dat de wachtwoordzin in platte tekst wordt opgeslagen in het script, vanuit een beveiligingsperspectief, is dit nauwelijks beter dan een wachtwoordloze ssh-sleutel hebben. Als deze benadering moet worden gebruikt, is het belangrijk om ervoor te zorgen dat het expect -script dat de wachtwoordzin bevat, de juiste machtigingen heeft, waardoor het leesbaar, schrijfbaar en alleen met de sleutel kan worden uitgevoerd eigenaar.

Reacties

• Oké, maar als ik je code in ~ / .bash_profile zet, moet ik elke keer dat ik inlog mijn wachtwoord invoeren. don ‘ wil dat ook niet. Ik maak me helemaal geen zorgen over de veiligheid. echo ” pass \ n ” | ssh-add werkt niet ‘ niet
• @ user1607072 Ja, dat is hoe het ssh-agent fragment in ~/.bash_profile gedraagt zich zoals uitgelegd in het antwoord. Misschien wil je het keychain hulpprogramma bekijken. Met keychain moet u het wachtwoord invoeren bij de eerste keer inloggen na het opnieuw opstarten, maar bij volgende keer inloggen zal keychain verbinding maken met een bestaande ssh-agent instantie met de gedecodeerde sleutel in het geheugen. Afgezien daarvan is er ‘ s de mogelijkheid om een ssh-sleutel zonder wachtwoordzin te genereren, maar dit wordt natuurlijk niet aanbevolen.
• @ user1607072 Hoewel ik het sterk zou willen suggereren een van de veiligere benaderingen, er is een manier om de wachtwoordzin door te geven aan ssh-add vanuit een script. De reden dat echo "pass\n" | ssh-add niet werkt, is dat ssh-add het wachtwoord van stdin niet leest, maar opent /dev/tty direct om te lezen. Het antwoord bijgewerkt met een tijdelijke oplossing hiervoor, met behulp van een hulpprogramma met de naam expect.
• @ user1607072 Het is misschien een beetje overdreven voor jouw situatie, maar Kerberos in combinatie met ssh GSSAPI -ondersteuning kan ook worden gebruikt voor wachtwoordloze ssh-logins. De corresponderende authenticatiemethode in ssh heet gssapi-with-mic. Dit wordt meestal gebruikt in grotere netwerken, maar als je hierin geïnteresseerd bent, kan het natuurlijk de moeite waard zijn om dit te onderzoeken.
• @ErickBrown: hier . De SSH Agent-eenheid moet worden gestopt bij het uitloggen als u gebruikersverblijf heeft uitgeschakeld in de systemd login manager . Als gebruikers achterblijven is ingeschakeld, blijven de systemd-gebruikersinstantie en de SSH Agent-eenheid actief, zelfs nadat de laatste inlogsessie is afgesloten.

Voeg dit toe aan uw ~/.bashrc en log vervolgens uit en weer in om van kracht te worden.

 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  

Dit zou alleen om een wachtwoord moeten vragen de eerste keer dat u inlogt na elke herstart. Het zal hetzelfde ssh-agent blijven gebruiken zolang het actief blijft.

Reacties

• heel netjes , op deze manier heb je maar één ssh-agent actief (: meerdere agents zoals in @thomasNyman ‘ s tweede oplossing lijkt mij een beveiligingsrisico …
• Na onderzoek te hebben gedaan op verschillende sites en verschillende oplossingen te hebben gelezen, lijkt deze hier de duidelijkste, direct ter zake. Erg leuk. +1
• beter om dit te doen: `alias ssh = ssh-check-agent “, en laat de check-agent versie het bovenstaande doen. op die manier: a) je krijgt maar één agent en b) je krijgt alleen de agent als je die nodig hebt
• Ik denk dat -s de standaard is, dus we ‘ doen dat al.
• Merk op dat ssh-add zonder argumenten voegt ~/.ssh/id_rsa toe. Misschien wil je ssh-add argumenten doorgeven als je privésleutels in een ander bestand staan.

Niet nauw verwant aan de vraag van het OP, maar het kan nuttig zijn voor anderen: sinds 7.2.0 heeft ssh (1) een optie die het mogelijk maakt om een sleutel toe te voegen aan de ssh-agent bij de eerste authenticatie; de optie is AddKeysToAgent en kan worden ingesteld op yes, no, ask, of confirm, systeembreed of op uw persoonlijke .ssh/config -bestand.

Referentie : https://www.openssh.com/txt/release-7.2

Reacties

• Van toepassing op degenen die nieuw zijn in het .ssh/config -bestand: dit is van toepassing op ssh en alles dat erachter, bijvoorbeeld scp, en kan per host worden gedaan.
• Het vraagt me nog steeds om een wachtwoord elke keer dat ik inlog en probeer git pull bijvoorbeeld.
• @trainosis Het probleem is dat je waarschijnlijk geen ssh-agent-instantie hebt die de gedecodeerde sleutel (s) in het geheugen houdt voor toekomstig gebruik. U hoeft het wachtwoord voor een bepaalde sleutel slechts één keer per inlogsessie in te voeren wanneer u ssh-agent gebruikt.

ssh-agent slaat verschillende ontgrendelde ssh-sleutels op in het cachegeheugen, zodat je ssh-sleutels beschermd kunt hebben door wachtwoorden, maar zonder dat je ze elke keer hoeft in te typen.

Om ontgrendelde sleutels in het cachegeheugen te kunnen opslaan, moet deze uiteraard worden ontgrendeld. Voor het ontgrendelen van sleutels die zijn vergrendeld met een wachtwoordzin, moet het uiteraard deze wachtwoordzinnen kennen.

Elke methode waarvoor geen toestemming van een mens vereist is (bijv. “Het invoeren van een wachtwoord”) zal niet alleen uw systeem onveilig; het zal ook het hele doel van de ssh-agent betekenisloos maken.

Dit alles gezegd hebbende, kun je eenvoudig ssh-sleutels gebruiken die niet met een wachtwoord zijn beveiligd (druk op Enter wanneer daarom wordt gevraagd voor een wachtwoord tijdens het genereren van de sleutel). Aangezien er “geen wachtwoord is, hoeft ssh-agent u er niet om te vragen om het (niet) in de cache te plaatsen.

Opmerkingen

• Ik ben het ermee eens, zolang uw sleutels correct alleen door de gebruiker zijn geautoriseerd, heeft ssh-agent weinig voordelen ten opzichte van sleutels zonder toestemming. Ik hou ervan om naar een login-server te sshen, en dan heeft die server een aantal permssieloze sleutels, die elk alleen kunnen worden gebruikt om een andere server te ontgrendelen. de inlogserver doet niets anders, dus ‘ is veel moeilijker te hacken / spoofen, enz … de andere servers hebben geen wachtwoordtoegang, zijn alleen sleutel.

Hier is een oplossing om uw SSH-wachtwoordzin te automatiseren.

1. Maak een one-liner-script dat uw wachtwoordzin afdrukt naar de standaarduitvoer, bijvoorbeeld:

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

   Belangrijk: zorg ervoor dat je kopieert de eerste spatie naar en voorkomt dat je wachtwoord in je geschiedenis wordt opgeslagen .

En gebruik een van de onderstaande methoden.

• met een standaard invoerbenadering:

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

• of named pipe -benadering:

  1. Maak een named pipe (je zou ook een processubstitutie kunnen proberen ):

     mkfifo --mode 0600 ~/.ssh_fifo 

  2. Voer ssh-add door het programma te specificeren dat wordt gebruikt voor de authenticatie:

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

  Zie: man ssh-add om meer te lezen over SSH_ASKPASS.

Reacties

• De echo my_passphrase is een groot beveiligingslek. Nadat je het hebt getypt, staat het wachtwoord in duidelijke tekst in het geschiedenisbestand van de shell die je gebruikt. En tweede opdrachtregelargumenten zijn wereldwijd leesbaar op Unix (ps -ef). Plaats nooit wachtwoorden in opdrachtregelargumenten!
• @ceving Het toevoegen van extra voorloopruimte lost het probleem met het geschiedenisbestand op. Extra info toegevoegd.
• @kenorb: dat lost ‘ niet het grotere probleem op van het wachtwoord dat zichtbaar is in ps output. Het geschiedenisbestand is over het algemeen alleen leesbaar door de gebruiker die de eigenaar is, maar de opdrachtregels zijn leesbaar door alle gebruikers op een systeem.

Ik zal je ssh-add (die een ssh-agent moeten openen) niet aanbevelen bij het inloggen. Dit komt omdat je niet kunt controleren wanneer de ssh-agent-sectie eindigt, en dit kan een beveiligingsrisico vormen wanneer je de keyfiles niet hoeft te gebruiken bij een login-sectie.

In plaats daarvan raad ik aan om een script te schrijven dat de subshell van een ssh-agent-sectie opent, met alle keyfiles automatisch toegevoegd, en te worden aangeroepen wanneer nodig om ssh te gebruiken. Als je dit zou kunnen gebruiken, lees dan verder.

Je zou twee keuzes hebben:

1. Verwijder alle wachtwoordzinnen voor je sleutels, die zwakke beveiliging als uw sleutelbestanden worden gestolen. (dus niet aanbevolen )

2. Gebruik dezelfde wachtwoordzin voor uw sleutels. Wanneer u ssh-add keyfile1 keyfile2 ... gebruikt, hoeft u de wachtwoordzin slechts één keer per sectie in te voeren.

In beide gevallen zou je een dergelijk scriptbestand “ssh_keys_section.sh” kunnen schrijven zoals hieronder:

#!/bin/bash # This script run a ssh-agent on a sub-shell and automatically ssh-add all keyfiles at once. # This agent ends when you type `exit` to close the sub-shell. exec ssh-agent bash -c "ssh-add /path/to/keyfile1 /path/to/keyfile2 ...; exec bash" 

Opmerkingen:

• Commando om wachtwoordzin te wijzigen of te verwijderen: ssh-keygen -p -f keyfile
• Binnen de subshell zou je zelfs meer terminals kunnen splitsen die dezelfde ontgrendelde sleutels, door misschien een commando te gebruiken zoals /path/to/yourterminal & (afhankelijk van OS)

Reacties

• Bijv Op Windows binnen Cygwin, /path/to/yourterminal & == > mintty &
• Opmerking: sluit na gebruik de sessie met ctrl-d of exit, net zoals je een geneste bash shell en moet deze sluiten.

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 

Ik gebruikte het script dat door steampowered wordt genoemd, ik heb het onderstaande nu gemaakt, omdat het geen bestanden achterlaat rondslingeren.

Alleen werken aan 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 

Reacties

• ” Werken aan alleen zsh-shell “, oké, maar waarom zegt je shebang-regel dat alleen ” sh “?

SSH_ENV="$HOME/.ssh/environment" function start_agent { echo "Initialising new SSH agent..." /usr/bin/ssh-agent | sed "s/^echo/#echo/" > "${SSH_ENV}" echo succeeded chmod 600 "${SSH_ENV}" . "${SSH_ENV}" > /dev/null /usr/bin/ssh-add; } # Source SSH settings, if applicable if [ -f "${SSH_ENV}" ]; then . "${SSH_ENV}" > /dev/null #ps ${SSH_AGENT_PID} doesn"t work under cywgin ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || { start_agent; } else start_agent; fi 

Hier krediet geven: https://www.cygwin.com/ml/cygwin/2001-06/msg00537.html

Deze oplossing wordt hier ook onderschreven: http://mah.everybody.org/docs/ssh

Als je Seahorse gebruikt als je wachtwoordbeheerder … Wat u waarschijnlijk ook bent; D

Een andere oplossing die het doel bereikt waarnaar u op zoek bent, is simpelweg het toevoegen van de SSH-sleutels aan het zeepaardje voor automatisch ontgrendelen bij inloggen . Het grote voordeel hiervan is dat u nooit een wachtwoord hoeft in te voeren voor de sleutels nadat u inlogt via gdm, of wat u ook doet, zelfs als de sleutels een wachtwoord hebben. Dit VEREIST zowel de private sleutel als de publieke sleutel. Ze MOETEN ook een naamgevingsconventie voor zeepaardjes volgen. De standaardwaarde is acceptabel (id_rsa voor privésleutel en id_rsa.pub voor openbare sleutel … Echt alles wat privésleutelnaam en privésleutelnaam.pub is)

Om je SSH-sleutel toe te voegen aan het zeepaardje voor automatische ontgrendeling bij het inloggen; (op fedora25 weet ik niet zeker waar het pad is in andere distributies, hoewel het waarschijnlijk erg op elkaar lijkt)

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

Voor mij was het

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

(zeepaardje gaat er automatisch van uit dat de publieke sleutel in mijn geval id_rsa.pub was)

Na het uitvoeren van het commando zal zeepaardje een schattig klein gtk-wachtwoordveld om het wachtwoord voor de privésleutel in te voeren. of laat het leeg als je de sleutel zonder wachtwoord hebt gegenereerd.

Seahorse zal je niet vragen of alles goed is gegaan. U moet proberen om naar de doelcomputer te sshen.Dan zal zeepaardje je vragen om de sleutel weer grafisch te ontgrendelen met een wachtwoord (DIT ZAL SLECHTS EENMAAL GEBEUREN) maar het zou er deze keer een beetje anders uit moeten zien; P (dit is ook het deel waar zeepaardje een zeepaardje doet om magie toe te voegen, geloof ik ), en bied de OPTIE aan om de sleutel te ontgrendelen bij het inloggen, je moet deze optie aanvinken om bereik je doel.

Alleen omdat ik niet alle antwoorden heb gelezen, raad ik aan om ongedaan te maken wat iedereen je heeft verteld te doen met ssh-add voordat je dit antwoord probeert. Als je dit doet, kan er anders iets ergs gebeuren to your keys, idk.

Single sign-on oplossing voor SSH kan me leiden naar pam_ssh .

Volgens dit artikel , het concept is:

Als je met meerdere * nix-gebaseerde machines werkt via ssh, ben je waarschijnlijk de nadelen beu Elke keer dat u een andere box wilt openen, moet u uw wachtwoord invoeren. Er is een veilige manier om u toegang te geven tot elke machine waartoe u ssh-toegang heeft, zonder dat u een ander wachtwoord hoeft in te voeren (anders dan het wachtwoord waarmee u zich oorspronkelijk hebt aangemeld).

Dit is eigenlijk vrij eenvoudig om te doen, je maakt in feite gewoon een publiek / privé sleutelpaar om jezelf te authenticeren bij je andere machines, en dan heb je PAM spawt een agent om uw sleutels te laden nadat u zich hebt aangemeld, wat een eenmalige aanmeldingsoplossing biedt voor toegang tot al uw externe machines. Deze gids helpt je bij het instellen hiervan.

Ik heb niet geverifieerd dat dit echt zou werken.

Voeg dit toe aan uw ~/.bashrc bestand:

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

Reacties

• Ik ‘ zie niet hoe dit betrekking heeft op de vraag, die gaat over het niet vragen om het wachtwoord bij volgende logins.

Om een (mogelijk wachtwoordloze) sleutel toe te voegen en ervoor te zorgen dat ssh-add zal niet om een wachtwoord vragen, wat er ook gebeurt, zelfs niet onder X :

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

De afsluitstatus geeft aan dat het is gelukt of mislukt.

Hier is de definitieve script.

Werk $ PASSW bij, kopieer en plak het vervolgens in je 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 

De beste manier die ik ken, is om een PAM-inlogscript te gebruiken dat ik heb aangepast van eerder werk, omdat ik geen bevredigend antwoord kon vinden in deze vraag.

Je wachtwoordzin wordt opgeslagen gecodeerd met uw systeemwachtwoord en een zware afleidingsfunctie. Bij het inloggen wordt uw systeemwachtwoord gebruikt om uw wachtwoordzin te decoderen en toe te voegen aan de agent.

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

Het voordeel ten opzichte van elke andere voorgestelde oplossing is dat het beveiliging combineert met het handmatig uitvoeren van ssh-add bij het opstarten zonder enige moeite. geen extra tools en heeft één extra afhankelijkheid die “standaard al is geïnstalleerd op de meeste systemen (OpenSSL).

Mijn setup op macOS is als volgt (in .zshrc, of .bash_profile voor bash folks):

Het || [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]] -gedeelte is nodig op macOS omdat de standaardwaarde /private/tmp/com.apple.launchd.SOMETHINGHERE/Listeners is. Anders mislukt het uitgebreide antwoord van @Thomas Nyman omdat $SSH_AUTH_SOCK altijd op iets is ingesteld.

Dan in .zlogout (of .bash_logout voor bash mensen):

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

Getest op macOS Mojave 10.14.5

Dit is heel goed uitgelegd door GitHub op Automatisch starten van ssh-agent op Git voor Windows , wat op zijn beurt ook voor Linux werkt.

Je kunt ssh-agent automatisch laten draaien wanneer je de bash of Git shell opent. Kopieer de volgende regels en plak ze in je ~/.profile of ~/.bashrc bestand in de 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  

Als uw privésleutel niet is opgeslagen op een van de standaardlocaties (zoals ~/.ssh/id_rsa), moet u uw SSH-authenticatieagent vertellen waar deze kan worden gevonden. Om uw sleutel toe te voegen aan ssh-agent, typt u ssh-add ~/path/to/my_key.

Tip: Als u wilt dat ssh-agent uw sleutel na enige tijd vergeet, kunt u configureer het om dit te doen door ssh-add -t <seconds> uit te voeren.