Beza SSH Connection Refused dan Connection Timed Out

Maksud "Connection refused" dan "Connection timed out" dalam SSH

Ralat SSH connection refused dan SSH connection timed out adalah kegagalan yang bertentangan, jadi penyelesaian bagi satu masalah tidak akan menyelesaikan masalah yang lain. Refused bermaksud paket anda sampai ke pelayan dan kernel pelayan menjawab "tiada apa-apa yang mendengar di sini". Timed out bermaksud paket anda tidak sampai kepada sesiapa yang boleh menjawab, jadi klien anda menunggu dan akhirnya berputus asa. Refused ialah masalah servis pada pelayan. Timed out ialah masalah laluan di hadapan pelayan tersebut.

Baca baris tepat yang dipaparkan oleh klien anda, kerana perkataan yang digunakan adalah diagnosis penuh bagi masalah tersebut.

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

Masa tindak balas adalah petunjuk kedua. Refused muncul serta-merta, dalam tempoh masa satu perjalanan pergi-balik (round trip). Timed out akan terhenti selama beberapa saat sebelum dipaparkan, kerana klien terus menghantar semula paket sebelum berputus asa. macOS memaparkan Operation timed out bagi keadaan yang sama. Jika protokol ini baharu bagi anda, cara SSH berfungsi dan peranan sshd adalah latar belakang yang diandaikan oleh panduan ini.

Mengapa "Connection refused" adalah berita baik

Refused ialah reset TCP (transmission control protocol). Pelanggan anda menghantar paket SYN ke port 22. Ia merentasi internet, sampai ke stack rangkaian pelayan, dan kernel mendapati tiada socket yang mendengar pada port tersebut, jadi ia menjawab dengan paket RST (reset). Pelanggan SSH anda menukarkan RST itu kepada perkataan Connection refused.

Satu paket yang kembali itu membuktikan banyak perkara. Alamatnya betul. Hos dihidupkan dan berfungsi dalam penghalaan. Tiada apa-apa di sepanjang laluan yang membuang trafik ke port tersebut secara senyap, kerana sesuatu telah kembali dari hujung sana. Jadi, setiap suspek yang tinggal berada pada pelayan itu sendiri.

• sshd tidak berjalan, kerana ia gagal bermula atau tidak pernah diaktifkan.
• sshd sedang mendengar pada port lain, biasanya selepas perubahan pengukuhan (hardening).
• sshd terikat pada satu alamat, seperti ListenAddress 127.0.0.1, jadi hanya pelayan itu sendiri yang boleh mencapainya.
• Firewall ditetapkan untuk menolak (reject) dan bukannya menggugurkan (drop) trafik, jadi firewall menghantar RST bagi pihak hos. Tindakan reject pada ufw dan peraturan nftables yang berakhir dengan reject with tcp reset kedua-duanya melakukan perkara ini.

Satu lagi kes kelihatan seperti ini tetapi sebenarnya bukan: anda menaip alamat yang dimiliki oleh hos lain yang sedang aktif. Hos itu menjawab SYN anda, tidak mempunyai SSH pada port 22, dan menolak anda dengan sopan. Sahkan alamat tersebut sebelum anda menghabiskan masa sejam pada pelayan yang salah. Mengetahui apa itu port yang mendengar (listening port) sebenarnya pada Linux menjadikan bahagian seterusnya lebih mudah difahami.

Cara membaiki Connection refused

Anda tidak boleh membaiki masalah ini melalui SSH, kerana SSH itu sendiri yang tergendala. Buka konsol web atau konsol bersiri pembekal anda, log masuk di sana, kemudian jalankan perintah-perintah berikut.

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

systemctl status ssh menggunakan nama unit pada Ubuntu dan Debian. Pada RHEL dan sistem binaan semula seperti AlmaLinux, unitnya ialah sshd. ss -tlnp menyenaraikan setiap soket TCP dalam keadaan mendengar (listening) berserta proses yang memilikinya, dan ia merupakan sumber kebenaran mutlak: jika tiada baris yang menyebut sshd, maka tiada apa-apa yang mendengar, tidak kira apa yang dinyatakan dalam fail konfigurasi. sshd -T mencetak konfigurasi berkesan selepas setiap fail Include digabungkan, di sinilah port yang terlupa dalam /etc/ssh/sshd_config.d/ akan kelihatan.

