Cara Mengatasi SSH Connection Refused ke VPS Ubuntu

The Last Digital
Update: ... minutes read

Apa Arti "Connection Refused" Sebenarnya?

Anda menjalankan ssh user@IP-VPS dan langsung mendapat balasan:

ssh: connect to host 203.0.113.10 port 22: Connection refused

Kalimat ini sering disalahartikan sebagai "server mati" atau "internet saya bermasalah". Padahal maknanya jauh lebih spesifik — dan justru kabar baik: paket Anda sampai ke mesin tujuan, dan mesin itu aktif menjawab bahwa tidak ada layanan yang menerima koneksi di port tersebut. Dengan kata lain, host-nya bisa dijangkau, tetapi tidak ada server SSH yang mendengarkan di port 22, atau ada firewall yang secara aktif menolak koneksi itu.

Ini berbeda total dari Connection timed out, yang berarti paket Anda tidak mendapat jawaban sama sekali — server mungkin mati, alamat IP salah, atau firewall diam-diam membuang paket. Bila pesan Anda adalah "refused", jangan menghabiskan waktu memeriksa jaringan dari sisi klien; masalahnya ada di sisi server: layanan SSH, konfigurasi port, atau aturan firewall.

Ini juga berbeda dari Permission denied (publickey) atau Permission denied (password). Pesan-pesan itu berarti Anda sudah sampai ke server SSH, tetapi otentikasi Anda ditolak. Pada connection refused, Anda bahkan belum sampai ke tahap otentikasi — belum ada server SSH yang menyambut Anda.

Jawaban Singkat: Urutan Perbaikan SSH Connection Refused

Karena Anda tidak bisa masuk lewat SSH, Anda membutuhkan jalur lain ke server dulu: konsol web penyedia VPS (biasanya disebut VNC console, serial console, atau rescue console), atau akses fisik bila server ada di dekat Anda. Setelah berada di dalam server, kerjakan urutan ini:

  1. Periksa layanan SSH: sudo systemctl status ssh. Bila belum terinstal, instal dengan sudo apt install openssh-server. Bila tidak berjalan, jalankan sudo systemctl enable --now ssh.
  2. Periksa apa yang benar-benar didengarkan: sudo ss -tlnp | grep ssh. Bila kosong, SSH tidak mendengarkan sama sekali. Bila hanya 127.0.0.1:22, SSH hanya menerima koneksi lokal.
  3. Periksa konfigurasi: sudo sshd -t untuk validasi, lalu periksa nilai Port dan ListenAddress di /etc/ssh/sshd_config dan di /etc/ssh/sshd_config.d/.
  4. Periksa firewall lokal: sudo ufw status verbose. Bila UFW aktif tanpa aturan SSH, tambahkan sudo ufw allow ssh — tetapi hanya setelah memastikan Anda tidak sedang mengunci diri sendiri (lihat peringatan di bawah).
  5. Periksa firewall penyedia VPS (security group / firewall panel). Aturan di panel ini berada di luar server dan tidak terlihat dari ufw status.
  6. Uji dari luar dengan ssh -v user@IP-VPS atau ssh -p PORT user@IP-VPS bila port-nya bukan 22.

Peringatan Penting Sebelum Mengubah Firewall dari Jarak Jauh

Bila Anda masih punya satu sesi SSH yang aktif, jangan menutupnya sebelum perbaikan selesai dan teruji. Sesi yang masih hidup adalah jalan kembali Anda. Dan bila Anda hendak mengaktifkan UFW, tambahkan aturan SSH sebelum mengaktifkan firewall — dokumentasi manpage UFW secara eksplisit mengingatkan bahwa aturan bisa ditambahkan sebelum ufw enable agar port SSH sudah terbuka setelah firewall aktif, dan bahwa ufw enable akan meminta konfirmasi saat dijalankan lewat SSH karena berisiko memutus koneksi Anda.

Aturan praktisnya: tambahkan aturan, periksa status, uji koneksi baru di terminal kedua tanpa menutup terminal pertama, dan hanya setelah koneksi baru berhasil, Anda boleh menutup sesi lama. Bila Anda sudah terkunci total dan tidak punya sesi aktif, satu-satunya jalan adalah konsol web penyedia VPS — bukan mengulang perintah SSH yang sama dengan harapan berbeda.

