SSH: Czy klient może hostować prywatny klucz RSA?

Czy można bezpiecznie wygenerować parę kluczy publiczny / prywatny na serwerze, dodać klucz publiczny do listy kluczy autoryzowanych, a następnie skopiować klucz prywatny do każdego klienta, jak opisano tutaj ( http://www.rebol.com/docs/ ssh-auto-login.html ) Zakładając, że zachowujesz stałą kontrolę nad każdym klientem? (tj. ten sam użytkownik, wiele komputerów).

Typowa procedura polega na wygenerowaniu pary kluczy publiczny / prywatny na kliencie, a następnie dodaniu klucza publicznego klienta do listy kluczy autoryzowanych na serwerze, jak opisano tutaj ( http://www.linuxproblem.org/art_9.html ). Dzięki tej metodzie, jeśli masz kilka komputerów klienckich, każdy z nich musi zostać połączony z listą uprawnionych kluczy i utrzymywany z czasem.

ssh ssh-keys

— użytkownik345807
źródło

Odpowiedzi:

Gratulacje, znalazłeś samouczek internetowy ze złymi poradami.

Problem z używaniem jednej pary kluczy dla wielu komputerów występuje, gdy jeden z komputerów jest zagrożony. Wtedy nie masz wyboru, ale aby odwołać parę kluczy wszędzie i aktualizację kluczy każdego komputera, który został przy użyciu tej pary kluczy. Zawsze należy używać unikatowych kluczy na maszynę i na użytkownika, aby ograniczyć szkody wyrządzone przez włamany klucz.

Jeśli chodzi o ten samouczek, generowanie pary kluczy na serwerze i kopiowanie klucza prywatnego do klienta jest niezwykle zła . To jest całkowicie zacofane. Zamiast tego należy wygenerować parę kluczy na kliencie, a klucz publiczny skopiować na serwer. Istnieje nawet skrypt pomocniczy, ssh-copy-idktóry robi to dokładnie, a po drodze upewnia się, że wszystkie uprawnienia są prawidłowe, klient otrzymuje klucz hosta serwera itp.

Rzeczywiście mogą zaistnieć sytuacje, w których chcesz centralnie zarządzać kluczami tożsamości użytkowników, np. W przypadku skryptów automatycznych, ale w tym przypadku naprawdę powinieneś to zrobić z trzeciego hosta lub najlepiej z systemu zarządzania konfiguracją, takiego jak marionetka.

— Michael Hampton
źródło

Ponadto użytkownik komputera klienckiego musi pamiętać, że tego konkretnego klucza nie można bezpiecznie użyć do jakichkolwiek innych celów, ponieważ nie wiadomo, gdzie był klucz prywatny. Jeśli wiesz, że tajny klucz został wygenerowany na kliencie i nigdy go nie opuścił, generalnie można bezpiecznie używać tego samego klucza do logowania się do różnych systemów.

— kasperd

Przyszła mi do głowy analogia do dzielenia się igłami, ale tak naprawdę nie byłam pewna, czy chcę posunąć się tak daleko ...

— Michael Hampton

Nie jestem pewien, jak wprowadzisz asymetryczną część do tej analogii.

— kasperd

Cóż ... zależy od tego, na jakim końcu igły jesteś.

— Mircea Vutcovici

Największym problemem związanym z protokołem opisanym w tym samouczku jest to, że nie określa on, w jaki sposób „pobierać klucz prywatny na komputer kliencki” w bezpieczny sposób (tj. Zapobiega to podsłuchowi). Jeśli nie masz jeszcze bezpiecznego kanału, prawdopodobnie klucz zostanie przesłany przez Internet (HTTP, FTP, e-mail itp.). Możesz użyć HTTPS, ale jeśli nie masz prawdziwego certyfikatu, MITM może sniffować klucz. Po prostu zrób to tak, jak powinieneś; wygeneruj parę kluczy na komputerze klienckim, przenieś klucz publiczny na serwer i nie zapomnij zweryfikować sumy kontrolnej pliku, aby upewnić się, że nie został zmodyfikowany podczas przesyłania.

— Atsby
źródło