Baca lajur alamat dengan teliti. 0.0.0.0:22 bermaksud setiap alamat IPv4 pada mesin tersebut. [::]:22 bermaksud setiap alamat IPv6. 127.0.0.1:22 bermaksud loopback sahaja, jadi setiap sambungan jauh kepadanya akan ditolak manakala ssh localhost tempatan berfungsi dengan sempurna.

Jika tiada apa-apa yang mendengar, mulakan servis tersebut dan baca ralat kegagalan apabila ia tidak dapat bermula.

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

sshd -t menghurai konfigurasi dan mencetak fail serta nombor baris arahan yang salah tanpa menyentuh servis yang sedang berjalan. Jalankan perintah ini sebelum setiap kali memulakan semula (restart), kerana konfigurasi yang ditolak bermakna sshd akan keluar semasa permulaan dan sambungan anda yang seterusnya akan ditolak.

Perangkap pengaktifan soket pada Ubuntu

Ubuntu 24.04 membekalkan unit soket systemd untuk OpenSSH. Apabila unit tersebut diaktifkan, systemd memegang port pendengar dan memulakan sshd bagi setiap sambungan, jadi Port 2222 dalam sshd_config tidak mengubah apa-apa dan pelayan terus menjawab pada port lama. Semak mod yang digunakan oleh sistem anda sebelum mengubah sebarang fail.

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

Jika soket diaktifkan, tetapkan port dalam unit soket tersebut dan bukannya dalam sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

Baris ListenStream= yang kosong diperlukan, kerana tetapan senarai systemd akan menambah kepada konfigurasi sedia ada. Jika ditinggalkan, pelayan akan mendengar pada kedua-dua port. Gunakan perubahan tersebut dengan sudo systemctl daemon-reload dan sudo systemctl restart ssh.socket, kemudian sahkan dengan sudo ss -tlnp bahawa port baharu adalah port yang sedang dipegang. Menukar port merupakan langkah biasa dalam pengukuhan SSH pada VPS, dan ini adalah langkah yang paling kerap menyebabkan pengguna terkunci daripada pelayan.

Mengapa "Connection timed out" bermaksud tiada jawapan

Timeout bermaksud kesenyapan. Pelanggan anda menghantar SYN, menghantarnya semula beberapa kali dalam tempoh satu atau dua minit, dan tidak menerima satu pun paket sebagai balasan. Tiada apa-apa tentang pelayan yang dapat dibuktikan di sini, kerana tiada apa-apa daripada pelayan yang pernah diterima.

Kesenyapan adalah hasil tepat daripada peraturan DROP, dan pengguguran paket (dropping) dilakukan secara sengaja. Penolakan (rejection) memberitahu sesiapa yang melakukan imbasan bahawa hos tersebut wujud, jadi ufw dan setiap firewall rangkaian penyedia awan akan membuang paket yang tidak diingini dan tidak menghantar apa-apa kembali. Timeout anda biasanya berpunca daripada firewall yang menjalankan tugasnya pada port yang anda mahu buka.

• Alamat salah: rekod DNS masih menghala ke pelayan yang telah anda bina semula, atau kesilapan taip yang membawa kepada alamat yang tidak digunakan oleh sesiapa.
• Hos tidak aktif: dimatikan, atau sedang dalam proses reboot. Penggantungan oleh penyedia perkhidmatan akibat isu bil kelihatan sama dari luar.
• Firewall hos menggugurkan port 22, selalunya kerana ufw enable dijalankan sebelum sebarang peraturan kebenaran (allow rule) wujud.
• Firewall penyedia di hadapan instans menggugurkannya, dan sistem pengendalian tidak melihat paket tersebut sama sekali.
• Rangkaian anda sendiri menyekat port 22 keluar, yang biasa berlaku pada sambungan pejabat dan hotel.

Jalankan ujian dari bahagian sambungan yang betul

