Keni shkruar një fjalëkalim për të nisur ssh -D. Ai vërtetoi lidhjen tuaj SSH. Nuk krijoi një llogari SOCKS të mbrojtur me fjalëkalim për çdo program që mund të arrijë dëgjuesin e ri.

Përcjellja dinamike e OpenSSH ofron një shërbim SOCKS lokal mbi një transport SSH të vërtetuar. Trajtimi i tij i SOCKS5 zgjedh metodën pa vërtetim; nuk është një server SOCKS i përgjithshëm me emër përdoruesi dhe fjalëkalim.

Për përdorim personal, lidheni lokalisht:

ssh -N -D 127.0.0.1:1080 [email protected]

Aplikacionet në atë kompjuter përdorin portën 1080 pa futur fjalëkalimin tuaj SSH si fjalëkalim SOCKS. Dokumentacioni i përcjelljes dinamike përshkruan dëgjuesin, dhe kodi burimor i trajtimit SOCKS të OpenSSH jep detajin e vërtetimit.

Ndarja ndryshon problemin

Lidhja me një adresë LAN e bën portën të arritshme përtej përdorimit fillestar lokal. Klientët e afërt nuk krijojnë sesione SSH të veçanta vetëm sepse trafiku i tyre kalon përmes tuajit. Nëse rrjeti lejon akses, ata klientë mund të ndajnë identitetin e jashtëm të portës tuaj.

Një mur zjarri mund të kufizojë klientët e arritshëm, por nuk shton një shkëmbim hyrjeje SOCKS. Për emra përdoruesish SOCKS, kuota ose rregulla për secilin përdorues veç e veç, zgjidhni një server që i mbështet këto veçori. Dante, për shembull, dokumenton vërtetimin SOCKS veçmas nga kufizimet e adresave të klientëve.

Kjo ndihmon edhe në zgjidhjen e problemeve. Një klient që këmbëngul në metodën e emrit të përdoruesit/fjalëkalimit SOCKS mund të mos negociojë me këtë dëgjues siç prisni. Rregulloni aplikacionin ose zgjidhni një shërbim SOCKS të vërtetuar të përshtatshëm; provimi i përsëritur i fjalëkalimit tuaj SSH adreson hyrjen e gabuar.

Arritshmëria vetëm lokale mbetet një kufi për t'u kuptuar, jo një pohim se çdo proces në kompjuterin lokal i përket të njëjtit përdorues.

Artikuj të ngjashëm