Cara Selesaikan Ralat SSH Permission denied (publickey)

Apakah maksud sebenar Permission denied (publickey)

Permission denied (publickey) bermaksud klien anda menghantar satu atau lebih kunci awam dan pelayan tidak menerima satu pun daripadanya. Rangkaian berfungsi dengan baik dan sshd sedang berjalan: penolakan berlaku pada langkah terakhir pengesahan. Pembaikannya bukan berdasarkan tekaan, kerana ssh -v memberitahu anda punca daripada lima kemungkinan yang ada.

Perkataan di dalam kurungan ialah kaedah yang sanggup diterima oleh pelayan. Permission denied (publickey) secara sendirian bermaksud log masuk kata laluan dimatikan pada pelayan tersebut, jadi tiada kata laluan untuk digunakan sebagai sandaran. Permission denied (publickey,password) bermaksud kata laluan ditawarkan dan anda gagal dalam percubaan tersebut juga.

Satu mesej merangkumi lima kerosakan berasingan, dan ia sengaja dibuat samar. Pelayan yang membalas "no such user" atau "that key is not installed" akan membantu sesiapa sahaja yang mengimbas akaun yang sah. Jadi, jangan mula menukar kunci dan menyunting fail konfigurasi. Jalankan satu arahan, baca tiga baris output, dan lima kemungkinan punca akan berkurangan kepada satu.

Jalankan ssh -v terlebih dahulu, dan baca tiga baris

Ulangi arahan yang gagal, dengan tambahan -v:

ssh -v deploy@203.0.113.10

Contoh output yang diringkaskan tetapi realistik adalah seperti berikut:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

Tiga baris ini mengandungi semua maklumat yang anda perlukan.

Authenticating to 203.0.113.10:22 as 'deploy' ialah nama pengguna yang sebenarnya akan digunakan. Bukan nama yang anda maksudkan: ia adalah nama yang ditentukan oleh ssh daripada baris arahan, daripada ~/.ssh/config, atau daripada nama log masuk tempatan anda.

Authentications that can continue: publickey ialah senarai kaedah yang diterima oleh pelayan, dihantar sebelum sebarang kunci dicuba. Jika publickey tiada dalam senarai pertama tersebut, pelayan telah mematikan log masuk kunci awam, jadi tiada kunci yang akan berfungsi.

Offering public key: ... ialah satu baris bagi setiap kunci yang benar-benar dihantar oleh klien anda, menamakan fail asal kunci tersebut serta fingerprint SHA256 miliknya. Kunci yang tidak mempunyai baris Offering tidak pernah dihantar kepada pelayan.

Sekarang, bahagikan masalah kepada dua bahagian:

• Tiada baris Offering public key untuk kunci yang anda jangkakan. Masalah berpunca daripada mesin anda, kerana pelayan tidak menerima kunci anda sama sekali.
• Kunci ditawarkan dan Authentications that can continue: publickey muncul semula. Pelayan telah menerima kunci tersebut dan menolaknya, jadi masalah berpunca daripada pelayan.

Punca-punca di bawah disusun mengikut kekerapan ia menjadi jawapan kepada masalah tersebut.

Punca 1: anda menyambung menggunakan nama pengguna yang salah

Punca yang paling kerap berlaku juga merupakan punca yang paling mudah. sshd, iaitu daemon pelayan SSH (secure shell), tidak akan memberitahu anda jika sesuatu akaun tidak wujud. Ia menjalankan keseluruhan pertukaran maklumat untuk nama pengguna yang direka-reka dan menolak sambungan pada akhirnya dengan mesej yang sama, kerana mendedahkan nama akaun yang sah akan membantu penyerang. Kesilapan menaip pada nama pengguna kelihatan sama seperti kunci yang rosak.

Semak baris Authenticating to ... as sebelum melakukan perkara lain. Jika ia memaparkan nama log masuk komputer riba anda dan bukannya akaun pelayan, bermakna anda tertinggal nama pengguna dalam arahan tersebut.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

