similar to: RFC: non-root ssh tun access

Displaying 20 results from an estimated 700 matches similar to: "RFC: non-root ssh tun access"

2006 Mar 10
0
tun with darwin/macos x
hi, the following patch adds ssh tun support for Darwin/MacOS X (layer 2+3). I tested it with Darwin 8.0.1 x86 and MacOS X 10.4 Tiger PPC, I would like to see any tests from MacOS X users. It requires an external tun/tap driver, see below. reyk --- README.platform.orig 2006-02-13 20:22:04.000000000 -0800 +++ README.platform 2006-02-13 20:21:45.000000000 -0800 @@ -30,6 +30,18 @@ gcc,
2017 Oct 10
3
tunnel device name acquisition?
Numerous how-tos all over the Internet show how one would set up a tunnel using ssh, e.g.: ssh -f -o Tunnel=ethernet <server_ip> true I was wondering if there's a way to subsequently acquire the names of the local and remote tun/tap interfaces (e.g., using the default "-w any:any") for subsequent automatic tunnel configuration, e.g.: ip link set $TapDev up ip link set
2013 Mar 22
1
[PATCH] Allow matching HostName against Host entries
It would be useful to allow matching HostName entries against Host entries. That's to say, I would find it very convenient to have an ssh_config like: Host zeus HostName zeus.greek.gods User hades Host hera HostName hera.greek.gods # [ ... ] Host *.greek.gods User poseidon UserKnownHostsFile ~/.ssh/known_hosts.d/athens # [ Default settings for *.greek.gods ] where I
2006 Aug 30
1
[Bug 1223] tun/tap capability only works with root login (openssh-4.3_p2)
http://bugzilla.mindrot.org/show_bug.cgi?id=1223 Summary: tun/tap capability only works with root login (openssh- 4.3_p2) Product: Portable OpenSSH Version: 4.3p2 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: bitbucket at
2006 Feb 10
0
OpenSSH VPN between Mac OS X and OpenBSD
Honestly, I'm probably not the best person to ask this. I really just deal with network performance issues. You should try the OpenSSH development group. I've cc:'d that group on this message. However, a quick look at the code shows that you'd only be getting that warning if both CUSTOM_SYS_TUN_OPEN and SSH_TUN_OPENBSD are not defined. Grep on the first define we find the
2009 Feb 23
6
[Bug 1561] New: Check for up on open tap device
https://bugzilla.mindrot.org/show_bug.cgi?id=1561 Summary: Check for up on open tap device Product: Portable OpenSSH Version: 5.1p1 Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: unassigned-bugs at mindrot.org ReportedBy:
2006 Sep 18
0
[Bug 1231] "Tunnel ethernet" always uses next tap-device
http://bugzilla.mindrot.org/show_bug.cgi?id=1231 Summary: "Tunnel ethernet" always uses next tap-device Product: Portable OpenSSH Version: 4.3p2 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org
2006 Sep 18
0
[Bug 1232] "LocalCommand" is executed before "Tunnel" is set up
http://bugzilla.mindrot.org/show_bug.cgi?id=1232 Summary: "LocalCommand" is executed before "Tunnel" is set up Product: Portable OpenSSH Version: 4.3p2 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org
2009 May 24
0
OpenSSH_5.2p1. non-vpn login to root account requests TUN interface and cannot exit
Hello! I've configured SSH-VPN between two subnets and it works fine. Option Tunnel=yes in config file is set. The problem I run into is that normal SSH login to root account does not terminate on "exit" command. > ssh root at pig pig> exit ;; screen is cleared but does not return to prompt <ctrl-C> Killed by signal 2. ctrl-D does not work. Running ssh with -vvv has
2008 Jul 03
2
[PATCH 1/3] tun: Interface to query tun/tap features.
The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch
2008 Jul 03
2
[PATCH 1/3] tun: Interface to query tun/tap features.
The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch
2007 Jun 22
1
[Bug 1223] tun/tap capability requires root privileges
http://bugzilla.mindrot.org/show_bug.cgi?id=1223 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|tun/tap capability only |tun/tap capability requires |works with root login |root privileges
2006 Sep 30
1
<net/if_tap.h> on FreeBSD
FreeBSD's <net/if_tap.h> requires u_char to be defined: checking net/if_tap.h usability... no checking net/if_tap.h presence... yes configure: WARNING: net/if_tap.h: present but cannot be compiled configure: WARNING: net/if_tap.h: check for missing prerequisite headers? configure: WARNING: net/if_tap.h: see the Autoconf documentation configure: WARNING: net/if_tap.h: section
2008 Jun 25
3
[PATCH 1/4] tun: Interface to query tun/tap features.
The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch
2008 Jun 25
3
[PATCH 1/4] tun: Interface to query tun/tap features.
The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch
2001 Apr 06
0
Protocol 1 not working in openssh-2.5.2p2
After upgrading to openssh-2.5.2p2, my users were unable to login using ssh Protocol 1. Entries like this were showing up in syslog: Apr 5 19:29:45 maple sshd[16726]: Accepted password for anthonyu from ::ffff:192.168.0.2 port 1019 Apr 5 19:29:45 maple sshd[16726]: fatal: stat(/dev/pts/1 19:29:45 sshd[16726]: Accepted password for anthonyu) failed: No such file or directory Apr 5 19:29:45
2009 Sep 20
1
openssh server and tun devices
If an ssh server receives a successful inbound ssh connection with 'ssh -w' without a tunnel number specified (i.e. in 'any' mode), it allocates the next tunnel device available on the server. The next thing the server needs to do is to set up the tunnel device. How does the server know which tunnel device was set up by the current connection? I'd really like something
2020 Jul 15
4
Support for macOS feth devices
Hi, I am currently using the L2 tunnel feature of ssh between two Linux machines, and it works beautifully! As a result, I have come to prefer a workflow that uses an L2 tunnel, but I can't seem to find a long-term solution for this workflow on macOS. At the moment, tap devices on macOS can be generated using a kernel extension like tuntaposx <http://tuntaposx.sourceforge.net/>;
2012 May 09
1
warning from configuring openssh-6.0p1
When running "configure" for openssh-6.0p1 , I got the following output from "configure": configure: WARNING: linux/filter.h: present but cannot be compiled configure: WARNING: linux/filter.h: check for missing prerequisite headers? configure: WARNING: linux/filter.h: see the Autoconf documentation configure: WARNING: linux/filter.h: section "Present But Cannot
2016 Dec 16
3
Call for testing: OpenSSH 7.4
On Thu, Dec 15, 2016 at 4:22 PM, Zev Weiss <zev at bewilderbeest.net> wrote: [...] > I tested (or tried) git commit b737e4d7 on three systems, with somewhat > mixed results. Thanks for the comprehensive testing! > On Mac OSX (macOS?) 10.9, configure failed with: > > ... > checking OpenSSL header version... 1000208f (OpenSSL 1.0.2h 3 May 2016) > checking