Uwierzytelnianie klucza SSH na wielu komputerach


21

Czytałem o uwierzytelnianiu klucza SSH i konfigurowaniu go z moimi 3 komputerami w domu.

Mam jeden główny komputer, nazywam go „A”, a dwa inne nazywają je „B” i „C”.

Teraz na podstawie przeczytanej dokumentacji uruchomiłbym ssh-keygen na B i C i umieściłem klucze publiczne na komputerze A, zakładając, że zawsze będę SSH na komputerze A, jeśli jestem na B lub C.

Ale myślę, że przykłady dokumentacji, które przeczytałem, zakładają, że będzie używany tylko 1 komputer domowy, powiedzmy inny komputer zewnętrzny. Czy w mojej sytuacji sensowne jest po prostu uruchomienie ssh-keygen na jednym komputerze i skopiowanie plików na inne? W ten sposób muszę wykonać kopię zapasową tylko jednego zestawu kluczy? A kiedy loguję się na zewnętrznym komputerze, muszę go skonfigurować tylko z 1 zestawem kluczy, a nie ze wszystkimi trzema komputerami.

Czy to ma sens? Jakieś wady lub uwagi ostrzegawcze do rozważenia?

Dzięki.

Odpowiedzi:


29

Teoretycznie możesz robić na dwa sposoby, ale każdy z nich ma swoje zalety i wady:

Możesz rzeczywiście utworzyć tylko 1 klucz, powiedzieć, że jest „twój” (jako osoba), zabezpieczyć go gdzieś i skopiować na dowolny komputer, którego używasz. Zaletą jest to, że możesz połączyć się z A z dowolnego miejsca, o ile posiadasz swój prywatny klucz SSH. Wadą jest to, że dopóki kopiujesz swój klucz prywatny z jednego miejsca do drugiego, w jakikolwiek sposób, zwiększasz ryzyko odczytania go przez osobę podsłuchującą połączenie. Co gorsza, jeśli komputer C zostanie skradziony, musisz ponownie wygenerować nowy klucz na wszystkich komputerach, które używają tego klucza, i rozpowszechnić nowy.

Z drugiej strony, użycie 1 klucza na użytkownika @ komputer ma tę zaletę, że zapewnia większą „dokładną kontrolę” nad „tym, co” można połączyć „gdzie”. To najczęstszy sposób.

Na przykład, jeśli chcesz przekazać komputer C swojemu bratu / siostrze / żonie / mężowi / przyjacielowi / psu lub złodziejowi (bez Twojej zgody), musisz po prostu usunąć klucz z „kluczy autoryzowanych” A plik.

Nawet jeśli oznacza to „więcej kluczy w uprawnionych kluczach”, sugeruję drugie podejście.


Nie można odszyfrować strumienia ssh za pomocą klucza prywatnego klienta, a w zależności od ustawień serwera nie można go również odszyfrować za pomocą klucza prywatnego serwera. zurlinux.com/?p=1772
Dan Merillat

Zgadza się i nie o to mi chodziło. Miałem na myśli, że jeśli twój klucz prywatny zostanie skradziony, można go użyć do połączenia z komputerem A z dowolnego miejsca. Można to złagodzić, dodając FROM = "<IP>" na początku wiersza autoryzowanych kluczy. (patrz strona
podręcznika

po skopiowaniu musiałem wstawić hasło, aby użyć go na innym komputerze, myślę, że to jest co najmniej pewne bezpieczeństwo :)
OZZIE

3

Używanie tych samych kluczy na wszystkich trzech komputerach jest zdecydowanie wykonalne - robię to cały czas, głównie dla wygody.

Kwaio prawidłowo wskazuje, że zwiększa to ryzyko naruszenia bezpieczeństwa twoich kluczy. Jednym z możliwych rozwiązań byłoby oddzielenie komponentów klucza prywatnego i publicznego. Więc:

  • Wszystkie komputery mają twój klucz publiczny w pliku autoryzowanych_kluczy.
  • Przechowujesz 2 kopie swojego klucza prywatnego; jeden znajduje się w pamięci USB na szyi (do użycia podczas korzystania z ssh w celu uzyskania dostępu do innego komputera), a drugi znajduje się także w pamięci USB w bezpiecznym miejscu (na wypadek utraty pierwszej kopii).

Jeśli jeden z komputerów zostanie skradziony lub klucz publiczny zostanie w inny sposób naruszony - cóż, to tylko klucz publiczny, więc co z tego.

Jeśli twój klucz prywatny zostanie skradziony lub utracony, natychmiast przystąpisz do generowania nowej pary kluczy i aktualizowania kluczy publicznych na wszystkich komputerach.

HTH.


2
Ok, ale co to jest HTH?
mikeserv

3
HTH = Hope That Help.
ALAN WARD,

1
Mądrze byłoby wskazać, że jeśli umieścisz swój klucz prywatny w napędzie flash, rozsądnie byłoby uczynić go kluczem prywatnym chronionym hasłem. Niespójność konieczności wprowadzania hasła za każdym razem można złagodzić za pomocą agenta (
pagent w systemie
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.