Lima perubahan kecil pada sshd_config yang benar-benar menutup pintu SSH, dan apa yang OpenSSH 10.6 ubah

Kalau laman anda dihoskan pada pelayan yang membenarkan anda masuk melalui SSH, pintu itu menghadap seluruh internet, bukan hanya anda. Tiga nombor lalai sudah cukup untuk menjelaskan keadaan: sshd mendengar pada port 22, pengesahan kata laluan dibenarkan secara lalai (PasswordAuthentication yes), dan setiap sambungan hanya diberi enam percubaan sebelum diputuskan (MaxAuthTries 6). Dalam tempoh tangguh 120 saat (LoginGraceTime) itu, satu bot boleh mencuba berulang kali daripada beribu alamat IP yang berbeza. Pos ini menyusun lima perubahan kecil pada /etc/ssh/sshd_config yang memberi kesan paling besar, memakai angka daripada manual rasmi OpenSSH dan advisori MyCERT - bukan nasihat kosong. Kalau hosting anda hanya memberi panel kawalan tanpa akses SSH, senarai ini tidak terpakai untuk anda; pautan di bawah menuju perbandingan yang lebih sesuai.

Lima nilai lalai yang perlu dilihat sebelum mengubah apa-apa

Manual sshd_config(5) menyenaraikan nilai lalai ini: Port 22, PasswordAuthentication yes, PermitRootLogin prohibit-password, MaxAuthTries 6, LoginGraceTime 120 saat, MaxStartups 10:30:100, RequiredRSASize 1024 bit, dan PerSourcePenalties yang kini dihidupkan secara lalai. Dua perkara mudah terlepas pandang. Pertama, lalai PermitRootLogin ialah prohibit-password, bukan no - root masih boleh masuk dengan kunci. Kedua, banyak pengedaran Linux menulis tetapan sendiri; pada Ubuntu dan Debian, fail dalam /etc/ssh/sshd_config.d/ dibaca di awal fail utama, jadi satu fail tambahan boleh mengalahkan apa yang anda tulis di bawahnya. Ini kerana sshd_config memakai peraturan nilai pertama menang, bukan nilai terakhir. Sebab itu langkah pertama bukan mengedit, tetapi melihat nilai berkesan yang benar-benar dipakai oleh perkhidmatan itu.

1. Matikan pengesahan kata laluan: satu baris, kesan paling besar

Pengesahan kata laluan membenarkan sesiapa sahaja yang menemui port 22 untuk meneka nama pengguna dan kata laluan. Enam percubaan setiap sambungan kedengaran sedikit, tetapi bot tidak berhenti pada satu sambungan; ia membuka semula selepas diputuskan dan menukar alamat sumber. Setelah pengesahan kunci sahaja dihidupkan, permukaan serangan itu hilang sepenuhnya: tiada kata laluan untuk diteka, kerana kata laluan tidak lagi diterima. Caranya: hasilkan pasangan kunci dengan ssh-keygen (tanpa argumen, ia menghasilkan kunci Ed25519), salin kunci awam ke ~/.ssh/authorized_keys, uji log masuk dalam sesi kedua sementara sesi pertama masih terbuka, kemudian barulah tetapkan PasswordAuthentication no dan KbdInteractiveAuthentication no pada fail utama atau fail dalam sshd_config.d. Baris kedua penting pada Ubuntu dan Debian kerana pengesahan melalui PAM boleh menjadi pintu lain yang menghasilkan kesan sama seperti kata laluan.

Sebelum menutup pintu itu, fikirkan tentang kunci yang dicuri. Kunci peribadi tanpa frasa laluan ialah fail biasa; sesiapa yang menyalinnya boleh masuk tanpa halangan. Beri frasa laluan pada kunci peribadi, dan jangan sesekali menyalin kunci peribadi ke mesin lain. Satu lagi amalan yang jarang dibuat: kekalkan satu sesi root yang sudah terbuka semasa mengedit, supaya kesilapan sintaks tidak menjadikan anda terkunci keluar sementara.

2. Kunci root: bagaimana prohibit-password berbeza daripada no

Sejak OpenSSH 7.0 yang keluar pada 11 Ogos 2015, lalai PermitRootLogin telah ditukar daripada yes kepada prohibit-password. Maksudnya: root masih boleh log masuk, tetapi hanya dengan kunci awam, hostbased atau GSSAPI. Semua kaedah interaktif termasuk kata laluan dan keyboard-interactive ditolak untuk akaun root. Banyak panduan masih menyuruh menetapkan nilai no, dan itu lebih ketat: tiada log masuk root sama sekali, dan kerja pentadbiran dilakukan melalui akaun biasa dengan sudo. Pilih satu dengan sedar. Kalau pelayan anda hanya mempunyai seorang pentadbir, menetapkan no mengurangkan nilai akaun root yang menjadi sasaran pertama bot, sementara jejak audit berpindah ke akaun peribadi yang boleh dibaca dalam log. Perkara yang sama penting: jangan biarkan akaun biasa berkongsi kunci dengan root, kerana nilai tetapan ini hanya mengawal akaun root, bukan akaun lain yang berkuasa sama.

