Zasadniczo, co sprawia, że jest lepsze od naprawdę długiego hasła?
Nie są przenoszone na serwer (ponieważ nawet bardzo długie hasło musi zostać przesłane). Nie jest niebezpieczny w przypadku ssh (kanał jest zaszyfrowany, chyba że używasz uszkodzonych szyfrów), ale teoretycznie może zostać przechwycony przez Man In the middle lub złośliwego (super) użytkownika na zdalny serwer.
A jak wpływa na to klucz publiczny?
To jest sedno kryptografii asymetrycznej. Klucz prywatny tworzy podpis, a publiczny może zweryfikować, czy podpis został złożony przy użyciu odpowiedniego klucza publicznego. Wysyłasz klucz publiczny i podpis danych oferowanych przez serwer i to wystarczy, aby serwer umożliwił Ci dostęp (jeśli klucz publiczny jest zgodny z kluczem w authorized_keys).
Komentarze
Nie jestem pewien, z czym porównujesz SSH z „bardzo długim hasłem”. SSH zapewnia bezpieczny sposób przesyłania loginu i hasła użytkownika do zdalnego serwera. Możesz też użyć klucza publicznego klienta. Klucze asymetryczne są na ogół trudniejsze do złamania, ponieważ „nie są podatne na tworzenie przez użytkowników złych haseł. Z tego powodu preferowane jest uwierzytelnianie oparte na kluczu publicznym. Możesz umieścić na białej liście określone klucze publiczne dla swojego użytkownika (i adresu IP), aby nie tylko każdy mógł zalogować się przy użyciu Twojej nazwy użytkownika iz dowolnego komputera. Ta biała lista znajduje się w /home/<user>/.ssh/authorized_keys.
Podstawy SSH:
-
Serwer przedstawia swój klucz publiczny RSA Klient. Klient ręcznie sprawdza, czy ufa temu kluczowi przed kontynuowaniem.
-
SSH używa Diffie Hellman do ustalenia wspólnej wartości tajnej.
-
Wspólne hasło wraz z wieloma danymi dotyczącymi wymiany kluczy jest mieszane i podpisywane przy użyciu klucza prywatnego serwera.
-
Klient może zweryfikować ten podpis, używając wcześniejszego klucza serwera zaufany klucz publiczny.
-
Obie strony mają teraz wszystkie informacje potrzebne do wygenerowania kluczy sesji.
Z sekcji 7.2 RFC4253
7.2. Output from Key Exchange The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re-exchanged. Each key exchange method specifies a hash function that is used in the key exchange. The same hash algorithm MUST be used in key derivation. Here, we"ll call it HASH. Encryption keys MUST be computed as HASH, of a known value and K, as follows: o Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data. "A" means the single character A, ASCII 65). o Initial IV server to client: HASH(K || H || "B" || session_id) o Encryption key client to server: HASH(K || H || "C" || session_id) o Encryption key server to client: HASH(K || H || "D" || session_id) o Integrity key client to server: HASH(K || H || "E" || session_id) o Integrity key server to client: HASH(K || H || "F" || session_id) Key data MUST be taken from the beginning of the hash output. As many bytes as needed are taken from the beginning of the hash value. If the key length needed is longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. This process is repeated until enough key material is available; the key is taken from the beginning of this value. In other words: K1 = HASH(K || H || X || session_id) (X is e.g., "A") K2 = HASH(K || H || K1) K3 = HASH(K || H || K1 || K2) ... key = K1 || K2 || K3 || ... This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH.
Po ustanowieniu szyfrowanego kanału protokół SSH rozpoczyna uwierzytelnianie klienta w oparciu na podstawie parametrów, które mu podałeś. Wszystko to odbywa się bezpiecznie przez zaszyfrowany kanał.
Pozwólcie, że przedstawię ogólny obraz. Oczywiście rozumiesz potrzebę bezpiecznej komunikacji, czy to SSH, czy HTTPS. Bezpieczna komunikacja oznacza, że kanał jest szyfrowany.
Ogólnie rzecz biorąc, wszystkie algorytmy szyfrowania należą do jednej z dwóch kategorii:
- Szyfrowanie symetryczne. Jeden klucz. Ten sam klucz jest używany do szyfrowania i odszyfrowywania. Szybki. Na przykład. AES.
- Asymetryczne szyfrowanie. Dwa klucze. Jednego z nich można używać do szyfrowania, ale tylko drugi może odszyfrować. Znacznie wolniej niż algorytmy symetryczne. Na przykład. RSA.
Szyfrowanie symetryczne jest szybkie i dlatego nadaje się do komunikacji obejmującej dużo danych między dwiema stronami. Używa tego samego klucza do szyfrowania i deszyfrowania – ten klucz jest analogiczny do twojej koncepcji bardzo długiego hasła. Problem: w jaki sposób udostępniasz swój klucz / hasło w pierwszej kolejności? Okazuje się, że nie możesz użyć bezpiecznego kanału, który jest zbudowany wyłącznie na algorytmie szyfrowania symetrycznego, bez wymyślenia sposobu, aby najpierw udostępnić swój klucz / hasło.
W tym miejscu pojawiają się algorytmy asymetryczne, ale są one znacznie wolniejsze niż algorytmy symetryczne. Przesyłanie dużych ilości danych jest niepraktyczne, ale w porządku, jeśli przesyłasz lub wymieniasz coś małego, na przykład symetryczny klucz szyfrowania / hasło. Gdy to zrobisz, możesz teraz używać szyfrowania symetrycznego do komunikacji.
Jeden z dwóch kluczy do szyfrowania asymetrycznego jest oznaczony jako klucz publiczny, a drugi jako klucz prywatny. Klucz publiczny może być dystrybuowany do wszystkich, ale klucz prywatny musi być utrzymywany w tajemnicy.
You (has pub) Server (has prv + pub) asym-encrypt(pub, sym-key/pwd) ----> asym-decrypt(prv, encrypted-data) => sym-key/pwd
pub = klucz publiczny, prv = klucz prywatny
W każdym przypadku to wyjaśnienie jest uproszczenie tego, co faktycznie robi SSH. Dwie inne rzeczy warte podkreślenia:
-
Diffie Hellman to typowy asymetryczny algorytm wymiany kluczy. Dzięki Diffie Hellman nie trzeba w rzeczywistości tworzyć klucza symetrycznego . Obie strony wspólnie tworzą klucz symetryczny podczas wymiany kluczy, co jest dobrym zabezpieczeniem. Zobacz " Diffie-Hellman Key Exchange " w prostym języku angielskim .
-
W swoim wyjaśnieniu założyłem, że znalazłeś klucz publiczny serwera i ufasz, że jest prawidłowy. Ale naprawdę powinieneś uważać na to, które klucze publiczne zaufania. Aby zaufać kluczowi publicznemu, powinien być podpisany cyfrowo. Podpisany klucz publiczny jest również nazywany certyfikatem.
Mamy nadzieję, że rozwiąże to pytania o długie hasło i klucze publiczne i ma wystarczająco dużo informacji, abyś mógł kopać głębiej w bardziej znaczący sposób.