SSH Connection refused vs timed out: wat is het verschil?

Wat "Connection refused" en "Connection timed out" betekenen bij SSH

Een SSH "connection refused" en een SSH "connection timed out" zijn tegengestelde fouten; de oplossing voor de een is nooit de oplossing voor de ander. "Refused" betekent dat uw pakket de server heeft bereikt en de kernel van de server antwoordde: "hier luistert niets". "Timed out" betekent dat uw pakket niemand heeft bereikt die antwoordde, waardoor uw client heeft gewacht en het uiteindelijk heeft opgegeven. "Refused" is een serviceprobleem op de server. "Timed out" is een padprobleem vóór de server.

Lees de exacte regel die uw client heeft weergegeven, want de formulering vormt de volledige diagnose.

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

De tijdsduur is de tweede aanwijzing. "Refused" komt direct terug, in ongeveer de tijd die één round-trip in beslag neemt. "Timed out" blijft vele seconden staan voordat de melding verschijnt, omdat de client blijft proberen te verzenden voordat deze opgeeft. macOS geeft Operation timed out weer voor dezelfde conditie. Als het protocol zelf nieuw voor u is, dan is hoe SSH werkt en wat sshd doet de achtergrondkennis waarvan deze handleiding uitgaat.

Waarom "Connection refused" goed nieuws is

Refused is een TCP (transmission control protocol) reset. Uw client verstuurt een SYN-pakket naar poort 22. Dit pakket reist over het internet, bereikt de netwerkstack van de server en de kernel vindt geen socket die op die poort luistert. Daarom antwoordt de kernel met een RST (reset) pakket. Uw SSH-client vertaalt die RST naar de melding Connection refused.

Dat ene terugkerende pakket bewijst veel. Het adres is correct. De host staat aan en routeert verkeer. Niets op het pad negeert het verkeer naar die poort stilletjes, omdat er daadwerkelijk een antwoord van de andere kant komt. Elke overgebleven verdachte bevindt zich dus op de server zelf.

• sshd draait niet, omdat het niet kon starten of nooit is ingeschakeld.
• sshd luistert op een andere poort, meestal na een wijziging voor hardening.
• sshd is gebonden aan één adres, zoals ListenAddress 127.0.0.1, waardoor alleen de server zelf de service kan bereiken.
• Een firewall is ingesteld om verkeer te weigeren (reject) in plaats van te negeren (drop), waardoor de firewall namens de host de RST verstuurt. De ufw reject actie en een nftables-regel die eindigt op reject with tcp reset doen dit beide.

Er is nog één situatie die hierop lijkt, maar het niet is: u heeft een adres ingevoerd dat bij een andere actieve host hoort. Die host beantwoordt uw SYN, heeft geen SSH op poort 22 en weigert u beleefd. Controleer het adres voordat u een uur op de verkeerde server doorbrengt. Weten wat een luisterende poort op Linux daadwerkelijk is zorgt ervoor dat de rest van deze sectie sneller leesbaar is.

Hoe u Connection refused oplost

U kunt dit niet via SSH herstellen, omdat juist de SSH-verbinding verbroken is. Open de webconsole of seriële console van uw provider, meld u daar aan en voer vervolgens onderstaande commando's uit.

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

systemctl status ssh gebruikt de unit-naam op Ubuntu en Debian. Op RHEL en afgeleiden zoals AlmaLinux is de unit sshd. ss -tlnp toont elke TCP-socket in de luisterende status samen met het bijbehorende proces; dit is de enige betrouwbare bron: als er geen regel met sshd wordt getoond, luistert er niets, ongeacht wat het configuratiebestand beweert. sshd -T toont de effectieve configuratie nadat elk Include-bestand is samengevoegd; hierin wordt een vergeten poort in /etc/ssh/sshd_config.d/ direct zichtbaar.

Lees de adreskolom zorgvuldig. 0.0.0.0:22 betekent elk IPv4-adres op de server. [::]:22 betekent elk IPv6-adres. 127.0.0.1:22 betekent alleen loopback; hierdoor wordt elke externe verbinding geweigerd, terwijl een lokale ssh localhost perfect werkt.

Als er niets luistert, start de service dan en lees de foutmelding wanneer deze niet wil opstarten.

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

sshd -t valideert de configuratie en toont het bestand en regelnummer van een onjuiste instructie zonder de actieve service te beïnvloeden. Voer dit uit voor elke herstart, omdat een afgekeurde configuratie ertoe leidt dat sshd direct afsluit en uw volgende verbinding wordt geweigerd.

De valkuil van socket-activatie op Ubuntu

