SSH op engem zweete private Wee, während de VPN aktiv bleift

Eng Maschinn erreecht eng aner iwwer eng VPN, an elo wëll een déiselwecht Shell iwwer en privaten Netzwierk vum Provider. D'Route existéiert, de Ping geléngt, an den SSH refuséiert nach ëmmer. Déi üblech Ursaach ass, datt den Daemon ni op der neier Adress gelauschtert huet, also gëtt et näischt, mat deem ee sech verbinde kann. Dëst ass en Adressbindungsproblem, ier et e Firewallproblem ass.

Firwat eng nei Route keen neien Listener erschafft

En lauschende Socket gëtt vun engem Prozess erstallt, deen d'Adressen nenne muss, op deenen e Verbindungen unhëlt. Eng Route seet de Paketen nëmmen, wou se hi solle goen; si erschafft keen Listener um Zil. Wann sshd mat enger eenzeger ListenAddress konfiguréiert ass, ginn Verbindungen op all aner lokal Adress refuséiert, och wann d'Schnittstell aktiv ass. Datselwecht gëllt fir eng Socket-Eenheet, déi de Port besëtzt, dofir ass déi éischt Kontroll ëmmer dat, wat tatsächlech lauschtert.

Vergläicht déi zwee Weeër no der Ziladress an net nom Numm vun der Schnittstell. E Client verbënnt sech mat enger Adress, an déi Adress muss gebonnen sinn, ier irgendeng Firewallregel wichteg gëtt.

D'Adressen an d'Listener opzielen

Ier Dir eppes ännert, notéiert d'Adressen um Host an d'Sockets, déi et just gëtt.

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

D'Adresslëscht weist, wéi eng privat Adress richteg ass an op wéi enger Schnittstell, während d'Socketlëscht weist, ob eppes un si gebonnen ass. En Listener op 0.0.0.0:22 akzeptéiert schonn all Adress, dofir füügt eng nei Bindung näischt derbäi. En Listener op enger bestëmmter Adress erkläert de Refus direkt. Wann de Port zu enger Socket-Eenheet gehéiert an net zum Daemon, ass d'Konfiguratioun vum Daemon net déi ganz Geschicht.

D'Bindung derbäifügen an déi al behalen

OpenSSH akzeptéiert méi ListenAddress-Anträg, dofir kann de VPN-Wee bestoen bleiwen, während de private derbäikënnt. Test den Fichier, ier Dir en nei lued.

sshd -t
systemctl reload sshd

En duerchgefallene Konfigurationstest léisst den lafenden Daemon onberéiert, an dat ass genau dat, wat Dir wëllt, während Dir iwwer de Wee verbonnen sidd, deen Dir änneret. Behaleft den existéierenden Antrag, füügt déi nei lokal Adress derbäi a bestätegt, datt de Service nei gelued gëtt, ouni déi aktuell Sitzung ze verléieren. Op socket-aktivéierten Installatiounen füügt d'Adress amplaz der Socket-Eenheet derbäi a lued déi Eenheet nei. Liest duerno d'Listenerlëscht nach eng Kéier, well eng Bindung déi ni opgetrueden ass bedeit, datt déi falsch Komponent geännert gouf.

Déi nei Sitzung verifizéieren, ier Dir déi al zoumaacht

Verbindt Iech mat der neier Adress, während déi ursprénglech Sitzung nach oppen ass, a benotzt déi ausféierlech Ausgab, fir ze gesinn, wéi eng Adress a Schlëssel benotzt goufen. Loosst déi ursprénglech Sitzung oppen, bis de Probes zweemol geléngt.

ssh -v [email protected]

Liest d'Debugzäile fir d'Ziladress an de presentéierte Hostschlëssel. Bestätegt de Fangerofdrock vum Hostschlëssel géint e Wäert, deem Dir schonn vertraut, amplaz en onbekannte Schlëssel ze akzeptéieren, well den Netzwierk als privat beschriwwe gëtt. D'neit Zil brauch säin eegene known_hosts-Antrag, an dat ass erwaart. Déi al Verwaltungssitzung sollt eréischt zougemaach ginn, wann de private Wee funktionéiert.

SSH schützt den Transport, awer et mécht zwou Netzwierker net gläichwäerteg fir sech. Entscheet, ob d'Vertraue vum private Transit zu den Daten passt, ier Dir Iech drop verloosst.