Paano I-hardening ang SSH sa VPS

Bakit SSH ang unang dapat i-harden

Ang SSH ang ginagamit mo para kontrolin ang server, kaya ito ang unang lock na sinusubukang pasukin ng bawat attacker. Sa sandaling online na ang isang VPS, nagsisimula nang manghula ang mga scanner ng username at password sa port 22. Makikita mo itong nangyayari sa logs sa loob lamang ng ilang minuto. Ang pag-harden ng SSH ay nangangahulugang alisin ang mga bagay na maaari nilang hulaan: ganap na i-disable ang password login, i-disable ang root login, at payagan lamang ang mga cryptographic key. Kapag nagawa mo na ito, hindi na magtatagumpay ang tuloy-tuloy nilang panghuhula dahil wala nang password na mahahanap.

Ipinapalagay nito na gumagana na ang SSH. Kung nakakapag-login ka, maaari mo na itong i-harden. Gawin ang mga hakbang ayon sa pagkakasunod-sunod at panatilihing bukas ang kasalukuyan mong session hanggang gumana ang isang bagong session. Sa ganitong paraan, hindi ka mai-lock out dahil sa isang pagkakamali.

Hakbang 1: Tiyaking gumagana muna ang key authentication

Pinapalitan ng key authentication ang password gamit ang key pair: isang private key na nananatili sa iyong computer at isang public key na inilalagay mo sa server. Pinatutunayan ng server na hawak mo ang private key nang hindi ito umaalis sa iyong machine. Bago mo i-disable ang mga password, tiyaking gumagana ang mga key. Kung hindi, maaari kang ma-lock out.

Sa sarili mong computer, gumawa ng key kung wala ka pa nito:

ssh-keygen -t ed25519

Kopyahin ang public half papunta sa server:

ssh-copy-id user@your-server

Pagkatapos, magbukas ng bagong SSH session. Kung nakapasok ka nang hindi hinihingan ng password, gumagana ang iyong key at ligtas nang i-disable ang mga password. Kung hihinto ito at ipapakita ang Permission denied (publickey), maaaring itago ng error na iyon ang limang magkakaibang fault, at sasabihin sa iyo ng output ng ssh -v kung alin ang mayroon ka bago ka magbago ng iba pa. Kung bago sa iyo ang mga key, o gumagamit ka ng higit sa isang computer, ipinapaliwanag ng mga pangunahing kaalaman sa SSH key management ang buong modelo: isang key bawat device, ang mga permission na hinihingi ng sshd, at kung paano bawiin ang isang key kapag nawawala ang laptop.

Hakbang 2: Patibayin ang sshd gamit ang drop-in file

Huwag direktang i-edit ang /etc/ssh/sshd_config. Binabasa ng Ubuntu 24.04 ang mga drop-in file mula sa /etc/ssh/sshd_config.d/. Mas malinis ang maliit na file doon, nananatili ito pagkatapos ng package upgrades, at madali itong alisin kapag may naging problema. Mahalaga ang pangalan: ginagamit ng sshd ang unang value na nababasa nito para sa bawat setting. Kasama sa Ubuntu cloud images ang 50-cloud-init.conf na may PasswordAuthentication yes sa directory na ito. Pangalanan ang file bilang 00- upang mauna ito sa sorting at manaig. Tahimik na matatalo ang file na 99-. Gumawa ng isa:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Ilagay ito sa:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Bawat linya ay nagsasara ng isang access path. Pinakamahalaga ang PasswordAuthentication no: kapag naka-off ang mga password, walang mapipilitang password ang brute-force attack. Isinasara ng KbdInteractiveAuthentication no ang isa pang path na gumagamit ng password. Ibig sabihin ng PermitRootLogin no, kailangang alam ng attacker ang iyong username at hawak niya ang iyong cryptographic key. Hindi sapat na i-target lamang ang account na root, na nasa bawat server.

Hakbang 3: Subukan ang configuration, pagkatapos ay i-reload

Suriin kung may mga mali sa configuration bago ito ilapat upang hindi mapahinto ng typo ang serbisyo:

sudo sshd -t

Kung walang inilabas na output, valid ang configuration. I-reload ang SSH:

sudo systemctl reload ssh

Pagkatapos, suriin ang aktuwal na settings na ginagamit ng sshd upang matukoy kung may drop-in na natalo sa isa pang file:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Dapat parehong maglaman ang mga ito ng no. Ngayon, nang hindi isinasara ang kasalukuyan mong session, magbukas ng bagong session mula sa ibang terminal. Kung naka-login ka gamit ang iyong key, tapos na ang proseso. Kung may mali, bukas pa rin ang unang session para maayos ito. Ito ang safety net, kaya huwag itong laktawan.

Hakbang 4: Ang opsyonal na non-standard port

Ang paglilipat ng SSH mula sa port 22 papunta sa gaya ng 2222 ay hindi tunay na nagpapalakas ng seguridad, dahil ini-scan ng determinadong attacker ang lahat ng port. Ang epekto nito ay nababawasan ang ingay sa log, dahil 22 lang ang karaniwang sinusubukan ng karamihan sa mga automated scanner. Kung kailangan mo ito, idagdag ang Port 2222 sa iyong drop-in file, payagan muna ang bagong port sa firewall, saka patakbuhin ang sudo systemctl daemon-reload && sudo systemctl restart ssh.socket at kumonekta gamit ang ssh -p 2222. Sa Ubuntu 24.04, ang ssh.socket ang may kontrol sa listening port, kaya hindi sapat ang plain na reload ssh at mananatili ang sshd sa 22; ang pag-restart sa socket ang maglalapat sa bagong port. Ituring ito bilang pag-aayos lamang, hindi bilang proteksiyon.

