SSH over en anden privat rute, mens VPN'et bliver oppe

En maskine når en anden over en VPN, og nu vil nogen have samme shell over et udbyders private netværk. Ruten findes, ping lykkes, og SSH afviser stadig. Den sædvanlige årsag er, at dæmonen aldrig lyttede på den nye adresse, så der er intet at forbinde til. Det er et adressebindingsproblem, før det er et firewallproblem.

Hvorfor en ny rute ikke skaber en ny lytter

En lyttende socket oprettes af en proces, som angiver de adresser, den vil acceptere. En rute fortæller kun pakkerne, hvor de skal rejse hen; den skaber ikke en lytter ved destinationen. Når sshd er konfigureret med en enkelt ListenAddress, afvises forbindelser til enhver anden lokal adresse, selv om interfacet er oppe. Det samme gælder for en socket-unit, som ejer porten, og derfor er den første kontrol altid, hvad der faktisk lytter.

Sammenlign de to ruter ud fra destinationsadressen i stedet for interfacenavnet. En klient forbinder til en adresse, og den adresse skal være bundet, før nogen firewallregel betyder noget.

List adresserne og lytterne

Før du ændrer noget, skal du notere adresserne på værten og de sockets, der findes nu.

ip -br addr
ss -ltnp | grep ':22'

Adresselisten viser, hvilken privat adresse der er reel, og på hvilket interface, mens socketlisten viser, om noget er bundet til den. En lytter på 0.0.0.0:22 accepterer allerede alle adresser, så en ny binding tilføjer intet. En lytter på én bestemt adresse forklarer afvisningen med det samme. Hvis porten tilhører en socket-unit i stedet for dæmonen, er dæmonkonfigurationen ikke hele historien.

Tilføj bindingen, og behold den gamle

OpenSSH accepterer flere ListenAddress-poster, så VPN-ruten kan blive, mens den private tilføjes. Test filen, før du genindlæser den.

sshd -t
systemctl reload sshd

En mislykket konfigurationstest lader den kørende dæmon være urørt, og det er præcis, hvad du vil, mens du er forbundet over den rute, du redigerer. Behold den eksisterende post, tilføj den nye lokale adresse, og bekræft, at tjenesten genindlæses uden at tabe den aktuelle session. På socket-aktiverede installationer skal du i stedet tilføje adressen til socket-uniten og genindlæse den unit. Læs derefter lytterlisten igen, for en binding, der aldrig dukkede op, betyder, at den forkerte komponent blev redigeret.

Verificér den nye session, før du lukker den gamle

Forbind til den nye adresse, mens den oprindelige session stadig er åben, og brug detaljeret output til at se, hvilken adresse og nøgle der blev brugt. Hold den oprindelige session åben, indtil testen lykkes to gange.

ssh -v [email protected]

Læs fejlretningslinjerne for destinationsadressen og den værtsnøgle, der blev præsenteret. Bekræft værtsnøglens fingeraftryk mod en værdi, du allerede stoler på, i stedet for at acceptere en ukendt nøgle, fordi netværket beskrives som privat. Den nye destination har brug for sin egen known_hosts-post, og det er forventeligt. Først når den private rute virker, bør den gamle administrationssession lukkes.

SSH beskytter transporten, men det gør ikke to netværk ækvivalente i sig selv. Beslut, om den private transits tillid passer til dataene, før du stoler på den.