SSD Nodes Learn 🎉 VPS mulai $5.50/bln
Panduan Matt ConnorOleh Matt Connor · Diperbarui 2026-08-13

Cara Mengatasi SSH Permission denied (publickey)

Pesan "Permission denied (publickey)" mencakup lima penyebab. Baca output ssh -v untuk menemukan masalah yang tepat tanpa terkunci dari server.

Arti sebenarnya dari Permission denied (publickey)

Permission denied (publickey) berarti klien Anda mengirimkan satu atau beberapa public key, tetapi server tidak menerima satu pun. Jaringan berfungsi dan sshd sedang berjalan. Penolakan terjadi pada tahap terakhir autentikasi. Perbaikannya tidak perlu dilakukan berdasarkan perkiraan, karena ssh -v memberi tahu Anda penyebabnya dari lima kemungkinan yang ada.

Teks di dalam tanda kurung menunjukkan metode autentikasi yang bersedia diterima server. Permission denied (publickey) saja berarti login dengan kata sandi dinonaktifkan pada server tersebut, sehingga tidak ada kata sandi yang dapat digunakan sebagai alternatif. Permission denied (publickey,password) berarti kata sandi tersedia sebagai opsi, tetapi Anda juga gagal menggunakannya.

Satu pesan mencakup lima masalah yang berbeda dan sengaja dibuat umum. Server yang membalas "pengguna tidak ditemukan" atau "key tersebut tidak terpasang" akan membantu siapa pun yang mencari akun yang valid. Jadi, jangan langsung mengganti key dan mengedit file konfigurasi. Jalankan satu perintah, baca tiga baris output, dan lima kemungkinan penyebab akan menyempit menjadi satu.

Jalankan ssh -v terlebih dahulu, lalu baca tiga baris

Ulangi perintah yang gagal dengan menambahkan -v:

ssh -v deploy@203.0.113.10

Hasil yang dipersingkat tetapi realistis terlihat seperti ini:

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 tersebut memuat semua informasi yang Anda perlukan.

Authenticating to 203.0.113.10:22 as 'deploy' adalah nama pengguna yang benar-benar akan digunakan. Bukan nama pengguna yang Anda maksud, melainkan nama pengguna yang ditentukan ssh dari baris perintah, dari ~/.ssh/config, atau dari nama login lokal Anda.

Authentications that can continue: publickey adalah daftar metode yang diterima server, yang dikirim sebelum kunci apa pun dicoba. Jika publickey tidak ada dalam daftar pertama tersebut, server menonaktifkan login dengan kunci publik sehingga tidak ada kunci yang dapat digunakan.

Offering public key: ... adalah satu baris untuk setiap kunci yang benar-benar dikirim oleh klien Anda. Baris ini mencantumkan file asal kunci dan sidik jari SHA256-nya. Kunci yang tidak memiliki baris Offering tidak pernah dikirim ke server.

Sekarang, pisahkan masalahnya menjadi dua:

  • Tidak ada baris Offering public key untuk kunci yang Anda harapkan. Masalahnya ada pada komputer Anda karena server sama sekali belum menerima kunci Anda.
  • Kunci ditawarkan dan Authentications that can continue: publickey muncul lagi. Server menerima kunci tersebut, tetapi menolaknya. Jadi, masalahnya ada pada server.

Penyebab di bawah ini diurutkan berdasarkan seberapa sering terbukti menjadi jawabannya.

Penyebab 1: Anda terhubung menggunakan username yang salah

Penyebab yang paling umum juga merupakan penyebab yang paling sederhana. sshd, daemon server SSH (secure shell), tidak pernah memberi tahu bahwa suatu akun tidak ada. sshd menjalankan seluruh pertukaran koneksi menggunakan username yang dibuat-buat, lalu menolaknya pada tahap akhir dengan pesan yang sama. Hal ini dilakukan karena membocorkan nama akun yang valid dapat membantu penyerang. Typo pada username terlihat sama persis seperti kunci yang rusak.

Periksa baris Authenticating to ... as terlebih dahulu. Jika baris tersebut mencantumkan login laptop Anda, bukan akun pada server, berarti username tidak dicantumkan dalam perintah.

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

Akun default bergantung pada image yang dibuat oleh provider Anda. Per Agustus 2026, image cloud Ubuntu biasanya menyediakan akun ubuntu, image Debian menyediakan debian atau admin, Rocky Linux dan AlmaLinux menyediakan rocky dan almalinux, sedangkan banyak provider VPS langsung memasang kunci Anda ke dalam root. Panel kontrol provider mencatat akun yang dibuatnya. Tidak ada perintah yang dijalankan dari luar server yang dapat menanyakannya.