Ubuntu 24.04 levert een systemd socket-unit voor OpenSSH. Wanneer die unit is ingeschakeld, beheert systemd de luisterpoort en start het sshd per verbinding. Hierdoor heeft Port 2222 in sshd_config geen effect en blijft de server op de oude poort antwoorden. Controleer in welke modus uw systeem draait voordat u wijzigingen aanbrengt.

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

Als de socket is ingeschakeld, stelt u de poort in de socket-unit in in plaats van in sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

De lege ListenStream=-regel is vereist, omdat systemd-lijstinstellingen worden toegevoegd aan de reeds geconfigureerde waarden. Laat u deze weg, dan luistert de server op beide poorten. Pas de wijziging toe met sudo systemctl daemon-reload en sudo systemctl restart ssh.socket, en bevestig daarna met sudo ss -tlnp dat de nieuwe poort daadwerkelijk wordt beheerd. Het verplaatsen van de poort is een standaardstap bij het beveiligen van SSH op een VPS, en dit is de stap waardoor gebruikers zichzelf het vaakst buitensluiten.

Waarom "Connection timed out" betekent dat er geen antwoord kwam

Een timeout is stilte. Uw client verstuurde een SYN, heeft deze gedurende een minuut of twee meerdere malen opnieuw verzonden, en heeft nooit een pakket als antwoord ontvangen. Er is hier niets over de server bewezen, omdat er nooit iets van de server is vernomen.

Stilte is precies wat een DROP-regel produceert, en het negeren van pakketten (dropping) is een bewuste keuze. Een afwijzing (rejection) vertelt iedereen die scant dat de host bestaat, dus ufw en de netwerkfirewall van elke cloudprovider negeren ongewenste pakketten en sturen niets terug. Uw timeout is meestal een firewall die zijn werk doet op een poort die u open wilde hebben.

• Het adres is onjuist: een DNS-record dat nog verwijst naar een server die u opnieuw heeft opgebouwd, of een typefout die uitkomt op een adres dat niemand gebruikt.
• De host is niet actief: uitgeschakeld, of halverwege een herstart. Een schorsing door een provider vanwege facturatie ziet er van buitenaf identiek uit.
• De host-firewall blokkeert poort 22, meestal omdat ufw enable werd uitgevoerd voordat er een allow-regel bestond.
• Een firewall van de provider voor de instantie blokkeert het pakket, waardoor het besturingssysteem het pakket nooit ziet.
• Uw eigen netwerk blokkeert uitgaand verkeer op poort 22, wat veel voorkomt bij kantoor- en hotelverbindingen.

Voer de test uit vanaf de andere kant van de verbinding

Dit is de fout die de meeste tijd kost. U kunt een verloren pakket niet diagnosticeren vanaf de machine die de pakketten niet bereikt. Als u kon inloggen om het commando uit te voeren, zou u het probleem niet hebben. Elk commando in deze sectie voert u uit op uw eigen machine.

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 toont het adres dat uw machine daadwerkelijk zal gebruiken; hiermee spoort u binnen enkele seconden een verouderd DNS-record op. ssh -G toont de instellingen die uw client toepast na het inlezen van ~/.ssh/config, waardoor een oud Host-blok dat stilletjes de hostnaam, de poort of de gebruiker herschrijft, aan het licht komt. ssh -vvv laat zien hoe ver de poging is gekomen: een laatste regel over het verbinden met het adres gevolgd door een lange pauze duidt op een timeout, terwijl een regel die de externe OpenSSH-versie rapporteert betekent dat TCP al is geslaagd en uw werkelijke probleem bij de authenticatie ligt. Op Windows vervangt Test-NetConnection 203.0.113.10 -Port 22 in PowerShell het commando nc.

Test de poort, niet de host. Een mislukte ping bewijst niets, omdat veel providers ICMP (internet control message protocol) filteren aan de rand van het netwerk. Een geslaagde ping bewijst eveneens niets, omdat dit niets zegt over poort 22.

Wijzig vervolgens de enige variabele die geen enkel commando voor u kan aanpassen: uw netwerk. Probeer het opnieuw via een mobiele hotspot. Als de hotspot wel verbinding maakt en uw vaste verbinding niet, dan bevindt de blokkade zich aan uw kant van het internet, of is uw kantooradres verbannen op de server.

De provider-firewall die u niet vanaf de server kunt zien

De meeste VPS-panelen bieden een netwerk-firewall aan, soms een security group of cloud firewall genoemd, die stroomopwaarts van uw instantie draait en een eigen regellijst bijhoudt. ufw status op de server kan deze niet zien, wat de reden is dat "maar ik heb poort 22 al toegestaan" zo'n veelgehoorde uitspraak is. Open het paneel en lees die lijst voordat u ook maar één regel op de server zelf herschrijft.

Eén commando lost de vraag op, en hiervoor is console-toegang vereist. Start het op de server en probeer vervolgens vanaf uw laptop verbinding te maken terwijl het commando draait.

