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.