Jak przechowywać klucze SSH?

67

Ostatnio zacząłem używać kluczy SSH zamiast haseł (oczywiście dzięki GitHub), więc proszę pamiętać, że jestem całkiem nowy w tej całej koncepcji. Obecnie moje klucze po prostu leżą w ~ / .ssh, ale nie jestem pewien, czy to dobra praktyka. Na przykład, jeśli mam wiele komputerów, musiałbym zduplikować moje klucze prywatne, co moim zdaniem jest niepożądane. Lub, jeśli mój HDD pójdzie kaput, wtedy zgubię te klucze, co (jak sądzę) jest również niepożądane.

Więc jakie są najlepsze praktyki bezpiecznego przechowywania, kluczy i niezawodności kluczy SSH?

Wydaje się, że używanie karty inteligentnej jest opcją (zobacz Karty inteligentne do przechowywania kluczy gpg / ssh (Linux) - czego potrzebuję? ), Czy to jest najlepsze?

Aktualizacja: Powodem pytania było to, że wiele usług (takich jak GitHub, AWS EC2) zawiera przewodniki na temat konfigurowania kluczy SSH do korzystania z usługi, ale w niewielkim stopniu lub bez tła (np. Co zrobić, jeśli już wygenerowano klucz przez ssh-keygen[1], jakie są zalecane środki bezpieczeństwa). I nie jest jasne, czy te informacje są w rzeczywistości nieistotne, czy oczekuje się, że będziesz je znać „domyślnie”.

Podsumowując odpowiedzi do tego momentu (ale proszę je przeczytać, a jeśli masz coś do dodania - proszę zrobić): wydaje się, że w tym przypadku dobrze jest zostawić swoje klucze prywatne w ~ / .ssh, o ile trzymaj ich przed innymi ludźmi; ale upewnij się, że masz inny sposób na dostęp do usługi w celu przesłania lub wygenerowania nowego klucza, jeśli go zgubisz (co zwykle ma miejsce).

[1] GitHub służył pomocą w zarządzaniu wieloma kluczami .

security ssh-keys

— Anton Strogonoff
źródło

Ten link wydaje się być zepsuty help.github.com/multiple-ssh-keys

— KJ Price

@KJ Price, dzięki Wayback Machine z Internet Archive , strona jest nadal dostępna online, ale nie pod oryginalnym linkiem. Kopię strony zarchiwizowaną 2 września 2011 r. Można znaleźć pod adresem Wiele kluczy SSH .

— punkt księżycowy

41

Na przykład, jeśli mam wiele komputerów, musiałbym zduplikować klucze prywatne, co moim zdaniem jest niepożądane.

Nie, właściwie nie. Jeśli masz wiele komputerów, po prostu utwórz oddzielny klucz prywatny na każdym z nich. Dla każdego klucza prywatnego po prostu prześlij odpowiedni klucz publiczny do GitHub przy użyciu tego samego procesu.

Ponadto, jeśli mój HDD pójdzie kaput, stracę mój klucz prywatny, co (jak sądzę) jest również niepożądane.

Nie całkiem; jeśli zgubisz swój klucz prywatny, po prostu wygeneruj nowy i prześlij odpowiedni klucz publiczny.

Co do tego, co jest warte, masz rację, że duplikowanie klucza prywatnego jest wysoce niepożądane. Idealnie, klucz prywatny powinien być generowany w jednym pliku ( ~/.ssh/id_rsana przykład) i nigdy nie powinien pozostawiać tego pliku - to znaczy, nigdy nie powinien być kopiowany, przenoszony, a zwłaszcza nie przesyłany przez sieć. (np. wykluczam je z kopii zapasowych) Ze względu na naturę asymetrycznych protokołów uwierzytelniania, musisz tylko martwić się o to, że Twój klucz prywatny nie jest dostępny dla innych. Jeśli pójdziesz trochę za burtę i sam się zorientujesz, to na ogół nie jest to wielka sprawa. (Nie należy tego mylić z kluczami prywatnymi szyfrowania asymetrycznego , np. Kluczami GPG, które prawdopodobnie chcesz zachować).

— David Z
źródło

14

Działa to tylko wtedy, gdy masz inną metodę dostępu do serwerów, do których dostęp zapewnia ten klucz prywatny. Możesz przesłać nowy klucz publiczny tylko wtedy, gdy masz dostęp do kopii zapasowej.

— DRZEWO

2

@TREE: racja, ale z mojego doświadczenia wynika, że wyjątkowo rzadko znajduje się serwer, który nie zapewnia alternatywnej metody dostępu (lub przynajmniej dodania dodatkowego klucza publicznego bez przechodzenia przez SSH).