Hakbang 5: Idagdag ang mga karagdagang depensa

Pundasyon ang pinatibay na SSH keys, at may dalawa pang layer na inilalagay sa ibabaw ng mga ito.

Minomonitor ng Fail2ban ang iyong logs at bina-ban ang mga address na patuloy na nagfa-fail sa authentication. Nababawasan nito ang ingay mula sa mga scanner at maagang naaalis ang mga ito. Likas itong ka-partner ng key-only auth: tingnan ang Fail2ban sa Ubuntu para ihinto ang mga SSH attack.

Mas matibay pa kung ganap na hindi naa-access ng public internet ang SSH. Kung ilalagay mo ang SSH sa likod ng WireGuard VPN at i-firewall ang port 22 para sa tunnel, hindi ito maaabot ng sinumang wala sa VPN. Dahil dito, hindi na posible ang brute-force guessing, sa halip na maging mahirap lang. Ipinapalagay ng lahat ng ito na may default-deny firewall sa ilalim, na naka-set up ang UFW sa VPS.

Isang bahagi lang ang SSH ng mas malawak na checklist: inililista ng unang 10 minuto sa isang bagong VPS ang mga hakbang ayon sa tamang pagkakasunod-sunod, at pinananatiling patched ng automatic security updates sa Ubuntu ang system pagkatapos. Wala ring nagagawa ang pag-lock ng pinto para sa mga serbisyong nasa likod nito. Kaya kung nagpapatakbo ang parehong VPS ng password vault, sinasaklaw ng hardening pass sa Vaultwarden ang dalawang bagay na hindi naaabot ng key auth: ang admin token nito at ang backup file nito.

FAQ

Paano ko idi-disable ang password login para sa SSH sa Ubuntu 24.04?

Gumawa ng drop-in file sa /etc/ssh/sshd_config.d/00-hardening.conf. Dahil ang prefix na 00 ay nauuna sa sorting kaysa sa 50-cloud-init.conf, mananaig ang value ng PasswordAuthentication yes dahil unang binabasa ng sshd ang value na iyon. Ilagay dito ang PasswordAuthentication no at KbdInteractiveAuthentication no, patakbuhin ang sudo sshd -t para suriin ito, at pagkatapos ay patakbuhin ang sudo systemctl reload ssh. Kumpirmahing gumagana ang key login sa isang bagong session bago mo ito asahan. Mananatili ang mga pagbabago sa drop-in kahit mag-upgrade ng package, at madali itong ibalik, hindi gaya ng pag-edit sa sshd_config.

Dapat ko bang i-disable ang root login sa SSH?

Oo. Itakda ang PermitRootLogin no upang walang direktang makapag-login bilang root. Mag-login gamit ang iyong regular na user at gamitin ang sudo para sa mga administrative task. May root account sa bawat Linux box, kaya kapag nanatili itong reachable, binibigyan mo ang attacker ng kilalang username na maaaring targetin. Kapag na-disable ito, kailangan nilang malaman ang pangalan ng account mo at taglayin ang iyong key.

Mas magiging secure ba ang server ko kapag binago ko ang SSH port?

Hindi nang makabuluhan. Kapag lumipat ka mula sa port 22, hindi ka makikita ng mga tamad na scanner na port 22 lamang ang tine-test, kaya mababawasan ang ingay sa logs. Gayunman, sini-scan ng totoong attacker ang bawat port at mahahanap pa rin nila ito. Ang key-only authentication ang aktuwal na pumipigil sa mga break-in. Kung babaguhin mo ang port, buksan muna ang bago sa firewall, pagkatapos ay patakbuhin ang sudo systemctl daemon-reload && sudo systemctl restart ssh.socket. Sa Ubuntu 24.04, ang socket ang may-ari ng listener, kaya mananatiling nakikinig ang sshd sa port 22 kapag plain reload lamang ang ginawa.

Kailangan ko ba ng Fail2ban kung gumagamit ako ng SSH keys?

Opsyonal ito pero kapaki-pakinabang pa rin. Kapag key-only authentication ang gamit, hindi magtatagumpay ang password guessing, kaya hindi Fail2ban ang pangunahing pumipigil sa mga attacker. Nililimitahan nito ang rate ng paulit-ulit na failure mula sa isang address. Dahil dito, nababawasan ang ingay ng mga scanner sa logs at maagang napapaalis ang mga paulit-ulit na umaatake. Gayunman, mananatiling mas mababa sa ban threshold nito ang isang mabagal at distributed na attack. Patakbuhin ito kasabay ng key auth, at pinakamainam na panatilihin ang SSH sa likod ng VPN.

Paano ako makakabawi kung ma-lock out ko ang sarili ko sa SSH?

Gamitin ang web console ng provider mo. Kumokonekta ito sa server gamit ang serial o VNC connection na hindi dumadaan sa SSH. Mula roon, makakapag-login ka, maaayos ang sshd drop-in file, at mai-reload ang service. Ito mismo ang dahilan kung bakit dapat mong i-test ang bagong SSH config sa pangalawang terminal bago isara ang unang session. Dapat ding gumagana na ang key authentication bago mo i-disable ang mga password.