3. Saiz kunci: 1024, 3072 dan 4096 bit

OpenSSH tidak menerima kunci RSA yang terlalu kecil. Pengawal RequiredRSASize pada pelayan menetapkan had minimum, dan lalainya 1024 bit - had itu hanya boleh dinaikkan, tidak boleh diturunkan di bawah lalai. Untuk menghasilkan kunci baharu, ssh-keygen menetapkan minimum 1024 bit bagi RSA dengan lalai 3072 bit. Angka ini bertemu dengan apa yang MyCERT syorkan dalam advisori MA-1213.122024 bertarikh 6 Disember 2024: matikan SSH versi 1, gunakan SSH 2.0 sahaja, konfigurasi sekurang-kurangnya kunci RSA 3072 bit, dan sekurang-kurangnya 4096 bit bagi saiz kunci Diffie-Hellman (kumpulan 16). Algoritma DSA sudah tiada langsung: ia dibuang dalam OpenSSH 10.0 pada 9 April 2025, selepas bertahun dihadkan kepada kunci 160 bit dengan cincang SHA-1, yang bersamaan kira-kira 80 bit keselamatan sahaja. Kalau anda masih ada kunci ssh-dss dalam senarai kunci hos, masa untuk membuangnya sudah lama berlalu, bukan sekarang.

• ▸ Semak kunci pengguna: ssh-keygen -l -f ~/.ssh/id_rsa menunjukkan bilangan bit dan cap jari.
• ▸ Semak kunci hos dalam /etc/ssh/: nama fail membayangkan jenisnya, dan fail ssh_host_dsa_key jika ada adalah sisa zaman lama.
• ▸ Kunci Ed25519 tidak mempunyai soalan saiz bit sama sekali, kerana panjangnya tetap.
• ▸ Naikkan RequiredRSASize hanya selepas menyemang kunci pelanggan anda, kerana kunci yang ditolak membuat sesi gagal sepenuhnya.

4. Penalti automatik: apa yang PerSourcePenalties buat sendiri

Ini bahagian yang paling kurang difahami pemilik laman. PerSourcePenalties, yang dihidupkan secara lalai pada versi OpenSSH terkini, menjatuhkan hukuman kepada alamat sumber tanpa perlu alat tambahan. Nilai lalainya: klien yang menyebabkan sshd terhempas ditolak selama 90 saat; klien yang memutuskan sambungan selepas percubaan masuk gagal ditolak 5 saat; cubaan dengan nama pengguna yang tidak wujud ditolak 5 saat; klien yang gagal masuk selepas tempoh tangguh ditolak 10 saat; dan sambungan yang ditolak secara pentadbiran ditolak 10 saat. Hukuman tidak berkuat kuasa serta-merta: jumlah minimum yang perlu terkumpul dahulu ialah 15 saat, dan jumlah maksimum satu julat alamat boleh ditolak ialah 10 minit. Had sambungan pula dikawal oleh MaxStartups, yang lalainya 10:30:100 - penolakan rawak mula berlaku apabila ada 10 sambungan belum disahkan, dengan kebarangkalian 30 peratus, dan semua cubaan ditolak apabila angka itu mencecah 100. PerSourcePenalties hanya ada sejak OpenSSH 9.8, jadi pelayan lama tidak mempunyainya; Ubuntu 24.04 LTS membawa OpenSSH 9.6p1, yang bermakna had ini tidak berjalan langsung pada pemasangan lalai sehingga pakej dikemas kini.

5. Kemas kini: apa yang OpenSSH 10.6 ubah pada 6 Oktober 2026

