Add Username Authentication to Dante

Move a Dante 1.4.4 SOCKS policy from source-only access to an explicit account check while keeping source and destination restrictions.

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.

Tënë sô zo