La tua password SSH non è una password SOCKS
Distingui l'accesso SSH dall'autenticazione client SOCKS su un listener dinamico OpenSSH.
Hai digitato una password per avviare ssh -D. Ha autenticato la tua connessione SSH. Non ha creato un account SOCKS protetto da password per ogni programma che può raggiungere il nuovo listener.
L'inoltro dinamico di OpenSSH fornisce un servizio SOCKS locale su un trasporto SSH autenticato. La sua gestione SOCKS5 sceglie il metodo senza autenticazione; non è un server SOCKS generico con nome utente e password.
Per uso personale, associa localmente:
ssh -N -D 127.0.0.1:1080 [email protected]Le applicazioni su quel computer usano la porta 1080 senza inserire la tua password SSH come password SOCKS. La documentazione sull'inoltro dinamico descrive il listener, e il codice di gestione SOCKS di OpenSSH fornisce il dettaglio dell'autenticazione.
La condivisione cambia il problema
L'associazione a un indirizzo LAN rende la porta raggiungibile oltre l'uso locale originale. I client vicini non stabiliscono sessioni SSH separate solo perché il loro traffico passa attraverso il tuo. Se la rete consente l'accesso, quei client possono condividere l'identità esterna del tuo gateway.
Un firewall può limitare i client raggiungibili ma non aggiunge uno scambio di accesso SOCKS. Per nomi utente SOCKS, quote o regole per utente separati, scegli un server che supporti queste funzionalità. Dante, ad esempio, documenta l'autenticazione SOCKS separatamente dalle restrizioni sugli indirizzi client.
Questo aiuta anche nella risoluzione dei problemi. Un client che insiste sul metodo nome utente/password SOCKS potrebbe non negoziare con questo listener come previsto. Adatta l'applicazione o scegli un servizio SOCKS autenticato adatto; riprovare ripetutamente la password SSH affronta l'accesso sbagliato.
La raggiungibilità solo locale resta un confine da comprendere, non un'affermazione che ogni processo sul computer locale appartenga allo stesso utente.