Akaun lalai bergantung pada imej yang dibina oleh penyedia anda. Sehingga Ogos 2026, imej awan Ubuntu biasanya menyertakan akaun ubuntu, imej Debian menyertakan debian atau admin, Rocky Linux dan AlmaLinux menyertakan rocky dan almalinux, manakala banyak penyedia VPS sebaliknya memasang kunci anda terus ke dalam root. Panel kawalan penyedia anda merekodkan akaun mana yang telah dicipta. Tiada arahan yang dijalankan dari luar pelayan boleh bertanyakan maklumat ini.

Blok Host dalam ~/.ssh/config juga menetapkan nama pengguna, dan ia mengatasi nama log masuk tempatan anda:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Jika anda mencipta akaun tersebut sendiri dan kemudian tidak dapat log masuk sebagai akaun itu, kunci tersebut mungkin dipasang untuk pengguna lalai imej dan tidak pernah disalin ke akaun baharu. Langkah itu adalah sebahagian daripada sepuluh minit pertama pada VPS baharu, dan ia mudah terlepas pandang.

Punca 2: kunci yang anda sangka sedang dihantar bukanlah kunci yang sebenarnya dihantar

Secara lalai, ssh hanya menawarkan kunci yang disimpan oleh ssh-agent serta set nama fail tetap dalam ~/.ssh: id_ed25519, id_ecdsa, id_rsa, dan varian perkakasan serta DSA bagi nama-nama tersebut. Kunci yang disimpan sebagai ~/.ssh/vps-prod tidak dapat dilihat oleh ssh sehingga anda menamakannya, itulah sebabnya output verbose tidak menunjukkan baris Offering public key untuk kunci tersebut.

Namakan fail tersebut, dan halang kunci ejen daripada mengambil tempatnya:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

-i sahaja tidak mencukupi apabila ejen menyimpan kunci, kerana ssh masih menawarkan kunci ejen terlebih dahulu dan fail yang dinamakan itu terakhir. Ini penting, kerana pelayan mengira setiap kunci yang ditolak terhadap MaxAuthTries, yang ditetapkan secara lalai kepada 6. Ejen yang menyimpan tujuh kunci boleh menghabiskan had tersebut sebelum kunci anda yang betul sampai, dan mesej kemudian berubah kepada:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

IdentitiesOnly=yes mengehadkan percubaan kepada fail yang anda berikan. Senaraikan apa yang disimpan oleh ejen dengan ssh-add -l, dan kosongkannya dengan ssh-add -D jika ia telah mengumpul kunci lama selama bertahun-tahun. Kemudian tulis tetapan tersebut supaya log masuk seterusnya tidak bergantung pada mengingati flag:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

Satu lagi perangkap di bahagian klien. ssh enggan menggunakan kunci peribadi yang boleh dibaca oleh akaun lain pada mesin anda sendiri. Ia mencetak amaran dan kemudian mengabaikan kunci tersebut, jadi kunci itu tidak pernah ditawarkan dan pelayan tidak pernah melihatnya:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod membetulkannya. Memindahkan kunci melalui pemacu USB atau share Windows adalah cara biasa mod fail tersebut hilang. Di mana kunci disimpan dan cara menamakannya dibincangkan dalam Asas pengurusan kunci SSH.

Punca 3: kunci awam tidak sampai ke authorized_keys

Jika ssh -v menunjukkan kunci telah dihantar namun pelayan masih menolak akses, persoalan seterusnya ialah sama ada kunci tersebut berada dalam fail authorized_keys akaun berkenaan. Buka konsol pembekal anda untuk menyemak, memandangkan anda tidak boleh log masuk melalui SSH untuk melihatnya.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

ssh-keygen -lf pada fail authorized_keys mencetak satu cap jari (fingerprint) bagi setiap entri:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

Bandingkan cap jari tersebut dengan cap jari pada baris Offering public key anda. Jika ia tiada dalam senarai, kunci tersebut tidak dipasang pada akaun itu, tidak kira apa yang anda ingat telah dilakukan.

