Jak mogę na stałe dodać mój prywatny klucz SSH do pęku kluczy, aby był automatycznie dostępny dla ssh?


419

Wygląda na to, że ssh-add -K ~/.ssh/id_rsazaładuje twój klucz, ale poprosi o hasło przy każdym ponownym uruchomieniu.

Szukam rozwiązania, które nie wymagałoby ode mnie ponownego wpisywania hasła klucza między logowaniami.


1
Czy możesz powiedzieć coś więcej o tym, kiedy pojawi się monit o hasło? Pytam, ponieważ mam ssh-klucz do zdalnego serwera, który zapewniam was nie jest taki sam jak mój Mac hasło logowania lub cokolwiek, a ja nie miałem, aby wprowadzić hasło do ssh-klucz dla lat . Mogę po prostu otworzyć terminal, wpisać „ssh <server>” i już tam jestem. Myślę, że najpierw ustawiłem ten klucz w OSX 10.5. id_dsa, ale nie sądzę, że to powinno mieć znaczenie.
Michael H.

Mój id_rsaklucz ma hasło.
sorin

Mam również problem, który rozwiązałem tak dawno temu, że nie pamiętam dokładnie, co zrobiłem. Ale myślę, że chodzi o to, aby nie uruchamiać ssh-add, ale po prostu biegać sshbezpośrednio. Powinno pojawić się wyskakujące okienko, które będzie jako fraza kluczowa, oraz pole wyboru umożliwiające przechowywanie go w pęku kluczy.
Harald Hanche-Olsen

1
@Sorin - moje też! Musiałem do niego wejść raz, dawno temu, a Mac zachował go dla mnie do tej pory. Mam nadzieję, że rada Haralda pomoże.
Michael H.

Czy masz na myśli hasło pęku kluczy (tj. Hasło logowania) lub hasło klucza? Jeśli to drugie, czy twoje hasła są zdecydowanie przechowywane w pęku kluczy? Możesz to sprawdzić, otwierając Dostęp do pęku kluczy i szukając go w pęku kluczy do logowania.
Mathew Hall,

Odpowiedzi:


685

W OSX natywny ssh-addklient ma specjalny argument do zapisania hasła klucza prywatnego w pęku kluczy OSX, co oznacza, że ​​normalne logowanie odblokuje go do użycia z ssh. W OSX Sierra i nowszych musisz również skonfigurować SSH, aby zawsze używał pęku kluczy (patrz krok 2 poniżej).

Alternatywnie możesz użyć klucza bez hasła, ale jeśli wolisz zabezpieczenia, które z pewnością są dopuszczalne w tym przepływie pracy.

Krok 1 - Przechowuj klucz w pęku kluczy

Po prostu zrób to raz:

ssh-add -K ~/.ssh/[your-private-key]

Wprowadź hasło klucza, a nie będziesz więcej o nie proszony.

(Jeśli korzystasz z OSX w wersjach wcześniejszych niż Sierra, to koniec, krok 2 nie jest wymagany).

Krok 2 - Skonfiguruj SSH, aby zawsze używał pęku kluczy

Wygląda na to, że OSX Sierra usunął wygodne zachowanie utrwalania kluczy między logowaniami, a aktualizacja ssh domyślnie nie używa już pęku kluczy. Z tego powodu po aktualizacji pojawi się monit o wprowadzenie hasła klucza i ponownie po każdym ponownym uruchomieniu.

Rozwiązanie jest dość proste i zostało przedstawione w komentarzu do wątku github . Oto jak to skonfigurować:

  1. Upewnij się, że wykonałeś krok 1 powyżej, aby zapisać klucz w pęku kluczy.

  2. Jeśli jeszcze tego nie zrobiłeś, utwórz ~/.ssh/configplik. Innymi słowy, w .sshkatalogu w katalogu domowym utwórz plik o nazwie config.

  3. W tym .ssh/configpliku dodaj następujące wiersze:

    Host *
      UseKeychain yes
      AddKeysToAgent yes
      IdentityFile ~/.ssh/id_rsa
    

    Zmień ~/.ssh/id_rsarzeczywistą nazwę pliku swojego klucza prywatnego. Jeśli masz inne klucze prywatne w swoim ~.sshkatalogu, dodaj również IdentityFilewiersz dla każdego z nich. Na przykład mam jedną dodatkową linię, która odczytuje IdentityFile ~/.ssh/id_ed25519drugi klucz prywatny.

    Jest UseKeychain yesto kluczowa część, która mówi SSH, aby szukał w pęku kluczy OSX klucza do hasła.

  4. Otóż ​​to! Następnym razem, gdy załadujesz dowolne połączenie ssh, wypróbuje określone przez ciebie klucze prywatne i wyszuka ich hasło w pęku kluczy OSX. Nie wymaga wpisywania hasła.


2
To prawie dla mnie zadziałało. Mój brelok „login” miał już wyłączone automatyczne blokowanie, więc odpowiedź Mateusza Sanabrii nie miała zastosowania. Używanie ssh-add -K ...dodało klucze do agenta ssh bez pytania o hasło, ale tylko dla bieżącej sesji. Po ponownym uruchomieniu musiałem ponownie wykonać polecenie.
Poulsbo,

