Your SSH Password Is Not a SOCKS Password

You typed a password to start ssh -D. It authenticated your SSH connection. It did not create a password-protected SOCKS account for every program that can reach the new listener.

OpenSSH's dynamic forwarding supplies a local SOCKS service over an authenticated SSH transport. Its SOCKS5 handling selects the no-authentication method; it is not a general SOCKS username/password server.

For personal use, bind locally:

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

Applications on that computer use port 1080 without entering your SSH password as a SOCKS password. The dynamic forwarding documentation describes the listener, and OpenSSH's SOCKS handling source provides the authentication detail.

Sharing changes the problem

Binding to a LAN address makes the port reachable beyond the original local use. Nearby clients do not establish separate SSH sessions just because their traffic passes through yours. If the network allows access, those clients can share your gateway's outward identity.

A firewall can restrict reachable clients but does not add a SOCKS login exchange. For separate SOCKS usernames, quotas, or per-user rules, choose a server supporting those features. Dante, for example, documents SOCKS authentication separately from client-address restrictions.

This also helps with troubleshooting. A client insisting on the SOCKS username/password method may not negotiate with this listener as you expect. Adjust the application or choose a suitable authenticated SOCKS service; repeatedly trying your SSH password addresses the wrong login.

Local-only reachability is still a boundary to understand, rather than a claim that every process on the local computer belongs to the same user.