Blok Host dalam ~/.ssh/config juga menetapkan username, dan pengaturan ini mengesampingkan nama login lokal Anda:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Jika Anda membuat akun sendiri lalu tidak dapat login menggunakan akun tersebut, kemungkinan kunci dipasang untuk user default image dan tidak pernah disalin ke akun baru. Langkah tersebut merupakan bagian dari sepuluh menit pertama pada VPS baru, dan mudah terlewat.

Penyebab 2: key yang Anda kira dikirim bukan key yang sebenarnya dikirim

Secara default, ssh hanya menawarkan key yang disimpan oleh ssh-agent serta sekumpulan nama file tetap di ~/.ssh: id_ed25519, id_ecdsa, id_rsa, dan varian hardware serta DSA dari nama-nama tersebut. Key yang disimpan sebagai ~/.ssh/vps-prod tidak terlihat oleh ssh sampai Anda menentukannya secara eksplisit. Karena itu, output verbose tidak menampilkan baris Offering public key untuk key tersebut.

Tentukan nama file tersebut, lalu cegah key dari agent menggantikannya:

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

-i saja tidak cukup jika agent menyimpan key, karena ssh tetap menawarkan key milik agent terlebih dahulu dan file yang ditentukan terakhir. Hal ini penting karena server menghitung setiap key yang ditolak terhadap MaxAuthTries, yang secara default bernilai 6. Agent yang menyimpan tujuh key dapat menghabiskan batas tersebut sebelum key yang benar dicoba. Pesannya kemudian berubah menjadi:

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

IdentitiesOnly=yes membatasi percobaan hanya pada file yang Anda berikan. Tampilkan key yang disimpan agent dengan ssh-add -l, lalu hapus key tersebut dengan ssh-add -D jika agent telah mengumpulkan key lama selama bertahun-tahun. Setelah itu, simpan pengaturan tersebut agar login berikutnya tidak bergantung pada ingatan Anda terhadap flag:

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

Ada satu jebakan lain di sisi client. ssh menolak menggunakan private key yang dapat dibaca oleh account lain pada mesin Anda sendiri. ssh menampilkan peringatan, lalu mengabaikan key tersebut. Akibatnya, key tidak pernah ditawarkan dan server tidak pernah menerimanya:

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

chmod 600 ~/.ssh/vps-prod memperbaikinya. Memindahkan key melalui USB flash drive atau Windows share biasanya menyebabkan mode file berubah. Penjelasan tentang lokasi penyimpanan key dan penamaannya tersedia di Dasar-dasar pengelolaan key SSH.

Penyebab 3: kunci publik tidak pernah masuk ke authorized_keys

Jika ssh -v menunjukkan bahwa kunci dikirim, tetapi server masih menolak koneksi, pertanyaan berikutnya adalah apakah kunci tersebut berada di file authorized_keys milik akun. Buka konsol dari provider Anda untuk memeriksanya karena Anda tidak dapat login melalui SSH untuk melihatnya.

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

ssh-keygen -lf pada file authorized_keys menampilkan satu fingerprint untuk setiap entri:

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

Bandingkan fingerprint tersebut dengan fingerprint pada baris Offering public key Anda. Jika tidak ada dalam daftar, kunci tersebut belum terpasang pada akun itu, terlepas dari apa pun yang Anda ingat telah dilakukan.

Berikut empat penyebab yang umum:

  • Anda menempelkan private key, bukan file .pub. Baris public key diawali dengan ssh-ed25519 atau ssh-rsa. Private key diawali dengan -----BEGIN OPENSSH PRIVATE KEY-----.
  • Teks yang ditempel terbungkus menjadi beberapa baris. Setiap entri harus berada tepat pada satu baris. Kunci yang terbungkus akan dibaca sebagai beberapa entri rusak dan tidak akan cocok dengan apa pun.
  • Kunci dimasukkan ke /root/.ssh/authorized_keys, sementara Anda login sebagai deploy, atau sebaliknya. File tersebut berlaku untuk setiap akun secara terpisah. Tidak ada file bersama.
  • Kotak "add my key" milik provider menulis kunci hanya ke user default pada image. Akibatnya, akun yang Anda buat kemudian memiliki direktori .ssh yang kosong.

Cara aman untuk menambahkan kunci dari 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 kembali setelah itu. Fingerprint baru seharusnya sudah ada dalam daftar. Dari mesin yang masih dapat login menggunakan password, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 melakukan hal yang sama dan mengatur mode file dengan benar untuk Anda.

