PuTTY toont Netwerkfout: Verbindingstime-out aan? Bij het openen van de sessie betekent dit dat er binnen de verwachte tijd geen nuttig antwoord is ontvangen. Het adres of de poort kunnen verkeerd zijn, het netwerkpad kan onbereikbaar of asymmetrisch zijn, of een apparaat kan de pakketten zonder antwoord laten. Op dit moment zijn het wachtwoord en de SSH-sleutel nog niet aan de orde.
Een verbindingsweigering is anders: de TCP-verbinding is geweigerd, bijvoorbeeld door een poort zonder actieve service of door een tussenliggend apparaat. Deze weigering bewijst op zich niet dat de juiste server heeft gereageerd. Raak voor deze andere tak de diagnose van Connection refused in PuTTY aan. De handleiding beschrijft officieel de PuTTY-timeout als de afwezigheid van een reactie van de server en noemt met name een geïsoleerde of uitgeschakelde server en een adres dat geverifieerd moet worden. Het geeft ook aan dat een timeout kan optreden na een contactverlies tijdens een verbinding: deze gids richt zich op het openen van de sessie.
Ga niet blindelings zonder de server aan te passen: controleer eerst de bestemming en het pad vanuit Windows, en vergelijk deze observaties met de listening, de retourroute en de filtering aan de Linux-zijde. Voor serveropdrachten, gebruik een onafhankelijke console aangeboden door de hoster, de VM of fysieke toegang. Houd elke SSH-sessie die al geopend is open.
Identificeer de timeout voordat u iets verandert
Noteer de exacte tekst die door PuTTY wordt weergegeven, het tijdstip met de tijdzone, de gebruikte sessie, de hostnaam, de poort en de fase waarin de storing zich voordoet. Noteer ook of u gebruik maakt van een proxy die in PuTTY is geconfigureerd, een VPN of een bastion. De beschikbare details in het Event Log van PuTTY kunnen helpen om het geprobeerd pad en adres te bevestigen.
- Timeout bij het openen: er is binnen de verwachte tijd geen nuttig antwoord ontvangen. Dit wijst op het adres, de routering of stille filtering, zonder deze oorzaken uit elkaar te halen.
- Connection refused: het pad heeft een TCP-weigering ontvangen. Controleer de specifieke tak voor verbinding geweigerd.
- Server weigerde onze sleutel: het transport heeft de authenticatiefase bereikt; dit is een andere storing. U kunt dan de gids voor het gebruik van een SSH-sleutel met PuTTY raadplegen.
- Een gevestigde sessie wordt verbroken na een periode van inactiviteit: dit is niet hetzelfde geval als een timeout bij het openen. Vertrouw niet op een keepalive-instelling om een initiële TCP-route die niet reageert te repareren.
Zoek niet naar een universele tijdsinstelling in PuTTY: het verlengen van de wachttijd repareert geen ontbrekende route of gefilterd pakket.
Controleer het adres, de DNS en de werkelijk gepubliceerde poort
Open de opgeslagen sessie in PuTTY en controleer de host en poort in de SSH-instellingen. Het hostveld bevat een naam of adres, geen URL met https://. Bevestig deze waarden bij de beheerder of in de console van de provider voordat u ze vervangt. Om de velden van een sessie te bekijken, volgt u de instellingen van een SSH-sessie in PuTTY.
In PowerShell vervangt u server.example.net door de geverifieerde naam en 22 door de feitelijk gepubliceerde externe TCP-poort voor uw toegang. Deze waarden zijn voorbeelden, geen instellingen voor uw server.
Resolve-DnsName server.example.net -Type A
Resolve-DnsName server.example.net -Type AAAA
Test-NetConnection -ComputerName server.example.net -Port 22 -InformationLevel DetailedDe eerste twee opdrachten geven afzonderlijk de verkregen IPv4 (A) en IPv6 (AAAA) adressen weer via DNS-resolutie. Vergelijk het teruggegeven adres met het verwachte adres in de console van de provider. Een AAAA-record kan PuTTY laten gebruikmaken van een IPv6-pad dat anders is dan het IPv4-pad. De Microsoft-documentatie van Test-NetConnection gaat in detail in op het TCP-resultaat en de routediagnose.
In de gedetailleerde resultaten van Test-NetConnection merkt u met name RemoteAddress, SourceAddress, InterfaceAlias en TcpTestSucceeded op. U kunt een al geverifieerd adres afzonderlijk testen om een probleem met resolutie te onderscheiden van een TCP-fout. Gebruik geen willekeurig gevonden adres en accepteer geen nieuwe host sleutelhandtekening zonder deze te verifiëren via een betrouwbare kanaal.
TcpTestSucceeded : Truebetekent dat deze test TCP heeft tot deze bestemming, deze poort en dit pad heeft ingesteld, op dat moment. Dit verifieert de SSH-identiteit van de server niet. Als PuTTY nog steeds faalt, vergelijk dan het gebruikte adres en de poort, de eventuele proxy en de instellingen van de sessie.TcpTestSucceeded : Falsegeeft aan dat de TCP-test is mislukt, maar onderscheidt op zich geen timeout van een weigering of lokaliseert het verlies niet. Bewaar het exacte bericht van PuTTY en ga door met controleren.
Een privé adres is doorgaans alleen bereikbaar vanaf het bedoelde netwerk of een VPN met de juiste route. Bij NAT kan de poort die door de client wordt gebruikt verschillen van de interne luisterpoort: bijvoorbeeld, een conceptuele externe poort 2222 kan worden doorgestuurd naar de interne poort 22. Laat de overeenstemming bevestigen; vervang deze voorbeelden niet door veronderstelde waarden. Maak de DNS-cache niet uit reflex leeg: doe dit alleen als is aangetoond dat er een verouderde lokale invoer is.
Vergelijk de paden van Windows, VPN en netwerk
Controleer het actieve netwerk, de toegang tot de verwachte VPN of bastion, de routes en het gebruikte bronadres. Als PuTTY via een proxy gaat, valideert een directe PowerShell-test deze proxy niet: de twee pogingen volgen dan mogelijk niet hetzelfde pad.
De volgende opdrachten zijn voor Windows-zijde uitlezingen. Voor tracert, vervang 192.0.2.20 door het adres van een server waar u toestemming voor heeft om te testen. 192.0.2.20 is een adres gereserveerd voor documentatievoorbeelden, niet het daadwerkelijke adres van uw server.
ipconfig
route print
Test-NetConnection -ComputerName server.example.net -DiagnoseRouting -InformationLevel Detailed
tracert -d 192.0.2.20ipconfig en route print helpen om lokale interfaces en routes te verzamelen. -DiagnoseRouting vraagt om een routingdiagnose; dit is een set verschillende parameters dan de test met -Port, combineer de twee niet in hetzelfde commando. tracert toont traverse stappen, maar sterren kunnen eenvoudigweg aangeven dat ICMP-antwoorden niet worden teruggestuurd. Ze duiden niet met zekerheid het apparaat aan dat SSH blokkeert. Evenzo bewijst een geslaagde ping niet dat SSH toegankelijk is, en een mislukte ping bewijst niet dat de server is uitgeschakeld.
Als dat is toegestaan, vergelijk hetzelfde host en dezelfde poort vanaf een ander netwerk, met de andere instellingen ongewijzigd. Een succes via een hotspot, bijvoorbeeld, wijst op een verschil in pad, bron of toestemming op het eerste netwerk; het bewijst niet automatisch dat de internetprovider de poort 22 blokkeert. Een lijst van toegestane bronadressen kan deze wijziging verklaren. Controleer de uitgaande Windows-regels en netwerbeleid met de administrator. Schakel geen firewall of antivirus uit en omzeil geen netwerkbeleid.
Controleer de listening en de retourroute vanaf Linux
Voer deze uitlezingen uit vanaf de onafhankelijke console van de server, en niet binnen het mislukte PuTTY-venster. Vervang 192.0.2.10 door het daadwerkelijke bronadres dat de server ziet, na NAT of VPN. 192.0.2.10 is een documentatieadres dat vervangen moet worden, geen echte client-IP. Voor een IPv6-bestemming gebruikt u ip -6 route get met het waargenomen IPv6-adres.
ip -br address
ip route
ip route get 192.0.2.10
sudo ss -ltnp
systemctl list-unit-files 'ssh*' --no-pager
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -Tip -br address geeft een samenvatting van de adressen van de interfaces; ip route toont de IPv4-routes en ip route get geeft het gekozen pad naar de te bereiken bron weer. Vergelijk dit pad met de werkelijke route: de aanwezigheid van een standaardroute bewijst niet dat de reactie de client bereikt. Op een distributie waar het binaire bestand niet op /usr/sbin/sshd staat, past u het bekende pad aan in plaats van aan te nemen dat het afwezig is.
ss -ltnp toont de TCP-sockets in listening en, afhankelijk van de rechten, het bijbehorende proces. Controleer de interne poort en het luisteradres: een luisteren beperkt tot 127.0.0.1 is niet toegankelijk van buitenaf. Een luisteren op [::] garandeert op zichzelf geen IPv4-toegankelijkheid. Het openbare adres van een server achter NAT verschijnt niet noodzakelijk op zijn Linux-interfaces.
Identificeer de eenheid die daadwerkelijk wordt gebruikt voordat u de status raadpleegt. Afhankelijk van de distributie kan deze ssh.service of sshd.service heten; socket-activatie kan ssh.socket gebruiken. Een onbekende eenheid betekent dus niet per se dat SSH afwezig is. Controleer alleen de geïdentificeerde eenheid, bijvoorbeeld:
systemctl status ssh.service --no-pagerVervang ssh.service door de bestaande eenheid. De handleiding van OpenSSH voor sshd beschrijft -t als een controle op configuratie en sleutelconsistency, en -T als het weergeven van de actuele configuratie. Deze opties herstarten de service niet. De regels Match kunnen afhankelijk zijn van verbindingsinstellingen; -T alleen bewijst dus niet de configuratie die op elke client van toepassing is. Met socket-activatie, observeer ook de daadwerkelijke listening met ss en de socket-eenheid.
De richtlijnen ListenAddress en Port bepalen luisteradressen en poorten in de configuratie; ze garanderen geen routering, geen firewallregel, noch de publicatie van de poort via NAT. Een poort zonder listening produceert vaak een weigering als het pakket het host zonder stille filtering bereikt: concludeer dus niet dat elke timeout betekent dat de SSH-service is gestopt.
Identificeer filtering zonder SSH naar het gehele internet te openen
Identificeer de firewalls die daadwerkelijk in gebruik zijn voordat u de regels interpreteert. Deze opdrachten zijn uitlezingen en zijn mogelijk niet allemaal beschikbaar op uw distributie:
sudo ufw status verbose
sudo nft list ruleset
sudo firewall-cmd --get-active-zonesAls firewalld actief is, raadpleeg dan de zone die daadwerkelijk aan de interface is gekoppeld, door ZONE te vervangen door de naam ervan:
sudo firewall-cmd --zone=ZONE --list-allEen ontbrekende opdracht bewijst niet dat er geen filtering bestaat: een regel kan zich in een andere beheerder bevinden, op een router of bij de hoster. Voorkom het combineren van firewallbeheerders in een poging om de storing te repareren.
Voor de regel die overeenkomt met het waargenomen pad, controleert u het TCP-protocol, de interne poort, het bronadres dat door de server wordt gezien, de volgorde van de regels en de actie. Een DROP regel kan de verbinding zonder antwoord achterlaten; een REJECT kan een weigering veroorzaken afhankelijk van de vorm van de weigering. Bekijk ook de security groups of cloud-firewalls, de route van de provider, de router, NAT-forwarding, de VPN en een eventuele CGNAT. Een test van het openbare adres vanuit de LAN hangt vooral af van de ondersteuning voor NAT loopback; een forwarding werkt niet noodzakelijk achter een CGNAT.
Corrigeer alleen een regel of route die door de observaties is geïdentificeerd, door de bron te beperken tot de noodzakelijke adressen. Open de poort niet naar 0.0.0.0/0 als standaard en verplaats SSH niet als automatische omzeiling naar poort 443.
Vergelijk logboeken en een korte TCP-captatie
Controleer de logboeken rond het genoteerde tijdstip, en pas de eenheid aan die daadwerkelijk wordt gebruikt:
sudo journalctl -u ssh.service --since '10 minutes ago' --no-pagerVervang ssh.service door de bestaande eenheid, bijvoorbeeld sshd.service of, indien van toepassing, ssh.socket. Sommige distributies registreren ook gebeurtenissen in /var/log/auth.log of /var/log/secure. Een timeout die vóór de SSH-uitwisseling optreedt, kan geen enkele authenticatielijn achterlaten: een lege logboek bewijst de afwezigheid van een poging niet.
Als tcpdump en GNU timeout beschikbaar zijn en u bent bevoegd om te capturen, vervang dan de poort en het adres door de interne poort en de bron die de server echt ziet. Start de capture net voor een nieuwe PuTTY-poging:
sudo timeout 10 tcpdump -ni any -c 20 'tcp port 22 and host 192.0.2.10'In deze opdracht zijn de poort 22 en 192.0.2.10 documentatievoorbeelden die vervangen moeten worden door de waargenomen waarden, geen gegevens van uw storing. De capture stopt na tien seconden of na twintig pakketten. Gebruik de opties -A of -X niet en laat geen permanente capture draaien. Verberg adressen voordat u een uitvoer deelt.
- Geen SYN op het waargenomen punt: controleer na het verifiëren van de interface, het capturefilter, de tijd en het bronadres de bestemming, de route of een upstream-filtering. Dit bewijst op zichzelf niet dat een cloudfirewall het verkeer blokkeert.
- SYN ontvangen, geen respons waargenomen: controleer de lokale filtering, de listening en de capture-omstandigheden. Accuseer
sshdniet zonder verder bewijs. - SYN ontvangen, vervolgens SYN-ACK verzonden, maar geen zichtbare eind-ACK: controleer de retourroute of een filtering aan de client/intermediair zij. Een capture alleen aan de serverzijde lokaliseert het verlies niet definitief.
- SYN gevolgd door een RST: u bent in de tak van de TCP-weigering; raadpleeg de diagnose die is gewijd aan Connection refused.
- Volledige TCP-handshake: TCP heeft op dat moment gewerkt. Vergelijk de capture met de PuTTY-poging, de proxy en de SSH-stap die is bereikt. Dit bewijst noch de identiteit van de server, noch een succesvolle authenticatie.
Corrigeer een bewezen oorzaak en valideer zonder SSH te onderbreken
Voordat u enige wijziging aanbrengt, maak een back-up van het betreffende bestand en zorg ervoor dat u over een back-upconsole beschikt. Voer slechts één wijziging tegelijk uit: corrigeer de bestemming van de sessie, de VPN-route of de specifieke regel die door de tests in twijfel is getrokken. Als u geen onafhankelijke console heeft, stop dan met het maken van wijzigingen op afstand en stuur de resultaten door naar de beheerder.
Wijzig geen sleutels, wachtwoorden, PermitRootLogin of SSH-algoritmen om een netwerkstilte voor authenticatie te repareren. Als u de SSH-configuratie wijzigt, zorg er dan eerst voor dat sshd -t slaagt, en gebruik dan de herlaadprocedure die wordt ondersteund door de eenheid en distributie, nadat u hun werking heeft gecontroleerd. Een herstart of reboot is geen eerste test en een herlaad lost niet noodzakelijkerwijs een verkeerd blootgestelde systemd-socket op.
Start nooit ufw disable, nft flush ruleset of iptables -F. Stop Fail2ban niet blindelings, open SSH niet voor alle bronnen en sluit de oude sessie niet voordat deze geverifieerd is.
Na een correctie, houd de console en de oude sessie geopend. Test in een nieuw PuTTY-venster opnieuw hetzelfde host, dezelfde poort en hetzelfde pad. Verifieer de SSH-handtekening via een betrouwbaar kanaal, ga door tot de authenticatie en bevestig dat een sessie werkt. Als het bericht verandert in Connection refused, keer dan terug naar deze tak in plaats van door te gaan met het diagnosticeren van de timeout.
Om hulp te vragen, geef het tijdstip, de host en de poort, de opgeloste adressen en het bronadres, het VPN/proxypad, de TCP-resultaten en de observatie aan de serverzijde door, evenals de verdachte regel. Verwijder adressen en gevoelige informatie. Presenteer geen uitvoer van niet-uitgevoerde opdrachten als resultaat.