Ping virker, men SSH feiler over VPN: hvilket trinn gikk i stykker?
Ett detaljert forsøk skiller TCP-nåbarhet, SSH-transport, vertsidentitet, brukerinnlogging og sesjonstillatelse, slik at du slutter å gjette på tunnelen.
Ping-svar og en avvist SSH-innlogging kan begge være sanne samtidig, og paret peker ikke på tunnelen. Ekkosvar og en TCP-tilkobling til port 22 er ulike tester med ulike selektorer, ulike retningslinjer og ofte ulike mål. Ta opp ett bevisst SSH-forsøk, og navngi deretter det siste trinnet det nådde. Den ene artefakten erstatter et dusin spekulative konfigurasjonsendringer.
Ta opp ett forsøk, ikke en økt med pirking
Kjør klienten én gang med detaljert diagnostikk, deling av tilkobling slått av og en begrenset tilkoblingstidsgrense. Å slå av deling betyr noe fordi en tidligere autentisert hovedtilkobling ellers svarer for det nye forsøket og skjuler feilen du jager.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Behold målet, adressefamilien, tidsstemplet og den siste ikke-hemmelige feilen. IPv4-flagget betyr også at dette forsøket ikke sier noe om en IPv6-rute til samme navn, så ikke generaliser fra det. Noter hvor forsøket ble gjort fra. En sjekk på VPN-gatewayen er ikke samme ståsted som en laptop bak den, og de fleste motsetningene i disse sakene kommer av å blande de to.
Trinn én og to: TCP før SSH
Den første grensen er nåbarheten til sockelen: en adresse, en port og en rute som pakken faktisk følger. Hvis TCP-tilkoblingen aldri fullføres, finnes det ennå ingenting over den, og vertsnøkler og kontoer er irrelevante.
nc -vz 10.90.4.20 22
ip route get 10.90.4.20
tcpdump -ni any 'host 10.90.4.20 and port 22'Korreler opptaket med klientforsøket. En SYN som går ut og ingenting som kommer tilbake peker på filtrering, selektorer eller en manglende rute i den fjerne enden; et svar med reset peker på noe som aktivt avviser i stedet for å droppe. Den andre grensen er selve SSH-protokollutvekslingen. En TCP-tilkobling som fullføres og deretter stopper, har passert nåbarheten og gått inn i forhandling, serversvar eller pakkehåndtering. Det er en annen undersøkelse, og det er der størrelsesrelaterte problemer først blir sannsynlige.
Trinn tre: hvis nøkkel svarte
Når transporten er oppe, verifiserer klienten vertsnøkkelen til serveren. En avvisning her er en uttalelse om identitet, ikke om kryptografi: motparten presenterte en nøkkel som retningslinjene dine ikke godtar. Behandle det som en stoppbetingelse og verifiser utenfor båndet, mot konsollen eller operatøren som bygde opp verten på nytt. Å slette den huskede oppføringen for å fjerne advarselen er den ene snarveien du bør avvise, fordi den ødelegger beviset for at noe svarte uventet.
Hvis verten virkelig ble bygget opp på nytt, fjern den gamle oppføringen først etter at det nye fingeravtrykket er bekreftet, og noter dato og årsak. Den neste ingeniøren møter samme advarsel og trenger den konteksten.
Trinn fire og fem: konto kontra tillatelse
Autentisering er den fjerde grensen. Avviste legitimasjoner betyr at serveren vurderte forsøket og avviste det; kontroller kontoen, typen legitimasjon serveren godtar, og serverens egen retningslinje i stedet for VPN-passordet. Den femte grensen er autorisasjon etter vellykket innlogging. En autentisert bruker kan fortsatt nektes et skall, en kommando, et undersystem eller videresending, og disse avvisningene ser ut som feil for noen som bare leser klientens siste linje.
| Last stage reached | What it proves | Where to look next |
|---|---|---|
| No TCP connection | No SSH transport exists | Address, port, route, selectors, filter, listener |
| TCP up, exchange incomplete | Reachability is not the blocker | Server response, negotiation, packet handling |
| Host identity rejected | The peer is not the expected host | Independently verified host key |
| User authentication rejected | The attempt reached authentication | Account, credential and server policy |
| Authenticated, session denied | Login succeeded, the operation did not | Shell, command or forwarding permission |
Stopp etter et par mislykkede passordforsøk. Gjentatte gjetninger gir utelåsinger som deretter ser ut som en andre, urelatert feil og koster mer tid enn den opprinnelige saken.
Tilbakerulling og registreringen du beholder
Endre én ting om gangen, og skriv ned hva du endret før du tester på nytt. Hvis en endring gjør forsøket verre, rull den tilbake umiddelbart i stedet for å stable nok en rettelse oppå. Gjenta den opprinnelige operasjonen fra den opprinnelige klienten og konteksten. En vellykket innlogging fra en annen maskin, på en annen adressefamilie, er ikke en reproduksjon og beviser ikke rettelsen.
Sanitér det du deler. Detaljert klientutdata kan bære interne navn, kontomerker, nøkkelstier og identifikatorer for offentlige nøkler, så publiser den trinnvise konklusjonen i stedet for et rått spor.