— David Z

3

Dzięki, to bardzo dużo wyjaśnia. Naprawdę, utrata prywatnego klucza SSH nie wygląda na problem, ponieważ dla wszystkich usług, z których korzystam, zawsze wydaje się, że jest inny sposób na uzyskanie dostępu do usługi w celu przesłania nowej.

— Anton Strogonoff,

3

AWS nie zapewnia żadnej innej formy dostępu oprócz klucza prywatnego. Musisz odłączyć dysk i wygłupić się, aby uzyskać dostęp po utracie klucza prywatnego.

— Asad Saeeduddin

1

Pamiętaj, że możesz wprowadzić hasło do klucza prywatnego, jeśli chcesz mieć kolejną warstwę zabezpieczeń.

— sudo

8

Dodałbym, że ~ / .ssh / jest czytelny dla twojej przeglądarki, jeśli używasz tego samego konta użytkownika do uruchamiania obu.

Spróbuj! Skieruj przeglądarkę na klucz prywatny w katalogu domowym. Jest fajnie

Polecam więc przechowywanie kluczy ssh w katalogu osobistym innego konta użytkownika.

słowo na temat kluczy chroniących hasło

Obecnie łamanie nielosowych haseł jest bardzo szybkie. Sprawdź hash cat
- (Chociaż losowe i długie hasła o długości ponad 12 znaków wciąż wymagają dość dużej siły)
- Tak więc zaszyfrowane klucze AES ssh są niemożliwe do odczytania w dającej się przewidzieć przyszłości, o ile użyjesz dobrych długich haseł. Zobacz rekomendacje github
Tak więc niektóre strony mogą zgadnąć klucz bez JavaScript. A potem brutalnie wciśnij klawisz offline.
Przeglądarki mogą również przeglądać Twój schowek z JS. Wklejanie i kopiowanie bardzo długich haseł również naraża Cię na ryzyko bardziej wyrafinowanych ataków javascript.

look_at_keys.html

 9 <HTML>
10 <HEAD>
11 <TITLE>look at keys</TITLE>
12 </HEAD>
13 <FRAMESET cols="20%, 80%">
14   <FRAMESET rows="100, 200">
15       <FRAME src="/Users/yourname/.ssh/stuff.pem">
16       <FRAME src="blah.html">
17   </FRAMESET>
18   <FRAME src="contents_of_frame3.html">
19 </FRAMESET>
20 </HTML>

— Cześć, to
źródło

17

Żeby było jasne, tylko dlatego, że przeglądarka może odczytać twój klucz prywatny, co nie oznacza, że witryna internetowa działająca w przeglądarce może to zrobić.

— Ajedi32,

6

Ale jeśli wstrzykniesz proces w proces przeglądarki. Następnie możesz przejąć kontrolę nad przeglądarką. Ten argument jest więc całkowicie poprawny.

— BigSack,

Ale potem musisz zhakować proces, który wstrzykuje procesy do rejestru procesów jednostki przetwarzania przeglądarki.

— Skid Kadda

8

