Klucze SSH – logowanie do serwera bez hasła
Przyszedł czas na omówienie bardzo istotnej kwestii bezpieczeństwa jaką jest korzystanie z kluczy SSH. Jest to współczesny substytut hasła do serwera. Każdy doświadczony admin potwierdzi to, że stosowanie kluczy SSH to konieczność, dająca wiele korzyści, a przy tym dość łatwa do wdrożenia.
Co to są klucze SSH?
Klucze SSH to tak naprawdę dwa pliki – klucz publiczny i klucz prywatny. W każdym z nich znajdują się kompletnie niezrozumiałe dla człowieka ciągi znaków. Generowane są one w taki sposób, aby były unikatowe i do siebie pasowały. Można to porównać do zamka (klucz publiczny, zapisany na serwerze), który montujemy w drzwiach i każdy sąsiad ma w teorii do niego dostęp, i klucza (klucz prywatny, zapisany na hoście), który posiadasz tylko Ty, dzięki czemu tylko Ty możesz otworzyć zamek. Oczywiście możesz dorobić wiele takich samych kluczy (prywatnych) do swojego zamka i umieścić je na wszystkich swoich urządzeniach.
Zaletą kluczy SSH jest to, że po pierwsze całkowicie uwalniają nas od konieczności zapamiętywania długiego hasła do serwera, a po drugie znacznie podnoszą poziom zabezpieczenia. Zapytasz – jak bardzo podnoszony jest poziom bezpieczeństwa? Klucz SSH bazuje (przeważnie) na szyfrowaniu RSA-2048. Klucz zapisany przy pomocy tego algorytmu jest ekwiwalentem hasła składającego się z ok. 617 znaków! Czy jesteś w stanie zapamiętać tak długie hasło składające się z dużych i małych liter, a także cyfr i znaków specjalnych? Nie sądzę, dlatego właśnie klucze SSH to must-have dla każdego admina.
Generujemy klucze SSH
Generowanie kluczy można przeprowadzić na hoście, ale zamiast pokazywać jak zrobić to dla Windowsa, Linuxa i macOS, po prostu pokażę jak to przeprowadzić na serwerze, wtedy dla każdego będzie to wyglądało tak samo. Zatem logujemy się na serwer i wykonujemy polecenie:ssh-keygen -t rsa -b 4096 -C odroid -f ~/.ssh/odroid
Wcześniej pisałem, że do generowania kluczy wykorzystuje się zazwyczaj algorytm RSA-2048, natomiast w powyższym poleceniu skorzystałem z jeszcze bardziej skomplikowanego RSA-4096. I jeden i drugi jest nie do złamania przyjmując obecny stan mocy obliczeniowej komputerów (fajnie obrazuje to ta strona).
Po zatwierdzeniu polecenia zostaniemy poproszeni dwa razy o podanie „passphrase”, nie ma konieczności tego robić (można dwa razy zostawić puste pole i potwierdzić ENTERem), ale jest to metoda zabezpieczenia klucza prywatnego, który niezabezpieczony w ten sposób może zostać po prostu skopiowany przez osobę, która uzyska dostęp do naszego hosta. „Passphrase” należy zapamiętać, bo bez niego nasz klucz prywatny jest bezwartościowy i nie umożliwi nam poprawnego uwierzytelnienia. Ja wyszedłem z założenia, że „passphrase” zostawię puste, bo w swojej ocenie ryzyka bardziej boję się utraty „passphrase” niż tego, że ktoś uzyska dostęp do mojego klucza prywatnego (gwarantuje mi to poziom zabezpieczeń moich urządzeń).Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): [ENTER]
Enter same passphrase again: [ENTER]
Your identification has been saved in /home/odroid/.ssh/odroid
Your public key has been saved in /home/odroid/.ssh/odroid.pub
The key fingerprint is:
SHA256:bYpao95NfM9cYmeYw9ziMufMYJDSvROAln+m2drFD1E odroid
The key's randomart image is:
[...]
Rezultatem wykonania powyższego polecenia jest utworzenie dwóch plików w folderze „~/.ssh/”. Pierwszym z nich jest plik „odroid” (bez rozszerzenia), który jest kluczem prywatnym. Wyświetlmy sobie jego zawartość:$ cat ~/.ssh/odroid
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAACFwAAAAdzc2gtcn
NhAAAAAwEAAQAAAgEAm3FsU6wcWnRIn6308dmxipoPAe9h+5pdQ0RZW0cltIEgh2q1pCLn
WK10JqfiTmom/1h/COPyS2CADOt/dT6dY7ZW5iaIa4SJw+HFWlEHyntX92BBNUAGmA5IMP
TfPBZZzYDbHFLhTdgMt57JGwERBg5KgSKC249Foy3/xNnh3MK1tM7q0x2k74gb7gRNwER9
pBsaeEzkDNUEm76I9EYbh8CHxa2ZTTYnK1/8FotEWmIo1jjseKKuBjTTjuFdaFMAjtXI2f
Exa5r0fLC+LJzYIkW0OBeMpcgVDc3g5EMeb3fK8czobUf8VJyE4IOzG7xoff+2Y6nozcsk
q+Dwmg6VoxunCY4o+pPhruQy+JeQNdByJPlaOZpV71CjTUNWmKloZ4Ra1W3rkn0qvxRkev
s10Y/y6oEKPjGSFe53/jFoHXYR/iwp7kOb/R1nbyZnlhPn1zYQTJyctXGA4osOa10xzPzv
bV2GQIQuSlvC51VhLV9emGNRIrtWWCfFM+csnQBbHUhsl3AquG3KSNOlmMV8DkkRbNkB4Q
rzf5j9jgZceuS3M8ijF7l6/BXyIeXpMYb/9aYFcLK1fJrMbgqMZigC9QDAJ+1jDH0IB7/u
f8ja3XW1w3CPZi2NeKj/sxbkpqxowuKkEpYLUDpvzKCi3IurNE7X1uVwvJzvw98r6V6PM5
MAAAdARcX0GkXF9BoAAAAHc3NoLXJzYQAAAgEAm3FsU6wcWnRIn6308dmxipoPAe9h+5pd
Q0RZW0cltIEgh2q1pCLnWK10JqfiTmom/1h/COPyS2CADOt/dT6dY7ZW5iaIa4SJw+HFWl
EHyntX92BBNUAGmA5IMPTfPBZZzYDbHFLhTdgMt57JGwERBg5KgSKC249Foy3/xNnh3MK1
tM7q0x2k74gb7gRNwER9pBsaeEzkDNUEm76I9EYbh8CHxa2ZTTYnK1/8FotEWmIo1jjseK
KuBjTTjuFdaFMAjtXI2fExa5r0fLC+LJzYIkW0OBeMpcgVDc3g5EMeb3fK8czobUf8VJyE
4IOzG7xoff+2Y6nozcskq+Dwmg6VoxunCY4o+pPhruQy+JeQNdByJPlaOZpV71CjTUNWmK
loZ4Ra1W3rkn0qvxRkevs10Y/y6oEKPjGSFe53/jFoHXYR/iwp7kOb/R1nbyZnlhPn1zYQ
TJyctXGA4osOa10xzPzvbV2GQIQuSlvC51VhLV9emGNRIrtWWCfFM+csnQBbHUhsl3AquG
3KSNOlmMV8DkkRbNkB4Qrzf5j9jgZceuS3M8ijF7l6/BXyIeXpMYb/9aYFcLK1fJrMbgqM
ZigC9QDAJ+1jDH0IB7/uf8ja3XW1w3CPZi2NeKj/sxbkpqxowuKkEpYLUDpvzKCi3IurNE
7X1uVwvJzvw98r6V6PM5MAAAADAQABAAACAQCEsxOTar7ZyaOmDc+qF/olJNfjAwVW0bUE
k/jkn5xkuEeY01Q1x0ZQweMCjRf5cU3Rdy8b290g1ET8wp6Q7N9YHHWbDRIxF3i0rKzaKY
rJJPs3yAhi+UGn1alzgdiBZ2NKuNJVH7wPxH021GtCjmqGDPU1wMyNu4XrhH1xA8B5wg91
R5/YktoXUs7lJu9pUA8iZbD3Ok0FV2UTwFkSkDc4cPh3nXfeHnjZ4ptGc6XqsxnBp97YLa
j6y2Y/98zSHum/BmrtA6b5AdPuDsSLOWqZ93+e0xvS+zheDIAM3e/BoTazrgZOJMIZSXV2
ZXgmGXXq+r4t3wNLjDzGLsW3/vNmcpmIew0s1JCTxTPmO9/ND/q60ezbIIqrHmlW3fiaZe
rfAqZCoMGLcBvYzL8+G7DH3QwfWCgcAcMAHFYj5J/d+vW3bdR9q/kyPD94mtNJYBBweM+y
6Wyv4wq57OviRSnniYPcubv3mwy6f7eFk+5aHzNLEo2DEZGD+G/uOrcZYVR0rt5pLicXMV
GfTw/+WpPgccQZp+sXCJGsf59cwSle4xUlrmybEzpjb0l0FeUDC0N8Ry+8fm873E9H5lK7
vQdXMVaA53Lgxoo9AWa+MdEvQUqoENiGcJd+aHcFEhsDs9D5YXbojtxAofWgLk8o1UWwJv
6gQZ635A6yLrhcH/sFYQAAAQEAwqS5O8Titp8sMd5MH7GHNJglyWFF22KU5zJ9OhQVSscZ
vwfEyoZxUqoITD5acUpetP2UHq8sTvxpvVhtMB5Tv0JQ6QDZoqz9Uzv1xwfp+g08qngRKJ
tCHkHLUjCdzwDriUxWZxC0SDtJ5AuZSI4s3M/wuZSVeWhkR6zLUhDM70anA0wJStQUL1L5
5B+lfzoOK3Y9/hrg+8vhXafuEBraNtGoa7FnZ1wSIY7ATWKRedjMZy26aTU+VeSQOZM7IE
IBsmuDF5qoo5+VE8w3JXQbRVWByhJjfH3e3QShExjeH6VNn+wwWym/2s5sosp2unKFJB+b
u1FLCRrTP7xJMirTZQAAAQEAzYMpsghRCl75ifBFZ60uj3qZ1G2zNv11ABV0tR6G5SCytu
ZwJXwuRUK0wVm6K1svKybAxv4Xx2r1kP3exBBTgYluYu11pR+77BeOsSVU51wDusZeZ+Fs
sFgidsiclY6kZBWHTvKZNMI/QyyY2R8zB1JXFT3fnvcsB73BC9nHZoVBwEVime78qe4YN+
GBT5xwMO5LDBcqp04iRDfsdDpdcNfDz7+FsO4UO4Hj5WcUM03jcw40dXipGS6cG7ufZEEx
lsGnpPZdSDL+ZeD8ZX//aQ48FEomG8/51FdEqsCVikZloxr33oRW/BRmBb82/wi53p1CUE
6fGARNFObqI2OXzwAAAQEAwaFcroJ49Cwd47ck9S5EOJqEL6tKDlJBpQAtVjvDzc9cmEeM
U77TCKI/eQUaVdpvYC9vYrWdNYAfukLwZRI6By9vUbObFLneqZugt64Jz7Aw7fRZKXDN8d
BqwOnzO+nlNYsdEUz7DLUHB+LE9hlkMx/061kGUD0tXFrzpAsWWpwDA43dtp+RjqHR1XpF
NJiIyExe5RKwvDpTUEnZIq2nmXK3PrQMvEtsuSj5bLonNYoZniV4K6/Bt9nxiMjAGoQVCo
BLLYVDj8ho5MB6nljw0RIB+PnBPqVuk/zo3MZ+xZxmt8PGClyRjHHBxWjSNLvIzraHn4P9
xQW32Ypn+doU/QAAAAZvZHJvaWQBAgM=
-----END OPENSSH PRIVATE KEY-----
Tego pliku należy strzec jak oka w głowie i nie udostępniać nikomu. Ja go tutaj udostępniam w ramach przykładu, a zaraz po napisaniu tego wpisu go zniszczę. Drugi plik to „odroid.pub”, który jest naszym kluczem publicznym. Wyświetlmy go tak samo:$ cat ~/.ssh/odroid.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCbcWxTrBxadEifrfTx2bGKmg8B72H7ml1DRFlbRyW0gSCHarWkIudYrXQmp+JOaib/WH8I4/JLYIAM6391Pp1jtlbmJohrhInD4cVaUQfKe1f3YEE1QAaYDkgw9N88FlnNgNscUuFN2Ay3nskbAREGDkqBIoLbj0WjLf/E2eHcwrW0zurTHaTviBvuBE3ARH2kGxp4TOQM1QSbvoj0RhuHwIfFrZlNNicrX/wWi0RaYijWOOx4oq4GNNOO4V1oUwCO1cjZ8TFrmvR8sL4snNgiRbQ4F4ylyBUNzeDkQx5vd8rxzOhtR/xUnITgg7MbvGh9/7ZjqejNyySr4PCaDpWjG6cJjij6k+Gu5DL4l5A10HIk+Vo5mlXvUKNNQ1aYqWhnhFrVbeuSfSq/FGR6+zXRj/LqgQo+MZIV7nf+MWgddhH+LCnuQ5v9HWdvJmeWE+fXNhBMnJy1cYDiiw5rXTHM/O9tXYZAhC5KW8LnVWEtX16YY1Eiu1ZYJ8Uz5yydAFsdSGyXcCq4bcpI06WYxXwOSRFs2QHhCvN/mP2OBlx65LczyKMXuXr8FfIh5ekxhv/1pgVwsrV8msxuCoxmKAL1AMAn7WMMfQgHv+5/yNrddbXDcI9mLY14qP+zFuSmrGjC4qQSlgtQOm/MoKLci6s0TtfW5XC8nO/D3yvpXo8zkw== odroid
Mamy klucze pora je wrzucić w odpowiednie miejsca
Tworzymy na serwerze plik:touch ~/.ssh/authorized_keys
Musimy nadać mu odpowiednie uprawnienia:chmod 600 ~/.ssh/authorized_keys
Warto też przy okazji sprawdzić uprawnienia folderu „.ssh”:chmod 700 ~/.ssh/
Przechodzimy do edycji utworzonego pliku i wklejamy do niego całą zawartość wygenerowanego klucza publiczego „odroid.pub”:nano ~/.ssh/authorized_keys
Plik zapisujemy i wychodzimy z niego.
Teraz musimy przeprowadzić pewne działania na hoście. Jedną z opcji jest po prostu wrzucenie klucza prywatnego wygenerowany na serwerze do klienta SSH jak: Termius (Windows, Linux, macOS, Android, iOS) czy PuTTy (Windows, Linux). Natomiast jeżeli ktoś chce korzystać z SSH bez klienta to musi utworzyć na hoście plik:touch ~/.ssh/odroid
Przechodzimy do edycji utworzonego pliku i wklejamy do niego całą zawartość wygenerowanego klucza prywatnego „odroid” z serwera:nano ~/.ssh/odroid
Plik zapisujemy i wychodzimy z niego. Plik, w którym zawarty jest klucz prywatny musi mieć odpowiednie uprawnienia, tak aby nie był dostępny dla innych użytkowników komputera. Jeżeli tego nie zrobimy to większość systemów wywali nam błąd, że uprawnienia są nieprawidłowe, klucz prywatny może zostać odczytany przez innych użytkowników, więc zostanie ignorowany. Dlatego musimy zmienić uprawnienia:chmod 600 ~/.ssh/odroid
Pozostaje już tylko dodać klucz do naszego „pęku” kluczy:ssh-add ~/.ssh/odroid
Wyłączenie możliwości logowania przy użyciu hasła
Rozłączmy się z serwerem i połączmy się z nim ponownie, żeby sprawdzić czy wszystko jest OK. Jeżeli cały powyższy proces przebiegł poprawnie to nie powinniśmy zostać poproszeni o hasło podczas łączenia. Pozostaje nam w takim razie jeszcze tylko wyłączyć możliwość logowania się do serwera poprzez hasło, bo nie po to wdrażaliśmy klucze SSH, aby i tak zostawić tylną furtkę, która pozwoli ominąć całe zabezpieczenie.
Przechodzimy do modyfikacji pliku:sudo nano /etc/ssh/sshd_config
Musimy znaleźć następujące parametry i ustawić ich wartość tak jak pokazano poniżej. Mogą być one porozrzucane po całym pliku, więc może przydać się funkcja szukania zaimplementowana w edytorze nano, którą wywołuje się kombinacją przycisków CTRL+W. Parametry mogą być też w innej kolejności. Jeżeli którykolwiek z parametrów jest zakomentowany to należy usunąć sprzed niego znak „#” i go odkomentować. Tak samo jeżeli nie ma w pliku któregoś z paramertrów to należy go dopisać.PermitRootLogin no
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
Plik zapisujemy i wychodzimy z niego. Pozostaje nam teraz już tylko zrestartować proces ssh:sudo service ssh restart
W efekcie wszystkich powyższych działań zablokowaliśmy możliwość logowania się do serwera przy pomocy poświadczeń użytkownika root, wprowadziliśmy konieczność uwierzytelniania przy pomocy klucza RSA oraz całkowicie wyłączyliśmy możliwość uwierzytelniania przy pomocy loginu i hasła.
Jeżeli materiał zawarty w tym wpisie jest dla Ciebie wartościowy i masz ochotę wesprzeć moją pracę to zapraszam na mój profil na >Patronite<. Zachęcam także do odwiedzenia mojej strony >tomaszdunia.pl<. Możesz także zagadać do mnie na Twitterze >@theto3k<.
Poprzedni wpis:
Nowy serwer – dobre praktyki na start
Następny wpis:
Nie tylko serwer fizyczny – sprawdź Mikrusa!
Komentarze: 7 - “Klucze SSH – logowanie do serwera bez hasła”
Dodaj komentarz Anuluj pisanie odpowiedzi
Kategorie: Dla początkujących,Poradniki - @ 2022-06-06 22:00
Tagi: klucz prywatny, klucz publiczny, ODROID, OpenSSH, PuTTy, RaspberryPi, RSA, SSH, Termius, ubuntu
Fajny art, ale teraz poleca się klucze ed25519 są mniejsze, szybsze i tak samo bezpieczne. A do wrzucenia klucza na serwer polecam komendę ssh-copy-id która wszystko robi za nas
Doczytam, dzięki za info! Co do ssh-copy-id to faktycznie może rozszerzę artykuł, ale tutaj chciałem jakby od podstaw pokazać to jak to się robić, a nie pokazywać od razu automatyzacji, żeby robiło się samo 🙂
Nowe Ubuntu domyślnie wyłącza klucze RSA. ed25519 działają out of the box
Przyznam szczerze, że pierwsze słyszę. W 22.04 LTS? Bo w 20.04 na pewno nie, a właśnie na tej wersji bazujemy w tym wpisie.
Tak. Tutaj np. ktoś miał z tym problem.
https://askubuntu.com/questions/1409105/ubuntu-22-04-ssh-the-rsa-key-isnt-working-since-upgrading-from-20-04
Znów skorzystałem z Twojej pomocy. Dziękuję. Mała ciekawostka. Otóż z desktopu loguję się tak po SSH do dwóch komputerów. I jeden działa automatycznie, a do drugiego musiałem dodać komendę dodawania klucza przy starcie sesji środowiska graficznego po boocie gdyż przy każdym restarcie zapominał tego klucza. Pomimo,że widnieje w bazie standardowej keyring. Czyli jedno łączenie działa książkowo, a drugie nie. Oba zrobione dokładnie taką samą metodą. 😉
Czasem tak jest na niektórych urządzeniach. U mnie przeważnie Macbook ma z tym problem, dlatego rozwiązałem sobie to prostym skryptem bashowym (.sh), w którym mam dwa polecenia – jedno to dodanie klucza do listy, a drugie to polecenie do łączenia SSH. Do tego podpiąłem ten skrypt jako alias, żeby nie wpisywać jego całego adresu za każdym razem 🙂