Tabel Diagnosis: Dari Pesan ke Penyebab

GejalaArtiPemeriksaan pertama di server
Connection refused, langsung (tanpa jeda)Host hidup, tidak ada yang mendengarkan di port itu, atau firewall REJECTsystemctl status ssh dan ss -tlnp
Connection timed out (lama, lalu gagal)Paket dibuang diam-diam atau host tidak terjangkau — BUKAN topik artikel iniPeriksa IP, status VPS di panel penyedia, dan firewall DROP
Permission denied (publickey/password)SSH berjalan, otentikasi ditolak — BUKAN connection refusedPeriksa authorized_keys, izin berkas, dan pengaturan otentikasi
Bisa SSH dari satu jaringan, tidak dari jaringan lainAturan firewall berbasis sumber atau fail2banufw status, aturan panel penyedia, dan status fail2ban
Refused setelah mengubah sshd_configKonfigurasi salah sehingga sshd gagal startsshd -t dan journalctl -u ssh
Refused setelah instalasi baru Ubuntuopenssh-server belum terinstal (Ubuntu Server minimal tidak selalu menyertakannya)apt policy openssh-server, lalu instal
Refused setelah upgrade ke Ubuntu 24.04Aktivasi soket (socket activation) — layanan dikelola lewat ssh.socketsystemctl status ssh.socket ssh.service

Persiapan: Apa yang Anda Butuhkan

  • Akses konsol penyedia VPS. Ini syarat utama bila SSH sudah tidak bisa dipakai sama sekali. Cari di panel penyedia Anda dengan nama seperti Console, VNC, atau Emergency Console. Tanpa ini, Anda tidak bisa memperbaiki server yang menolak semua koneksi SSH.
  • Akses sudo di server. Semua perintah perbaikan memakai sudo.
  • Informasi yang benar: alamat IP VPS, nama pengguna yang benar, dan port SSH bila pernah diubah dari 22. Menebak port atau pengguna hanya menambah putaran gagal.
  • Catatan perubahan terakhir. Apa yang terakhir diubah sebelum SSH menolak? Instalasi baru, perubahan sshd_config, pengaktifan firewall, atau upgrade Ubuntu? Jawabannya mempersempit pencarian secara drastis.

Langkah 1: Pastikan OpenSSH Server Terinstal dan Berjalan

Menurut dokumentasi Ubuntu Server, paket server OpenSSH diinstal dengan perintah berikut, dan daemon-nya bernama sshd:

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh

Bila status menunjukkan active (running), lanjut ke Langkah 2. Bila tidak berjalan, jalankan dan aktifkan agar otomatis jalan setelah reboot:

sudo systemctl enable --now ssh
sudo systemctl status ssh

Bila layanan gagal start, jangan langsung menginstal ulang. Baca log-nya dulu (Langkah 4) — instal ulang jarang memperbaiki konfigurasi yang salah dan sering menghapus penyesuaian yang sudah ada.

Catatan untuk Ubuntu 24.04 dan yang lebih baru: SSH di Ubuntu modern dapat memakai socket activation, di mana ssh.socket yang mendengarkan dan membangunkan layanan saat ada koneksi. Bila ssh.service tampak tidak aktif tetapi ssh.socket aktif dan mendengarkan, itu bisa jadi kondisi normal, bukan kerusakan. Periksa keduanya:

sudo systemctl status ssh.socket ssh.service
sudo ss -tlnp | grep -E 'ssh|22'

Langkah 2: Periksa Apa yang Benar-Benar Didengarkan

sudo ss -tlnp | grep ssh

