openssh bugs - Sep 2023 - [Bug 3614] New: add setting to redirect all Network access over client

https://bugzilla.mindrot.org/show_bug.cgi?id=3614

            Bug ID: 3614
           Summary: add setting to redirect all Network access over client
           Product: Portable OpenSSH
           Version: 9.4p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: micet2004-github at yahoo.de

Currently I have several RaspberryPi for SmartHome reasons. Goal is,
non of this devices has pure unfiltered Internet access, I wish limit
them on specific IP adresses or domains.

These devices only need Internet access If I'm connected over ssh to do
updates and other configuration.

I wish a setting on ssh that allows me to redirect all network traffic
through my client. I prefer a "take all but exclude" way of
configuration.

May settings on ssh-server is also needed.

Im not a ssh professional so my example may not suits youur needs.

ssh SERVER --network  // take all
ssh SERVER --network[ex:192.168.1,3.1-200] // take all, but exclude
ssh SERVER --network[settings1] // act acording to [settings1]

ssh_config:
NetworkRedirect settings1[192.168.1,3.1-200] // without ex: only
redirect given range.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3614

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
It's basically not possible for ssh to forward all network traffic
without requiring either bespoke configuration on your system or root
access, and we definitely don't want ssh to have root access.

It is possible to do this via manual configuration via tun forwarding,
though how to do this is deeply dependent on your particular system.
E.g. here's an example for Archlinux
https://wiki.archlinux.org/title/VPN_over_SSH#Enable_forwarding_for_the_TUN_device

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3614

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #2 from Darren Tucker <dtucker at dtucker.net>
---
> to do updates and other configuration.
I did something like this, but at the application instead of the
network layer.  I had a HTTP proxy (I used Squid, but you could use
anything, or in a pinch you could use another ssh -D as a SOCKS proxy),
then when I logged in I had a remote port forward to that proxy ("ssh
-L 3128:127.0.0.1:3128 device"), and configured the device's package
manager to use 127.0.0.1:3128 as a HTTP proxy.

To use ssh itself as the proxy without a separate proxy server, you
could probably do something like this (admittedly it's bit Rube
Goldberg):

Host sandbox-device
  ProxyCommand ssh -D 1080 localhost netcat %h %p
  RemoteForward 1080 127.0.0.1:1080

The ProxyCommand would make an SSH connection to itself and establish a
SOCKS server on 1080 then connect from there to your device, and the
RemoteForward would forward port 1080 on that device to the SOCKS
server, which would relay out to the world.  Your package manager would
need to be configured to use a SOCKS proxy, though.

There are also tools like http://darkk.net.ru/redsocks/ which act as an
adapter between iptables transparent redirects and a SOCKS server such
as ssh -D.  There is a bunch of related discussion on bug#1295 and
bug#2526.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3614

--- Comment #3 from micet2004-github at yahoo.de ---
@Darren Tucker 

I had in mind something like that. Years ago I used tsocks for such
ideas but tsocks seems last version from 2002 and redsocks 2016. In my
environment It's not that important but that  motivated me to put it
here, because I assume server, that only need Internet on a maintenance
connection may a common case.

Around 2008 where I used tsocks last time it was, because it was not
possible to run some application with a socks proxy. May this changed.


@Damien Miller

I'm not sure, where the pro and cons between both ways are. Currently,
it seems that the socks way seems more easy to set-up.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3614

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
yeah, if you can use SOCKS then you should use SOCKS. Note however that
ssh's SOCKS support doesn't cover *all* network traffic, just TCP.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3614

--- Comment #5 from micet2004-github at yahoo.de ---
(In reply to Damien Miller from comment #4)
> yeah, if you can use SOCKS then you should use SOCKS. Note however
> that ssh's SOCKS support doesn't cover *all* network traffic, just
> TCP.
If you have this setting than IMHO you only need it for update reasons.
So I assume TCP should be enough. If you agree this feature request
could be helpful for several users, than the socks way could be an easy
start for this. If some more cases rise out of this possibility than I
propose a re-thinking of this feature and design an enhancement with
the experience got until then and the case user tell that time.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3614

--- Comment #6 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to micet2004-github from comment #5)
> If you agree this feature
> request could be helpful for several users, than the socks way could
> be an easy start for this.
I neglected to mention it in my earlier reply, but this already exists
in the one-argument variant of -R / RemoteForward:

     -R [bind_address:]port
             Specifies that connections to the given TCP port or Unix
socket
             on the remote (server) host are to be forwarded to the
local
             side.

             This works by allocating a socket to listen to either a
TCP port
             or to a Unix socket on the remote side. Whenever a
connection is
             made to this port  [...]  if no explicit destination was
             specified, ssh will act as a SOCKS 4/5 proxy and forward
connec-
             tions to the destinations requested by the remote SOCKS
client.

It was added in OpenSSH 7.6:https://www.openssh.com/txt/release-7.6

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.