Ini adalah kesilapan yang paling banyak membuang masa. Anda tidak boleh mendiagnosis paket yang tercicir dari dalam kotak yang tidak menerima paket tersebut. Jika anda boleh log masuk untuk menjalankan perintah, anda tidak akan menghadapi masalah ini. Setiap perintah dalam bahagian 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 menunjukkan alamat yang akan digunakan oleh mesin anda, yang dapat mengesan rekod DNS yang lapuk dalam beberapa saat. ssh -G mencetak tetapan yang digunakan oleh klien anda selepas membaca ~/.ssh/config, jadi ia dapat mengesan blok Host lama yang mengubah nama hos, port atau pengguna secara senyap. ssh -vvv menunjukkan sejauh mana percubaan tersebut berjaya: baris terakhir tentang penyambungan ke alamat yang diikuti dengan jeda yang lama bermaksud tamat masa (timeout), manakala baris yang melaporkan versi OpenSSH jauh bermaksud TCP sudah berjaya dan masalah sebenar anda ialah pengesahan. Pada Windows, Test-NetConnection 203.0.113.10 -Port 22 dalam PowerShell menggantikan nc.

Uji port, bukan hos. ping yang gagal tidak membuktikan apa-apa, kerana banyak penyedia menapis ICMP (internet control message protocol) di bahagian pinggir. Ping yang berjaya juga tidak membuktikan apa-apa, kerana ia tidak menyatakan apa-apa tentang port 22.

Kemudian, ubah satu pemboleh ubah yang tidak boleh diubah oleh mana-mana perintah untuk anda: rangkaian anda. Cuba semula daripada hotspot telefon. Jika hotspot boleh bersambung dan meja anda tidak, sekatan tersebut berada di bahagian internet anda, atau alamat pejabat anda telah disekat pada pelayan.

Firewall penyedia yang tidak kelihatan daripada pelayan

Kebanyakan panel VPS menawarkan firewall rangkaian, yang kadangkala dipanggil kumpulan keselamatan atau firewall awan, yang berjalan di hulu instans anda dan mengekalkan senarai peraturannya sendiri. ufw status pada pelayan tidak dapat melihatnya, itulah sebabnya "tetapi saya sudah membenarkan port 22" merupakan ayat yang sangat biasa. Buka panel tersebut dan baca senarai itu sebelum anda menulis semula satu pun peraturan pada mesin tersebut.

Satu arahan menyelesaikan persoalan ini, dan ia memerlukan akses konsol. Mulakannya pada pelayan, kemudian cuba sambung daripada komputer riba anda semasa ia berjalan.

sudo tcpdump -ni any tcp port 22

Jika tiada apa-apa yang muncul semasa klien anda cuba menyambung, paket tersebut sedang dibuang sebelum ia sampai ke sistem pengendalian, jadi puncanya ialah firewall penyedia atau laluan ke hos. Jika paket SYN sampai dan tiada balasan keluar, pengguguran berlaku secara setempat dan berpunca daripada ufw atau nftables. Ujian tunggal itu membahagikan cawangan tamat masa kepada dua, itulah sebabnya ia berbaloi untuk menggunakan konsol.

Susunan ufw, IPv6, dan sekatan diri sendiri

Kesilapan susunan ufw menyebabkan lebih ramai pengguna terkunci keluar berbanding isu lain di sini. sudo ufw enable melaksanakan polisi deny incoming secara serta-merta, jadi tanpa peraturan SSH yang ditetapkan, sesi semasa anda mungkin kekal aktif melalui state yang sedia ada, manakala setiap sambungan baharu akan tamat tempoh (timeout). Benarkan akses dahulu, kemudian baru aktifkan.

sudo ufw allow OpenSSH
sudo ufw status verbose

Profil aplikasi OpenSSH hanya meliputi port 22. Jika anda bercadang untuk menukar SSH ke port 2222, peraturan yang anda perlukan ialah sudo ufw allow 2222/tcp, yang perlu ditambah sebelum port ditukar, bukannya selepas. Set peraturan yang lebih luas dibincangkan dalam asas firewall ufw untuk VPS, dan susunan yang selamat merupakan sebahagian daripada apa yang perlu dilakukan dalam sepuluh minit pertama pada VPS baharu.

IPv6 menghasilkan timeout yang terasa ganjil. Jika hostname mempunyai rekod AAAA, klien anda akan mencuba IPv6 terlebih dahulu, jadi pelayan yang tiada peraturan IPv6 akan tergantung manakala percubaan IPv4 biasa akan berjaya. Asingkan kedua-duanya secara manual.

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