Versi yang berjalan menentukan perlindungan yang anda ada, dan projek OpenSSH kini keluar lebih kerap: 10.6 pada 6 Oktober 2026, 10.5 pada 11 Ogos 2026, dan 10.4 pada 6 Julai 2026. Sebabnya dinyatakan terus dalam nota keluaran: jumlah laporan pepijat keselamatan berbantukan AI meningkat, dan sebahagian daripada pepijat itu kemudian dijumpai semula oleh penyelidik bebas, jadi projek itu memilih untuk tidak menunggu kitaran keluaran panjang. Antara perubahan dalam 10.6: pilihan WarnWeakCrypto ditambah pada sshd dan dihidupkan secara lalai, sehingga pelayan mencatat amaran apabila klien menggunakan pertukaran kunci yang tidak selamat terhadap komputer kuantum; pengekod kamus LZ77 dimatikan untuk menutup kebocoran saluran sampingan yang diterangkan dalam kajian Crossing the Streams oleh Fabian Baumer dan Marcus Brinkmann, dengan pracetak arXiv 2609.07709 (2026); nama pengguna yang mengandungi aksara dolar atau garis condong ke belakang ditolak pada baris perintah untuk mengelak suntikan; dan bilangan pusingan lalai KDF dinaikkan daripada 24 kepada 32 untuk melambatkan percubaan meneka frasa laluan pada kunci peribadi yang dicuri. Nota keluaran 10.6 juga memperkenalkan algoritma tandatangan hibrid pascakuantum ssh-mldsa44-ed25519 yang kini dihidupkan secara lalai.

Cara mengesahkan perubahan tanpa mengunci diri sendiri

Simpan satu sesi SSH yang sudah terbuka sepanjang kerja ini. Uji sintaks fail sebelum menyimpan nilai berkesan, dan periksa versi yang benar-benar berjalan. Perintah berikut selamat dijalankan pada pelayan Linux dan tidak mengubah apa-apa; ia cuma membaca:

# 1) uji sintaks fail sebelum dimuatkan
sudo sshd -t

# 2) lihat nilai berkesan, termasuk fail dalam sshd_config.d
sudo sshd -T | grep -Ei "passwordauthentication|permitrootlogin|maxauthtries|logingracetime|requiredrsasize|persourcepenalties"

# 3) versi yang berjalan, bukan versi pakej
sshd -V 2>&1 | head -1

# 4) hitung percubaan masuk gagal hari ini
sudo journalctl -u ssh --since today | grep -ci "invalid user"

Baris ketiga penting kerana pakej boleh dikemas kini tanpa perkhidmatan dimulakan semula, jadi versi yang berjalan boleh ketinggalan. Baris keempat memberi angka, dan angka itu cara paling pantas untuk tahu sama ada port 22 anda sedang diuji orang: jumlah baris Invalid user yang bertambah setiap hari ialah tanda biasa pada pelayan yang terbuka. Sebelum menyimpan sebarang perubahan, ambil sandaran fail konfigurasi dahulu, kerana memulihkan fail lama lebih pantas daripada meneka baris yang tersalah tulis.

Apa yang lima perubahan ini tidak selesaikan

Menukar port SSH daripada 22 kepada nombor lain mengurangkan bunyi dalam log, tetapi ia bukan kawalan keselamatan: pengimbas mencari port terbuka dalam lingkungan penuh alamat, dan port bukan rahsia yang boleh diharap. Begitu juga dengan menyembunyikan versi sshd. Perubahan di atas tidak melindungi daripada kunci peribadi yang dicuri, tidak membaiki perisian lain pada mesin yang sama, dan tidak menggantikan kemas kini sistem yang teratur. Kalau anda menggunakan hosting dikongsi atau cPanel yang tiada akses SSH, tiada satu pun tetapan ini boleh anda sentuh; pilihan sebenar anda ialah ciri keselamatan yang disediakan penyedia, dan itu soalan yang perlu ditanya sebelum memilih pelan. Bagi pelayan sendiri, tiga tabiat lain menyokong kerja ini: sandaran konfigurasi sebelum perubahan, kemas kini keselamatan bulanan, dan semakan kunci lama setiap enam bulan kerana kunci yang tidak digunakan lagi ialah kunci yang paling mudah dilupakan.

Senarai semak 30 minit

• ▸ Jalankan sshd -T dan catat enam nilai berkesan sebelum mengubah apa-apa.
• ▸ Sediakan kunci Ed25519, uji dalam sesi kedua, kemudian matikan pengesahan kata laluan.
• ▸ Tetapkan PermitRootLogin kepada no atau kekalkan prohibit-password dengan kesedaran penuh.
• ▸ Naikkan RequiredRSASize kepada 3072 bit selepas menyemak kunci yang sedang digunakan.
• ▸ Pastikan kunci hos RSA sekurang-kurangnya 3072 bit, dan buang kunci DSA yang tinggal.
• ▸ Semak sshd -V, dan rancang kemas kini jika versi masih 9.6 atau lebih lama.
• ▸ Simpan sandaran sshd_config dan catat tarikh percubaan masuk gagal pada minggu berikutnya untuk perbandingan.