An SSH Proxy Account Can Work Without a Shell

Keep SSH forwarding available while disabling shell sessions and understanding the limits of SOCKS-only enforcement.

The tempting setting is AllowTcpForwarding no. Unfortunately, it also disables the forwarding a local SSH SOCKS proxy needs. Dynamic forwarding is not a loophole around server policy.

For a dedicated account, OpenSSH separates several capabilities. A policy fragment can allow local forwarding while preventing shell and subsystem sessions:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

The server manual describes MaxSessions 0 as preventing shell, login, and subsystem sessions while permitting forwarding. Integrate this into an existing authenticated account; it is not a complete SSH security configuration.

Forwarding-only is not SOCKS-only

A fixed local forward and a SOCKS request can ultimately ask the server for the same kind of destination connection. Allowing local forwarding does not guarantee a client used a particular SOCKS interface. Do not describe the account as enforcing SOCKS-only use.

PermitOpen can restrict destination host-and-port pairs when a specific list fits the requirement. It is not a general hostname-resolution-aware ban on every private network. Broader address restrictions may need an appropriate host network policy.

Account, key, and included server settings can further restrict forwarding. A blanket forwarding prohibition elsewhere may remove a capability this fragment appears to allow.

Use the normal server administration procedure with a recovery path, then assess allowed and denied capabilities separately. The intended outcome is explicit forwarding permissions, not an interactive login accidentally left available or a proxy disabled by its own restriction.

Erthyglow kevrennek