Jak mogę ustalić, czy czyjś klucz SSH zawiera puste hasło?

44

Niektóre z moich systemów Linux i FreeBSD mają dziesiątki użytkowników. Personel użyje tych węzłów „bramy SSH” do SSH na innych serwerach wewnętrznych.

Obawiamy się, że niektóre z tych osób używają niezaszyfrowanego prywatnego klucza SSH (klucz bez hasła . Jest to złe , ponieważ jeśli włamywacz kiedykolwiek uzyska dostęp do swojego konta na tym komputerze, może ukraść klucz prywatny i mieć teraz dostęp na dowolnym komputerze, który używa tego samego klucza. Ze względów bezpieczeństwa wymagamy od wszystkich użytkowników szyfrowania ich prywatnych kluczy SSH za pomocą hasła.

Skąd mam wiedzieć, czy klucz prywatny nie jest zaszyfrowany (np. Nie zawiera hasła)? Czy istnieje inna metoda, aby to zrobić w przypadku klucza pancernego ASCII, a nie klucza pancernego ASCII?

Aktualizacja:

Aby to wyjaśnić, załóżmy, że mam dostęp administratora do komputera i mogę odczytać klucze prywatne wszystkich osób.

security ssh users

— Stefan Lasiewski
źródło

2

grumble ssh-agent grumble Na bramie nie powinno być żadnych kluczy prywatnych.

— derobert

Kilka pedantycznych notatek: - Użytkownicy często mają słabe hasło . - Użytkownicy mogą zmieniać hasła. - Użytkownik może przechowywać swoje klucze w wielu miejscach. - Użytkownicy prawdopodobnie używają agenta ssh, aby raz odblokować klucz, powiedzmy na swoim laptopie.

— Ben Hyde,

59

Cóż, prywatne klucze OpenSSH z pustymi hasłami nie są w rzeczywistości szyfrowane.

Zaszyfrowane klucze prywatne są zadeklarowane jako takie w pliku klucza prywatnego. Na przykład:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,7BD2F97F977F71FC

BT8CqbQa7nUrtrmMfK2okQLtspAsZJu0ql5LFMnLdTvTj5Sgow7rlGmee5wVuqCI
/clilpIuXtVDH4picQlMcR+pV5Qjkx7BztMscx4RCmcvuWhGeANYgPnav97Tn/zp
...
-----END RSA PRIVATE KEY-----

Coś w stylu

# grep -L ENCRYPTED /home/*/.ssh/id_[rd]sa

powinien załatwić sprawę.

— kodhead
źródło

3

@ jmanning2k: Właśnie utworzyłem klucz prywatny RSA bez hasła i nie zawiera on ciągu „Szyfrowanie: brak”.

— Stefan Lasiewski

@ jmanning2k: -Lflaga zawiera tylko te nazwy plików, które nie pasują do wzorca. Ta odpowiedź jest poprawna sama w sobie.

— bahamat

Poprawiłem się, komentarz został usunięty dla jasności. Dla przypomnienia, skopiowałem kilka plików klucza prywatnego Putty, które brzmią „Szyfrowanie: brak”.

— jmanning2k

2

lub ciąg OPENSSH: patrz tedunangst.com/flak/post/…

— Jack Wasey

10

Rozejrzałem się za tym i nigdy nie znalazłem satysfakcjonującej odpowiedzi, ale udało mi się zbudować jedną, więc ...

Pamiętaj, że spowoduje to zaktualizowanie pliku, jeśli działa, więc jeśli próbujesz nie zostać zauważonym przez użytkowników, których klucze testujesz, możesz najpierw skopiować klucz. OTOH, skoro właśnie złapałeś swojego użytkownika kluczem bez hasła, być może nie obchodzi Cię, jeśli zauważy. :RE

$ ssh-keygen -p -P '' -N '' -f ~/.ssh/KEYTEST
Key has comment '/home/rlpowell/.ssh/KEYTEST'
Your identification has been saved with the new passphrase.
$ echo $?
0

$ ssh-keygen -p -P '' -N '' -f ~/.ssh/KEYTEST
Bad passphrase.
$ echo $?
1

— rlpowell
źródło

3

Dlaczego nie -N ''zamiast tego, aby hasło zawsze pozostało niezmienione?

— traktuj swoje mody dobrze

facepalm To idealnie, dziękuję bardzo.

— rlpowell

+1, ponieważ to rozwiązanie działa nawet z nowym formatem klucza prywatnego SSH.

— Sebastian Krysmanski

8

Jeśli masz dostęp do klucza prywatnego, przypuszczam, że możesz go użyć bez hasła do uwierzytelnienia na kluczu publicznym. Jeśli to działa, wiesz, że nie ma hasła. Gdyby tak było, wyświetlałby komunikat o błędzie.

Jeśli nie masz dostępu do klucza prywatnego, wątpię, czy możesz to wykryć. Hasło ma na celu „odblokowanie” klucza prywatnego, nie ma żadnej funkcji w odniesieniu do klucza publicznego.

W rzeczywistości, gdyby tak było, spowodowałoby to, że system byłby mniej bezpieczny. Można użyć klucza publicznego, który jest dostępny, aby spróbować wykonać brutalną siłę lub inne ataki próbujące złamać hasło.

— txwikinger
źródło