Via SSH-pasvorto ne estas SOCKS-pasvorto
Distinguu SSH-ensaluton de SOCKS-klienta aŭtentikigo ĉe dinamika OpenSSH-aŭskultilo.
Vi tajpis pasvorton por lanĉi ssh -D. Ĝi aŭtentikigis vian SSH-konekton. Ĝi tamen ne kreis pasvortprotektitan SOCKS-konton por ĉiu programo, kiu povas atingi la novan aŭskultilon.
La dinamika plusendado de OpenSSH liveras lokan SOCKS-servon super aŭtentikigita SSH-transporto. Ĝia SOCKS5-traktado elektas la metodon sen aŭtentikigo; ĝi ne estas ĝenerala SOCKS-servilo kun uzantnomo kaj pasvorto.
Por persona uzo, ligu loke:
ssh -N -D 127.0.0.1:1080 [email protected]Programoj sur tiu komputilo uzas pordon 1080 sen enigi vian SSH-pasvorton kiel SOCKS-pasvorton. La dokumentaro pri dinamika plusendado priskribas la aŭskultilon, kaj la fontkodo de SOCKS-traktado en OpenSSH donas la aŭtentikigan detalon.
Kunhavigado ŝanĝas la problemon
Ligi al LAN-adreso igas la pordon atingebla preter la origina loka uzo. Proksimaj klientoj ne starigas apartajn SSH-sesiojn nur ĉar ilia trafiko pasas tra la via. Se la reto permesas aliron, tiuj klientoj povas kunhavigi la eksteran identecon de via enirejo.
Fajroŝirmilo povas limigi atingeblajn klientojn, sed ĝi ne aldonas SOCKS-ensalutan interŝanĝon. Por apartaj SOCKS-uzantnomoj, kvotoj aŭ reguloj por uzanto, elektu servilon subtenantan tiujn funkciojn. Dante, ekzemple, dokumentas SOCKS-aŭtentikigon aparte de klientadresaj limigoj.
Tio ankaŭ helpas ĉe problemserĉado. Kliento insistanta pri la SOCKS-uzantnoma/pasvorta metodo eble ne intertraktos kun ĉi tiu aŭskultilo tiel, kiel vi atendas. Ĝustigu la programon aŭ elektu taŭgan aŭtentikigitan SOCKS-servon; ripetaj provoj de via SSH-pasvorto alparolas la malĝustan ensaluton.
Nur-loka atingeblo restas limo komprenenda, ne aserto, ke ĉiu procezo sur la loka komputilo apartenas al la sama uzanto.