SSH: Bedanya Connection Refused dan Timed Out

Arti "Connection refused" dan "Connection timed out" pada SSH

Koneksi SSH yang ditolak dan koneksi SSH yang mengalami timeout adalah dua kegagalan yang berlawanan. Solusi untuk salah satunya tidak pernah menjadi solusi untuk yang lain. Refused berarti paket Anda mencapai server, lalu kernel server menjawab bahwa tidak ada layanan yang sedang listening di sini. Timed out berarti paket Anda tidak mencapai pihak mana pun yang akan menjawab, sehingga client menunggu lalu berhenti. Refused adalah masalah service pada server. Timed out adalah masalah jalur jaringan sebelum mencapai server.

Baca baris persis yang ditampilkan client, karena kata-kata tersebut merupakan diagnosis utamanya.

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

Waktu respons adalah petunjuk kedua. Refused muncul segera, kira-kira selama satu perjalanan pulang-pergi paket. Timed out baru muncul setelah beberapa detik karena client terus mengirim ulang paket sebelum berhenti. macOS menampilkan Operation timed out untuk kondisi yang sama. Jika protokol ini masih baru bagi Anda, cara kerja SSH dan fungsi sshd adalah dasar yang digunakan panduan ini.

Mengapa "Connection refused" merupakan kabar baik

Penolakan ini merupakan reset TCP (transmission control protocol). Klien Anda mengirim paket SYN ke port 22. Paket tersebut melintasi Internet, tiba di network stack server, lalu kernel tidak menemukan socket yang mendengarkan pada port tersebut. Kernel kemudian menjawab dengan paket RST (reset). Klien SSH menerjemahkan RST tersebut menjadi kata-kata Connection refused.

Satu paket balasan itu membuktikan banyak hal. Alamatnya benar. Host aktif dan memiliki routing yang berfungsi. Tidak ada perangkat di jalur yang membuang trafik ke port tersebut secara diam-diam, karena ada balasan dari sisi tujuan. Jadi, semua kemungkinan penyebab yang tersisa berada di server itu sendiri.

• sshd tidak berjalan karena gagal start atau belum diaktifkan.
• sshd mendengarkan pada port lain, biasanya setelah perubahan hardening.
• sshd terikat ke satu alamat, seperti ListenAddress 127.0.0.1, sehingga hanya server itu sendiri yang dapat menjangkaunya.
• Firewall dikonfigurasi untuk menolak, bukan membuang paket. Karena itu, firewall mengirim RST atas nama host. Tindakan ufw reject dan aturan nftables yang diakhiri dengan reject with tcp reset sama-sama melakukan hal ini.

Ada satu kasus lain yang tampak serupa, tetapi sebenarnya berbeda: Anda memasukkan alamat milik host aktif yang lain. Host tersebut menjawab SYN Anda, tidak menjalankan SSH pada port 22, lalu menolak koneksi Anda dengan baik. Konfirmasikan alamat tersebut sebelum menghabiskan waktu satu jam pada server yang salah. Memahami fungsi port yang mendengarkan pada Linux membuat bagian ini lebih cepat dipahami.

Cara memperbaiki Connection refused

Anda tidak dapat memperbaikinya melalui SSH karena SSH adalah komponen yang bermasalah. Buka konsol web atau konsol serial dari provider Anda, masuk melalui konsol tersebut, lalu jalankan perintah berikut secara berurutan.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

systemctl status ssh menggunakan nama unit ini pada Ubuntu dan Debian. Pada RHEL dan turunannya, seperti AlmaLinux, unitnya adalah sshd. ss -tlnp menampilkan semua socket TCP dalam status listening beserta proses yang memilikinya. Perintah ini menjadi sumber kebenaran utama: jika tidak ada baris yang menyebut sshd, berarti tidak ada proses yang listening, apa pun isi file konfigurasi. sshd -T menampilkan konfigurasi efektif setelah setiap file Include digabungkan. Di sinilah port yang terlupa dalam /etc/ssh/sshd_config.d/ akan terlihat.

