Uruchom SSH.
Zarządzaj serwerem zdalnie.

Poznaj SSH i przygotuj stanowisko.

SSH (Secure Shell) tworzy szyfrowane połączenie ze zdalnym komputerem. Klient ssh działa na stacji roboczej, a serwer sshd przyjmuje połączenia i uruchamia sesję po uwierzytelnieniu użytkownika. Domyślny port to 22/TCP.

Pracuj na własnej maszynie laboratoryjnej. Potrzebujesz konta z sudo, dostępu do konsoli serwera oraz Internetu do instalacji pakietów. Obie maszyny powinny mieć połączenie w tej samej sieci. W maszynach wirtualnych użyj wspólnej sieci wewnętrznej lub host-only; dostęp do Internetu możesz zapewnić drugim interfejsem NAT.

Adresy są przykładowe. Ustaw je zgodnie ze swoją pracownią; instrukcję znajdziesz w lekcji o Netplanie. Konto uczen jest zwykłym kontem przeznaczonym do ćwiczeń.

ip -br address
ip route
cat /etc/os-release

Zainstaluj serwer i sprawdź port.

sudo apt update
sudo apt install openssh-server
systemctl status ssh.socket ssh.service --no-pager
sudo ss -ltnp 'sport = :22'

Wynik ss powinien zawierać LISTEN na porcie 22. W Ubuntu 24.04 port może obsługiwać ssh.socket; usługa uruchamia się po nadejściu połączenia. Sam stan inactive usługi przed pierwszym połączeniem nie rozstrzyga, czy SSH działa.

Jeśli nie ma nasłuchu, sprawdź komunikaty w systemctl status. W instalacji korzystającej z aktywacji gniazdem uruchom:

sudo systemctl enable --now ssh.socket

Jeśli system jest skonfigurowany do klasycznego trybu usługi i nie używa ssh.socket, uruchom sudo systemctl enable --now ssh.service. Zachowaj istniejący tryb pracy.

Przygotuj konto i zaporę.

Jeżeli konto uczen jeszcze nie istnieje, utwórz je i ustaw własne hasło. Do zwykłego logowania SSH nie potrzebuje uprawnień administratora.

id uczen
# Tylko jeśli konto nie istnieje:
sudo adduser uczen

sudo ufw status verbose
sudo ufw allow from 10.0.0.20 to any port 22 proto tcp

Jeśli UFW jest nieaktywny, sama reguła nie włącza filtrowania. Włączenie sudo ufw enable wykonuj przy konsoli dopiero po dodaniu reguł dla wszystkich potrzebnych usług. Sprawdź również zaporę maszyny wirtualnej lub dostawcy serwera.

Wykonaj pierwsze logowanie.

Na Linuxie klienta doinstalujesz poleceniem sudo apt install openssh-client. W Windows 11 otwórz PowerShell i sprawdź ssh -V. Jeżeli polecenia brakuje, dodaj funkcję opcjonalną „Klient OpenSSH”.

ssh uczen@10.0.0.10

Przy pierwszym połączeniu klient pokaże odcisk klucza hosta. Porównaj go z wynikiem uzyskanym bezpośrednio przy konsoli serwera:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Porównuj ten sam typ klucza i cały odcisk SHA256:…. Dopiero po potwierdzeniu wpisz yes i hasło konta uczen. Podczas wpisywania hasła terminal nie pokazuje znaków — to normalne.

whoami
hostname
ip -br address
exit

Oczekiwany wynik whoami to uczen, a nazwa hosta powinna należeć do serwera. exit zamyka sesję i wraca do terminala klienta.

Ustaw podstawowe zasady dostępu.