4
@Poulsbo i @Abram - zobacz moją aktualizację, Sierra zmieniła zachowanie automatyczne, a teraz musisz uruchomić ssh-add -Aręcznie, aby załadować zapisany pęku kluczy. Niektóre możliwe rozwiązania wymienione powyżej.
trisweb

3
@trisweb Dzięki za wskazówkę. Rozwiązanie modyfikacji .ssh/configpliku przez joshbuchea wygląda obiecująco! Zobacz github.com/lionheart/openradar-mirror/issues/…
Poulsbo

2
@sorin zobacz zaktualizowaną odpowiedź i daj mi znać, jeśli masz jakieś uwagi. Dzięki!
trisweb

9
Działa świetnie! W moim przypadku musiałem użyć Aflagi oprócz tego, Kaby dodać moje klucze do pęku kluczy i zarejestrować w nim hasło ( ssh-add -AK ~/.ssh/[your-private-key]). Dzięki!
youssman,

21

Miałem podobny problem, ponieważ KAŻDY raz proszono mnie o moje hasło klucza pub.

Zgodnie z sugestią użytkownika „trisweb” powyżej, włączyłem te opcje do ~ / .ssh / config:

Host *
  UseKeychain yes
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa

ALE to wciąż monitowało za każdym razem, gdy chciałem użyć ssh.

W końcu włączyłem „ssh -v” i znalazłem tę linię debugowania:

debug1: key_load_private: podano niepoprawne hasło do odszyfrowania klucza prywatnego

Następnie otworzyłem swój pęku kluczy w „Keychain Access.app”, znalazłem klucz o nazwie „SSH: /Users/username/.ssh/id_rsa” i otworzyłem go.

Kliknąłem „Pokaż hasło”, aby ujawnić hasło, i rzeczywiście znalazłem, że hasło w breloku było starym hasłem.

Zaktualizowałem hasło w Keychain Access, a teraz działa bez hasła.

Mógłbym również zaktualizować hasło za pomocą tego wyrażenia:

ssh-keygen -p -f ~ / .ssh / id_rsa


13

Za każdym razem pojawia się monit o podanie hasła, ponieważ brelok „login” jest blokowany po bezczynności i / lub spaniu lub w twoim przypadku ponownym uruchomieniu. Istnieją dwa sposoby rozwiązania tego problemu.

  1. Zmień ustawienia swojego pęku kluczy „login”. Zakładając, że Twój klucz ssh jest przechowywany w pęku kluczy „login”.

    • Otwórz dostęp do pęku kluczy
    • Podświetl brelok „login”
    • Kliknij prawym przyciskiem myszy lub kliknij klawisz opcji „brelok do logowania”
    • Odznacz pola „Zablokuj po X minutach bezczynności” i „Zablokuj podczas snu”.
  2. Wygeneruj kolejny klucz SSH bez użycia hasła.

    • Otwórz terminal.
    • Wpisz polecenie: ssh-keygen -t rsa -b 4096 -C <comment> -f <.ssh/id_rsa>
    • -t to typ, -b to rozmiar klucza, -C to komentarz, -f plik wyjściowy (najpierw należy utworzyć katalogi)
    • Nie ustawiaj hasła.
    • Zaimportuj klucz SSH do pęku kluczy „login” ssh-add -K <path to ssh key>

Nie powinieneś być monitowany o hasło do pęku kluczy.


2
Zauważ, że podczas wywoływania ssh-addz wewnątrz SSH security unlock-keychainnależy wywołać najpierw. Nie musiałem też tworzyć katalogów dla -fparametru. Niestety nadal musiałem dzwonić security unlocl-keychainw sesjach SSH, aby uzyskać dostęp do pęku kluczy logowania, który monituje o hasło za każdym razem ...
Ohad Schneider

2
Chodzi o to, aby mieć klucz na kluczu. Wątpię, czy wygenerowanie nowego klucza SSH jest pomocne w tym pytaniu.
Gray

7

Ponadto w systemach macOS Sierra i HighSierra (nie wiem o poprzednich wersjach) uruchomienie ssh-add -Aspowoduje, że agent załaduje wszystkie klucze, których hasła są przechowywane w pęku kluczy ... To bardzo przydatne


7

Dla wszystkich, w których powyższe nie zadziałało, mój problem wydaje się być spowodowany tym, że kopiowałem UseKeychain yes& AddKeysToAgent yeswe wszystkich profilach / skrótach kluczy ssh. Zaktualizowałem mój ~/.ssh/configplik, aby zadeklarować je tylko raz, a teraz wszystkie ładują się przy logowaniu bez monitowania o podanie hasła podczas uruchamiania, np .:

Host *
  UseKeychain yes
  AddKeysToAgent yes
  IdentityFile ~/.ssh/foo
  IdentityFile ~/.ssh/bar

Host foo
  HostName foo.com
  User fooUser
  IdentityFile ~/.ssh/foo

Host bar
  HostName bar.com
  User barUser
  IdentityFile ~/.ssh/bar

-3

Dodaj klucz publiczny w:

.ssh/known_hosts

Klucz publiczny zwykle jest włączony:

/home/user/.ssh/id_rsa.pub

Mam nadzieję, że to pomaga


8
Myślę, że mam na myśliauthorized_keys
Rene Larsen

W każdym razie to nie działa, jeśli masz więcej niż jeden klucz!
sorin
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.