Poniższe parametry stosuję od lat na serwerach u różnych dostawców i nie miałem żadnego problemu z bezpieczeństwem oraz brak przejęcia serwera przez niepowołane ręce.


Takie praktyki bezpieczeństwa są praktykowane przez większość administratorów, którzy zarządzają serwerami.

Komenda do otwarcia pliku z konfiguracją SSH

sudo nano /etc/ssh/sshd_config

Unieważnienie dodatkowego pliku konfiguracyjnego w serwerach chmurowych

Zanim przejdziemy do konfiguracji zabezpieczeń SSH, jeszcze musimy w jednym miejscu skomentować znakiem „#” na początku pliku konfiguracyjnego.

Include /etc/ssh/sshd_config.d/*.conf

Musimy skomentować tą linijkę na:

#Include /etc/ssh/sshd_config.d/*.conf

Powód skomentowania: W folderze sshd_config.d znajduje się dodatkowy plik konfiguracyjny pod nazwą: „50-cloud-init.conf” do obsługi protokołu SSH, dodane przez większość dostawców chmurowych, gdzie jest dodany parametr „PasswordAuthenication yes”. Mając dodany parametr w pliku „50-cloud-init.conf” z folderu „sshd_config.d” mają pierwszeństwo wykonania działań i powoduje unieważnienie parametrów znajdującym się w głównym pliku konfiguracyjnym. Z tego powodu stare poradniki są nieaktualne z powodu monitu o podanie hasła do zalogowania się do SSH, pomimo ustawień, które są podane poniżej.

Konfiguracja z użytkownikiem „root”

PermitRootLogin prohibit-password
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

Konfiguracja z innym użytkownikiem niż „root”
np.: w OVHCloud – „ubuntu”

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

Po zmianie parametrów – zresetować usługę SSH

sudo systemctl restart ssh.service

UWAGA!

Zalecam użycie firewalla zewnętrznego u dostawcy VPS i ograniczenie portu 22 do adresu serwera z własnym VPN albo pełną pulę adresu dostawcy Internetu domowego.

Skategoryzowano w

SSH,

Tagowano w:

, , , , ,