Ćwiczenia do wykonania:# Wygeneruj parę kluczy RSA za pomocą ssh-keygen Wyeksportuj klucz publiczny z klienta do serwera za pomocą ssh-copy-id Zaloguj się za pomocą hasła poprzez ssh do serwera i przełącz na konto root za pomocą komendy sudo - su lub sudo -i Włącz logowanie kluczami i wyłącz logowanie hasłem. Zapisz zmiany i zrestartuj usługę ssh. Nie zamykaj bieżącej sesji. Otwórz nową sesję ssh i zaloguj się do serwera za pomocą klucza prywatnego. Jeśli udało ci się zalogować, zabezpiecz serwer korzystając z poniższych informacji a następnie zrestartuj usługę ssh na drugiej sesji. Pamiętaj, by pierwszą sesję ssh cały czas mieć otwartą, by w razie potrzeby móc cofnąć zmiany. Zrestartuj usługę ssh i sprawdź, czy możesz zalogować się za pomocą trzeciej sesji do serwera. Jeśli tak, udało ci się poprawnie skonfigurować serwer ssh. Dla chętnych napisz skrypt z użyciem sed lub awk, który dokona zmian po stronie serwera w pliku sshd_config, aby nie trzeba było ręcznie nanosić zmian. OpenSSH : KeyBoard-Intereractive Auth# OpenSSH jest już domyślnie zainstalowany, więc nie ma potrzeby instalowania nowych pakietów. Domyślnie możesz logować się za pomocą KeyBoard-Interactive Authentication, ale zmień niektóre ustawienia dla bezpieczeństwa jak poniżej.
Jeśli OpenSSH jednak nie jest jeszcze zainstalowany możesz go zainstalować za pomocą następującego polecenia:
SLES
Debian
RedHat
SLES# Aby zainstalować OpenSSH wpisz:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# odśwież repozytoria
sudo zypper ref
# zainstaluj OpenSSH
sudo zypper -n in openssh
# włącz OpenSSH podczas boot-owania
sudo systemctl enable sshd
# wystartuj openSSH
sudo systemctl start sshd
# włącz regułę w firewalld dla ssh
sudo firewall-cmd --permanent --add-service= ssh
success
# Przeładuj reguły firewalld
sudo firewall-cmd --reload
success
Kopiuj
Debian# Aby zainstalować OpenSSH wpisz:
1
2
3
4
5
6
7
8
9
10
# odśwież repozytoria
sudo apt update
# zainstaluj OpenSSH
sudo apt -y install openssh-server
# włącz OpenSSH podczas boot-owania
sudo systemctl enable sshd
# wystartuj OpenSSH
sudo systemctl start sshd
# włącz regułę w ufw firewall dla ssh
sudo ufw allow ssh
Kopiuj
Red Hat# Aby zainstalować OpenSSH wpisz:
1
2
3
4
5
6
7
8
9
10
11
12
13
sudo yum install openssh-server -y
lub
sudo dnf install openssh-server -y
# włącz OpenSSH podczas boot-owania
sudo systemctl enable sshd
# wystartuj OpenSSH
sudo systemctl start sshd
# włącz regułę w firewalld dla ssh
sudo firewall-cmd --permanent --add-service= ssh
success
# Przeładuj reguły firewalld
sudo firewall-cmd --reload
success
Kopiuj
Następnie na maszynie z Linux, za pomocą której zamierzasz łączyć się do serwera, musisz zainstalować odpowiedniego klienta:
SLES
Debian
RedHat
SLES# Aby zainstalować OpenSSH wpisz:
1
2
3
4
# odśwież repozytoria
sudo zypper ref
# zainstaluj OpenSSH
sudo zypper -n in openssh-clients
Kopiuj
Debian# Aby zainstalować OpenSSH wpisz:
1
2
3
4
# odśwież repozytoria
sudo apt update
# zainstaluj OpenSSH
sudo apt -y install openssh-client
Kopiuj
Red Hat# Aby zainstalować OpenSSH wpisz:
1
2
3
sudo yum install openssh-clients -y
lub
sudo dnf install openssh-clients -y
Kopiuj
Instalacja firewalld# SLES
Debian
RedHat
SLES# Aby zainstalować firewalld wpisz:
1
2
3
4
5
6
7
8
# odśwież repozytoria
sudo zypper ref
# zainstaluj firewalld
sudo zypper -n in firewalld
# włącz firewalld podczas boot-owania
sudo systemctl enable firewalld
# wystartuj firewalld
sudo systemctl start firewalld
Kopiuj
Debian# Aby zainstalować firewalld wpisz:
1
2
3
4
5
6
7
8
# odśwież repozytoria
sudo apt update
# zainstaluj firewalld
sudo apt -y install firewalld
# włącz firewalld podczas boot-owania
sudo systemctl enable firewalld
# wystartuj firewalld
sudo systemctl start firewalld
Kopiuj
Red Hat# Aby zainstalować firewalld wpisz:
1
2
3
4
5
6
7
sudo yum install firewalld -y
lub
sudo dnf install firewalld -y
# włącz firewalld podczas boot-owania
sudo systemctl enable firewalld
# wystartuj firewalld
sudo systemctl start firewalld
Kopiuj
Domyślnie firewalld po instalacji ma zaimplementowaną usługę SSH jako dozwoloną. Jeśli nie, zawsze możesz zezwolić na usługę SSH.
SLES
Debian
RedHat
SLES# 1
2
3
4
linux:~ # sudo firewall-cmd --add-service=ssh --permanent
success
linux:~ # sudo firewall-cmd --reload
success
Kopiuj
Debian# 1
sudo ufw allow ssh
Kopiuj
Red Hat# 1
2
3
4
linux:~ # sudo firewall-cmd --add-service=ssh --permanent
success
linux:~ # sudo firewall-cmd --reload
success
Kopiuj
Konfiguracja klienta SSH# Połącz się z serwerem SSH za pomocą zwykłego użytkownika.
1
2
3
4
5
6
7
8
# ssh [login_user@hostname_or_IP_address]
adrian@client:~> ssh adrian@example.com
The authenticity of host 'example.com (10.0.0.50)' can't be established.
ECDSA key fingerprint is SHA256:h0QhlXgCZ860UjM8sAjY6Wmrr2EqSIY5UADBi0wAFV4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ' example.com,10.0.0.50' (ECDSA) to the list of known hosts.
Password: # login user' s password
adrian@example.com:~> # just logined
Kopiuj
Uwierzytelnianie parą kluczy SSH# Skonfiguruj serwer SSH do logowania za pomocą Key-Pair Authentication. Utwórz klucz prywatny dla klienta i klucz publiczny dla serwera, aby to zrobić.
Utwórz Key-Pair dla każdego użytkownika, więc zaloguj się wspólnym użytkownikiem na SSH Server Host i pracuj jak poniżej.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# utwórz parę kluczy na kliencie
ssh-keygen -t rsa -b 4096 -C "imię i nazwisko"
Generating public/private rsa key pair.
Enter file in which to save the key ( /home/adrian/.ssh/id_rsa) : /home/adrian/.ssh/p-tech
Enter passphrase ( empty for no passphrase) :
Enter same passphrase again:
Your identification has been saved in /home/adrian/.ssh/p-tech
Your public key has been saved in /home/adrian/.ssh/p-tech.pub
The key fingerprint is:
SHA256:IPtApVZ/8o6mCY3lKSvcfEtkD6wzHJ0LzKeHFm3qbxs adrian@G02PLXN05963
The key' s randomart image is:
+---[ RSA 4096] ----+
| o |
| + . |
| = . o . |
| = * o + |
| O % S . |
| . ^ = o |
| . o& E + . |
| oooOo = |
| .o+*o |
+----[ SHA256] -----+
Kopiuj
Aby wygenerować passphrase możesz użyć następującego polecenia w osobnym oknie CLI
1
hexdump -vn16 -e'4/4 "%08X" 1 "\n"' /dev/urandom
Kopiuj
Wylistuj parę kluczy
1
2
3
adrian@linux:~> ll ~/.ssh/p-tech*
-rw------- 1 adrian adrian 3.4K Apr 1 16:44 /home/adrian/.ssh/p-tech
-rw-r--r-- 1 adrian adrian 745 Apr 1 16:44 /home/adrian/.ssh/p-tech.pub
Kopiuj
Skopiuj klucz publiczny z klienta na serwer
1
ssh-copy-id -i ~/.ssh/p-tech.pub student@IP-ADDRRESS
Kopiuj
Podaj hasło
Zaloguj się z kluczem do serwera
1
ssh -i ~/.ssh/p-tech student@IP-ADDRRESS
Kopiuj
Podaj passphrase
Automatyzacja# Dodaj poniższe wpisy do pliku .bashrc lub .zshrc znajdującego się w katalogu /home/user. Pierwszy wpis uruchamia agenta ssh, a drugi ładuje do niego Twój klucz prywatny. Jeśli ustawiłeś passphrase na swoim kluczu, agent zapyta o jego wpisanie. Możesz dodać więcej niż jeden klucz. Należy pamiętać, że za każdym razem, gdy Bash lub Zsh uruchomi proces restartu lub rozruchu systemu operacyjnego, w CLI poprosi o podanie passphrase.
1
2
eval $( ssh-agent -s)
ssh-add ~/.ssh/p-tech
Kopiuj
Zabezpieczanie SSH# Edytuj /etc/ssh/sshd_config
1
sudo vi /etc/ssh/sshd_config
Kopiuj
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
# odkomentuj te linie i zmień na [no ]
PasswordAuthentication no
ChallengeResponseAuthentication no
# Wyłącz puste hasła
# Musisz zapobiec zdalnym logowaniom z kont z pustymi hasłami dla zwiększenia bezpieczeństwa .
PermitEmptyPasswords no
# Ograniczenie dostępu użytkowników do SSH
# Aby zapewnić kolejną warstwę bezpieczeństwa , powinieneś ograniczyć logowanie do SSH
# tylko do niektórych użytkowników , którzy potrzebują zdalnego dostępu .
# W ten sposób zminimalizujesz wpływ posiadania użytkownika ze słabym hasłem .
# Dodaj linię "AllowUsers" , a następnie listę nazw użytkowników i oddziel je spacją :
AllowUsers student adrian
# Wyłączanie logowania roota
# Jedną z najbardziej niebezpiecznych dziur w zabezpieczeniach ,
# jakie możesz mieć w swoim systemie jest umożliwienie bezpośredniego logowania się
# do roota przez SSH . W ten sposób hakerzy próbujący złamać hasło roota mogą
# hipotetycznie uzyskać dostęp do systemu ; a jeśli się nad tym zastanowić ,
# root może wyrządzić dużo więcej szkód na maszynie niż zwykły użytkownik .
# Aby wyłączyć logowanie przez SSH jako root , zmień linię na taką :
PermitRootLogin no
# Ostatecznie możesz pozwolić rootowi na logowanie się przez SSH przy użyciu pary kluczy .
# Zrób to tylko jeśli serwer nie jest w DMZ ( nie ma dostępu z Internetu )
PermitRootLogin prohibit - password
# Dodaj Protocol 2
# SSH posiada dwa protokoły , których może używać . Protokół 1 jest starszy i mniej bezpieczny .
# Protokół 2 jest tym , czego powinieneś używać , aby wzmocnić swoje bezpieczeństwo .
# Jeśli chcesz , aby Twój serwer był zgodny z PCI , musisz wyłączyć protokół 1 .
Protocol 2
# Protocol
# Określa wersje protokołu , które obsługuje sshd ( 8 ) . Możliwe .
# wartości to '1' i '2' . Wiele wersji musi być oddzielonych przecinkami .
# Domyślnie jest to '2' . Protokół 1 cierpi na szereg
# słabości kryptograficznych i nie powinien być używany .
# Jest oferowany tylko w celu wsparcia starszych urządzeń .
# Przykład : Protocol 2 , 1
# Użyj innego portu
# Jedną z głównych korzyści ze zmiany portu i użycia niestandardowego portu
# jest uniknięcie bycia widzianym przez przypadkowe skanowanie . Zdecydowana większość hakerów
# szukających otwartych serwerów SSH będzie szukała portu 22 , ponieważ domyślnie ,
# SSH nasłuchuje połączeń przychodzących na tym porcie .
# Jeśli trudniej jest zeskanować Twój serwer SSH , to zmniejszają się Twoje szanse na atak .
# Uruchom SSH na niestandardowym porcie powyżej portu 1024 .
Port 2025
# Możesz wybrać dowolny nieużywany port , o ile nie jest on używany przez inną usługę .
# Wiele osób może wybrać 222 lub 2222 jako swój port , ponieważ
# jest to dość łatwe do zapamiętania , ale właśnie z tego powodu , hakerzy skanujący port 22
# prawdopodobnie będą również próbować portów 222 i 2222 . Spróbuj wybrać numer portu
# który nie jest jeszcze używany , podążaj za tym linkiem , aby uzyskać listę numerów portów i ich znanych usług .
# Jeśli StrictModes jest ustawiony na tak , to wymagane są poniższe uprawnienia .
# sudo chmod 700 ~ /.ssh
# sudo chmod 600 ~ /.ssh/ authorized_keys
StrictModes yes
# Konfiguracja interwału czasu bezczynności
ClientAliveInterval 360
ClientAliveCountMax 1
# ClientAliveInterval - Ustawia interwał czasowy w sekundach , po którym , jeśli nie otrzymano żadnych danych od klienta ,
# sshd wyśle wiadomość przez kanał szyfrowany , aby zażądać odpowiedzi od klienta . Domyślnie jest to 0 , co oznacza ,
# że te wiadomości nie będą wysyłane do klienta . Opcja dotyczy tylko protokołu w wersji 2 .
# ClientAliveCountMax - Wartość domyślna to 3 . Jeśli ClientAliveInterval ustawiony jest na 15 , a ClientAliveCountMax
# na wartość domyślną , to niereagujący klienci SSH będą rozłączani po około 45 sekundach .
# Opcja dotyczy tylko protokołu w wersji 2 .
# Wartość timeout jest obliczana przez pomnożenie
# ClientAliveInterval i ClientAliveCountMax .
# timeout interval = ClientAliveInterval * ClientAliveCountMax
# Opcje OpenSSH ClientAliveInterval i ClientAliveCountMax
# nie są używane do rozłączania nieaktywnych sesji .
# W rzeczywistości zapobiegają one zamknięciu połączenia ,
# nawet na nieaktywnych sesjach , tak długo jak klient i łącze sieciowe jest żywe .
# Jest to wewnętrzny mechanizm ssh , który wysyła pakiet "null
# wewnątrz ustanowionego tunelu , i czeka na odpowiedź od klienta .
# W tym przypadku wysyła jeden pakiet co 360 sekund , i rozłącza się po 1 brakującej odpowiedzi .
# Chociaż te opcje są pomocne w wykrywaniu i czyszczeniu rozłączonych sesji klientów ,
# nie zabiją one sesji klientów , którzy nadal są połączeni , nawet jeśli są nieaktywni .
# Chyba , że ich klient nie odpowie na pakiet null .
Kopiuj
Aby odłączyć nieaktywnych klientów, jeśli używasz bash jako powłoki, możesz ustawić wartość TMOUT w ogólnosystemowym profilu domyślnym lub na użytkownika:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# TMOUT Jeśli ustawione na wartość większą od zera ,
# TMOUT traktowane jest jako domyślny limit czasu ( tiomeout )
# dla wbudowanego odczytu ( read ) .
#
# Polecenie select kończy pracę jeśli nie otrzyma danych na wejściu
# z terminala po TMOUT sekund .
#
# W powłoce interaktywnej , wartość ta interpretowana jest jako liczba
# sekund oczekiwania na wiersz wejścia po wydaniu głównej zachęty .
#
# Bash kończy pracę po odczekaniu tej liczby sekund
# jeśli nie nadejdzie pełny wiersz wejścia .
# Na przykład , dodanie następującej linii do `/etc/ .bashrc `.
# zamknie sesje bashowe nieaktywnego użytkownika po 5 minutach ,
# ale przeczytaj następujące ostrzeżenie przed włączeniem tego :
`export TMOUT = 300 `
# Ostrzeżenie : jako codzienny użytkownik powłoki , często pozwalam ,
# aby jakiś terminal był otwarty podczas wielozadaniowości .
# Osobiście uznałbym ten mechanizm TMOUT za bardzo denerwujący ,
# jeśli byłby ustawiony na niską wartość ( nawet 10 minut ) .
# Nie polecam tego , chyba że jest przynajmniej ustawiony
# na bardzo wysoką wartość ( co najmniej 1 godzinę - 3600 sekund ) .
# Moja opinia jest taka , że opcje OpenSSH `ClientAliveInterval ` i `ClientAliveCountMax `
# ( lub `ServerAliveInterval ` i `ServerAliveCountMax `, ustawiane po stronie serwera ),
# wystarczą , aby pozbyć się zombie /rozłączonych klientów .
# Używając ich , masz już gwarancję , że aktywna sesja na serwerze
# odpowiada otwartemu terminalowi na podłączonym kliencie .
#
# To jest wybór użytkownika , aby utrzymać swój terminal otwarty ,
# podczas gdy rozumiem . że chcesz zamknąć rozłączonych klientów .
# Nie widzę sensu zamykania sesji od legalnych użytkowników .
Kopiuj
Bezpieczna konfiguracja szyfrów/MAC/Kex dostępnych w SSH# 1
2
3
4
5
6
7
8
KexAlgorithms diffie - hellman - group14 - sha256 , diffie - hellman - group16 - sha512 , diffie - hellman - group18 - sha512 , diffie - hellman - group - exchange - sha256 , ecdh - sha2 - nistp256 , ecdh - sha2 - nistp384 , ecdh - sha2 - nistp521 , curve25519 - sha256 , curve25519 - sha256 @libssh .org
Ciphers aes256 - ctr , aes192 - ctr , aes128 - ctr
MACs hmac - sha2 -512
# Mniej bezpieczne , lecz działające
KexAlgorithms curve25519 - sha256 @libssh .org , ecdh - sha2 - nistp521 , ecdh - sha2 - nistp384 , ecdh - sha2 - nistp256 , diffie - hellman - group - exchange - sha256
Ciphers chacha20 - poly1305 @openssh .com , aes256 - gcm @openssh .com , aes128 - gcm @openssh .com , aes256 - ctr , aes192 - ctr , aes128 - ctr
MACs hmac - sha2 -512 - etm @openssh .com , hmac - sha2 -256 - etm @openssh .com , umac -128 - etm @openssh .com , hmac - sha2 -512 , hmac - sha2 -256 , umac -128 @openssh .com
Kopiuj
Upewnij się, że twój klient ssh może używać tych szyfrów, uruchom:
1
2
ssh -Q cipher | sort -u
to see the list
Kopiuj
Polecam przeczytać ten artykuł::
Secure Configuration of Ciphers/MACs/Kex available in SSH
Przeładuj usługę SSH
1
sudo systemctl reload sshd
Kopiuj
Comments