Konfiguracja serwera znajduje się w /etc/ssh/sshd_config i dołączanych plikach /etc/ssh/sshd_config.d/*.conf. Konfiguracja klienta ~/.ssh/config ma inną rolę: zapisuje parametry połączeń.

Zachowaj kopię konfiguracji w katalogu domowym administratora. Nie umieszczaj kopii z rozszerzeniem .conf w katalogu dołączanym.

sudo tar -czf "$HOME/ssh-config-$(date +%Y%m%d-%H%M%S).tar.gz" /etc/ssh/sshd_config /etc/ssh/sshd_config.d
sudo nano /etc/ssh/sshd_config.d/00-laboratorium.conf

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication yes
KbdInteractiveAuthentication no
PermitEmptyPasswords no
MaxAuthTries 3
X11Forwarding no

Na tym etapie hasło pozostaje dostępne do nauki i instalacji klucza. PermitRootLogin no wyłącza bezpośrednie logowanie roota, a MaxAuthTries ogranicza próby w jednym połączeniu. Nie blokuje kolejnych połączeń.

OpenSSH dla większości opcji przyjmuje pierwszą odczytaną wartość. Sprawdź położenie Include w pliku głównym, wcześniejsze pliki i ewentualne bloki Match. Rozstrzygający jest wynik sshd -T.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=uczen,host=stacja,addr=10.0.0.20 | grep -E '^(permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|maxauthtries|x11forwarding) '

sshd -t przy poprawnej składni kończy się bez komunikatu. Jeśli wystąpi błąd, popraw go przed restartem. Gdy wyniki są zgodne z celem, zastosuj ustawienia:

sudo systemctl restart ssh.service

W drugim terminalu ponów ssh uczen@10.0.0.10. Zmiany zasad uwierzytelniania nie wymagają zmiany portu ani restartowania gniazda.

Przejdź od hasła do klucza.

Para kluczy składa się z klucza prywatnego na kliencie i publicznego na serwerze. Plik .pub można przekazać administratorowi. Klucz prywatny zachowaj u siebie i zabezpiecz frazą hasłową.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_lab -C "uczen-laboratorium"
ssh-copy-id -i ~/.ssh/id_ed25519_lab.pub uczen@10.0.0.10

Nie nadpisuj istniejącego klucza. Jeżeli podana nazwa już istnieje, użyj innej albo świadomie wykorzystaj istniejącą parę.

ssh-keygen -t ed25519 -f "$env:USERPROFILE\.ssh\id_ed25519_lab" -C "uczen-laboratorium"
scp "$env:USERPROFILE\.ssh\id_ed25519_lab.pub" uczen@10.0.0.10:lab-key.pub
ssh uczen@10.0.0.10

Po zalogowaniu z Windowsa dopisz przesłany klucz do konta uczen. Nie zastępuj wcześniejszych wpisów:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat ~/lab-key.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Udowodnij, że działa klucz.

W nowym terminalu klienta wymuś uwierzytelnienie publicznym kluczem. Prośba o frazę klucza prywatnego jest prawidłowa; hasło konta serwera nie powinno być potrzebne.

ssh -i ~/.ssh/id_ed25519_lab -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no uczen@10.0.0.10

ssh -i "$env:USERPROFILE\.ssh\id_ed25519_lab" -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no uczen@10.0.0.10

Dopiero po udanym teście edytuj 00-laboratorium.conf: zmień PasswordAuthentication yes na PasswordAuthentication no, pozostaw KbdInteractiveAuthentication no. Sprawdź sshd -t i sshd -T -C …, zrestartuj usługę i wykonaj jeszcze jeden test w nowej sesji.

Prześlij plik i zapisz wygodny skrót.

printf 'Laboratorium SSH\n' > raport-ssh.txt
scp -i ~/.ssh/id_ed25519_lab raport-ssh.txt uczen@10.0.0.10:~/
sftp -i ~/.ssh/id_ed25519_lab uczen@10.0.0.10

W sesji SFTP polecenie ls pokazuje pliki serwera, lls pliki klienta, get raport-ssh.txt raport-z-serwera.txt pobiera raport, a bye kończy sesję. W PowerShell również dostępne są scp i sftp; jako ścieżkę klucza podaj "$env:USERPROFILE\.ssh\id_ed25519_lab".

Host lab-ssh
    HostName 10.0.0.10
    User uczen
    Port 22
    IdentityFile ~/.ssh/id_ed25519_lab
    IdentitiesOnly yes

ssh lab-ssh
ssh lab-ssh "hostname; whoami; uptime"

Zdalne polecenie wykonuje się na serwerze, a jego wynik wraca do terminala klienta. Plik config w Windows nie powinien mieć rozszerzenia .txt.

Ćwiczenie dodatkowe: port 2222.

Wykonaj przy konsoli serwera po ukończeniu części podstawowej. Zmiana portu ogranicza część automatycznego szumu, ale nie zastępuje kluczy i kontroli dostępu. Najpierw dodaj regułę zapory:

sudo ufw allow from 10.0.0.20 to any port 2222 proto tcp

Dodaj Port 2222 w pliku laboratoryjnym. Przejrzyj inne aktywne dyrektywy Port: mogą wskazywać dodatkowe porty. Sprawdź sudo /usr/sbin/sshd -t i sudo /usr/sbin/sshd -T | grep ^port.

W Ubuntu 24.04 LTS przy aktywnym ssh.socket przeładuj generator systemd i uruchom ponownie gniazdo oraz usługę:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket ssh.service
sudo ss -ltnp 'sport = :2222'

W klasycznym trybie bez aktywnego gniazda wystarczy sudo systemctl restart ssh.service. Starsze wydania Ubuntu mogą wymagać konfiguracji ListenStream w nadpisaniu ssh.socket — ten wariant ćwiczenia dotyczy Ubuntu 24.04.

ssh -p 2222 -i ~/.ssh/id_ed25519_lab uczen@10.0.0.10
scp -P 2222 -i ~/.ssh/id_ed25519_lab raport-ssh.txt uczen@10.0.0.10:~/

ssh używa małego -p, natomiast scp i sftp dużego -P. Zaktualizuj też Port w konfiguracji klienta. Usuń starą regułę UFW dopiero po udanym teście i sprawdzeniu, że inne usługi jej nie potrzebują.

Znajdź przyczynę problemu.

ssh -vvv -i ~/.ssh/id_ed25519_lab -o IdentitiesOnly=yes uczen@10.0.0.10

Test-NetConnection 10.0.0.10 -Port 22

sudo journalctl -u ssh.service -u ssh.socket -n 60 --no-pager
sudo ss -ltnp
sudo ufw status numbered

Uprawnienia poprawiaj na koncie, do którego się logujesz: chmod 700 ~/.ssh i chmod 600 ~/.ssh/authorized_keys. Pliki powinny należeć do tego użytkownika. Nie używaj chmod 777.

Sprawdź działanie po instalacji.

Wykonaj testy na dwóch komputerach. Zapisz wyniki w raporcie. Instalacja pakietu jest pierwszym etapem; działanie usługi potwierdzają nowe połączenie i wykonane zdalnie polecenia.

Po przesłaniu raportu sprawdź na serwerze cat ~/raport-ssh.txt. Po pobraniu użyj na Linuxie cmp raport-ssh.txt raport-z-serwera.txt: brak komunikatu i kod zakończenia 0 oznaczają identyczne pliki. W Windows porównaj wyniki Get-FileHash dla obu plików.

Wykonaj zadanie i zbierz dowody.

Pytania kontrolne.

1. Czym różni się klient SSH od serwera sshd?
2. Czym różni się klucz hosta od klucza użytkownika?
3. Dlaczego klucz prywatny zostaje na stacji roboczej?
4. Dlaczego sprawdzamy nową sesję przed zamknięciem starej?
5. Jaką rolę pełni ssh.socket i dlaczego po zmianie portu sprawdzamy ss?

Dokumentacja do dalszej pracy.

• Ubuntu Server — instalacja OpenSSH i podstawowa konfiguracja
• OpenSSH — znaczenie opcji sshd_config
• Ubuntu — aktywacja SSH przez gniazdo systemd
• Na własnym systemie: man ssh, man sshd_config, man scp i man sftp.

Scenariusz podstawowy: Ubuntu Server 24.04 LTS, port 22, klient Linux lub Windows 11. Materiał przygotowany 12.10.2026. Wyniki poleceń zależą od konfiguracji stanowiska.