Jika -4 berjaya bersambung tetapi -6 tidak, penyelesaiannya terletak pada peraturan IPv6 pelayan, dan membuka port yang sama untuk IPv6 dalam ufw menerangkan langkah-langkahnya.

Anda mungkin juga telah menyekat diri sendiri. fail2ban memantau log pengesahan dan memasukkan peraturan firewall terhadap alamat yang gagal berulang kali, jadi kunci yang salah atau skrip yang mencuba semula di latar belakang boleh menyekat keseluruhan alamat pejabat. Sekatan yang menggugurkan paket (drop) kelihatan seperti timeout. Sekatan yang menolak (reject) akan memulangkan No route to host. Dari konsol:

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

Menambah alamat anda sendiri ke dalam ignoreip adalah sebahagian daripada persediaan fail2ban yang berfungsi pada Ubuntu 24.04.

Ralat yang tidak ditolak dan tidak tamat tempoh

No route to host bermaksud mesej ICMP unreachable telah diterima. Sama ada mesin anda sendiri tidak mempunyai laluan ke rangkaian tersebut, atau sesuatu pada laluan tersebut membalas dengan penolakan pentadbiran, iaitu perkara yang dihantar oleh peraturan iptables REJECT.

Network is unreachable bermaksud mesin anda sendiri yang memberikan respons. Ia tidak mempunyai laluan untuk keluarga alamat tersebut sama sekali, dan ini merupakan jawapan biasa apabila nama hos hanya diselesaikan kepada alamat IPv6 pada sambungan yang hanya menyokong IPv4.

kex_exchange_identification: Connection closed by remote host bermaksud TCP telah bersambung dan pelayan kemudian memutuskan sambungan sebelum pertukaran kunci selesai. Port tersebut terbuka dan sshd sedang berjalan, jadi periksa beban pelayan, pada MaxStartups, atau sekatan yang dikenakan semasa anda sedang menyambung.

Permission denied (publickey) bermaksud anda telah mencapai peringkat pengesahan dan gagal di situ. Rangkaian berfungsi dengan baik dan firewall juga berfungsi dengan baik, jadi tiada apa-apa dalam panduan ini yang terpakai. Sila pergi ke membaiki Permission denied (publickey) pada SSH sebaliknya.

Cara untuk masuk semula, dan cara mengelakkan terkunci buat kali kedua

Setiap hos VPS yang serius menyediakan konsol yang tidak bergantung pada rangkaian tetamu: konsol bersiri, atau skrin VNC berasaskan pelayar. Konsol tersebut merupakan laluan pemulihan bagi kedua-dua cabang panduan ini, kerana ia terus berfungsi apabila sshd dihentikan dan ia terus berfungsi apabila peraturan firewall membuang segala trafik. Cari konsol tersebut di dalam panel, log masuk sebagai root atau sebagai pengguna biasa anda, kemudian jalankan pemeriksaan di atas. Jika anda tidak pernah menetapkan kata laluan root, kebanyakan panel boleh menetapkannya semula untuk anda.

Jika tiada konsol disediakan, langkah terakhir ialah mod penyelamat (rescue mode) pembekal. Ia memulakan sistem pemulihan kecil dan melekapkan cakera anda, supaya anda boleh menyunting /etc/ssh/sshd_config atau memadam peraturan firewall secara luar talian dan but semula.

Dua tabiat boleh menghalang kejadian terkunci seterusnya. Pastikan sesi SSH kedua sentiasa dibuka setiap kali anda menyunting sshd atau firewall, kerana sesi tersebut akan bertahan berdasarkan status yang telah ditetapkan sementara anda menguji sesi yang baharu. Selain itu, berikan diri anda fungsi buat asal (undo) automatik sebelum melakukan perubahan firewall yang berisiko.

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