Empat punca perkara ini berlaku, semuanya lazim:

• Anda menampal kunci peribadi (private key) dan bukannya fail .pub. Baris kunci awam bermula dengan ssh-ed25519 atau ssh-rsa. Kunci peribadi bermula dengan -----BEGIN OPENSSH PRIVATE KEY-----.
• Teks yang ditampal bersambung ke beberapa baris. Setiap entri mesti berada tepat pada satu baris, jadi kunci yang bersambung akan dibaca sebagai beberapa entri rosak dan tidak sepadan dengan apa-apa.
• Kunci dimasukkan ke dalam /root/.ssh/authorized_keys sedangkan anda log masuk sebagai deploy, atau sebaliknya. Fail ini adalah khusus untuk setiap akaun, dan tiada fail yang dikongsi.
• Kotak "add my key" pembekal hanya menulis kunci tersebut kepada pengguna lalai imej, jadi akaun yang anda cipta kemudian mempunyai direktori .ssh yang kosong.

Cara selamat untuk menambah kunci daripada konsol, sebagai root:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Jalankan sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys sekali lagi selepas itu. Cap jari baharu sepatutnya sudah ada dalam senarai sekarang. Daripada mesin yang masih boleh log masuk dengan kata laluan, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 melakukan kerja yang sama dan menetapkan mod (permissions) dengan betul untuk anda.

Punca 4: mengapa sshd mengabaikan authorized_keys apabila kebenaran terlalu terbuka

StrictModes yes ialah tetapan lalai sshd. Di bawahnya, sshd enggan membaca authorized_keys jika fail tersebut, direktori .ssh, atau direktori utama akaun boleh ditulis oleh sesiapa selain pemiliknya. Sebabnya jelas: jika kumpulan atau pengguna lain boleh menulis ke direktori utama anda, mana-mana akaun yang mempunyai akses tersebut boleh menggantikan authorized_keys dan mengambil alih log masuk. sshd menganggap laluan yang tidak dipercayai sebagai tiada kunci yang wujud.

Pelanggan akan melihat mesej Permission denied yang biasa. Log pelayan merekodkan sebab sebenar:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

atau, apabila fail itu sendiri yang menjadi masalah:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

Apa yang akan diterima oleh sshd:

• Direktori utama: tidak boleh ditulis oleh kumpulan dan tidak boleh ditulis oleh pengguna lain. 755, 750 dan 700 semuanya diterima. 775 dan 777 gagal.
• ~/.ssh: mod 700.
• ~/.ssh/authorized_keys: mod 600.
• Pemilikan: ketiga-tiganya dimiliki oleh akaun yang anda gunakan untuk log masuk, bukan oleh root.

Pemilikan adalah sama penting dengan mod. Fail di dalam /home/deploy/.ssh yang dimiliki oleh root akan gagal dalam pemeriksaan yang sama, iaitu perkara yang berlaku apabila anda menciptanya dengan sudo nano dan terlupa untuk menukar pemilikan semula. Selesaikan kedua-duanya serentak:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

Perintah terakhir menunjukkan hasilnya. Anda mahukan drwxr-xr-x atau lebih ketat pada direktori utama dan drwx------ pada .ssh. Jika rentetan tersebut belum jelas, baca cara membaca rentetan kebenaran seperti drwxr-xr-x sebelum anda menukar mod pada pelayan yang sedang berjalan.

Pada Rocky Linux dan AlmaLinux, tambahkan SELinux (security-enhanced Linux) ke dalam senarai suspek. Direktori .ssh yang dicipta melalui laluan luar biasa boleh membawa label fail yang salah, menyebabkan sshd dinafikan akses baca walaupun mod kelihatan betul. sudo restorecon -Rv /home/deploy/.ssh membetulkan label tersebut, dan sudo ausearch -m avc -ts recent menunjukkan sama ada SELinux merupakan komponen yang menafikan akses.

Punca 5: sshd dikonfigurasikan untuk menolak anda

