„Tyle tego Panie, kto by się w tym połapał”. My spróbujemy.
Pomoże nam OpenSSH Legacy Options
OpenSSH ma wiele funkcji związanych z kluczami, ich typami i algorytmami; pakiet jest dostarczany po prostu z z całą masą opcji do ich kontrolowania i czuwania nad sposobami logowania ich użycia. Może to być niejasne gdy czytasz strony manuala dla ssh, ssh_config czy sshd. Okazuje się, że OpenSSH ma też świetne wyjaśnienie tych opcji w dokumentacji OpenSSH Legacy Options. Pozwólmy mu ;-) wyjaśnić nam o co w tym wszystkich chodzi.
Gdy klient SSH łączy się z serwerem, każda ze stron oferuje drugiej stronie listy parametrów połączenia. Są to, wraz z odpowiednim słowem kluczowym ssh_config:
- KexAlgorithms: metody wymiany kluczy używane do generowania kluczy dla poszczególnych połączeń [szyfrowanie symetryczne]
- HostkeyAlgorithms: algorytmy klucza publicznego akceptowane przez serwer SSH w celu uwierzytelnienia się na kliencie SSH
- Ciphers: szyfry do szyfrowania połączenia
- MACs: kody uwierzytelniające wiadomości używane do wykrywania modyfikacji ruchu
Wymiana kluczy
Po ustanowieniu połączenia SSH klient i serwer używają protokołu transportowego SSH do utworzenia początkowego zestawu symetrycznych kluczy szyfrujących, które będą szyfrować całą rozmowę w przyszłości, a podczas tego procesu klient weryfikuje klucz hosta serwera (tylko jeden klucz ze wszystkich kluczy oferowanych przez serwer). Jeśli serwer obsługuje wiele typów kluczy hosta, klient zasadniczo decyduje, który z nich będzie używany, na podstawie kolejności swoich algorytmów HostkeyAlgorithms.
Metody wymiany kluczy KexAlgorithms nie mają nic wspólnego z algorytmami klucza publicznego używanymi do weryfikacji klucza hosta, chociaż używają powiązanych technik kryptograficznych. Sposób ich działania jest omówiony w różnych specyfikacjach RFC i innej dokumentacji. Może to być początkowo nieco mylące ponieważ niektóre nazwy algorytmów KEX wyglądają trochę podobnie do nazw typów kluczy (np. „Curve25519-sha256” i „ecdh-sha2-nistp384”).
Gdy użycie protokołu transportowego SSH skończy się powodzeniem klient SSH zażąda uwierzytelnienia użytkownika a wtedy pojawiają się dodatkowe opcje:
- PubkeyAcceptedKeyTypes (ssh / sshd): algorytmy klucza publicznego, które będą podejmowane przez klienta i akceptowane przez serwer w celu uwierzytelnienia za pomocą klucza publicznego (np. przez
.ssh/authorized_keys) - HostbasedKeyTypes (ssh) i HostbasedAcceptedKeyTypes (sshd): typy kluczy, które będą podejmowane przez klienta i akceptowane przez serwer do uwierzytelniania na hoście (np. za pośrednictwem
.rhostslub.shosts)
Przełącznik -Q
Polecenie ssh obsługuje format ssh -Q <cośtam> do wykonywania zapytań o różne rzeczy związane z kryptografią (możesz też użyć ssh_config i sshd_config. Ale uwaga: to nie odczytuje Twoich rzeczywistych plików konfiguracyjnych SSH a zamiast tego raportuje, co Twój OpenSSH mógłby obsługiwać, gdybyś włączył wszystkie opcje. W związku z tym niekoniecznie wymienia on algorytmy klucza publicznego w preferowanej kolejności.
Czyli ssh -Q HostkeyAlgorithms” czy ssh -Q HostbasedKeyTypes zawsze będzie zawierać tę samą listę, nawet jeśli masz je inaczej skonfigurowane. To są po prostu aliasami dla ssh -Q key-sig.
Możesz wreszcie ustawić HostkeyAlgorithms w sshd_config na serwerze, jak również w kliencie używając tej opcji do wyłączenia oferowania ssh-rsa klientom przez jakiś czas, bo masz akurat taką potrzebę. Zasadniczo administrator kontroluje jakie algorytmy kluczy hosta oferuje klientom poprzez to jakie klucze generuje dla sshd, ponieważ większość kluczy ma tylko jeden algorytm podpisu klucza (w tym klucze ECDSA).
