Jak mogę uruchomić ssh-add automatycznie, bez pytania o hasło?

To jest typowy przykład kompromisu między bezpieczeństwem i wygoda. Na szczęście jest kilka opcji. Najbardziej odpowiednie rozwiązanie zależy od scenariusza użytkowania i pożądanego poziomu bezpieczeństwa.

klucz ssh z hasłem, no ssh-agent

Teraz hasło należy wprowadzić za każdym razem, gdy klucz jest używany do uwierzytelniania. Chociaż jest to najlepsza opcja z punktu widzenia bezpieczeństwa, oferuje najgorszą użyteczność. Może to również prowadzić do wybierania słabego hasła w celu zmniejszenia obciążenia związanego z jego wielokrotnym wprowadzaniem.

klucz ssh z hasłem, z ssh-agent

Dodanie następującego elementu do ~/.bash_profile rozpocznie się automatycznie ssh-agent i załaduj klucz (y) ssh podczas logowania:

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

Teraz hasło musi być wpisane przy każdym Zaloguj sie. Chociaż jest to nieco lepsze z punktu widzenia użyteczności, ma tę wadę, że ssh-agent pyta o hasło niezależnie od tego, czy klucz ma być używany, czy nie podczas sesji logowania. Każde nowe logowanie powoduje również powstanie odrębnej instancji ssh-agent, która pozostaje uruchomiona z dodanymi kluczami w pamięci nawet po wylogowaniu, chyba że zostanie wyraźnie zabita.

Aby zabić ssh_agent przy wylogowywaniu, dodaj następujące elementy do ~/.bash_logout

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

lub następujące, aby ~/.bash_profile

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

Tworzenie wielu ssh-agent instancji można uniknąć, tworzenie trwałego gniazda komunikacyjnego z agentem w stałej lokalizacji w systemie plików, na przykład w odpowiedzi Collina Andersona . Jest to ulepszenie w stosunku do tworzenia wielu agentów jednak instancje, o ile nie zostaną wyraźnie zabite, odszyfrowany klucz nadal pozostaje w pamięci po wylogowaniu.

Na komputerach stacjonarnych agenty ssh dołączone do środowiska graficznego, takie jak Agent SSH Gnome Keyring , może być lepszym podejściem, ponieważ zazwyczaj można poprosić o podanie hasła frazę, gdy klucz ssh jest używany po raz pierwszy podczas sesji logowania i przechowuj odszyfrowany klucz prywatny w pamięci do końca sesji.

ssh- klucz z hasłem, z ssh-ident

ssh-ident to narzędzie, które może zarządzać ssh-agent w Twoim imieniu i ładować tożsamości w razie potrzeby. Dodaje klucze tylko raz, gdy są potrzebne, niezależnie od tego, ile terminali, sesji ssh lub sesji logowania wymaga dostępu do ssh-agent. Może także dodawać i używać innego agenta i innego zestawu kluczy w zależności od podłączonego hosta lub katalogu, z którego jest wywoływany ssh. Pozwala to na izolowanie kluczy podczas korzystania z przekazywania agentów z różnymi hostami. Umożliwia także korzystanie z wielu kont w witrynach takich jak GitHub.

Aby włączyć ssh-ident, zainstaluj go i dodaj następujący alias do swojego ~/bash_profile:

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

klucz ssh z hasłem, z keychain

keychain to małe narzędzie, które zarządza ssh-agent w Twoim imieniu i umożliwia ssh-agent działanie po zakończeniu sesji logowania. Przy kolejnych logowaniach keychain połączy się z istniejącą instancją ssh-agent. W praktyce oznacza to, że hasło należy wprowadzić tylko podczas pierwszego logowania po restarcie. Przy kolejnych logowaniach używany jest niezaszyfrowany klucz z istniejącej instancji ssh-agent.Może to być również przydatne przy zezwalaniu na uwierzytelnianie RSA / DSA bez hasła w zadaniach cron bez kluczy SSH bez hasła.

Aby włączyć keychain, zainstaluj go i dodaj coś podobnego do poniższego do ~/.bash_profile:

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

Z punktu bezpieczeństwa widoku, ssh-ident i keychain są gorsze niż ssh-agent wystąpienia ograniczone do okresu istnienia konkretnego sesji, ale zapewniają wysoki poziom wygody. Aby poprawić bezpieczeństwo keychain, niektórzy dodają opcję --clear do swojego pęku kluczy ~/.bash_profile wezwanie. W ten sposób hasła należy wprowadzić ponownie podczas logowania, jak powyżej, ale zadania cron będą nadal miały dostęp do niezaszyfrowanych kluczy po wylogowaniu użytkownika. Więcej informacji i przykładów zawiera keychain strona wiki .