Tiga hasil yang mungkin, dan artinya:

  • Tidak ada baris sama sekali. SSH tidak mendengarkan. Kembali ke Langkah 1 dan log (Langkah 4) — layanan tidak jalan atau gagal start.
  • 0.0.0.0:22 atau [::]:22. SSH mendengarkan di semua antarmuka pada port 22. Bila dari luar tetap refused, penyebabnya hampir pasti firewall (Langkah 5), bukan SSH.
  • 127.0.0.1:22 saja. SSH hanya menerima koneksi dari dalam server itu sendiri. Ini terjadi bila ListenAddress dikunci ke localhost. Perbaiki di konfigurasi (Langkah 3).
  • Port lain, misalnya 0.0.0.0:2222. SSH berjalan, tetapi bukan di port 22. Sambungkan dengan ssh -p 2222 user@IP-VPS dan perbarui catatan Anda — ini bukan kerusakan, ini konfigurasi.

Langkah 3: Periksa dan Validasi Konfigurasi SSH

Dokumentasi Ubuntu Server menegaskan dua hal penting: konfigurasi utama ada di /etc/ssh/sshd_config, tetapi Ubuntu juga memakai cuplikan di /etc/ssh/sshd_config.d/, dan karena OpenSSH memakai nilai pertama yang ditetapkan untuk sebagian besar direktif, pengaturan di sshd_config.d dapat mengalahkan pengaturan di berkas utama. Jadi jangan hanya memeriksa satu berkas.

Pertama, validasi konfigurasi sebelum me-restart — dokumentasi Ubuntu secara eksplisit mengingatkan untuk memeriksa konfigurasi setelah mengubahnya dan sebelum me-restart server, karena kehilangan server SSH bisa berarti kehilangan jalan masuk ke server:

sudo sshd -t

Bila sshd -t tidak mengeluarkan apa-apa, konfigurasi valid. Bila mengeluarkan pesan error, pesan itu menunjuk baris yang salah — perbaiki baris itu, bukan menebak.

Lalu periksa nilai yang menentukan port dan alamat dengar, termasuk nilai efektifnya:

sudo grep -R "^Port\|^ListenAddress" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
sudo sshd -T | grep -E '^(port|listenaddress)'

Perintah sshd -T menampilkan konfigurasi efektif setelah semua cuplikan digabung — inilah nilai yang benar-benar dipakai server, bukan sekadar yang tertulis di satu berkas. Bila nilai efektif berbeda dari yang Anda kira, cari cuplikan di sshd_config.d/ yang menetapkannya lebih dulu.

Bila Anda mengubah konfigurasi, buat cadangan dulu, ubah, validasi, baru restart:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl restart ssh

Untuk Ubuntu dengan socket activation, restart soketnya bila perubahan tidak berefek setelah restart layanan biasa:

sudo systemctl restart ssh.socket

Langkah 4: Baca Log Bila SSH Gagal Start

sudo journalctl -u ssh --no-pager -n 100
sudo tail -n 100 /var/log/auth.log | grep sshd

Pola log yang memberi petunjuk langsung:

  • "Address already in use" / "Bind to port 22 failed". Port sudah dipakai proses lain. Cari dengan sudo ss -tlnp | grep :22 dan tentukan proses apa itu sebelum mematikan apa pun.
  • "Missing privilege separation directory". Direktori /run/sshd hilang. Ini bisa terjadi setelah pembersihan direktori sementara. Perbaiki dengan membuat direktori itu dan me-restart layanan, sesuai kebutuhan sistem Anda.
  • "Bad configuration option" / error pada baris tertentu. Kesalahan ketik di sshd_config. Kembalikan dari .bak atau perbaiki baris tersebut.
  • Tidak ada log sshd sama sekali. Layanan mungkin belum pernah terinstal atau unit-nya bernama berbeda. Verifikasi instalasi paket dan nama unit di sistem Anda.

Langkah 5: Periksa Firewall Lokal (UFW)

sudo ufw status verbose

Bila hasilnya Status: inactive, UFW bukan penyebabnya — lanjut ke Langkah 6. Bila aktif, periksa apakah ada aturan yang mengizinkan SSH. Menurut dokumentasi UFW Ubuntu, aturan bisa dibuat berdasarkan nama layanan:

sudo ufw allow ssh

Perintah ini setara dengan mengizinkan port 22/tcp melalui profil aplikasi OpenSSH. Bila SSH Anda memakai port kustom, izinkan port itu secara eksplisit:

sudo ufw allow 2222/tcp

