Paano i-harden ang SSH sa VPS

Bakit SSH ang unang dapat i-harden

Ang SSH ang paraan para kontrolin ang iyong server, kaya ito ang unang target ng mga attacker. Sa sandaling maging online ang isang VPS, magsisimula na ang mga scanner na mag-guess ng mga username at password sa port 22. Makikita mo agad ang mga attempt na ito sa iyong logs sa loob lamang ng ilang minuto. Ang pag-harden sa SSH ay ang pag-alis ng mga bagay na madaling hulaan: i-disable ang password login, i-disable ang root login, at payagan lamang ang paggamit ng cryptographic keys. Kapag nagawa mo ito, hindi na magtatagumpay ang mga brute-force attack dahil wala nang password na pwedeng hulaan.

Ipinapalagay nito na gumagana na ang iyong SSH. Kung nakakapag-log in ka na, maaari mo na itong i-harden. Sundin ang mga hakbang nang sunod-sunod. Panatilihing bukas ang kasalukuyang session hanggang sa masubukan ang bagong session, para hindi ka ma-lockout kung magkaroon ng pagkakamali.

Step 1: Siguraduhing gumagana muna ang key authentication

Pinapalitan ng key authentication ang password gamit ang isang key pair: isang private key na mananatili sa iyong computer at isang public key na ilalagay mo sa server. Pinapatunayan ng server na hawak mo ang private key nang hindi ito lumalabas sa iyong machine. Bago i-disable ang mga password, kumpirmahin muna kung gumagana ang mga key para hindi ka ma-lock out.

Sa iyong sariling computer, gumawa ng key kung wala ka pa nito:

ssh-keygen -t ed25519

I-copy ang public half sa server:

ssh-copy-id user@your-server

Pagkatapos, magbukas ng bagong SSH session. Kung papasukin ka nito nang hindi nagtatanong ng password, gumagana ang iyong key at ligtas nang i-off ang mga password. Kung bago pa sa iyo ang mga key, o gumagamit ka ng higit sa isang computer, ipinapaliwanag ng SSH key management basics ang buong modelo: isang key bawat device, ang mga permission na kailangan ng sshd, at kung paano i-revoke ang isang key kapag nawala ang laptop.

Step 2: I-harden ang sshd gamit ang isang drop-in file

Huwag i-edit nang direkta 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 paggamit ng maliit na file sa directory na ito, hindi ito mawawala kapag nag-upgrade ng package, at madali itong burahin kung magkaroon ng error. Mahalaga ang pangalan ng file: pinapanatili ng sshd ang unang value na nababasa nito para sa bawat setting. Ang mga Ubuntu cloud images ay may 50-cloud-init.conf na may PasswordAuthentication yes sa directory na ito. Pangalanan ang iyong file nang 00- para mauna ito sa sorting at maging priority; ang isang 99- file ay hindi magiging priority. Gumawa ng file:

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

Ang bawat linya ay nagsisilbing proteksyon. Ang PasswordAuthentication no ang pinakaimportante: kapag naka-off ang passwords, walang magagamit ang brute-force attack. Ang KbdInteractiveAuthentication no ay nagpapatay ng isa pang password-style na access path. Ang PermitRootLogin no ay nangangahulugan na kailangang malaman ng attacker ang iyong username at hawak ang iyong key, sa halip na i-target lang ang root account na laging naroon sa bawat system.

Step 3: I-test ang config, pagkatapos ay i-reload

Suriin ang config para sa mga pagkakamali bago ito i-apply. Ginagawa ito para hindi masira ang service dahil sa typo:

sudo sshd -t

Kung walang lumabas na output, valid ang config. I-reload ang SSH:

sudo systemctl reload ssh

Pagkatapos, suriin ang settings na ginagamit ng sshd. Makakatulong ito para malaman kung may ibang file na nag-override sa iyong configuration:

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

Dapat parehong nakasaad ang no. Ngayon, nang hindi isinasara ang kasalukuyang session, magbukas ng bagong session mula sa ibang terminal. Kung naka-log in ka gamit ang iyong key, tapos ka na. Kung may mali, bukas pa ang iyong unang session para ayusin ito. Ang overlap na ito ang nagsisilbing safety net, kaya huwag itong lalaktawan.

Step 4: Ang optional na non-standard port

