Blog IT, Blog Marketing

Zrozumieć opcje OpenSSH dotyczące kluczy

Zrozumieć opcje OpenSSH dotyczące kluczy

Marcin Sarna , 13.07.2021 r.

„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_configsshd_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ć HostkeyAlgorithmssshd_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).

Najnowsze oferty pracy:

Polecane wpisy na blogu IT:

Szukasz pracownika IT?

Dostarczymy Ci najlepszych specjalistów z branży IT. Wyślij zapytanie

Wyrażam zgodę TeamQuest Sp. z o.o. na przetwarzanie moich danych osobowych w celu marketingu produktów i usług własnych TeamQuest, w tym na kontaktowanie się ze mną w formie połączenia telefonicznego lub środkami elektronicznymi.
Administratorem podanych przez Ciebie danych osobowych jest TeamQuest Sp. z o.o., z siedzibą w Warszawie (00-814), ul. Miedziana 3a/21, zwana dalej „Administratorem".
Jeśli masz jakiekolwiek pytania odnośnie przetwarzania przez nas Twoich danych, skontaktuj się z naszym Inspektorem Ochrony Danych (IOD). Do Twojej dyspozycji jest pod adresem e-mail: office@teamquest.pl.
W jakim celu i na jakiej podstawie będziemy wykorzystywać Twoje dane? Dowiedz się więcej