Choosing SOCKS5 Authentication Methods in Dante

With SOCKS5, authentication is negotiated before the client sends its destination request. That makes an early credential failure a different event from an FTP, HTTPS or other application failure beyond the proxy.

The client’s greeting lists the authentication methods it supports. The server chooses one method from that list and sends the selection back. A value of 0xff means no offered method is acceptable, and the connection must close. The client does not simply try every server-side method after a password fails.

What Dante’s ordering controls

Dante 1.4.x calls the protocol-level setting socksmethod. Its documentation says methods are listed in preference order. For a policy that allows both methods, this declaration prefers username/password when the client offers it:

socksmethod: username none

Reversing the list prefers unauthenticated access when both methods are offered:

socksmethod: none username

These are alternative method declarations, not complete server configurations. Listening interfaces, permitted clients, destination rules and any rule-specific authentication constraints still matter.

Allowing none has a concrete consequence: a client offering only no-authentication may be accepted under the applicable rules. Placing username first does not turn a list containing none into a requirement that everyone provide a password.

Choose the requirement first

If every permitted client must authenticate with username/password, configure that requirement consistently in the global and applicable rules instead of adding none as a general compatibility fix. If anonymous access is intentional for a restricted client group, make the group and its permitted destinations explicit.

Dante also has clientmethod, which concerns checks performed when the TCP client connects, before SOCKS negotiation. It is a separate layer from the methods exchanged in the SOCKS5 greeting. Configuration snippets using an older method keyword should be read against the manual for the installed Dante version.

When two clients behave differently, compare what each offers, what Dante selects, and whether the selected method’s sub-negotiation succeeds. Then inspect the SOCKS destination reply. This sequence identifies a missing credential callback without attributing every failure to FTP or changing the server’s authentication policy blindly.

Finally, SOCKS5 username/password authentication does not encrypt the password exchange. Use an appropriately protected transport or network when those credentials need confidentiality.