Cara Memperkukuh Keselamatan SSH pada VPS

Mengapa SSH perlu diperkukuh terlebih dahulu

SSH ialah cara anda mengawal pelayan, menjadikannya kunci yang cuba dipecahkan oleh setiap penyerang. Sebaik sahaja VPS dalam talian, pengimbas akan mula meneka nama pengguna dan kata laluan pada port 22. Anda boleh melihat perkara ini berlaku dalam log anda dalam masa beberapa minit. Memperkukuh SSH bermaksud membuang perkara yang boleh diteka oleh mereka: matikan log masuk kata laluan sepenuhnya, matikan log masuk root, dan benarkan hanya kunci kriptografi untuk masuk. Apabila anda berbuat demikian, cubaan meneka yang berterusan tidak akan berjaya, kerana tiada kata laluan untuk ditemui.

Langkah ini mengandaikan SSH anda sudah berfungsi. Jika anda boleh log masuk, anda boleh memperkukuhnya. Lakukan langkah-langkah mengikut urutan dan pastikan sesi semasa anda kekal terbuka sehingga sesi baharu berfungsi, supaya kesilapan tidak menyebabkan anda terkunci keluar.

Langkah 1: Pastikan pengesahan kunci berfungsi terlebih dahulu

Pengesahan kunci menggantikan kata laluan dengan pasangan kunci: kunci peribadi yang kekal pada komputer anda dan kunci awam yang anda letakkan pada pelayan. Pelayan membuktikan anda memegang kunci peribadi tersebut tanpa kunci itu meninggalkan mesin anda. Sebelum anda menyahdayakan kata laluan, sahkan kunci berfungsi, atau anda akan terkunci daripada sistem.

Pada komputer anda sendiri, cipta kunci jika anda belum memilikinya:

ssh-keygen -t ed25519

Salin bahagian awam ke pelayan:

ssh-copy-id user@your-server

Kemudian buka sesi SSH baharu. Jika ia membenarkan anda masuk tanpa meminta kata laluan, kunci anda berfungsi dan anda selamat untuk mematikan kata laluan. Jika ia menghalang anda dengan Permission denied (publickey), ralat itu menyembunyikan lima punca berbeza, dan output ssh -v memberitahu anda punca yang mana satu anda hadapi sebelum anda menukar perkara lain. Jika kunci adalah perkara baharu bagi anda, atau anda menggunakan lebih daripada satu komputer, asas pengurusan kunci SSH menerangkan model penuh: satu kunci bagi setiap peranti, kebenaran yang dituntut oleh sshd, dan cara membatalkan kunci apabila komputer riba hilang.

Langkah 2: Mengukuhkan sshd dengan fail drop-in

Jangan sunting /etc/ssh/sshd_config secara terus. Ubuntu 24.04 membaca fail drop-in daripada /etc/ssh/sshd_config.d/, dan fail kecil di situ lebih kemas, kekal selepas naik taraf pakej, serta mudah dibuang jika berlaku masalah. Nama fail adalah penting: sshd mengekalkan nilai pertama yang dibacanya untuk setiap tetapan, dan imej awan Ubuntu membekalkan 50-cloud-init.conf dengan PasswordAuthentication yes dalam direktori ini. Namakan fail anda 00- supaya ia disusun sebelum fail tersebut dan diutamakan; fail 99- akan kalah tanpa sebarang amaran. Cipta satu fail:

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

Masukkan kandungan ini:

# 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

Setiap baris menutup satu pintu masuk. PasswordAuthentication no adalah yang paling utama: dengan kata laluan dimatikan, serangan brute-force tidak mempunyai sasaran untuk ditembusi. KbdInteractiveAuthentication no menutup satu lagi laluan gaya kata laluan. PermitRootLogin no bermakna penyerang perlu mengetahui nama pengguna anda dan memegang kunci anda, bukannya sekadar menyasarkan satu akaun, root, yang wujud pada setiap pelayan.

Langkah 3: Uji konfigurasi, kemudian muat semula

Semak konfigurasi untuk mengesan kesilapan sebelum mengaplikasikannya, supaya ralat taip tidak melumpuhkan servis:

sudo sshd -t

sudo sshd -t

Jika tiada output dipaparkan, konfigurasi adalah sah. Muat semula SSH:

sudo systemctl reload ssh

sudo systemctl reload sshd

Seterusnya, semak tetapan yang sebenarnya digunakan oleh sshd, supaya anda dapat mengesan fail drop-in yang mungkin ditindih oleh fail lain:

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

sshd -T | grep -E 'pubkeyauthentication|passwordauthentication'

Kedua-duanya harus memaparkan no. Sekarang, tanpa menutup sesi semasa anda, buka sesi baharu daripada terminal lain. Jika anda berjaya log masuk menggunakan kunci anda, tugasan anda selesai. Jika terdapat sebarang masalah, sesi pertama anda masih terbuka untuk membaikinya. Pertindihan ini merupakan langkah keselamatan, jadi jangan sekali-kali melangkauinya.

Langkah 4: Port bukan standard pilihan