Istnieje bardzo ładne narzędzie o nazwie KeePass2 ( http://keepass.info/ ) z rozszerzeniem ( http://lechnology.com/software/keeagent/ )

Możesz tam przechowywać Hasła, Klucze SSH i wiele innych (na oficjalnej stronie KeePass są o wiele bardziej przydatne rozszerzenia)
Jeśli chcesz logować się automatycznie za pomocą kluczy SSH, wystarczy zainstalować PuTTY, Pageant i KeePass w KeeAgent. Jeśli konfigurujesz go poprawnie, nie musisz konfigurować kluczy w PuTTY, Pageant lub FileZilla.

Sam go używam i jestem z tego bardzo zadowolony. Mam ponad 30 VPS i Root Server z pewną ilością różnych kluczy SSH i jedyne, co muszę zrobić, to otworzyć KeePass (to nie jest moje podstawowe hasło bezpieczne), a następnie muszę tylko wpisać hasło w konsoli.

— CentrixDE
źródło

3

Polecam przechowywanie kluczy prywatnych:

offline (nie w chmurze)
w więcej niż jednym miejscu
poza wszystkim, z czym jest związany, np. klucz do zaszyfrowanych danych, przechowuj go w innym miejscu niż dane

Powiedziałbym, że najlepszym miejscem byłoby:

zewnętrzny dysk twardy
klucz flash
komputer niepodłączony do Internetu

Jeszcze lepiej, po prostu wydrukuj i umieść w ognioodpornym sejfie.

— bla
źródło

4

Bezpieczeństwo / najlepsze praktyki idą w parze z praktycznością. Jeśli strategia bezpieczeństwa utrudnia korzystanie z systemu, będzie on omijany przez użytkownika, a nie atakującego.

— zaTricky,

1

Mam plik tar, który zawiera moje ustawienia katalogu użytkownika (.bashrc, .ssh / i inne pliki konfiguracyjne), które przechowuję w bezpiecznym miejscu. Kiedy dostanę nowe konto powłoki gdziekolwiek, rozpakuję do niego plik tar.

Klucze prywatne należy umieszczać tylko na zaufanych serwerach, w przeciwnym razie należy utworzyć nowy klucz prywatny na serwerze tylko dla tego serwera i umożliwić mu dostęp do rzeczy, do których ma on mieć dostęp.

Osobiście czuję się swobodnie po prostu kopiując wszędzie mój plik .ssh / stuff (oznacza to również, że zwykły klucz ssh natychmiast uzyskuje dostęp do ssh, ponieważ jest już w pliku autoryzowanym_kluczy).

— EightBitTony
źródło

Wydaje mi się, że zaszyfrowanie ~ / .ssh kręcącego się na pendrivie pozwoli zaoszczędzić na konieczności generowania i przesyłania nowego klucza w przypadku awarii sprzętu. Ponieważ jednak jest bardzo mało serwerów, do których dostępu używam kluczy SSH (i bardzo mało komputerów, z których się łączę), generowanie nowych kluczy nie spowoduje dużego obciążenia.

— Anton Strogonoff,

2

To konie na kursy i zależy od tego, dlaczego używasz kluczy. Nie widzę problemu z skopiowaniem prywatnego klucza ssh przez już zaszyfrowany link SSH. Ale jeśli nie ufasz maszynie docelowej i nie wiesz, kto ma dostęp do konta root, nie powinieneś umieszczać na serwerze niczego, na co nie możesz stracić.

— EightBitTony

Nie chcesz umieszczać swojego klucza prywatnego na serwerze innej osoby. Każdy, kto ma dostęp do rootowania na tym serwerze, może odczytać twój klucz prywatny, a następnie podszyć się pod Ciebie w systemach, do których masz dostęp za pomocą tego klucza prywatnego. Klucz publiczny należy umieszczać tylko w celu uzyskania dostępu do serwera. I nie sądzę, że hasło bardzo pomaga, jeśli używasz go na zdalnym komputerze do odszyfrowania klucza prywatnego.

— Codeguy007

Możesz przesłać ssh-agent przez ssh. W ten sposób nie musisz przechowywać klucza prywatnego na serwerze ani wysyłać hasła przez sieć. stackoverflow.com/questions/12257968/…

— Codeguy007

1

Możesz przechowywać klucze ssh w osobnym katalogu wewnątrz zaszyfrowanej partycji. Następnie możesz użyć ssh wskazującego na ten katalog za pomocą -i:

ssh -i identity_file me@example.com

Pełny opis ( man ssh):

-i plik_identyfikacji

Wybiera plik, z którego odczytywana jest tożsamość (klucz prywatny) do uwierzytelnienia za pomocą klucza publicznego. Domyślna wartość to ~ / .ssh / identity dla protokołu w wersji 1 i ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa, ~ / .ssh / id_ed25519 i ~ / .ssh / id_rsa dla protokołu w wersji 2. Pliki tożsamości mogą należy również określić dla każdego hosta w pliku konfiguracyjnym.
Możliwe jest posiadanie wielu opcji -i (i wielu tożsamości określonych w plikach konfiguracyjnych). Jeśli dyrektywa CertificateFile nie określiła wyraźnie żadnego certyfikatu, ssh spróbuje również załadować informacje o certyfikacie z nazwy pliku uzyskanej przez dodanie -cert.pub do nazw plików tożsamości.

Moje podejście do bezpieczeństwa polega na tym, że dzielę informacje na prywatne i ogólne. Nie chcę szyfrować całej partycji domowej, dlatego kopiuję tajne pliki (takie jak te ~/.sshwewnątrz) na zaszyfrowaną partycję.

Myślę, że daje to dość skuteczne zabezpieczenia, ponieważ złośliwe oprogramowanie nie znajdzie niczego w ~ / .ssh i prawdopodobnie nie skanuje całego systemu lub profili powłoki, aby znaleźć tę lokalizację.

-F configfile

ustawia ścieżkę do pliku konfiguracyjnego.

PS Chciałbym utworzyć alias alias ssh='ssh -i ... -F ...'i umieścić go w twoim profilu.

PPS Jeszcze tego nie sprawdziłem i nie wiem, jak inne programy (takie jak git) będą działać z tymi ustawieniami ssh.

— Jarosław Nikitenko
źródło