sudo tcpdump -ni any tcp port 22

Als er niets verschijnt terwijl uw client verbinding probeert te maken, worden de pakketten verwijderd voordat ze het besturingssysteem bereiken; de fout ligt dan bij de provider-firewall of de route naar de host. Als SYN-pakketten wel aankomen maar er geen antwoord vertrekt, vindt de blokkade lokaal plaats en ligt het probleem bij ufw of nftables. Deze enkele test splitst de timeout-tak in tweeën, wat de reden is dat de moeite om de console te openen de moeite waard is.

Volgorde van ufw, IPv6 en het buitensluiten van uzelf

De fout in de volgorde van ufw sluit meer mensen buiten dan welk ander probleem dan ook. sudo ufw enable past direct een standaardbeleid toe waarbij inkomend verkeer wordt geweigerd. Als er geen SSH-regel is ingesteld, blijft uw huidige sessie actief door de bestaande status, maar zal elke nieuwe verbinding een time-out geven. Sta eerst toegang toe en schakel de firewall daarna pas in.

sudo ufw allow OpenSSH
sudo ufw status verbose

Het applicatieprofiel OpenSSH heeft alleen betrekking op poort 22. Als u van plan bent SSH naar 2222 te verplaatsen, is de benodigde regel sudo ufw allow 2222/tcp. Voeg deze toe voordat u de poort wijzigt, niet erna. De uitgebreidere regelset wordt behandeld in ufw firewall basisprincipes voor een VPS, en de veilige volgorde is onderdeel van wat te doen in de eerste tien minuten op een nieuwe VPS.

IPv6 veroorzaakt een time-out die onnatuurlijk aanvoelt. Als de hostnaam een AAAA-record heeft, probeert uw client eerst IPv6. Een server waarvoor de IPv6-regels ontbreken, zal dus blijven hangen, terwijl een poging via IPv4 wel werkt. Scheid de twee handmatig.

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

Als -4 verbinding maakt en -6 niet, ligt de oplossing bij de IPv6-regels van de server. dezelfde poort openen voor IPv6 in ufw legt uit hoe u dit aanpakt.

Het is ook mogelijk dat u uzelf heeft buitengesloten. fail2ban monitort het authenticatielogboek en voegt een firewallregel toe tegen adressen die herhaaldelijk falen. Een verkeerde sleutel of een script dat op de achtergrond opnieuw probeert te verbinden, kan een heel kantooradres blokkeren. Een blokkade die verkeer negeert (drop), lijkt op een time-out. Een blokkade die verkeer weigert (reject), geeft No route to host terug. Vanaf de console:

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

Het toevoegen van uw eigen adres aan ignoreip is onderdeel van een werkende fail2ban-configuratie op Ubuntu 24.04.

Fouten die niet worden geweigerd of waarbij de verbinding niet is verlopen

No route to host betekent dat er een ICMP unreachable-bericht is ontvangen. Of uw eigen machine heeft geen route naar dat netwerk, of een apparaat op het pad heeft geantwoord met een administratieve afwijzing, wat het resultaat is van een iptables REJECT-regel.

Network is unreachable is uw eigen machine die reageert. Deze heeft in het geheel geen route voor die adresfamilie; dit is het gebruikelijke antwoord wanneer een hostnaam alleen naar een IPv6-adres resolveert op een verbinding die alleen IPv4 ondersteunt.

kex_exchange_identification: Connection closed by remote host betekent dat de TCP-verbinding tot stand is gekomen, maar dat de server de verbinding verbrak voordat de sleuteluitwisseling was voltooid. De poort is open en sshd is actief; controleer daarom de serverbelasting, bekijk MaxStartups, of controleer op een ban die werd opgelegd terwijl u verbinding probeerde te maken.

Permission denied (publickey) betekent dat u de authenticatiefase heeft bereikt en daar bent gefaald. Het netwerk en de firewall functioneren naar behoren, dus deze handleiding is hier niet van toepassing. Ga in plaats daarvan naar het oplossen van Permission denied (publickey) bij SSH.

Hoe u weer toegang krijgt en een tweede buitensluiting voorkomt

Elke serieuze VPS-provider biedt een console die niet afhankelijk is van het netwerk van de guest: een seriële console of een VNC-scherm in de browser. Deze console is de herstelroute voor beide scenario's in deze handleiding, omdat deze blijft werken wanneer sshd is gestopt en wanneer een firewallregel al het verkeer negeert. Zoek deze in het configuratiescherm, log in als root of als uw normale gebruiker en voer vervolgens de bovenstaande controles uit. Als u nooit een root-wachtwoord heeft ingesteld, kunnen de meeste configuratieschermen dit voor u resetten.

