SSH SOCKS Forwarding Is Separate from TUN Device Errors
Recognize an established SOCKS listener even when the same SSH session later fails to create a separate TUN device.
These two observations can coexist in one SSH log:
Local forwarding listening on 127.0.0.1 port 1080.
Tunnel device open failed.The first concerns a dynamic SOCKS listener. The second concerns a tunnel network device. They are separate forwarding requests.
OpenSSH uses -D for application-level dynamic forwarding and -w for tunnel devices. A Tunnel setting can also request the latter through configuration. Failure to obtain the privileges or server permission for a TUN device does not, by itself, prove that the earlier SOCKS listener was never created.
Read what succeeded before the error: SSH authentication, listener creation, and any later destination-channel request. A listening SOCKS port still needs a compatible client and a reachable, permitted destination. It is evidence about one stage.
If the intended job is only SOCKS forwarding, inspect why a tunnel device was requested at all. A scoped configuration can disable that unrelated request:
ssh -N -o Tunnel=no -D 127.0.0.1:1080 [email protected]Retain the normal SSH host-key and account checks. There is no reason to grant network-device privileges merely to silence an error for a feature the SOCKS route does not need.