Penyebab 4: sshd mengabaikan authorized_keys ketika izin terlalu terbuka

StrictModes yes adalah default sshd. Dalam mode ini, sshd menolak membaca authorized_keys jika file tersebut, direktori .ssh, atau direktori home akun dapat ditulisi oleh siapa pun selain pemiliknya. Alasannya jelas: jika grup atau pengguna lain dapat menulis ke direktori home Anda, akun mana pun yang memiliki akses tersebut dapat mengganti authorized_keys dan mengambil alih login. sshd memperlakukan path yang tidak tepercaya seolah-olah tidak ada key.

Client hanya menerima pesan Permission denied. Log server mencatat alasan sebenarnya:

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

atau, jika masalahnya terdapat pada file itu sendiri:

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

Yang akan diterima sshd:

  • Direktori home: tidak dapat ditulisi oleh grup dan tidak dapat ditulisi oleh pengguna lain. 755, 750, dan 700 diterima. 775 dan 777 ditolak.
  • ~/.ssh: mode 700.
  • ~/.ssh/authorized_keys: mode 600.
  • Kepemilikan: ketiganya dimiliki oleh akun yang Anda gunakan untuk login, bukan oleh root.

Kepemilikan sama pentingnya dengan mode. File di dalam /home/deploy/.ssh yang dimiliki oleh root akan gagal dalam pemeriksaan yang sama. Kondisi ini terjadi ketika Anda membuatnya dengan sudo nano lalu lupa mengembalikan kepemilikannya. Perbaiki keduanya sekaligus:

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 menampilkan hasilnya. Direktori home harus memiliki drwxr-xr-x atau izin yang lebih ketat, serta drwx------ pada .ssh. Jika format tersebut belum jelas, baca cara membaca string izin seperti drwxr-xr-x sebelum mengubah mode pada server aktif.

Pada Rocky Linux dan AlmaLinux, tambahkan SELinux (security-enhanced Linux) ke dalam daftar pemeriksaan. Direktori .ssh yang dibuat melalui cara yang tidak biasa dapat memiliki label file yang salah. Akibatnya, sshd ditolak saat membaca file tersebut meskipun modenya sudah benar. sudo restorecon -Rv /home/deploy/.ssh mengembalikan label, dan sudo ausearch -m avc -ts recent menunjukkan apakah SELinux yang menolak akses tersebut.

Penyebab 5: sshd dikonfigurasi untuk menolak koneksi Anda

