An existing SSH forwarding account can restrict the destination pairs used by its SOCKS clients. A server-side fragment can allow one named service:

Match User proxyuser
    PermitOpen api.example.net:443

Integrate this with the account’s existing authentication and forwarding policy. PermitOpen does not itself grant forwarding permission or disable shell access.

OpenSSH compares supplied destination names without performing address lookups for that comparison. Except for its documented wildcard forms, the value is not a general hostname pattern.

This matters to SOCKS5. A client sending api.example.net with port 443 can match that pair. A client resolving the same name locally and sending a numeric IP has supplied a different destination string. An alias resolving to the same address is different too.

Keep the client’s local-versus-proxy resolution mode consistent with the intended rule. The allowed hostname’s subsequent resolution still determines where the server connects; this setting is not a DNS-aware prohibition on every private address.

Review key-specific restrictions and other applicable server settings alongside it, because any further forwarding prohibition can still reject the request.

Related articles