ssh-key bez hasła

Z punktu widzenia bezpieczeństwa jest to najgorsza opcja, ponieważ klucz prywatny jest całkowicie niechroniony, gdyby tak się stało jest narażony. Jest to jednak jedyny sposób, aby upewnić się, że hasło nie musi być ponownie wprowadzane po ponownym uruchomieniu.

klucz ssh z hasłem, z ssh-agent, przekazanie hasła do ssh-add ze skryptu

Chociaż może wydaje się być prostym pomysłem na przekazanie hasła do ssh-add ze skryptu, np. echo "passphrase\n" | ssh-add, to nie jest tak proste, jak się wydaje, ponieważ ssh-add nie czyta hasło z stdin, ale otwiera /dev/tty bezpośrednio do czytania .

Może to być obejrzałam z expect , narzędziem do automatyzacji interaktywnych Aplikacje. Poniżej znajduje się przykład skryptu, który dodaje klucz ssh przy użyciu hasła zapisanego w skrypcie:

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

Zwróć uwagę, że hasło jest przechowywane w postaci zwykłego tekstu w skryptu, z punktu widzenia bezpieczeństwa, jest to niewiele lepsze niż posiadanie klucza SSH bez hasła. Jeśli chcesz zastosować to podejście, ważne jest, aby upewnić się, że skrypt expect zawierający hasło ma odpowiednie uprawnienia, dzięki czemu jest czytelny, zapisywalny i uruchamialny tylko za pomocą klucza właściciel.

Komentarze

• OK, ale kiedy umieszczam twój kod w ~ / .bash_profile, muszę wpisywać hasło przy każdym logowaniu, nie ' też tego nie chcę. W ogóle nie martwię się o bezpieczeństwo. echo ” pass \ n ” | ssh-add nie ' t działa
• @ user1607072 Tak, tak oto ssh-agent fragment w ~/.bash_profile zachowuje się tak, jak wyjaśniono w odpowiedzi. Warto przyjrzeć się narzędziu keychain. W przypadku keychain musisz wprowadzić hasło przy pierwszym logowaniu po ponownym uruchomieniu, ale przy kolejnych logowaniach keychain połączy się z istniejącym z odszyfrowanym kluczem w pamięci. Poza tym istnieje ' opcja generowania klucza SSH bez hasła, ale to oczywiście nie jest zalecane.
• @ user1607072 Chociaż zdecydowanie zasugeruj jedno z bezpieczniejszych podejść, istnieje sposób na przekazanie hasła do ssh-add ze skryptu. Powodem, dla którego echo "pass\n" | ssh-add nie działa, jest to, że ssh-add nie odczytuje hasła z stdin, ale otwiera /dev/tty bezpośrednio do czytania. Zaktualizowałem odpowiedź, aby uwzględnić obejście tego problemu, używając narzędzia o nazwie expect.
• @ user1607072 Może to być trochę przesada w Twoim przypadku użycia, ale Kerberos w połączeniu z obsługą ssh GSSAPI może być również używany do logowania SSH bez hasła. Odpowiednia metoda uwierzytelniania w ssh nosi nazwę gssapi-with-mic. Jest to zwykle używane w większych sieciach, ale oczywiście jeśli jesteś tym zainteresowany, warto się temu przyjrzeć.
• @ErickBrown: już odpowiedział tutaj . Jednostka agenta SSH powinna zostać zatrzymana przy wylogowaniu, jeśli użytkownik ma wyłączoną funkcję zalegania w menedżerze logowania systemd . Jeśli opóźnianie użytkownika jest włączone, instancja użytkownika systemd i jednostka agenta SSH działają nawet po zamknięciu ostatniej sesji logowania.

Dodaj to do swojego ~/.bashrc, a następnie wyloguj się i z powrotem, aby odniosły skutek.

 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  

Powinno to tylko monitować o podanie hasła przy pierwszym logowaniu po każdym ponownym uruchomieniu. Będzie nadal używać tego samego ssh-agent tak długo, jak długo będzie działać.

Komentarze

