I try to set up an ssh vpn (Debian OS server and client both).

I changed /etc/ssh/sshd_config (the server):

PermitTunnel yes
PermitRootLogin without-password

but when I try to connect (the client):

$ ssh -NTCf -vvvw  0:0 root@server-ip

debug1: Authentication succeeded (publickey).
Authenticated to <server-ip> ([<server-ip>]:22).
debug1: Requesting tun unit 0 in mode 1
debug1: sys_tun_open: failed to configure tunnel (mode 1): Operation not permitted
Tunnel device open failed.
Could not request tunnel forwarding.

What can be wrong? Please help!


I tried to run ssh as root, but still has errors (the client):

# ssh -i ~user/.ssh/id_rsa -NTCf -vvvw any root@server-ip
debug1: Requesting tun unit 2147483647 in mode 1
debug1: sys_tun_open: tunnel mode 1 fd 5
Tunnel device open failed.
Could not request tunnel forwarding.
debug2: fd 3 setting TCP_NODELAY

Client configuration:

OpenSSH_7.7p1 Debian-2, OpenSSL 1.0.2o  27 Mar 2018
Linux 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64
Debian GNU/Linux testing (buster)

The creation of a network interface requires root (or at least CAP_NET_ADMIN) privileges. The error message tells the client ssh command couldn't create the tun0 interface, as confirmed by this strace excerpt when running the client ssh:

21510 open("/dev/net/tun", O_RDWR)      = 4
21510 ioctl(4, TUNSETIFF, 0x7fff5f9f1530) = -1 EPERM (Operation not permitted)
21510 close(4)                          = 0
21510 write(2, "Tunnel device open failed.\r\n", 28) = 28
21510 write(2, "Could not request tunnel forward"..., 38) = 38

The simpliest is to run it as root, for example (configuring and) using sudo or su -c and probably providing the right ssh key using -i (or it could pick root's ssh key instead). On a Debian client, this works:

su -c 'ssh -i ~myuser/.ssh/id_rsa -NTCf -w 0:0 root@server-ip'

You should replace -w 0:0 with -w any while testing to avoid clashing.

An alternate method, still requiring root (or CAP_NET_ADMIN) anyway, is to create in advance the interface following the common naming convention (tunX with X the number reused later in the ssh parameter) but giving the access to the ssh user to this interface:

# ip tuntap add name tun0 mode tun user myuser
# ip address add dev tun0
# ip link set dev tun0 up

The same can be done (by root) on remote server if the remote ssh user won't be root.

The ssh command (running as myuser, eg: ssh -NTCf -w 0:0 remoteuser@server-ip) will then be able to tunnel the traffic by using the pre-existing tunnel interfaces with matching names.

If you don't have any privileges on the client side, nor are allowed instead to run VMs or containers with network access to server-ip, you probably can't succeed.

NOTE: at the time of this Q/A, as OP found, in Debian buster (testing at this time) the packages openssh-client and openssh-server version 1:7.7p1-2 had a bug preventing the use of tun/tap tunnels. The fix in Debian was made available since (Debian) version 1:7.7p1-3.

  • Thank you for explanation, the bug about operation not permitted has solved, but still has another bug, please, see updated post Jul 2 '18 at 9:23
  • /var/log/auth.log has no errors, it contains exactly the same lines as about just simply ssh login (without options). Jul 2 '18 at 9:59
  • I can't reproduce it on a stable Debian (physical host). I ran two LXC containers, one with Debian stable, the other with Debian testing, enabled tun/tap in the containers. Works in Debian stable, gets your exact error message in Debian testing. So it's related to using Debian testing instead of Debian stable (stretch). I'm stopping here
    – A.B
    Jul 2 '18 at 11:58
  • 1
    NB it is CAP_NET_ADMIN not NET_CAP_ADMIN per capabilities(7).
    – jonathanjo
    Apr 20 '21 at 11:38
  • 1
    @jonathanjo indeed. Fixed.
    – A.B
    Apr 20 '21 at 11:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.