Membaca /etc/ssh/sshd_config saja tidak cukup pada sistem Ubuntu atau Debian saat ini. File tersebut diawali dengan Include /etc/ssh/sshd_config.d/*.conf, dan OpenSSH menggunakan nilai pertama yang ditemukannya untuk setiap pengaturan. Karena itu, file drop-in seperti 50-cloud-init.conf dibaca lebih dahulu dan mengalahkan pengaturan apa pun yang Anda ubah di bagian bawah file utama. Inilah sebabnya perubahan dapat terlihat benar, tetapi sama sekali tidak mengubah hasil.

Minta sshd menampilkan konfigurasi yang benar-benar digunakannya:

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

Hasil yang sehat terlihat seperti ini:

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

Periksa hal-hal berikut pada output Anda:

  • pubkeyauthentication no. Tidak ada key yang akan pernah diterima. Ini juga muncul dalam ssh -v sebagai daftar Authentications that can continue: pertama tanpa publickey di dalamnya.
  • authorizedkeysfile mengarah ke lokasi lain, misalnya /etc/ssh/authorized_keys/%u. File Anda di direktori home kemudian diabaikan sepenuhnya, dan aturan mode dari penyebab 4 berlaku pada path baru tersebut.
  • allowusers atau allowgroups ada. Akun apa pun yang tidak tercantum akan ditolak dengan error ini tanpa penjelasan. denyusers dan denygroups melakukan hal yang sama secara terbalik.
  • permitrootlogin no saat Anda mencoba login sebagai root. prohibit-password adalah pengaturan tengah yang sesuai: root dapat menggunakan key, tetapi tidak dapat menggunakan password.

Blok Match tidak muncul dalam sshd -T biasa karena hasilnya bergantung pada pihak yang melakukan koneksi. Tanyakan konfigurasi untuk satu koneksi tertentu:

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

Ada satu pengaturan lain yang memengaruhi key lama. OpenSSH 8.8 berhenti menerima tanda tangan SHA-1 (ssh-rsa) secara default. Akibatnya, RSA key yang telah berfungsi selama bertahun-tahun dapat berhenti berfungsi segera setelah server di-upgrade. Client menyatakan penyebabnya dengan jelas:

debug1: send_pubkey_test: no mutual signature algorithm

Perbaikan yang benar adalah membuat key baru: ssh-keygen -t ed25519 -C "deploy@vps-prod", lalu memasang file .pub seperti yang ditunjukkan di atas. Mengatur PubkeyAcceptedAlgorithms +ssh-rsa pada server akan mengaktifkan kembali tanda tangan lama dan memungkinkan Anda masuk hari ini. Namun, perlakukan langkah ini hanya sebagai cara untuk mengakses server, bukan sebagai penyelesaian akhir. Pengaturan sisi server lain yang perlu ditinjau tersedia dalam melakukan hardening SSH server pada VPS.

Cara membuktikan bahwa private key cocok dengan public key yang terpasang

Sebagian besar kebingungan dalam error ini terjadi karena tidak diketahui apakah dua file merupakan pasangan. Satu perintah dapat memastikannya:

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

Perintah tersebut mencetak public key yang diturunkan dari private key. Perintah ini tidak pernah membaca file .pub di sebelahnya. Jadi, hasilnya menunjukkan isi private key yang sebenarnya, bukan isi yang diklaim oleh file .pub yang sudah usang. Jika key memiliki passphrase, perintah tersebut akan memintanya. Ini juga membuktikan bahwa Anda masih mengetahui passphrase tersebut.

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

Perintah pertama mencetak fingerprint dari satu file public key. Perintah kedua mencetak fingerprint yang disimpan oleh agent Anda. Selanjutnya, bandingkan empat tampilan dari string yang sama: fingerprint pada baris Offering public key dari ssh -v, fingerprint file .pub Anda, fingerprint dalam ssh-keygen -lf pada authorized_keys milik server, dan fingerprint dalam log server. Titik saat nilai-nilai tersebut berhenti cocok menunjukkan sumber kesalahan Anda.

Baca log server saat login gagal

Klien sengaja tidak diberi informasi yang berguna. Server mencatat alasan sebenarnya. Jalankan pemantau log pada sesi konsol, lalu jalankan perintah ssh yang gagal dari laptop Anda.

sudo journalctl -u ssh -f

Ubuntu 24.04 tidak memasang rsyslog secara default, sehingga /var/log/auth.log mungkin tidak tersedia di sana. Pada Rocky Linux dan AlmaLinux, unitnya bernama sshd dan catatan yang sama juga ditulis ke /var/log/secure.

Atur LogLevel VERBOSE dalam konfigurasi sshd, lalu muat ulang service. Setiap percobaan kemudian mencatat fingerprint yang benar-benar diterima server:

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

Baris tersebut menunjukkan pihak yang bermasalah. Fingerprint yang Anda kenali berarti key Anda sampai ke server, tetapi ditolak oleh server. Periksa penyebab 3, 4, dan 5. Fingerprint yang tidak Anda kenali berarti klien mengirim key yang tidak Anda maksudkan. Kembali ke penyebab 2.

Jika log masih belum jelas, jalankan sshd kedua pada port lain dalam mode debug. Proses ini berjalan di foreground, melayani satu koneksi, menampilkan alasan keputusannya, lalu keluar:

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

Dari sesi konsol pada server yang sama, sambungkan ke proses tersebut melalui alamat loopback:

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

Koneksi melalui 127.0.0.1 mengeluarkan firewall dari pengujian. Output debug menampilkan file yang dibuka, fingerprint yang dibandingkan, dan penolakan secara tepat, termasuk baris seperti Authentication refused: bad ownership or modes for directory /home/deploy. Tekan Ctrl+C setelah Anda memperoleh jawabannya. sshd utama pada port 22 tidak terpengaruh selama proses ini.

Cara menghindari kehilangan akses

Setiap langkah yang mengubah konfigurasi server harus memiliki cara untuk mendapatkan kembali akses tanpa bergantung pada SSH. Siapkan akses ini saat SSH masih berfungsi, bukan setelah SSH bermasalah.

  1. Buka konsol dari provider Anda melalui serial atau VNC (virtual network computing), lalu pastikan Anda dapat login melalui konsol tersebut.
  2. Pastikan Anda mengetahui kata sandi lokal yang valid untuk akun dengan akses sudo. Jika belum memilikinya, reset kata sandi root dari konsol provider terlebih dahulu.
  3. Biarkan sesi SSH saat ini tetap terbuka. Sesi yang terbuka tetap bertahan setelah systemctl restart ssh, sehingga sesi tersebut dapat menjadi cara untuk mendapatkan kembali akses jika konfigurasi baru salah.
  4. Periksa sintaks sebelum melakukan restart: sudo sshd -t tidak menampilkan apa pun jika file valid, dan menampilkan nama file serta nomor baris jika file tidak valid.
  5. Buka terminal kedua dan lakukan login baru sebelum menutup terminal pertama. Konfigurasi yang rusak menghentikan login baru, tetapi tidak mengganggu sesi yang sudah ada. Karena itu, sesi yang sedang Anda gunakan tidak dapat memastikan apakah perubahan berhasil.

Lakukan restart dengan sudo systemctl restart ssh pada Debian dan Ubuntu, atau dengan sudo systemctl restart sshd pada Rocky Linux dan AlmaLinux. Pada Ubuntu 24.04, sshd dimulai dari unit socket. Karena itu, perubahan pada Port atau ListenAddress juga memerlukan sudo systemctl restart ssh.socket sebelum perubahan tersebut berlaku.

FAQ

Mengapa saya mendapatkan Permission denied (publickey) padahal key yang sama berfungsi di server lain?

Karena key tersebut tidak bermasalah, tetapi ada masalah pada bagian lain. Jalankan ssh -v dan cari baris Offering public key. Jika key Anda tidak tercantum, ssh tidak pernah mengirimkannya: file tersebut tidak berada di ~/.ssh dengan nama default dan tidak dimuat oleh agent, jadi tambahkan -i /path/to/key -o IdentitiesOnly=yes. Jika key tercantum tetapi server tetap menolaknya, berarti key tersebut tidak ada di authorized_keys milik akun, path menuju file tersebut dapat ditulis oleh group, atau konfigurasi sshd memblokir pengguna. Log server membedakan kasus-kasus tersebut.

Bagaimana cara melihat key yang benar-benar dikirim SSH?

ssh -v host menampilkan satu baris debug1: Offering public key: untuk setiap key. Setiap baris menyebutkan file sumber dan fingerprint SHA256. ssh-add -l mencantumkan fingerprint yang disimpan agent. ssh-keygen -lf ~/.ssh/id_ed25519.pub menampilkan fingerprint dari satu file key, sedangkan ssh-keygen -y -f ~/.ssh/id_ed25519 menampilkan public key yang benar-benar diturunkan dari private key. Agar login berhasil, fingerprint dari baris Offering juga harus muncul dalam ssh-keygen -lf yang dijalankan terhadap authorized_keys milik server.

Mengapa sshd mengabaikan file authorized_keys saya?

Karena StrictModes aktif secara default, dan file tersebut, direktori .ssh, atau home directory dapat ditulis oleh group atau world, atau dimiliki oleh akun yang salah. sshd tidak akan mempercayai path yang dapat diubah oleh pihak lain, sehingga bertindak seolah-olah tidak ada key. Atur home directory ke 755 atau lebih ketat, .ssh ke 700, authorized_keys ke 600, dan pastikan ketiganya dimiliki oleh akun login. Dengan LogLevel VERBOSE, server mencatat Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Key saya berhenti berfungsi tepat setelah upgrade server. Apa yang berubah?

Jika key tersebut adalah key RSA, kemungkinan besar penyebabnya adalah perubahan SHA-1. OpenSSH 8.8 menonaktifkan signature ssh-rsa SHA-1 secara default, sehingga key yang hanya dapat membuat signature dengan cara tersebut kini ditolak. Output client verbose menampilkan debug1: send_pubkey_test: no mutual signature algorithm. Buat key modern dengan ssh-keygen -t ed25519 dan pasang file .pub-nya. Jika Anda perlu segera mendapatkan akses, PubkeyAcceptedAlgorithms +ssh-rsa di server akan mengaktifkan kembali signature lama. Hapus baris tersebut setelah key baru berfungsi.

Saya mengedit sshd_config dan sekarang sama sekali tidak dapat login. Bagaimana cara mendapatkan kembali akses?

Gunakan console dari provider Anda. Console tersebut tidak melalui SSH. Login di sana menggunakan password lokal, jalankan sudo sshd -t untuk melihat error sintaks dan nomor barisnya, batalkan perubahan, lalu restart service. Kemudian periksa sudo sshd -T untuk memastikan nilai yang sedang berjalan, karena file di /etc/ssh/sshd_config.d/ mungkin menimpa konfigurasi utama. Jika Anda tidak memiliki password lokal, reset password root dari console terlebih dahulu, lalu perbaiki file tersebut.

#ssh#openssh#troubleshooting#permissions#vps