Ganti 2222 dengan port SSH Anda yang sebenarnya. Setelah menambah aturan, periksa status lagi dan uji koneksi baru dari terminal kedua tanpa menutup sesi yang masih aktif.

Perbedaan penting: aturan REJECT membuat koneksi ditolak langsung (pesan refused), sedangkan aturan DROP membuat paket dibuang diam-diam (pesan timed out). Jadi bila pesan Anda adalah refused dan firewall lokal aktif, carilah aturan REJECT; bila pesan Anda timed out, carilah aturan DROP atau firewall panel penyedia. Jangan mengaktifkan UFW dari jarak jauh tanpa aturan SSH yang sudah ditambahkan terlebih dahulu.

Langkah 6: Periksa Firewall Penyedia VPS

Ini adalah penyebab yang paling sering terlewat, karena tidak terlihat dari dalam server. Penyedia VPS umumnya punya firewall di panel kontrol (sering disebut Security Group, Firewall, atau Cloud Firewall) yang berdiri di depan VPS Anda. Bila panel ini hanya mengizinkan port 80 dan 443, atau tidak mengizinkan port 22 sama sekali, maka tidak peduli seberapa benar konfigurasi SSH dan UFW di dalam server — koneksi dari luar tetap ditolak atau dibuang sebelum sampai ke server.

Langkahnya: buka panel penyedia VPS, cari pengaturan firewall/security group yang terpasang pada VPS Anda, pastikan ada aturan inbound yang mengizinkan TCP port 22 (atau port SSH kustom Anda) dari sumber yang sesuai. Untuk keamanan, batasi sumber ke IP Anda bila memungkinkan, daripada membuka ke semua alamat. Setelah mengubah aturan panel, uji lagi dari luar — perubahan panel biasanya berlaku tanpa restart server.

Langkah 7: Periksa Pemblokiran Lain (fail2ban dan TCP Wrapper)

Bila SSH berjalan, port benar, dan firewall sudah mengizinkan, tetapi koneksi dari IP Anda saja yang ditolak, periksa pemblokiran otomatis:

sudo fail2ban-client status sshd

Bila IP Anda ada di daftar banned karena terlalu banyak percobaan login gagal, lepaskan blokirnya dari konsol server:

sudo fail2ban-client set sshd unbanip ALAMAT_IP_ANDA

Ganti ALAMAT_IP_ANDA dengan IP publik Anda yang sebenarnya. Jangan menonaktifkan fail2ban secara permanen hanya karena satu blokir — ia melindungi server dari serangan brute force, dan menonaktifkannya membuka risiko yang lebih besar daripada masalah yang diselesaikannya.

Pada konfigurasi lama, TCP wrapper di /etc/hosts.allow dan /etc/hosts.deny juga bisa memblokir. Periksa kedua berkas itu bila semua langkah di atas sudah bersih tetapi masalah berlanjut.

Verifikasi: Bagaimana Tahu Masalah Sudah Beres?

  1. Dari luar server, ssh -v user@IP-VPS mencapai tahap otentikasi (meminta password atau menawarkan kunci) — bukan refused. Mencapai tahap otentikasi berarti koneksi TCP dan server SSH sudah berfungsi; masalah otentikasi setelah itu adalah topik terpisah.
  2. Bila port kustom, ssh -p PORT user@IP-VPS berhasil mencapai tahap yang sama.
  3. sudo systemctl status ssh (dan ssh.socket bila memakai socket activation) menunjukkan layanan aktif, dan ss -tlnp menunjukkan SSH mendengarkan di alamat dan port yang benar.
  4. Setelah reboot VPS, ulangi pengujian dari luar. SSH yang hanya bertahan sampai reboot berikutnya belum benar-benar diperbaiki — pastikan layanan di-enable, bukan hanya di-start sekali.
  5. Uji dari jaringan yang berbeda bila memungkinkan, untuk memastikan bukan aturan berbasis sumber yang menyembunyikan masalah.

Troubleshooting Lanjutan

