Add Username Authentication to Dante

In Dante 1.4.4, the client rules admit the connection before SOCKS negotiation, while the SOCKS rules decide which authenticated requests may proceed. A source-allowlisted connection can still require a username at the second stage.

For operating-system username authentication, review the service identities as well as the method. Reading the account database may require a privileged identity:

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

Use the actual low-privilege service account installed for Dante. Create or select an authorized client account compatible with the username backend; the service identity and the client login are different roles.

Keep the request boundaries

After the existing narrow client rule, require the account on the permitted SOCKS route:

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

The addresses and account name are placeholders. This permits one source, one destination, one command, and the specified authenticated user. Do not replace that boundary with unrestricted sources simply because a password has been added.

The global and rule-specific method settings must agree. Check for an older none-only rule left from a source-only setup. Also retain the intended listener and firewall restrictions.

Test negotiation and access separately

Verify the file with the installed server's configuration-check mode before starting it. Then use an authorized client that actually supports SOCKS5 username/password negotiation. Check missing credentials, incorrect credentials, and a permitted account requesting a forbidden target.

The username/password subnegotiation defined by RFC 1929 does not encrypt the password. A later HTTPS destination session does not protect that earlier proxy exchange. Use an appropriately protected client-to-server path.

A successful configuration check confirms syntax and identities, not the account database or network path. Inspect the server logs for the stage that rejected a real test.