Perhatikan kolom alamat dengan teliti. 0.0.0.0:22 berarti semua alamat IPv4 pada server. [::]:22 berarti semua alamat IPv6. 127.0.0.1:22 berarti hanya loopback. Karena itu, setiap koneksi remote ke alamat tersebut akan ditolak, sedangkan ssh localhost lokal tetap berfungsi dengan baik.

Jika tidak ada proses yang listening, start service tersebut dan baca pesan kegagalannya saat service tidak dapat start.

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

sshd -t memeriksa konfigurasi dan menampilkan file serta nomor baris dari directive yang salah tanpa mengubah service yang sedang berjalan. Jalankan perintah ini sebelum setiap restart karena konfigurasi yang ditolak menyebabkan sshd keluar saat start, sehingga koneksi berikutnya akan ditolak.

Jebakan aktivasi socket di Ubuntu

Ubuntu 24.04 menyertakan unit socket systemd untuk OpenSSH. Jika unit tersebut diaktifkan, systemd memegang port yang listening dan memulai sshd untuk setiap koneksi, sehingga Port 2222 dalam sshd_config tidak mengubah apa pun dan server tetap merespons pada port lama. Periksa mode yang digunakan sebelum mengubah apa pun.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

Jika socket diaktifkan, tetapkan port pada unit socket, bukan pada sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

Baris ListenStream= yang kosong diperlukan karena pengaturan list systemd menambahkan nilai ke konfigurasi yang sudah ada. Jika baris tersebut dihilangkan, server akan listening pada kedua port. Terapkan perubahan dengan sudo systemctl daemon-reload dan sudo systemctl restart ssh.socket, lalu konfirmasikan dengan sudo ss -tlnp bahwa port baru adalah port yang sedang digunakan. Memindahkan port merupakan langkah umum dalam memperkuat keamanan SSH pada VPS, dan langkah inilah yang paling sering menyebabkan pengguna terkunci dari server.

Mengapa "Connection timed out" tidak menunjukkan apa pun

Timeout berarti tidak ada respons. Client Anda mengirim SYN, mengirim ulangnya beberapa kali selama satu atau dua menit, dan tidak pernah menerima satu paket pun sebagai balasan. Tidak ada kesimpulan tentang server yang dapat dipastikan di sini karena tidak pernah ada respons dari server.

Tidak adanya respons adalah efek yang memang dihasilkan oleh aturan DROP, dan pembuangan paket dilakukan secara sengaja. Respons penolakan memberi tahu pemindai bahwa host tersebut ada. Karena itu, ufw dan firewall jaringan dari setiap penyedia cloud membuang paket yang tidak diinginkan dan tidak mengirimkan respons apa pun. Timeout Anda biasanya disebabkan oleh firewall yang bekerja pada port yang ingin Anda buka.

• Alamatnya salah: record DNS masih mengarah ke server yang Anda buat ulang, atau terdapat kesalahan pengetikan yang mengarah ke alamat yang tidak digunakan siapa pun.
• Host tidak aktif: host dimatikan atau sedang menjalani reboot. Penangguhan oleh penyedia karena masalah penagihan akan terlihat sama dari luar.
• Firewall host membuang port 22, biasanya karena ufw enable dijalankan sebelum aturan allow apa pun dibuat.
• Firewall penyedia yang berada di depan instance membuang paket tersebut, sehingga sistem operasi sama sekali tidak pernah melihatnya.
• Jaringan Anda sendiri memblokir port keluar 22. Hal ini umum terjadi pada koneksi kantor dan hotel.

Jalankan pengujian dari sisi koneksi yang benar

Inilah kesalahan yang paling banyak membuang waktu. Anda tidak dapat mendiagnosis paket yang terputus dari dalam server yang tidak menerima paket tersebut. Jika Anda dapat masuk untuk menjalankan perintah, masalah itu tidak akan terjadi. Semua perintah dalam bagian ini dijalankan pada mesin Anda sendiri.

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

