Pernah ngalamin SSH ke VPS tiba-tiba gagal? Kamu coba ssh user@server, tunggu beberapa detik, lalu muncul error Connection refused atau Connection timed out. Frustrasi banget, apalagi kalau VPS itu tempat aplikasi production kamu jalan. Saya juga pernah ngalamin ini, dan ternyata penyebabnya bisa bermacam-macam dari yang simpel kayak SSH service mati, sampai yang tricky kayak firewall rules yang bentrok.
Artikel ini bakal bahas cara debug SSH connection refused step by step, mulai dari cek service, port, firewall, SSH config, sampai kasus-kasus khusus yang sering bikin pusing. Semua command di sini udah saya tes di Ubuntu 20.04 dan 24.04.
Apa Itu "Connection Refused" vs "Connection Timed Out"
Pertama, kamu perlu paham bedanya dua error ini karena solusinya beda banget:
- Connection refused VPS kamu hidup dan reachable, tapi nggak ada service yang listen di port 22 (atau port SSH kamu). Artinya SSH service mati atau listen di port lain.
- Connection timed out VPS kamu nggak respon sama sekali di port itu. Biasanya firewall nge-drop paket, atau servernya bener-bener down/mati.
Kalau kamu lihat ssh: connect to host port 22: Connection refused, itu berarti koneksi TCP berhasil tapi service-nya nggak ada. Kalau ssh: connect to host port 22: Connection timed out, paket kamu nggak nyampe atau nggak ada balasan.
Step 1: Cek Apakah SSH Service Running
Hal pertama yang harus kamu cek apakah sshd service jalan atau nggak. Masuk ke VPS lewat console/VNC (karena SSH-nya kan lagi down), lalu jalankan:
# Cek status SSH service
sudo systemctl status sshd
# Kalau mati, start lagi
sudo systemctl start sshd
# Pastikan auto-start saat boot
sudo systemctl enable sshd
Kalau kamu lihat Active: active (running), service-nya jalan. Tapi kalau Active: inactive (dead) atau failed, kamu nemu akar masalahnya. Coba start dulu, lalu cek kenapa dia mati:
# Lihat log SSH service
sudo journalctl -u sshd -n 50 --no-pager
# Atau cek syslog
sudo tail -50 /var/log/auth.log
Sering kali SSH mati karena config error. Misalnya kamu habis edit /etc/ssh/sshd_config dan ada syntax error. Coba validasi config:
# Test config SSH sebelum restart
sudo sshd -t
# Kalau ada error, outputnya bakal nunjukin baris yang bermasalah
# Contoh: /etc/ssh/sshd_config:42: Bad configuration option: PermitRootLogins
Fix error-nya, lalu restart. Ini cara paling cepat tau kenapa SSH nggak mau start.
Step 2: Cek Port yang Listen
Kadang SSH jalan tapi listen di port yang nggak kamu expect. Mungkin kamu pernah ganti port default 22 ke port lain (best practice sih), lalu lupa. Cek dengan:
# Cek port yang listen untuk SSH
sudo ss -tlnp | grep ssh
# Atau pakai netstat (kalau masih ada)
sudo netstat -tlnp | grep ssh
Output yang normal kelihatan kayak gini:
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1234,fd=4))
Kalau portnya beda, misalnya 2222, maka kamu harus specify saat connect: ssh -p 2222 user@server. Banyak yang lupa step ini terutama kalau VPS-nya di-setup oleh orang lain.
Step 3: Cek Firewall (UFW atau iptables)
Ini penyebab paling sering di VPS baru. Kamu install Ubuntu, UFW default-nya block semua incoming kecuali yang kamu allow. Kalau kamu nggak allow port 22, SSH nggak bisa diakses dari luar.
# Cek status UFW
sudo ufw status verbose
# Allow SSH (port 22)
sudo ufw allow 22/tcp
# Kalau SSH pakai port custom
sudo ufw allow 2222/tcp
# Pastikan UFW enabled
sudo ufw enable
Pitfall: Kalau kamu enable UFW tanpa allow port 22 dulu, kamu bisa nge-lock diri sendiri dari SSH. Selalu allow dulu, baru enable.
Kalau kamu pakai iptables (bukan UFW), cek rules-nya:
# List semua iptables rules
sudo iptables -L -n --line-numbers
# Cek khusus port 22
sudo iptables -L -n | grep 22
# Allow SSH di iptables
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
Untuk persistensi, simpan rules-nya:
# Install iptables-persistent kalau belum ada
sudo apt install iptables-persistent
sudo netfilter-persistent save
Step 4: Cek Cloud Provider Security Group / Firewall
Nah ini yang sering bikin orang bingung. Kamu udah cek SSH service jalan, UFW allow port 22, tapi tetap nggak bisa connect. Masalahnya ada di firewall cloud provider.
Kalau VPS kamu di AWS, Google Cloud, Oracle Cloud, atau Azure, masing-masing punya security group / firewall rules yang beroperasi di luar VPS itu sendiri. Kamu harus allow port 22 di dashboard cloud provider juga.
Oracle Cloud: VCN Settings > Security Lists > Ingress Rules > add rule untuk TCP port 22, source 0.0.0.0/0 (atau IP kamu saja untuk security lebih baik).
AWS: EC2 > Security Groups > Inbound Rules > add SSH (port 22) dari source yang kamu tentukan.
Google Cloud: VPC Network > Firewall > create rule untuk allow TCP 22.
Saya pribadi pernah habis 2 jam debugging SSH di Oracle Cloud, ternyata lupa add ingress rule di VCN security list. SSH service running, UFW allow, tapi paket dari luar nggak pernah nyampe ke VPS karena di-drop di level cloud.
Step 5: Cek SSH Config yang Bikin Connection Drop
Kadang SSH berhasil connect tapi langsung putus setelah beberapa detik. Ini bisa karena beberapa setting di sshd_config:
# Edit SSH config
sudo nano /etc/ssh/sshd_config
Beberapa setting yang sering bermasalah:
# Pastikan ini ada dan tidak di-comment
PermitRootLogin yes # atau "prohibit-password" kalau pakai key
PasswordAuthentication yes # kalau masih pakai password login
MaxAuthTries 3 # terlalu rendah bisa bikin disconnect
ClientAliveInterval 60 # keepalive interval
ClientAliveCountMax 3 # jumlah keepalive yang boleh miss
Setelah edit, jangan lupa restart:
sudo systemctl restart sshd
Step 6: Debug dengan Verbose Mode
Kalau kamu masih bingung kenapa koneksi gagal, pakai verbose mode di sisi client. Outputnya detail banget dan sering nunjukkin di mana prosesnya stuck:
# Verbose SSH connection
ssh -v user@server
# Lebih detail lagi
ssh -vv user@server
# Paling detail
ssh -vvv user@server
Output verbose bakal nunjukkin setiap step dari DNS resolution, TCP connect, key exchange, sampai auth. Kalau stuck di debug1: Connecting to, itu network/firewall issue. Kalau stuck di debug1: SSH2_MSG_KEXINIT, itu key exchange issue.
Step 7: Cek SSH Host Keys
Kalau kamu pernah reinstall OS di VPS yang sama, fingerprint SSH server berubah. Client kamu nolak koneksi karena host key mismatch:
# Error yang muncul
# @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
# @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
# @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
# Fix: hapus entry lama dari known_hosts
ssh-keygen -R server_ip
# Atau hapus manual
nano ~/.ssh/known_hosts
# Cari baris dengan IP server, hapus, save
Setelah itu, coba connect lagi. Kamu bakal ditanya untuk accept fingerprint baru, ketik yes.
Step 8: Cek Fail2Ban atau DenyHosts
Kalau kamu pakai Fail2Ban (dan seharusnya pakai untuk security), IP kamu bisa kena ban karena terlalu banyak failed login attempt. Ini sering terjadi kalau kamu lupa password atau salah ketik beberapa kali.
# Cek status Fail2Ban
sudo fail2ban-client status sshd
# Lihat daftar IP yang di-ban
sudo fail2ban-client status sshd | grep "Banned IP"
# Unban IP tertentu
sudo fail2ban-client set sshd unbanip YOUR_IP_ADDRESS
Kalau kamu pakai denyhosts (jarang tapi mungkin), cek /etc/hosts.deny:
cat /etc/hosts.deny
# Kalau IP kamu ada di sini, hapus barisnya
sudo nano /etc/hosts.deny
Step 9: Cek DNS dan Hosts File
Kadang bukan SSH-nya yang bermasalah, tapi DNS resolution. Kamu connect pakai hostname tapi DNS-nya nggak resolve dengan benar. Coba connect pakai IP langsung:
# Pakai IP langsung, bukan hostname
ssh [email protected]
# Kalau ini berhasil, masalahnya di DNS
# Cek DNS resolution
dig server-domain.com
nslookup server-domain.com
# Atau pakai /etc/hosts sebagai workaround
sudo nano /etc/hosts
# Tambahkan: 192.168.1.100 server-domain.com
Step 10: Network Level Debugging
Kalau semua step di atas belum solve masalah, waktunya debugging di level network. Cek apakah port 22 reachable dari sisi client:
# Test konektivitas dengan telnet
telnet server_ip 22
# Atau pakai nc (netcat)
nc -zv server_ip 22
# Trace route untuk lihat di mana paket drop
traceroute server_ip
# Cek apakah port 22 open dari luar
nmap -p 22 server_ip
Kalau nc -zv return Connection refused, service-nya nggak ada di port itu. Kalau Connection timed out, firewall nge-drop paket kamu. Ini beda solusi yang harus kamu approach.
Tips Preventif: Setup SSH dengan Key-Based Auth
Setelah masalah selesai, sebaiknya kamu setup SSH key authentication dan disable password login. Ini lebih secure dan nggak bakal kena masalah brute-force atau Fail2Ban ban:
# Generate SSH key di client
ssh-keygen -t ed25519 -C "[email protected]"
# Copy key ke server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
# Setelah verify key login works, disable password auth
sudo nano /etc/ssh/sshd_config
# Set: PasswordAuthentication no
sudo systemctl restart sshd
Key-based auth pakai ed25519 lebih secure dari RSA dan lebih cepat. Sebagai bonus, kamu nggak perlu repot dengan Fail2Ban karena brute-force nggak bakal berhasil tanpa private key.
Checklist Cepat saat SSH Connection Refused
Simpan checklist ini biar nggak panik next time:
- sshd running?
systemctl status sshd - Listen di port yang benar?
ss -tlnp | grep ssh - UFW allow port 22?
ufw status - Cloud security group allow? cek dashboard provider
- sshd_config valid?
sshd -t - Host key mismatch?
ssh-keygen -R server_ip - Fail2Ban ban?
fail2ban-client status sshd - DNS resolve?
dig hostname - Verbose output?
ssh -vvv user@server - Port reachable?
nc -zv server_ip 22
Kesimpulan
SSH connection refused itu sebenernya masalah yang gampang di-fix kalau kamu tahu urutan debugging yang benar. Mulai dari yang paling basic cek service running, port listen, firewall allow sampai yang lebih advanced kayak cloud security group, host key mismatch, dan Fail2Ban. Yang penting jangan panik, ikuti checklist step by step, dan pakai verbose mode untuk lihat di mana persisnya koneksi gagal.
Kalau kamu sering manage banyak VPS, pertimbangkan untuk pakai SSH config file (~/.ssh/config) biar connection details udah pre-configured per host. Jauh lebih praktis daripada ngetik ssh -p 2222 -i ~/.ssh/custom_key [email protected] setiap kali.
Punya pengalaman SSH debugging yang lain? Atau ada kasus tricky yang belum dibahas di sini? Share di komen ya, siapa tahu bisa bantu developer lain yang lagi struggle.