Membaca /etc/ssh/sshd_config tidak mencukupi pada sistem Ubuntu atau Debian semasa. Fail tersebut bermula dengan Include /etc/ssh/sshd_config.d/*.conf, dan OpenSSH mengekalkan nilai pertama yang ditemui untuk sebarang tetapan. Fail tambahan seperti 50-cloud-init.conf oleh itu dibaca terlebih dahulu dan mengatasi apa sahaja yang anda edit di bahagian bawah fail utama. Inilah sebabnya mengapa suntingan boleh kelihatan betul tetapi tidak mengubah apa-apa.

Minta sshd menunjukkan konfigurasi yang sebenarnya digunakan:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

Jawapan yang sihat kelihatan seperti ini:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

Perkara yang perlu dicari dalam output anda sendiri:

• pubkeyauthentication no. Tiada kunci akan diterima. Ini juga muncul dalam ssh -v sebagai senarai Authentications that can continue: pertama tanpa publickey di dalamnya.
• authorizedkeysfile yang menghala ke tempat lain, contohnya /etc/ssh/authorized_keys/%u. Fail anda dalam direktori home kemudiannya diabaikan sepenuhnya, dan peraturan mod daripada punca 4 terpakai pada laluan baharu tersebut.
• allowusers atau allowgroups hadir. Mana-mana akaun yang tidak disenaraikan akan ditolak dengan ralat tepat ini tanpa penjelasan. denyusers dan denygroups melakukan perkara yang sama secara terbalik.
• permitrootlogin no semasa anda cuba log masuk sebagai root. prohibit-password ialah tetapan pertengahan yang berguna: root boleh menggunakan kunci tetapi bukan kata laluan.

Blok Match tidak muncul dalam sshd -T biasa, kerana hasilnya bergantung kepada siapa yang sedang menyambung. Tanya tentang satu sambungan khusus:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

Satu lagi tetapan menjejaskan kunci lama. OpenSSH 8.8 berhenti menerima tandatangan SHA-1 (ssh-rsa) secara lalai, jadi kunci RSA yang berfungsi selama bertahun-tahun boleh berhenti berfungsi sejurus selepas naik taraf pelayan. Pelanggan menyatakan perkara ini dengan jelas:

debug1: send_pubkey_test: no mutual signature algorithm

Pembaikan yang betul ialah kunci baharu: ssh-keygen -t ed25519 -C "deploy@vps-prod", kemudian pasang fail .pub seperti yang ditunjukkan di atas. Menetapkan PubkeyAcceptedAlgorithms +ssh-rsa pada pelayan mengaktifkan semula tandatangan lama dan membolehkan anda masuk hari ini, jadi anggap ia sebagai cara untuk mencapai kotak tersebut, bukan sebagai penyelesaian akhir. Selebihnya tetapan bahagian pelayan yang perlu disemak ada dalam pengukuhan pelayan SSH pada VPS.

Cara membuktikan kunci peribadi sepadan dengan kunci awam yang dipasang

Kebanyakan tekaan dalam ralat ini berpunca daripada ketidakpastian sama ada dua fail merupakan pasangan. Satu arahan dapat menjawabnya:

ssh-keygen -y -f ~/.ssh/vps-prod

Arahan tersebut mencetak kunci awam yang diterbitkan daripada kunci peribadi. Ia tidak membaca fail .pub di sebelahnya, jadi ia memberitahu anda perkara sebenar tentang kunci peribadi tersebut dan bukannya apa yang didakwa oleh fail .pub yang lapuk. Jika kunci mempunyai frasa laluan, arahan ini akan memintanya, yang juga membuktikan anda masih mengetahui frasa laluan tersebut.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

Arahan pertama mencetak cap jari bagi satu fail kunci awam. Arahan kedua mencetak cap jari yang dipegang oleh ejen anda. Sekarang, selaraskan empat paparan rentetan yang sama: cap jari pada baris Offering public key daripada ssh -v, cap jari fail .pub anda, cap jari dalam ssh-keygen -lf pada authorized_keys pelayan, dan cap jari dalam log pelayan. Titik di mana ia tidak lagi sepadan adalah punca kesilapan anda.

Membaca log pelayan semasa log masuk gagal

Pelanggan tidak diberikan maklumat berguna secara sengaja. Pelayan menulis sebab sebenar kegagalan tersebut. Mulakan pemantau log pada sesi konsol, kemudian jalankan arahan ssh yang gagal itu daripada komputer riba anda.

sudo journalctl -u ssh -f

Ubuntu 24.04 tidak memasang rsyslog secara lalai, jadi /var/log/auth.log mungkin tidak wujud di situ. Pada Rocky Linux dan AlmaLinux, unit tersebut dinamakan sshd dan rekod yang sama juga disimpan dalam /var/log/secure.

Tetapkan LogLevel VERBOSE dalam konfigurasi sshd dan muat semula servis tersebut. Setiap percubaan kemudiannya akan mencatatkan cap jari (fingerprint) yang sebenarnya diterima oleh pelayan:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

Baris tersebut memberitahu anda pihak mana yang menyebabkan kegagalan. Cap jari yang anda kenali bermakna kunci anda telah sampai tetapi ditolak oleh pelayan, jadi lihat punca 3, 4 dan 5. Cap jari yang tidak anda kenali bermakna pelanggan anda menghantar kunci yang tidak anda niatkan, jadi kembali ke punca 2.

Apabila log masih tidak jelas, jalankan sshd kedua pada port lain dalam mod nyahpepijat (debug mode). Ia akan kekal di latar depan, melayani satu sambungan, mencetak alasannya, kemudian keluar:

sudo /usr/sbin/sshd -ddd -p 2222

Daripada sesi konsol pada pelayan yang sama, sambung kepadanya melalui alamat loopback:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

Menggunakan 127.0.0.1 memastikan firewall tidak terlibat dalam ujian ini. Output nyahpepijat menamakan fail yang dibuka, cap jari yang dibandingkan, dan penolakan tepat, termasuk baris seperti Authentication refused: bad ownership or modes for directory /home/deploy. Tekan Ctrl+C apabila anda mendapat jawapannya. sshd sebenar pada port 22 tidak terjejas sepanjang proses ini.

Cara mengelakkan diri daripada terkunci keluar

Setiap langkah yang mengubah konfigurasi pelayan memerlukan jalan masuk alternatif yang tidak bergantung pada SSH. Sediakan perkara ini semasa SSH masih berfungsi, bukan selepas ia terputus.

1. Buka konsol pembekal anda, melalui serial atau VNC (virtual network computing), dan sahkan anda boleh log masuk di sana.
2. Pastikan anda mengetahui kata laluan tempatan yang berfungsi untuk akaun dengan keistimewaan sudo. Jika anda tidak mempunyainya, tetapkan semula kata laluan root daripada konsol pembekal terlebih dahulu.
3. Pastikan sesi SSH semasa anda kekal terbuka. Sesi yang terbuka akan bertahan walaupun berlaku systemctl restart ssh, jadi ia kekal sebagai jalan masuk jika konfigurasi baharu didapati salah.
4. Semak sintaks sebelum anda memulakan semula: sudo sshd -t tidak akan mencetak apa-apa jika fail tersebut sah, dan akan mencetak fail serta nombor baris jika ia tidak sah.
5. Buka terminal kedua dan log masuk sebagai sesi baharu sebelum menutup terminal pertama. Konfigurasi yang rosak akan menghalang log masuk baharu tetapi membiarkan sesi sedia ada terus berjalan, jadi sesi yang sedang anda gunakan tidak dapat memberitahu anda sama ada perubahan tersebut berjaya atau tidak.

Mulakan semula dengan sudo systemctl restart ssh pada Debian dan Ubuntu, atau sudo systemctl restart sshd pada Rocky Linux dan AlmaLinux. Pada Ubuntu 24.04, sshd dimulakan daripada unit soket, jadi perubahan pada Port atau ListenAddress juga memerlukan sudo systemctl restart ssh.socket sebelum ia berkuat kuasa.

FAQ

Mengapa saya mendapat ralat Permission denied (publickey) sedangkan kunci yang sama berfungsi pada pelayan lain?

Kerana kunci tersebut tiada masalah, tetapi persekitarannya yang bermasalah. Jalankan ssh -v dan cari baris Offering public key. Jika kunci anda tidak disenaraikan, ssh tidak menghantarnya: fail tersebut tiada dalam ~/.ssh dengan nama lalai dan tidak dimuatkan ke dalam ejen, jadi tambahkan -i /path/to/key -o IdentitiesOnly=yes. Jika kunci disenaraikan namun pelayan masih menolak, maka kunci itu tiada dalam authorized_keys akaun tersebut, laluan ke fail itu boleh ditulis oleh kumpulan (group-writable), atau konfigurasi sshd menyekat pengguna. Log pelayan akan membezakan kes-kes tersebut.

Bagaimanakah cara untuk melihat kunci yang sebenarnya dihantar oleh SSH?

ssh -v host mencetak satu baris debug1: Offering public key: bagi setiap kunci, yang menamakan fail sumber dan fingerprint SHA256. ssh-add -l menyenaraikan fingerprint yang dipegang oleh ejen. ssh-keygen -lf ~/.ssh/id_ed25519.pub mencetak fingerprint bagi satu fail kunci, dan ssh-keygen -y -f ~/.ssh/id_ed25519 mencetak kunci awam yang terhasil daripada kunci peribadi. Untuk membolehkan log masuk berjaya, fingerprint daripada baris Offering mestilah muncul dalam ssh-keygen -lf yang dijalankan terhadap authorized_keys pelayan.

Mengapa sshd mengabaikan fail authorized_keys saya?

Kerana StrictModes diaktifkan secara lalai, dan sama ada fail tersebut, direktori .ssh, atau direktori home boleh ditulis oleh kumpulan atau orang lain (world-writable), atau dimiliki oleh akaun yang salah. sshd tidak akan mempercayai laluan yang boleh diubah oleh orang lain, jadi ia bertindak seolah-olah tiada kunci yang wujud. Tetapkan direktori home kepada 755 atau lebih ketat, .ssh kepada 700, authorized_keys kepada 600, dan pastikan kesemuanya dimiliki oleh akaun log masuk. Dengan LogLevel VERBOSE, pelayan akan merekodkan Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Kunci saya berhenti berfungsi sejurus selepas naik taraf pelayan. Apa yang berubah?

Jika ia adalah kunci RSA, ini kemungkinan besar disebabkan oleh perubahan SHA-1. OpenSSH 8.8 melumpuhkan tandatangan SHA-1 ssh-rsa secara lalai, jadi kunci yang hanya boleh menandatangani dengan cara itu kini ditolak. Output klien yang terperinci (verbose) akan menunjukkan debug1: send_pubkey_test: no mutual signature algorithm. Jana kunci moden dengan ssh-keygen -t ed25519 dan pasang fail .pub miliknya. Jika anda memerlukan akses segera, PubkeyAcceptedAlgorithms +ssh-rsa pada pelayan akan mengaktifkan semula tandatangan lama tersebut, dan anda harus membuang baris itu sebaik sahaja kunci baharu berfungsi.

Saya telah menyunting sshd_config dan kini saya tidak boleh log masuk langsung. Bagaimanakah cara untuk masuk semula?

Gunakan konsol pembekal anda yang tidak melalui SSH. Log masuk di sana menggunakan kata laluan tempatan, jalankan sudo sshd -t untuk melihat ralat sintaks dan nombor barisnya, batalkan perubahan tersebut, dan mulakan semula servis. Kemudian semak sudo sshd -T untuk mengesahkan nilai yang sedang berjalan, kerana fail dalam /etc/ssh/sshd_config.d/ mungkin mengatasi konfigurasi utama. Jika anda tiada kata laluan tempatan, tetapkan semula kata laluan root daripada konsol terlebih dahulu, kemudian baiki fail tersebut.