getent hosts menampilkan alamat yang benar-benar akan digunakan mesin Anda. Ini dapat mendeteksi catatan DNS yang sudah usang dalam hitungan detik. ssh -G menampilkan pengaturan yang diterapkan client setelah membaca ~/.ssh/config. Dengan demikian, perintah ini dapat mendeteksi blok Host lama yang secara diam-diam mengubah hostname, port, atau user. ssh -vvv menunjukkan sejauh mana proses koneksi berlangsung. Baris terakhir yang menunjukkan koneksi ke alamat tertentu lalu diikuti jeda panjang berarti terjadi timeout. Sebaliknya, baris yang menampilkan versi OpenSSH remote berarti koneksi TCP sudah berhasil dan masalah sebenarnya adalah autentikasi. Di Windows, Test-NetConnection 203.0.113.10 -Port 22 dalam PowerShell menggantikan nc.

Uji port, bukan host. Kegagalan ping tidak membuktikan apa pun karena banyak provider memfilter ICMP (internet control message protocol) di edge. Ping yang berhasil juga tidak membuktikan apa pun karena tidak memberikan informasi tentang port 22.

Selanjutnya, ubah satu variabel yang tidak dapat diubah oleh perintah mana pun untuk Anda: jaringan Anda. Ulangi pengujian menggunakan hotspot ponsel. Jika koneksi berhasil melalui hotspot tetapi tidak melalui jaringan kantor, pemblokiran terjadi di sisi jaringan Anda, atau alamat kantor Anda telah diblokir di server.

Firewall penyedia yang tidak dapat Anda lihat dari server

Sebagian besar panel VPS menyediakan firewall jaringan, yang terkadang disebut security group atau cloud firewall. Firewall ini berjalan di sisi upstream instance Anda dan menyimpan daftar aturannya sendiri. ufw status pada server tidak dapat melihatnya. Karena itu, kalimat “tetapi saya sudah mengizinkan port 22” sering muncul. Buka panel dan periksa daftar tersebut sebelum mengubah aturan apa pun pada server.

Satu perintah dapat memastikan penyebabnya, tetapi Anda memerlukan akses console. Jalankan perintah tersebut pada server, lalu coba terhubung dari laptop saat perintah masih berjalan.

sudo tcpdump -ni any tcp port 22

Jika tidak ada apa pun yang muncul saat client mencoba terhubung, paket dibuang sebelum mencapai sistem operasi. Berarti masalahnya ada pada firewall penyedia atau rute menuju host. Jika paket SYN tiba tetapi tidak ada balasan yang keluar, paket tersebut dibuang secara lokal oleh ufw atau nftables. Pengujian ini membagi dua kemungkinan penyebab timeout. Karena itu, akses console diperlukan untuk melakukan pemeriksaan ini.

Urutan ufw, IPv6, dan pemblokiran terhadap alamat Anda sendiri

Kesalahan urutan ufw menyebabkan lebih banyak pengguna terkunci daripada hal lain dalam panduan ini. sudo ufw enable segera menerapkan kebijakan default untuk menolak koneksi masuk. Jika belum ada aturan SSH, sesi Anda saat ini tetap bertahan karena status koneksi yang sudah terbentuk, sedangkan setiap koneksi baru mengalami timeout. Izinkan akses terlebih dahulu, lalu aktifkan ufw.

sudo ufw allow OpenSSH
sudo ufw status verbose

Profil aplikasi OpenSSH hanya mencakup port 22. Jika Anda berencana memindahkan SSH ke 2222, aturan yang diperlukan adalah sudo ufw allow 2222/tcp. Tambahkan aturan ini sebelum mengubah port, bukan setelahnya. Kumpulan aturan yang lebih luas dibahas dalam dasar-dasar firewall ufw untuk VPS, sedangkan urutan yang aman merupakan bagian dari hal yang harus dilakukan dalam sepuluh menit pertama pada VPS baru.