Gejala setelah perbaikanPenyebab yang mungkinYang dilakukan
Refused tetap, padahal ss menunjukkan 0.0.0.0:22Firewall panel penyedia belum mengizinkan port SSHPerbaiki aturan di panel penyedia, bukan di server
Berhasil dari konsol, gagal dari laptopAturan berbasis sumber, fail2ban, atau IP laptop berubahPeriksa fail2ban dan aturan sumber; unban bila perlu
Refused setelah restart, padahal tadi berhasilLayanan tidak di-enable, hanya di-start manualsystemctl enable ssh (dan ssh.socket bila relevan)
sshd -t lolos, tapi layanan tetap gagal startKonflik port, direktori privilege separation hilang, atau unit soket bermasalahBaca journalctl; periksa proses pemakai port dan /run/sshd
Perubahan sshd_config tidak berefekNilai di sshd_config.d mengalahkan berkas utama, atau soket belum di-restartPeriksa sshd -T (nilai efektif) dan restart ssh.socket
Semua bersih, tapi tetap refused dari semua jaringanVPS belum sepenuhnya boot, atau alamat IP salah / VPS sudah dihapusPeriksa status VPS di panel penyedia dan alamat IP yang benar

FAQ

Apakah connection refused berarti VPS saya mati?

Tidak. Justru sebaliknya: refused berarti mesin menjawab. Mesin yang mati atau tidak terjangkau akan menghasilkan timed out, bukan refused. Refused menunjukkan tidak ada layanan di port itu atau ada penolakan aktif.

Saya tidak bisa SSH sama sekali — bagaimana cara memperbaiki SSH?

Pakai konsol web penyedia VPS. Itulah jalur yang dirancang untuk situasi ini: akses terminal lewat panel penyedia tanpa melewati SSH. Setelah masuk lewat konsol, ikuti langkah-langkah di artikel ini.

Apakah menginstal ulang openssh-server akan memperbaiki semuanya?

Belum tentu. Instal ulang hanya membantu bila paketnya rusak atau hilang. Bila penyebabnya konfigurasi salah atau firewall, instal ulang tidak mengubah apa pun — bahkan bisa menimpa penyesuaian konfigurasi Anda. Diagnosis dulu, instal ulang terakhir.

Kenapa saya harus memeriksa sshd_config.d, bukan hanya sshd_config?

Karena Ubuntu menyertakan direktif Include di bagian atas sshd_config, dan OpenSSH memakai nilai pertama untuk sebagian besar direktif. Pengaturan di cuplikan sshd_config.d bisa mengalahkan pengaturan di berkas utama tanpa Anda sadari.

Apakah aman membuka port 22 ke semua alamat di firewall panel?

Berfungsi, tetapi bukan praktik terbaik. Bila memungkinkan, batasi ke IP Anda, pakai kunci SSH, dan pertimbangkan fail2ban tetap aktif. Membuka ke semua alamat memperbesar permukaan serangan brute force.

Setelah SSH kembali, apakah saya perlu mengubah port ke non-standar?

Tidak wajib. Port non-standar mengurangi kebisingan log dari pemindai otomatis, tetapi bukan pengganti kunci SSH, firewall yang benar, dan fail2ban. Jangan mengandalkan kerahasiaan port sebagai satu-satunya pertahanan.

Kesimpulan

SSH connection refused adalah pesan yang informatif, bukan vonis. Ia memberi tahu Anda bahwa mesin hidup dan bisa dijangkau, tetapi tidak ada server SSH yang menerima di port yang Anda tuju. Masuklah lewat konsol penyedia VPS, lalu kerjakan urutan yang benar: pastikan openssh-server terinstal dan berjalan, pastikan ia mendengarkan di alamat dan port yang benar, validasi konfigurasi dengan sshd -t dan periksa nilai efektifnya, lalu periksa dua lapis firewall — UFW di dalam server dan firewall panel penyedia di luar server. Uji dari terminal kedua tanpa menutup sesi yang masih aktif, dan pastikan layanan di-enable agar bertahan setelah reboot. Bila Anda mencapai tahap otentikasi, masalah connection refused sudah selesai — apa pun yang terjadi setelah itu adalah urusan otentikasi, bukan koneksi.

Tags:

Related Posts

Memuat…
Cookie Consent