Zaloguj się na maszynę wirtualną i przeanalizuj komunikaty pojawiające się przy
logowaniu się na serwer polon w trybie podwyższonej gadatliwości, tzn. po zastosowaniu
komendy ssh -vv -X user@polon.
Porównaj te komunikaty z poniższymi, które zostały uzupełnione o komentarze ułatwiające zrozumienie konwersacji pomiędzy klientem i serwerem.
# Wersja oprogramowania używanego przez klienta; por. ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
# Klient pobiera konfigurację z plików:
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
# Użycie opcji '-F ~/.ssh/config' powoduje pominięcie ustawień z pliku /etc/ssh_config.
# Klient nawiązuje połączenie TCP
debug2: resolving "polon" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to polon [158.75.5.226] port 22.
debug1: Connection established.
# Klient szuka pliku, gdzie znajduje się prywatny klucz SSH-2 próbuje załadować informację
# o certyfikacie z pliku *-cert.pub w celu identyfikacji nazw
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
# Klient włącza obsługę SSH-2
debug1: Enabling compatibility mode for protocol 2.0
# Klient zgłasza serwerowi używaną przez siebie wersje protokołu i programu
debug1: Local version string SSH-2.0-OpenSSH_7.4
# Serwer zgłasza używaną przez siebie wersje protokołu i programu
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to polon:22 as 'jkob'
# Uzgadnianie parametrów sesji
# Klient wysyła wiadomość inicjującą wymianę klucza (Key EXchange INITialization)
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
# Klient oferuje następujące algorytmy wymiany kluczy
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,\
ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,\
diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,\
diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,\
diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
# Klient oferuje następujące klucze dla hostów
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,\
ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,\
ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,\
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,\
rsa-sha2-256,ssh-rsa,ssh-dss
# Klient ogłasza wspierane szybkie algorytmy szyfrowania danych (bulk ciphers)
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,\
aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,\
aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
# Klient określa używane funkcje haszujące. Każda wiadomość słana przsz SSH wraz z
# numerem sekwencyjnym i identyfikatorem sesji jest haszowana; podpis jest dołączany do
# wiadomości (jako MAC, Message Authentication Code)
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,\
hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,\
umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,\
hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,\
umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
# Klient ogłasza wspierane algorytmy kompresji
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
# Klient otrzymuje od serwera analogiczną listę parametrów komunikacji
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,\
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,\
diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,\
diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,\
diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,\
aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,\
blowfish-cbc,cast128-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,\
aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,\
blowfish-cbc,cast128-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,\
hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,\
umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,\
hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,\
umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
# Klient i serwer decydują się na określony zestaw algorytmów
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
# W tej fazie ma także miejsce proces uwierzytelniania serwera (np. poprzez dane
# zawarte w pliku ~/.ssh/known_hosts), żeby chronić się przed atakami typu spoofing
# i man-in-the-middle
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:h9CW8f24cYNXU3EJobzUmtPfufvmYUqwjHlFj31aLRw
Warning: Permanently added 'polon,158.75.5.226' (ECDSA) to the list of known hosts.
# W oparciu o wymienione wiadomości klient i serwer (osobno) tworzą główny klucz sesji
# (master key) oraz hash wymiany. Klucz sesji nie jest przesyłany i powinien być trudny
# do odgadnięcia. "The default is between ‘1G’ and ‘4G’, depending on the cipher."
# Klucz sesji będzie regenerowany po przesłaniu 1GB MB danych (blok=8B?)
debug1: rekey after 134217728 blocks
# Hash klucza głównego jest używany jako identyfikator sesji (session identifier). Główny
# klucz sesji stanowi podstawę uzyskania dodatkowych kluczy potrzebnych do szyfrowania
# i sprawdzania integralności danych
# Klient pyta serwer o dostępne metody uwierzytelniania
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
# Klient dokonuje wyboru metody uwierzytelniania (kolejność zależy od klienta).
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:0)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:0)
debug2: we did not send a packet, disable method
# Kolejna próba uwierzytelnienia oparta jest o klucz publiczny użytkownika
# i kończy się porażką
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug2: we did not send a packet, disable method
# Kolejna próba uwierzytelnienia oparta jest o klucz publiczny użytkownika
# i kończy się sukcesem
debug1: Next authentication method: password
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to polon ([158.75.5.226]:22).
# Klient żąda utworzenia pseudo-terminala (pty) dla danego kanału, który jest
# potrzebny do pracy interaktywnej.
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: exec
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
# Porównaj poniższy komunikat z komunikatem uzyskanym przy łączeniu się pomiędzy
# serwerami polon i tor.
debug1: X11 forwarding requested but DISPLAY not set
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env XMODIFIERS = @im=none
debug2: channel 0: request env confirm 0
debug1: Sending env LANG = pl_PL.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LANGUAGE = en_GB
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Thu May 23 09:14:59 2019 from coreos7.fizyka.umk.pl
jkob@polon7:~
Po stronie serwera także można śledzić połączenie. W tym celu trzeba uruchomić demona sshd z opcją -d (lub -ddd) lub dodać opcję LOGLEVEL DEBUG[1-3] w pliku /etc/ssh/sshd_config.
Wykonaj poniższe czynności, aby móc wykonywać często połączenia z maszyny wirtualnej na serwer polon (ssh lub scp) bez konieczności podawania hasła:
przejdź do katalogu ~/.ssh
wygeneruj parę kluczy ed25519 (ssh-keygen -t ed25519)
Jakie pliki zostały utworzone? Co one zawierają? Do czego służy passphrase?
przekopiuj klucz publiczny do podkatalogu ~/.ssh Twojego katalogu na serwerze polon
(ssh-copy-id -i id_ed25519.pub user@polon)
Czy można się logować bez podawania hasła? Gdzie zawartość pliku id_ed25519.pub została umieszczona?
Zaloguj się przy pomocy komendy ssh -vv user@polon, przeanalizuj fragment
komunikaty dotyczące wyboru metody logowania i porównaj z odpowiednimi komunikatami z
zad. 1.
Zaloguj się jako użytkownik labul i wygeneruj dla niego parę kluczy ed25519, a
następnie dodaj klucz publiczny do pliku /root/.ssh/authorized_keys (np. via
ssh-copy-id). Zmodyfikuj ten nowy wpis w pliku authorized_keys w taki
sposób, żeby użytkownik labul mógł obserwować logi serwera buforującego
DNS, np. zawartość pliku /var/named/data/named.run.
Utwórz na maszynie wirtualnej dwie konsole i wykonaj następujące czynności:
na pierwszej konsoli wykonaj komendę time ssh user@polon exit
Zapamiętaj czas jej wykonania. Czemu odpowiada ten czas?
na pierwszej konsoli wykonaj komendę ssh -S /tmp/ssh-polon -M user@polon
na drugiej konsoli wykonaj komendę time ssh -S /tmp/ssh-polon user@polon exit
Jaki jest jej czas wykonania w stosunku do komendy ssh user@polon exit? Z czego
wynika różnica?
Uwaga! Wykonaj komendę ssh -S /tmp/ssh-polon user@polon. Czy logowanie na Twoje
konto wymagało podania hasła?
Czy można wykorzystać kanał master do przesyłania plików przy pomocy komendy
scp? Zob. ControlPath w man ssh_config.
Zapoznaj się z działaniem skryptów masterctl i slavectl i przy ich pomocy
wykonaj testy szybkości połączeń SSH w trybie master i slave pomiędzy
maszynami wirtualnymi.
Umieść w pliku ~/.ssh/config następujące wiersze:
ControlMaster auto
ControlPath ~/.ssh/control:%h:%p:%r
i na obu konsolach wykonaj komendy, odpowiednio, ssh user@polon oraz time ssh
user@polon exit. Przeanalizuj zawartość katalogu ~/.ssh.
(Lokalne przekazywanie połączeń) Masz do dyspozycji maszynę wirtualną
(np. centos7-i) i serwer polon. Zaloguj się na obie maszyny, pobierz skrypt ncatctl
(wget http://jkob.fizyka.umk.pl/labul/scripts/ncatctl) i zapoznaj się z jego
działaniem.
Na serwerze polon uruchom usługę ,,odmierzanie czasu” komendą
ncatctl -p 51000+i start i sprawdź, że jest lokalnie dostępna (ncatctl
-p 51000+i status|ss). Czy ta usługa jest dostępna z maszyny centos7-i? Dlaczego?
Na maszynie centos7-i udostępnij jej użytkownikom usługę ,,odmierzania czasu”
używając do tego swojego konta na serwerze polon (ssh -N -L
51001:localhost:51000+i user@polon).
Jaki jest status usługi na obu maszynach (ncatctl [-p 51000+i] status|ss)?
Co się dzieje, jeśli na maszynie centos7-i wykonać komendę ncatctl client-send?
Na maszynie centos7-i udostępnij użytkownikom sieci 192.168.142.0/24
,,odmierzania czasu” przy pomocy komendy ssh -g -N -L 51001:localhost:51000+i
user@polon. Zaloguj się na maszynę centos7-(i+1) i sprawdź działanie komendy
ncatctl -s 192.168.142.i status|client-send.
Czy można także zastosować komendę ssh -N -L 192.168.142.i:51001:localhost:51000+i?
(Lokalne przekazywanie połączeń) Jesteś administratorem lokalnej sieci analogicznej do tej, w której pracują maszyny wirtualne. Załóż dodatkowo, że tylko administrator, który korzysta z maszyny centos7-1 ma dostęp via SSH do maszyny centos7-10 (zapora ogniowa blokuje innym maszynom możliwość wykonywania połączeń na port 22).
Co powinien zrobić administrator, żeby użytkownicy korzystający z maszyn w lokalnej sieci mogli logować się na maszynę centos7-10 (zakładamy, że mają tam swoje konto, np. labul).
Czy zamiast użytkownika root przekazywanie połączeń może być zrealizowane przez użytkownika labul?
Uwaga Załóżmy, że maszyna centos7-1 pełni rolę bastionu dla centos7-10, tzn. użytkownicy nie mogą logować się na centos7-10 bezpośrednio, lecz tylko poprzez wcześniejsze zalogowanie sie na centos7-1. W takiej sytuacji można zastosować komendy:
# ssh -J labul@centos7-1 labul@centos7-10
# ssh -o ProxyJump=labul@centos7-1 labul@centos7-10
(Zdalne przekazywanie połączeń) Masz do dyspozycji maszynę wirtualną centos7-i
i serwer polon. Na maszynie centos7-i uruchom usługę ,,odmierzanie czasu” i
udostępnij ją użytkownikom serwera polon używając do tego swojego konta na tym
serwerze i komendy ssh -N -R 51000+i:localhost:51001 user@polon.
Co pokazuje komenda ncatctl -p 51000+i status na serwerze polon?
Co się dzieje, jeśli na serwerze polon wykonać komendę ncatctl -p 51000+i client-send?
Czy usługa ,,odmierzania czasu” jest dostępna z serwera tor? Czy tworzenie
tunelu przy pomocy komendy ssh -N -R polon:51000+i:localhost:51001 user@polon zmienia
sytuację? Zapoznaj się z opcją GatewayPort (man sshd_config).
(Przekazywanie portów poza hosta) Załóż, że na serwerze polon została uruchomiona usługa ,,odmierzania czasu” (na domyślnym porcie) i tylko z maszyny centos7-10 jest do niej dostęp. Załóż dalej, że jesteś administratorem lokalnej sieci maszyn wirtualnych i tylko ty masz dostęp do maszyny centos7-10 (zapora ogniowa blokuje innym maszynom możliwość wykonywania połączeń na port 22). Co powinieneś zrobić, żeby użytkownicy maszyn w lokalnej sieci mieli możliwość korzystania z usługi ,,odmierzania czasu”? Czy równocześnie wielu użytkowników może korzystać z tej usługi?
(Przekazywanie portów poza hosta) Załóżmy, że z maszyn wirtualnych można się tylko połączyć z serwerem polon. Czy administrator maszyny wirtualnej może dać możliwość bezpośredniego logowania się użytkownikom na serwer tor? Wypróbuj komendy:
# ssh -N -L 2222:tor.fizyka.umk.pl:22 user@polon # konsola 1.
# ssh -p 2222 user@localhost # konsola 2.
Uwaga Nieco dłuższa komenda ssh ssh://user@localhost:2222 jest równoważna
komendzie ssh -p2222 user@localhost, ale taki zapis jest dostępny w wersji ssh
dostępnej w dystrybucji Fedora 31, ale nie w CentOS 7.
(Przekazywanie portów poza hosta) Załóżmy, że z maszyn wirtualnych można się tylko połączyć z serwerem polon. Czy administrator maszyny wirtualnej może dać możliwość swoim użytkownikom do serwera WWW, który jest dostępny dla użytkowników serwera polon? Wypróbuj komendy:
# ssh [-N] -L 80:www.fizyka.umk.pl:80 user@polon # konsola 1.
# curl http://localhost # konsola 2.
# ssh [-N] -L 80:158.75.1.4:80 user@polon # konsola 1.
# curl http://localhost # konsola 2.
# ssh -D 1080 user@polon # konsola 1.
# curl --socks5 localhost http://www.fizyka.umk.pl # konsola 2.
Jakie wnioski można wyciągnąć z powyższych prób? Czy w tym przypadku przekazywanie portu poza serwer SSH do serwera WWW jest równoważne zastosowaniu protokołu SOCKS?
(teleconsole) Zainstaluj program teleconsole i zapoznaj się z jego działaniem (teleconsole
-h, http://www.teleconsole.com/using/).
Użyj tego programu do współdzielenia z użytkownikiem serwera polon konsoli na maszynie wirtualnej centos7-i.
Użyj tego programu do udostępnienia użytkownikowi, np. serwera polon, usługi ,,odmierzania czasu” uruchomionej na maszynie centos7-i.
(Certyfikaty SSH dla hostów) Podczas próby pierwszego połączenia SSH z jakimś serwerem pojawia się komunikat:
The authenticity of host 'polon.fizyka.umk.pl (158.75.5.226)' can't be established.
ECDSA key fingerprint is SHA256:h9CW8f24cYNXU3EJobzUmtPfufvmYUqwjHlFj31aLRw.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
Jeśli na serwerze polon administrator wykonał komendę ssh-keygen -l -f
/etc/ssh/ssh_host_ecdsa_key.pub i upublicznił jej wynik, mianowicie,
256 SHA256:h9CW8f24cYNXU3EJobzUmtPfufvmYUqwjHlFj31aLRw no comment (ECDSA)
to wówczas użytkownik może z całkowitym zaufaniem kontynuować logowanie, odpowiadając yes. W konsekwencji do pliku ~/.ssh/known_hosts zostanie dopisany klucz publiczny serwera polon
polon.fizyka.umk.pl,158.75.5.226 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBnFpmwVvoXDQ9d0+n9qj68Z68yeeqV6e/MJl9+LRuN+x2u6C5xIcgm7GBouHXHWj9ZBKbjnLRCbLF0E/2pJGYU=
Weryfikowanie tożsamości serwerów można jednak uprościć wykorzystując w tym celu certyfikaty SSH i tworząc na jednym z serwerów centrum uwierzytelniania hostów. Niech to będzie maszyna centos7-1. Na tej maszynie należy (jako root) wygenerować klucze potrzebne do podpisania certyfikatu dla serwera CA:
# cd ~/.ssh
# ssh-keygen -t ed25519 -f ca_host_key
# cd /etc/ssh
# ssh-keygen -s ~/.ssh/ca_host_key -I centos7-1 -h -Z centos7-1.fizyka.umk.pl -V -1w:+1w1d /etc/ssh/ssh_host_ed25519_key.pub
W katalogu /etc/ssh powinien pojawić się plik ssh_host_ed25519_key-cert.pub.
Zawartość certyfikatu można sprawdzić komendą ssh-keygen -L -f /etc/ssh/ssh_host_ed25519_key.pub.
Trzeba także zmodyfikować konfigurację serwera SSH dopisując do pliku /etc/ssh/sshd_config wiersze:
HostKey /etc/ssh/ssh_host_ed25519_key
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
i oczywiście wykonać komendę systemctl restart sshd.
Na pozostałych maszynach wirtualnych należy wykonać analogiczne czynności używając do podpisania certyfikatów klucza ca_host_key wygenerowanego na serwerze CA, tj. centos7-1. Wystarczy teraz umieścić w pliku ~/.ssh/known_hosts klucz publiczny ca_host_key.pub (klucz ca_host_key był używany do podpisywania certyfikatów!)
@cert-authority * ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILEh1QdnpWN9H9qtNOyLaM4JEDWJw/LvW+e5kABKv2az root@centos7-1
żeby uwierzytelnianie hostów dokonywało się automatycznie.
(Certyfikaty SSH dla użytkowników) Zad. 2 pokazuje, w jaki sposób użytkownik może logować się bez podawania hasła na wybrany serwer. Jeśli użytkownik, np. administrator, chce mieć taki ułatwiony dostęp do wielu serwerów, to potrzebne jest inne rozwiązanie. SSH oferuje możliwość używania przez użytkowników certyfikatów wystawionych i podpisanych przez administratora zasobów, do których użytkownicy mogą mieć dostęp.
Przede wszystkim administrator musi wygenerować certyfikat CA, który jest niezbędny w procesie uwierzytelniania użytkowników. W tym celu użytkownik root musi wygenerować klucze niezbędne do podpisywania certyfikatów:
# cd ~/.ssh
# ssh-keygen -t ed25519 -f ca_user_key
# cp ca_user_key.pub /etc/ssh
Trzeba także zmodyfikować konfigurację serwera SSH dopisując do pliku /etc/ssh/sshd_config wiersz:
TrustedUserCAKeys /etc/ssh/ca_user_key.pub
i zrestartować usługę sshd.
Klucz ca_user_key.pub trzeba skopiować na każdy serwer, który ma uwierzytelniać użytkowników przez ich certyfikaty, a także na każdym z tych serwerów trzeba zmodyfikować w podany wyżej sposób konfigurację serwera sshd.
Załóżmy, że użytkownik labul, który posługuje się kluczem id_ed25519_key.pub, jest upoważniony do logowania się bez podawania hasła na maszyny centos7-[12] jako labul, a także dodatkowo, jako użytkownik root. W celu wygenerowania certyfikatu superużytkownik musi wykonać komendy:
ssh-keygen -s ~/.ssh/ca_user_key -I labul-centos7-1 -n labul,root /home/labul/.ssh/id_ed25519.pub
chown labul:labul /home/labul/.ssh/id_ed25519-cert.pub
Zawartość certyfikatu można sprawdzić komendą ssh-keygen -L -f /home/labul/.ssh/id_ed25519-cert.pub.