IPv6 dapat menghasilkan timeout yang sulit dijelaskan. Jika hostname memiliki data AAAA, client akan mencoba IPv6 terlebih dahulu. Akibatnya, server dengan aturan IPv6 yang belum dikonfigurasi akan macet, sementara percobaan melalui IPv4 biasa berhasil. Pisahkan kedua kemungkinan ini secara manual.

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

Jika -4 berhasil terhubung tetapi -6 tidak, masalahnya berada pada aturan IPv6 di server. Membuka port yang sama untuk IPv6 di ufw menjelaskan langkah-langkahnya.

Anda juga mungkin telah memblokir alamat Anda sendiri. fail2ban memantau log autentikasi dan menambahkan aturan firewall untuk alamat yang berulang kali gagal, sehingga key yang salah atau script yang mencoba ulang di latar belakang dapat memblokir seluruh alamat kantor. Pemblokiran yang menjatuhkan paket terlihat seperti timeout. Pemblokiran yang menolak koneksi akan mengembalikan No route to host. Dari console:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

Menambahkan alamat Anda sendiri ke ignoreip merupakan bagian dari konfigurasi fail2ban yang berfungsi di Ubuntu 24.04.

Kesalahan yang bukan penolakan atau timeout

No route to host berarti pesan ICMP unreachable diterima kembali. Mesin Anda tidak memiliki rute ke jaringan tersebut, atau ada perangkat di jalur yang menjawab dengan penolakan administratif. Inilah respons yang dikirim oleh aturan iptables REJECT.

Network is unreachable berasal dari mesin Anda sendiri. Mesin tersebut sama sekali tidak memiliki rute untuk keluarga alamat itu. Respons ini biasanya muncul ketika hostname hanya mengarah ke alamat IPv6 pada koneksi yang hanya mendukung IPv4.

kex_exchange_identification: Connection closed by remote host berarti koneksi TCP berhasil, tetapi server kemudian memutus koneksi sebelum pertukaran key selesai. Port terbuka dan sshd aktif. Karena itu, periksa beban server, MaxStartups, atau ban yang diterapkan saat Anda sedang terhubung.

Permission denied (publickey) berarti Anda berhasil mencapai tahap autentikasi, tetapi gagal pada tahap tersebut. Jaringan dan firewall tidak bermasalah. Jadi, tidak ada bagian dalam panduan ini yang berlaku. Buka memperbaiki Permission denied (publickey) pada SSH sebagai gantinya.

Cara mendapatkan kembali akses dan mencegah pemblokiran berikutnya

Setiap penyedia VPS yang serius menyediakan konsol yang tidak bergantung pada jaringan guest: konsol serial atau layar VNC berbasis browser. Konsol tersebut adalah jalur pemulihan untuk kedua cabang panduan ini karena tetap berfungsi saat sshd dihentikan dan saat aturan firewall membuang semua trafik. Temukan konsol itu di panel, masuk sebagai root atau pengguna biasa Anda, lalu jalankan pemeriksaan di atas. Jika Anda belum pernah menetapkan kata sandi root, sebagian besar panel dapat mengatur ulang kata sandi tersebut untuk Anda.

Jika tidak ada konsol, gunakan mode pemulihan dari penyedia. Mode ini mem-boot sistem pemulihan kecil dan me-mount disk Anda, sehingga Anda dapat mengedit /etc/ssh/sshd_config atau menghapus aturan firewall secara offline, lalu melakukan reboot.

Dua kebiasaan dapat mencegah pemblokiran berikutnya. Biarkan sesi SSH kedua tetap terbuka setiap kali Anda mengedit sshd atau firewall karena sesi tersebut tetap berjalan dengan status koneksi yang sudah terbentuk saat Anda menguji sesi baru. Selain itu, siapkan pembatalan otomatis sebelum mengubah firewall secara berisiko.

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