Baris pertama menjadualkan ufw untuk mematikan dirinya sendiri dalam masa sepuluh minit. Gunakan peraturan baharu anda, buka sesi SSH baharu untuk membuktikan ia berfungsi, kemudian jalankan baris kedua untuk membatalkan proses buat asal tersebut. Jika anda sebaliknya terkunci, tunggu sepuluh minit dan firewall akan dimatikan dengan sendirinya. Ia akan membiarkan pelayan tanpa penapisan sehingga anda mengaktifkan ufw semula, jadi gunakan kaedah ini semasa anda berada di hadapan papan kekunci dan bukan sebagai aturan kekal.

Urutan kerja

1. Baca teks ralat dan perhatikan berapa lama masa yang diambil untuk ralat tersebut muncul.
2. Refused: pergi ke konsol dan periksa sudo ss -tlnp untuk melihat soket yang sedang mendengar, portnya, dan alamat yang diikat kepadanya.
3. Timed out: dari mesin anda sendiri, sahkan alamat tersebut, kemudian periksa firewall penyedia dalam panel, diikuti dengan firewall hos pada pelayan.
4. Tiada satu pun daripada rentetan tersebut: anda sudah mempunyai sambungan TCP, jadi anggap ia sebagai isu pengesahan atau beban pelayan, bukan isu rangkaian.

FAQ

Mengapa SSH menyatakan "Connection refused" sedangkan sshd sedang berjalan?

Kerana penolakan datang daripada soket, bukan daripada servis, dan sshd yang sedang berjalan masih boleh menolak anda. Buka konsol pembekal dan jalankan sudo ss -tlnp. Soket pada 127.0.0.1:22 menolak setiap klien jauh kerana ia terikat pada loopback sahaja. Soket pada port lain menolak sesiapa sahaja yang masih menggunakan 22. Jika pengaktifan soket systemd sedang digunakan, port tersebut datang daripada ssh.socket dan bukan daripada sshd_config, jadi periksa systemctl is-enabled ssh.socket juga. Peraturan ufw reject juga mengembalikan penolakan bagi pihak hos, jadi baca sudo ufw status verbose sebelum anda membuat sebarang kesimpulan.

Mengapa SSH tamat masa (time out) sedangkan ufw sudah membenarkan port 22?

Kerana tamat masa bermaksud tiada jawapan yang kembali, dan ufw bukanlah satu-satunya firewall dalam laluan tersebut. Kebanyakan panel VPS menjalankan firewall rangkaian di hadapan instans, dan sistem pengendalian tidak pernah melihat apa yang digugurkan oleh firewall tersebut. Dari konsol, jalankan sudo tcpdump -ni any tcp port 22 dan cuba sambung dari komputer riba anda semasa ia berjalan. Tiada paket yang tiba bermaksud pengguguran berlaku di hulu (upstream), dalam panel. Paket yang tiba tanpa balasan keluar bermaksud pengguguran berlaku secara setempat, dalam ufw atau nftables.

Adakah ping yang gagal bermaksud VPS saya tidak berfungsi?

Tidak. Ramai pembekal menapis ICMP di pinggir rangkaian, jadi pelayan yang melayan trafik secara normal boleh mengabaikan setiap ping yang anda hantar. Ping yang berjaya juga sama lemahnya dalam arah yang bertentangan, kerana ia tidak menyatakan sama ada port 22 dibuka atau tidak. Uji port itu sendiri dengan nc -vz -w 5 203.0.113.10 22 dari mesin anda sendiri, atau dengan Test-NetConnection 203.0.113.10 -Port 22 dalam PowerShell pada Windows.

Saya menukar port SSH dan kini tiada apa yang boleh disambungkan. Apa yang tidak kena?

Dua urutan menyebabkan perkara ini. Jika firewall tidak pernah mendapat peraturan untuk port baharu, percubaan ke port baharu akan tamat masa manakala port 22 menolak, jadi sudo ufw allow 2222/tcp perlu dilakukan sebelum penukaran port dan bukan selepasnya. Jika kotak tersebut menggunakan pengaktifan soket systemd untuk SSH, Port 2222 dalam sshd_config diabaikan dan systemd terus memegang port lama, yang boleh anda sahkan dengan systemctl is-enabled ssh.socket. Pulihkan melalui konsol pembekal, betulkan mana-mana yang berkenaan, kemudian sambung dengan ssh -p 2222 user@203.0.113.10 sebaik sahaja sudo ss -tlnp menunjukkan soket baharu.