„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
.rhosts
lub.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).