Mengalihkan SSH daripada port 22 ke port seperti 2222 tidak meningkatkan keselamatan secara nyata, kerana penyerang yang bertekad akan mengimbas semua port. Tindakan ini hanya mengurangkan gangguan log, memandangkan kebanyakan pengimbas automatik hanya mencuba port 22. Jika anda mahukannya, tambahkan Port 2222 ke dalam fail drop-in anda, benarkan port baharu tersebut dalam firewall terlebih dahulu, kemudian jalankan sudo systemctl daemon-reload && sudo systemctl restart ssh.socket dan sambungkan menggunakan ssh -p 2222. Pada Ubuntu 24.04, ssh.socket mengawal port yang mendengar, jadi reload ssh biasa akan membiarkan sshd pada port 22; memulakan semula socket adalah langkah yang akan mengambil port baharu tersebut. Anggap ini sebagai langkah kekemasan, bukan perlindungan.

Langkah 5: Melapis pertahanan tambahan

Kunci SSH yang dikukuhkan merupakan asas, dan dua lapisan lagi diletakkan di atasnya.

Fail2ban memantau log anda dan menyekat alamat yang terus gagal log masuk, yang mengurangkan gangguan pengimbas dan menyingkirkannya lebih awal. Ia berfungsi secara semula jadi dengan pengesahan berasaskan kunci sahaja: lihat Fail2ban pada Ubuntu untuk menghentikan serangan SSH.

Lebih kukuh lagi adalah dengan menjauhkan SSH daripada internet awam sepenuhnya. Jika anda meletakkan SSH di sebalik VPN WireGuard dan memadamkan port 22 pada firewall kepada tunnel, tiada sesiapa di luar VPN boleh mencapainya, dan tekaan brute-force tidak lagi menjadi mungkin dan bukannya sekadar sukar. Semua ini mengandaikan firewall default-deny di bawahnya, iaitu UFW yang disediakan pada VPS.

SSH hanyalah satu baris dalam senarai semak yang lebih besar: 10 minit pertama pada VPS baharu menyusun langkah-langkah tersebut mengikut urutan, dan kemas kini keselamatan automatik pada Ubuntu memastikan pelayan sentiasa ditampal selepas itu. Mengunci pintu juga tidak memberi kesan kepada servis di belakangnya, jadi jika VPS yang sama menjalankan peti besi kata laluan, pusingan pengukuhan ke atas Vaultwarden meliputi dua perkara yang tidak disentuh oleh pengesahan kunci: token pentadbir dan fail sandarannya.

FAQ

Bagaimanakah cara untuk menyahdayakan log masuk kata laluan bagi SSH pada Ubuntu 24.04?

Cipta fail drop-in di /etc/ssh/sshd_config.d/00-hardening.conf (prefiks 00 memastikan ia diisih sebelum 50-cloud-init.conf, yang mana PasswordAuthentication yes akan menang jika tidak, kerana sshd mengekalkan nilai pertama yang dibacanya) yang mengandungi PasswordAuthentication no dan KbdInteractiveAuthentication no, jalankan sudo sshd -t untuk menyemaknya, kemudian sudo systemctl reload ssh. Pastikan log masuk kunci berfungsi dalam sesi baharu sebelum anda bergantung padanya. Menyunting fail drop-in berbanding sshd_config membolehkan konfigurasi bertahan semasa naik taraf pakej dan mudah untuk dibatalkan.

Patutkah saya menyahdayakan log masuk root melalui SSH?

Ya. Tetapkan PermitRootLogin no supaya tiada sesiapa boleh log masuk secara terus sebagai root. Log masuk sebagai pengguna biasa anda dan gunakan sudo untuk tugasan pentadbiran. Akaun root wujud pada setiap sistem Linux, jadi membiarkannya boleh dicapai memberikan penyerang nama pengguna yang diketahui untuk disasarkan. Menyahdayakannya bermakna mereka perlu mengetahui nama akaun anda dan memiliki kunci anda.

Adakah menukar port SSH menjadikan pelayan saya lebih selamat?

Tidak secara signifikan. Mengalih keluar daripada port 22 menyembunyikan anda daripada pengimbas malas yang hanya memeriksa port 22, yang mengurangkan gangguan log, tetapi penyerang sebenar akan mengimbas setiap port dan tetap menemuinya. Pengesahan kunci sahaja adalah perkara yang sebenarnya menghalang pencerobohan. Jika anda menukar port, buka port baharu dalam firewall terlebih dahulu, kemudian jalankan sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; pada Ubuntu 24.04, soket memiliki pendengar (listener), dan muat semula biasa akan membiarkan sshd pada port 22.

Adakah saya memerlukan Fail2ban jika saya menggunakan kunci SSH?

Ia adalah pilihan tetapi masih berguna. Dengan pengesahan kunci sahaja, tekaan kata laluan tidak akan berjaya, jadi Fail2ban bukanlah perkara yang menghalang penyerang. Ia mengehadkan kadar kegagalan berulang daripada satu alamat, yang mengurangkan gangguan pengimbas daripada log anda dan mengeluarkan pesalah berulang dengan lebih awal; serangan yang perlahan dan teragih tetap akan berada di bawah ambang sekatan. Jalankannya di atas pengesahan kunci, dan sebaik-baiknya letakkan SSH di sebalik VPN.

Bagaimanakah cara untuk memulihkan akses jika saya terkunci daripada SSH?

Gunakan konsol web pembekal anda, yang mencapai pelayan melalui sambungan bersiri atau VNC yang tidak melalui SSH. Dari situ anda boleh log masuk, membaiki fail drop-in sshd, dan memuat semula servis tersebut. Inilah sebabnya anda perlu menguji konfigurasi SSH baharu dalam terminal kedua sebelum menutup sesi pertama anda, dan mengapa pengesahan kunci sepatutnya sudah berfungsi sebelum anda mematikan kata laluan.