Waar geen console beschikbaar is, is de reddingsmodus (rescue mode) van de provider het alternatief. Hiermee wordt een klein herstelsysteem opgestart en uw schijf aangekoppeld, zodat u /etc/ssh/sshd_config kunt bewerken of een firewallregel offline kunt verwijderen en opnieuw kunt opstarten.

Twee gewoontes voorkomen een volgende buitensluiting. Houd altijd een tweede SSH-sessie open wanneer u sshd of de firewall bewerkt, omdat die sessie gebruikmaakt van de bestaande verbinding terwijl u een nieuwe test. Zorg daarnaast voor een automatische terugdraai-actie voordat u een risicovolle firewallwijziging doorvoert.

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

De eerste regel plant in dat ufw zichzelf over tien minuten uitschakelt. Pas uw nieuwe regels toe, open een nieuwe SSH-sessie om te verifiëren dat ze werken en voer vervolgens de tweede regel uit om de terugdraai-actie te annuleren. Als u uzelf toch buitensluit, wacht dan tien minuten; de firewall schakelt zichzelf dan uit. De server is daarna ongefilterd totdat u ufw weer inschakelt, dus gebruik dit alleen terwijl u achter het toetsenbord zit en niet als permanente configuratie.

De volgorde van werken

1. Lees de foutmelding en let op hoe lang het duurde voordat deze verscheen.
2. Refused: ga naar de console en controleer met sudo ss -tlnp of er een listening socket is, op welke poort deze actief is en aan welk adres deze is gebonden.
3. Timed out: bevestig het adres vanaf uw eigen machine, controleer vervolgens de firewall van de provider in het configuratiescherm en daarna de lokale firewall op de server.
4. Geen van deze meldingen: u heeft al een TCP-verbinding, dus behandel het als een vraag over authenticatie of serverbelasting, niet als een netwerkprobleem.

FAQ

Waarom geeft SSH "Connection refused" terwijl sshd draait?

Omdat een weigering afkomstig is van de socket, niet van de service, en een draaiende sshd u nog steeds kan weigeren. Open de console van de provider en voer sudo ss -tlnp uit. Een socket op 127.0.0.1:22 weigert elke externe client, omdat deze alleen aan loopback is gebonden. Een socket op een andere poort weigert iedereen die nog steeds poort 22 gebruikt. Als systemd socket activation wordt gebruikt, komt de poort van ssh.socket en niet van sshd_config, dus controleer ook systemctl is-enabled ssh.socket. Een ufw reject-regel geeft namens de host ook een weigering terug, dus lees sudo ufw status verbose voordat u conclusies trekt.

Waarom krijgt SSH een time-out terwijl ufw poort 22 al toestaat?

Omdat een time-out betekent dat er geen antwoord terugkwam, en ufw niet de enige firewall in het pad is. De meeste VPS-panelen draaien een netwerkfirewall voor de instance, en het besturingssysteem ziet nooit wat die firewall tegenhoudt. Voer vanuit de console sudo tcpdump -ni any tcp port 22 uit en probeer verbinding te maken vanaf uw laptop terwijl dit draait. Als er geen pakketten aankomen, vindt de blokkade upstream plaats, in het paneel. Als er wel pakketten aankomen maar er geen antwoord vertrekt, vindt de blokkade lokaal plaats, in ufw of nftables.

Betekent een mislukte ping dat mijn VPS offline is?

Nee. Veel providers filteren ICMP aan de netwerkrand, waardoor een server die normaal verkeer afhandelt elke ping die u verstuurt kan negeren. Een geslaagde ping is in de andere richting net zo onbetrouwbaar, omdat het niets zegt over de vraag of poort 22 openstaat. Test de poort zelf met nc -vz -w 5 203.0.113.10 22 vanaf uw eigen machine, of met Test-NetConnection 203.0.113.10 -Port 22 in PowerShell op Windows.

Ik heb de SSH-poort gewijzigd en nu maakt niets meer verbinding. Wat ging er mis?

Twee zaken veroorzaken dit. Als de firewall nooit een regel voor de nieuwe poort heeft gekregen, krijgen pogingen naar de nieuwe poort een time-out terwijl poort 22 weigert; daarom hoort sudo ufw allow 2222/tcp vóór de poortwijziging en niet erna. Als de server systemd socket activation voor SSH gebruikt, wordt Port 2222 in sshd_config genegeerd en blijft systemd de oude poort vasthouden, wat u kunt bevestigen met systemctl is-enabled ssh.socket. Herstel de toegang via de console van de provider, corrigeer de van toepassing zijnde instelling en maak daarna verbinding met ssh -p 2222 user@203.0.113.10 zodra sudo ss -tlnp de nieuwe socket toont.