Fjalëkalimi juaj SSH nuk është fjalëkalim SOCKS
Dalloni hyrjen SSH nga vërtetimi i klientit SOCKS në një dëgjues dinamik OpenSSH.
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.