• bardzo fajne , w ten sposób masz uruchomionego tylko jednego agenta ssh (: wiele agentów, jak w @thomasNyman ', drugie rozwiązanie wydaje mi się zagrożeniem dla bezpieczeństwa …
• Po przeszukaniu różnych witryn i przeczytaniu różnych rozwiązań, to tutaj wydaje się być najbardziej przejrzyste, od razu do rzeczy. Bardzo fajnie. +1
• lepiej to zrobić: `alias ssh = ssh-check-agent ” i niech wersja check-agent zrobi to powyżej. w ten sposób: a) otrzymasz tylko jednego agenta i b) otrzymasz agenta tylko wtedy, gdy go potrzebujesz
• Myślę, że -s jest wartością domyślną, więc ' już to robimy.
• Pamiętaj, że ssh-add bez argumentów dodaje ~/.ssh/id_rsa. Możesz chcieć przekazać ssh-add argumenty, jeśli twoje klucze prywatne znajdują się w innym pliku.

Nie jest ściśle związane z pytaniem OP, ale może być przydatne dla innych: od wersji 7.2.0 ssh (1) ma opcję, która pozwala na dodanie klucza do ssh-agent przy pierwszym uwierzytelnieniu; opcja to AddKeysToAgent i może być ustawiona na yes, no, ask lub confirm, w całym systemie lub w osobistym pliku .ssh/config.

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

Komentarze

• Dotyczy tych, którzy są nowicjuszami w pliku .ssh/config: dotyczy to ssh i wszystkiego, co używa ssh za nim, na przykład scp, i można to zrobić dla każdego hosta.
• Nadal pyta mnie o hasło za każdym razem, gdy się loguję i próbuję na przykład użyć git pull.
• @trainosis Problem polega na tym, że prawdopodobnie nie masz uruchomionej instancji ssh-agent, która przechowuje w pamięci odszyfrowane klucze do wykorzystania w przyszłości. W przypadku korzystania z ssh-agent wystarczy wpisać hasło dla danego klucza tylko raz na sesję logowania.

ssh-agent buforuje różne odblokowane klucze SSH, więc możesz mieć klucze SSH chronione hasłami, ale bez konieczności ich wpisywania za każdym razem.

Aby zapisać odblokowane klucze w pamięci podręcznej, oczywiście musi je odblokować. Aby odblokować klucze zablokowane hasłem, oczywiście musi znać te hasła.

Każda metoda, która nie wymaga autoryzacji przez człowieka (np. „Wpisanie hasła”), nie tylko sprawi, że niezabezpieczony system; spowoduje to również, że cały cel ssh-agent stanie się bez znaczenia.

Powiedziawszy to wszystko, możesz po prostu użyć kluczy ssh, które nie są chronione hasłem (naciśnij Enter gdy zostaniesz zapytany hasła podczas generowania klucza). Ponieważ nie ma żadnego hasła, ssh-agent nie musi Cię o nie prosić, aby (nie) przechowywać go w pamięci podręcznej.

Komentarze

• Zgadzam się, o ile twoje klucze mają odpowiednie uprawnienia tylko dla użytkownika, ssh-agent ma niewielką przewagę nad kluczami bez uprawnień. Lubię ssh do serwera logowania, a wtedy ten serwer ma kilka kluczy bez uprawnień, z których każdy może być użyty tylko do odblokowania jednego innego serwera. serwer logowania nie robi nic innego, więc ' jest znacznie trudniejszy do zhakowania / podszywania się itp. … inne serwery nie mają dostępu do hasła, są dostępne tylko za pomocą klucza.

Oto obejście umożliwiające zautomatyzowanie hasła SSH.

1. Utwórz jednoliniowy skrypt, który wypisze Twoje hasło na standardowe wyjście, np .:

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

   Ważne: upewnij się, że kopiujesz początkową spację do zapobiegasz zapisywaniu hasła w historii .

I użyj jednej z poniższych metod.

• używając standardowego podejścia do wprowadzania danych:

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

• lub nazwany potok podejście:

  1. Utwórz nazwany potok (możesz też wypróbować podstawienie procesu ):

     mkfifo --mode 0600 ~/.ssh_fifo 

  2. Uruchom ssh-add określając program używany do uwierzytelniania:

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

  Patrz: man ssh-add , aby dowiedzieć się więcej o SSH_ASKPASS.

Komentarze

• echo my_passphrase to duża dziura w zabezpieczeniach. Po pierwsze, po wpisaniu, hasło znajduje się w postaci zwykłego tekstu w pliku historii używanej powłoki. Drugie argumenty wiersza poleceń są czytelne dla wszystkich w systemie Unix (ps -ef). Nigdy nie umieszczaj haseł w argumentach wiersza poleceń!
• @ceving Dodanie dodatkowej spacji na początku rozwiązuje problem z plikiem historii. Dodano dodatkowe informacje.
• @kenorb: To nie ' nie rozwiązuje większego problemu z hasłem widocznego w ps wynik. Plik historii i tak jest zwykle czytelny tylko dla użytkownika będącego właścicielem, ale wiersze poleceń są w stanie odczytać wszyscy użytkownicy w systemie.

Nie polecam ci ssh-add (który musi otworzyć ssh-agent) podczas logowania. Dzieje się tak, ponieważ nie możesz kontrolować, kiedy kończy się sekcja ssh-agent i może to spowodować zagrożenie bezpieczeństwa kiedy nie potrzebujesz używać plików kluczy w jednej sekcji logowania.

Raczej polecam napisanie skryptu, który otwiera pod-powłokę sekcji ssh-agent, z automatycznie dodawanymi wszystkimi plikami kluczy i wywoływany, gdy potrzebne do użycia ssh. Jeśli możesz to przyjąć, czytaj dalej.

Miałbyś dwie możliwości:

1. Usuń wszystkie hasła do kluczy, które mają słabe zabezpieczenia w przypadku kradzieży plików kluczy. (w związku z tym niezalecane )

2. Użyj tego samego hasła dla swoich kluczy. Następnie, gdy ssh-add keyfile1 keyfile2 ..., będziesz musiał wpisać je tylko raz w każdej sekcji.

W obu przypadkach możesz napisać taki plik skryptu „ssh_keys_section.sh” jak poniżej:

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

Uwagi:

• Polecenie zmiany lub usunięcia hasła: ssh-keygen -p -f keyfile
• W ramach podpowłoki możesz nawet rozwidlić więcej terminali, które mają to samo odblokowane klucze, być może przy użyciu polecenia takiego jak /path/to/yourterminal & (w zależności od systemu operacyjnego)

Komentarze

• Np W systemie Windows w Cygwin, /path/to/yourterminal & == > mintty &
• Uwaga: po użyciu zamknij sesję za pomocą ctrl-d lub exit, tak jak przy wywołaniu zagnieżdżonego bash i zamknij ją.

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 

Używałem skryptu wspomnianego przez steampowered, zrobiłem teraz poniższy, ponieważ nie pozostawia on plików kłamać.

Praca tylko na zsh powłoce.

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

Komentarze

• ” Praca nad tylko powłoka zsh „, w porządku, ale dlaczego w linii shebang stwierdza się, że wymaga tylko ” 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 

Tutaj podajemy kredyt: https://www.cygwin.com/ml/cygwin/2001-06/msg00537.html

To rozwiązanie jest również zalecane tutaj: http://mah.everybody.org/docs/ssh

Jeśli używasz seahorse jako menedżera haseł … którym prawdopodobnie jesteś; D

Innym rozwiązaniem, które osiąga cel, którego szukasz, jest po prostu dodanie kluczy ssh do konika morskiego w celu automatycznego odblokowania po zalogowaniu . Główną korzyścią z tego jest to, że nigdy nie musisz wprowadzać hasła dla kluczy po zalogowaniu się przez gdm lub cokolwiek innego, z którym się logujesz, nawet jeśli klucze mają hasło. WYMAGA to zarówno klucza prywatnego, jak i publicznego. MUSZĄ również przestrzegać konwencji nazewnictwa koników morskich. Wartość domyślna jest akceptowalna (id_rsa dla klucza prywatnego i id_rsa.pub dla klucza publicznego … Naprawdę wszystko, co jest privatekeyname i privatekeyname.pub )

Aby dodać klucz SSH do konika morskiego w celu automatycznego odblokowania po zalogowaniu; (w Fedorze25 nie mam pewności, gdzie znajduje się ścieżka w innych dystrybucjach, chociaż najprawdopodobniej jest bardzo podobna)

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

Dla mnie była to

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

(konik morski automatycznie założy, że kluczem publicznym w moim przypadku był id_rsa.pub)

Po wykonaniu polecenia konik morski otworzy słodkie małe pole hasła gtk do wpisania hasła do klucza prywatnego lub po prostu pozostaw je puste, jeśli wygenerowałeś klucz bez hasła.

Seahorse nie zapyta Cię, jeśli wszystko poszło dobrze. Będziesz musiał spróbować ssh na maszynę docelową.Następnie konik morski ponownie poprosi Cię o odblokowanie klucza za pomocą hasła (TO ZDARZY SIĘ TYLKO RAZ), ale tym razem powinno wyglądać trochę inaczej; P (jest to również część, w której konik morski robi jakiś konik morski, aby ssh-add magic. ) i zaoferować OPCJA w celu odblokowania klucza po zalogowaniu, musisz zaznaczyć tę opcję, aby osiągnąć swój cel.

Tylko dlatego, że nie przeczytałem wszystkich odpowiedzi, polecam cofnąć to, co wszyscy kazali ci zrobić z ssh-add przed podjęciem tej odpowiedzi. W przeciwnym razie może się zdarzyć coś złego do twoich kluczy, idk.

Rozwiązanie jednokrotnego logowania dla SSH może doprowadzić mnie do pam_ssh .

Zgodnie z tym artykułem , koncepcja jest taka:

Jeśli pracujesz z wieloma maszynami opartymi na * nix przez ssh, prawdopodobnie masz dość wad konieczność wprowadzania hasła za każdym razem, gdy chcesz uzyskać dostęp do innej skrzynki. Istnieje bezpieczny sposób na uzyskanie dostępu do każdego komputera, do którego masz dostęp przez ssh, bez konieczności wprowadzania innego hasła (innego niż to, za pomocą którego pierwotnie się zalogowałeś).

Jest to całkiem proste, po prostu tworzysz parę kluczy publiczny / prywatny, aby uwierzytelnić się na innych komputerach, a następnie PAM tworzy agenta, który ładuje klucze po zalogowaniu, zapewniając rozwiązanie pojedynczego logowania w celu uzyskania dostępu do wszystkich zdalnych maszyn. Ten przewodnik przeprowadzi Cię przez proces konfiguracji.

Nie zweryfikowałem, czy to faktycznie zadziała.

Dodaj to do swojego ~/.bashrc pliku:

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

Komentarze

• Nie ' nie rozumiem, jak to się ma do pytania, czyli o brak pytania o hasło przy kolejnych logowaniach.

Aby dodać klucz (prawdopodobnie bez hasła) i upewnić się, że ssh-add nie zapyta o hasło, bez względu na wszystko, nawet jeśli działa pod X :

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

Status wyjścia wskazuje na sukces lub porażkę.

Oto ostateczne scenariusz.

Zaktualizuj $ PASSW, a następnie skopiuj i wklej go do swojego terminala

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

Najlepszym znanym mi sposobem jest użycie skryptu logowania PAM, który zaadaptowałem z poprzedniej pracy, ponieważ nie mogłem znaleźć satysfakcjonującej odpowiedzi na to pytanie.

Twoje hasło jest przechowywane w postaci zaszyfrowanej za pomocą hasła systemowego i funkcji intensywnego wyprowadzania. Podczas logowania hasło systemowe jest używane do odszyfrowania hasła i dodania go do agenta.

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

Zaletą każdego innego prezentowanego rozwiązania jest to, że łączy ono zabezpieczenia równoważne z ręcznym uruchamianiem ssh-add przy rozruchu bez żadnego wysiłku. żadnych dodatkowych narzędzi i ma jedną dodatkową zależność, która jest już domyślnie zainstalowana w większości systemów (OpenSSL).

Mój konfiguracja w systemie macOS jest następująca (w .zshrc lub .bash_profile dla osób bash):

Część || [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]] jest niezbędna w systemie macOS, ponieważ wartość domyślna to /private/tmp/com.apple.launchd.SOMETHINGHERE/Listeners. W przeciwnym razie wyczerpująca odpowiedź @Thomas Nyman nie powiedzie się, ponieważ $SSH_AUTH_SOCK jest zawsze ustawione na coś.

Następnie w .zlogout (lub .bash_logout dla osób bash):

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

Przetestowano na macOS Mojave 10.14.5

Zostało to bardzo dobrze wyjaśnione przez GitHub na Automatyczne uruchamianie ssh-agent w Git dla Windows , co z kolei działa również w Linuksie.

ssh-agent możesz uruchomić automatycznie po otwarciu powłoki bash lub Git. Skopiuj poniższe wiersze i wklej je do swojego pliku ~/.profile lub ~/.bashrc w powłoce 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  

Jeśli twój klucz prywatny nie jest przechowywany w żadnej z domyślnych lokalizacji (np. ~/.ssh/id_rsa), „będziesz musiał powiedzieć swojemu agentowi uwierzytelniającemu SSH, gdzie go znaleźć. Aby dodać swój klucz do ssh-agent, wpisz ssh-add ~/path/to/my_key.

Wskazówka: Jeśli chcesz, aby ssh-agent zapomniał klucz po pewnym czasie, możesz skonfiguruj go, aby to zrobić, uruchamiając ssh-add -t <seconds>.