Baris pertama menjadwalkan ufw untuk menonaktifkan dirinya sendiri dalam sepuluh menit. Terapkan aturan baru, buka sesi SSH baru untuk memastikan aturan tersebut berfungsi, lalu jalankan baris kedua untuk membatalkan rollback. Jika Anda justru terkunci dari server, tunggu sepuluh menit dan firewall akan dinonaktifkan secara otomatis. Server akan tetap tanpa penyaringan sampai Anda mengaktifkan ufw kembali. Karena itu, gunakan cara ini saat Anda berada di depan keyboard, bukan sebagai pengaturan permanen.

Urutan pemeriksaan

1. Baca teks error dan perhatikan berapa lama waktu yang diperlukan hingga error tersebut muncul.
2. Ditolak: buka konsol dan periksa sudo ss -tlnp untuk mencari socket yang sedang listen, portnya, serta alamat yang menjadi binding-nya.
3. Waktu habis: dari mesin Anda sendiri, konfirmasi alamat tersebut. Kemudian periksa firewall provider pada panel, lalu firewall host pada server.
4. Jika tidak ada satu pun dari kedua string tersebut: koneksi TCP sudah berhasil dibuat. Perlakukan ini sebagai masalah autentikasi atau beban server, bukan masalah jaringan.

FAQ

Mengapa SSH menampilkan "Connection refused" saat sshd sedang berjalan?

Karena penolakan berasal dari socket, bukan dari service, dan sshd yang sedang berjalan tetap dapat menolak koneksi. Buka console provider, lalu jalankan sudo ss -tlnp. Socket pada 127.0.0.1:22 menolak semua client jarak jauh karena hanya terikat ke loopback. Socket pada port lain tetap menolak semua client yang masih menggunakan 22. Jika systemd socket activation digunakan, port ditentukan oleh ssh.socket, bukan sshd_config. Karena itu, periksa systemctl is-enabled ssh.socket juga. Rule reject ufw juga dapat mengembalikan penolakan atas nama host. Baca sudo ufw status verbose sebelum menarik kesimpulan.

Mengapa SSH mengalami timeout saat ufw sudah mengizinkan port 22?

Karena timeout berarti tidak ada jawaban yang kembali, dan ufw bukan satu-satunya firewall dalam jalur koneksi. Sebagian besar panel VPS menjalankan firewall jaringan di depan instance. Sistem operasi tidak pernah melihat paket yang dibuang firewall tersebut. Dari console, jalankan sudo tcpdump -ni any tcp port 22, lalu coba terhubung dari laptop saat perintah itu berjalan. Jika tidak ada paket yang masuk, paket tersebut dibuang di upstream, yaitu di panel. Jika paket masuk tetapi tidak ada balasan yang keluar, paket tersebut dibuang secara lokal, oleh ufw atau nftables.

Apakah ping yang gagal berarti VPS saya tidak aktif?

Tidak. Banyak provider memfilter ICMP di edge jaringan. Karena itu, server yang melayani trafik secara normal dapat mengabaikan semua ping yang Anda kirim. Ping yang berhasil juga tidak banyak memberi informasi, karena tidak menunjukkan apakah port 22 terbuka. Uji port itu sendiri dengan nc -vz -w 5 203.0.113.10 22 dari mesin Anda, atau dengan Test-NetConnection 203.0.113.10 -Port 22 di PowerShell pada Windows.

Saya mengubah port SSH, tetapi sekarang tidak ada koneksi yang berhasil. Apa yang terjadi?

Ada 2 urutan tindakan yang dapat menyebabkan masalah ini. Jika firewall belum memiliki rule untuk port baru, percobaan ke port baru akan mengalami timeout, sedangkan port 22 akan menolak koneksi. Karena itu, sudo ufw allow 2222/tcp harus dijalankan sebelum perubahan port, bukan sesudahnya. Jika server menggunakan systemd socket activation untuk SSH, Port 2222 dalam sshd_config diabaikan dan systemd tetap mempertahankan port lama. Hal ini dapat dikonfirmasi dengan systemctl is-enabled ssh.socket. Pulihkan akses melalui console provider, perbaiki penyebab yang sesuai, lalu hubungkan dengan ssh -p 2222 user@203.0.113.10 setelah sudo ss -tlnp menampilkan socket baru.