Ang paglipat ng SSH mula sa port 22 patungo sa 2222 ay hindi nagpapataas ng security, dahil ang mga attacker ay nag-i-scan ng lahat ng ports. Ang nagagawa nito ay ang pagbabawas ng log noise, dahil karamihan sa mga automated scanner ay port 22 lang ang sinusubukan. Kung gusto mo ito, i-add ang Port 2222 sa iyong drop-in file, i-allow muna ang bagong port sa firewall, pagkatapos ay i-run ang sudo systemctl daemon-reload && sudo systemctl restart ssh.socket at mag-connect gamit ang ssh -p 2222. Sa Ubuntu 24.04, ang ssh.socket ang may hawak sa listening port, kaya ang simpleng reload ssh ay pananatili sa sshd sa port 22; ang pag-restart ng socket ang kailangan para makuha ang bagong port. Ituring ito bilang paraan ng pag-aayos, hindi bilang proteksyon.

Step 5: Magdagdag ng karagdagang layer ng proteksyon

Ang hardened SSH keys ang pundasyon, at may dalawa pang layer na nakapatong sa mga ito.

Binabantayan ng Fail2ban ang iyong mga log at bina-ban ang mga address na paulit-ulit na nagkakamali. Binabawasan nito ang ingay mula sa mga scanner at agad silang inaalis. Bagay ito sa key-only auth: tingnan ang Fail2ban sa Ubuntu para pigilan ang SSH attacks.

Mas matindi ang proteksyon kung hindi ilalantad ang SSH sa public internet. Kung ilalagay ang SSH sa likod ng isang WireGuard VPN at i-fa-firewall ang port 22 para sa tunnel lamang, walang makakaabot dito maliban sa mga nasa loob ng VPN. Dahil dito, hindi na posibleng magkaroon ng brute-force guessing sa halip na mahirap lang ito. Ang lahat ng ito ay umaasa sa isang default-deny firewall, gaya ng pag-set up ng UFW sa VPS.

Ang SSH ay bahagi lamang ng mas malawak na checklist: ang unang 10 minuto sa isang bagong VPS ay nagbibigay ng tamang pagkakasunod-sunod ng mga hakbang, at ang automatic security updates sa Ubuntu ang nagpapanatili sa server na may mga patch.

FAQ

Paano i-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 (ang 00 prefix ay nagpapabago sa pagkakasunod-sunod nito bago ang 50-cloud-init.conf, kung saan ang PasswordAuthentication yes nito ang mananalo kung hindi, dahil binabasa ng sshd ang unang value na makikita nito) na naglalaman ng PasswordAuthentication no at KbdInteractiveAuthentication no. Patakbuhin ang sudo sshd -t para i-check ito, pagkatapos ay sudo systemctl reload ssh. Siguraduhin na gumagana ang key login sa isang bagong session bago ito gamitin nang tuluyan. Ang pag-edit sa isang drop-in sa halip na sa sshd_config ay hindi mawawala kahit mag-package upgrade, at madali itong i-undo.

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

Oo. I-set ang PermitRootLogin no para walang makapag-log in nang direkta bilang root. Mag-log in gamit ang iyong normal na user at gamitin ang sudo para sa mga admin task. Ang root ay naroon sa bawat Linux box, kaya kung mananatili itong reachable, mayroon nang kilalang username ang attacker na pwedeng i-target. Kung i-disable ito, kailangan muna nilang malaman ang iyong account name at hawakan ang iyong key.

Nagpapataas ba ng security ng server kung papalitan ang SSH port?

Hindi nang malaki. Ang paglipat mula sa port 22 ay nagtatago sa iyo mula sa mga lazy scanner na port 22 lang ang pini-probe, na nagbabawas sa log noise, pero ang totoong attacker ay ini-scan ang lahat ng port at mahahanap pa rin ito. Key-only authentication ang tunay na pumipipigil sa mga break-in. Kung papalitan ang port, i-open muna ang bagong port 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 ang simpleng reload ay mag-iiwan sa sshd sa port 22.

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

Optional ito pero kapaki-pakinabang pa rin. Sa key-only authentication, hindi magtatagumpay ang password guessing, kaya hindi Fail2ban ang pumipigil sa mga attacker. Nililimitahan nito ang bilang ng mga paulit-ulit na failure mula sa isang address, na nagbabawas sa scanner noise sa iyong mga logs at nagtatanggal sa mga paulit-ulit na offender nang maaga; ang isang mabagal at distributed attack ay mananatili pa rin sa ilalim ng ban threshold nito. Patakbuhin ito kasabay ng key auth, at mas mainam kung ilalagay ang SSH sa likod ng isang VPN.

Paano ako magre-recover kung ma-lockout ako sa SSH?

Gamitin ang web console ng iyong provider, na kumokonekta sa server via serial o VNC connection na hindi dumadaan sa SSH. Mula doon, maaari kang mag-log in, ayusin ang sshd drop-in file, at i-reload ang service. Ito ang dahilan kung bakit dapat i-test ang bagong SSH config sa isang pangalawang terminal bago i-close ang unang session, at kung bakit dapat gumagana na ang key authentication bago i-off ang mga password.