Am Sun, 7 Nov 2021 10:51:59 +0100
schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:

> How is that different from IPv4 CGNAT ?
It results in the same, but there is no direct IPv4 connection to the
provider like CG-NAT, IPv4 is being tunneled.

> Dual-Stack Lite is a promising approach that takes the best of NAT464
> while avoiding its problems: It uses IPv6-only links between the
> provider and the customer, but does not use NAT64 translation. When a
> device in the customer network sends an IPv4 packet to an external
> destination, the IPv4 packet is encapsulated in an IPv6 packet for
> transport into the provider network. At the LSN, the packet is
> decapsulated and NAT44 is performed (Figure 1). Tunneling IPv4 over
> IPv6 is far simpler than translation, so the performance and
> redundancy concerns are eliminated.
https://www.networkworld.com/article/2232181/understanding-dual-stack-lite.html

Am Sat, 6 Nov 2021 21:54:50 -0000 (UTC)
schrieb Lew Pitcher <lew.pitcher@digitalfreehold.ca>:

> Nonsense. If your ISP blocks /all/ inbound ports, then your system is
> effectively /not/ connected to the internet: both TCP and UDP require
> that /some/ port be open on each side of the conversation.
They can block "incoming" traffic by running a stateful package
inspection firewall that only allows incoming traffic on a port if a
package ha already been sent to the target. That is SPI firewalling.

For TCP, they can just block all incoming packages with no ACK flag
set, so you can properly connect to a server because the outgoing SYN
(only SYN flag set) can pass, but incoming such a package is being
dropped.

On Sun, 7 Nov 2021 01:56:03 -0000 (UTC), Bob Tennent wrote:
> On Sat, 06 Nov 2021 18:01:56 -0400, David W. Hodgins wrote:
> > On Sat, 06 Nov 2021 17:57:50 -0400, David W. Hodgins
> <dwhodgins@nomail.afraid.org> wrote:
> >
> >> On Sat, 06 Nov 2021 17:33:27 -0400, Bob Tennent
> <rdtennent@tennent.ca> wrote:
> >>> That doesn't work. The ISP doesn't allow access of any sort
> >>> to the system.
> >>
> >> As long as one of the systems can access the other, use a
> >> reverse ssh proxy to
> >> allow access in the other direction.
> >>
> >> See http://www.harding.motd.ca/autossh/
> >
> > Sorry, meant to also include
> > https://hobo.house/2016/06/20/
> fun-and-profit-with-reverse-ssh-tunnels-and-autossh/
>
> Thanks. This looks like it might be the solution.

So I'm trying this, following those instructions though I'm
not sure I undestand what's going on.

In my case I believe the "remoteserver" (that can initiate
outbound SSH connections) is my home system called jimmy and
the "homeserver" (that I control and can accept inbound SSH
connections) is an AWS instance with a static IP address.

So on jimmy I execute

ssh AWS -p 9991 -R 8081:localhost:1991

I've opened ports 9991 and 8081 on the AWS firewall and
configured sshd to use port 9991. This command doesn't
generate any error messages and I get connected to AWS.

So then on AWS, I execute

ssh localhost -p 8081

and I get the following error messages:

connect_to localhost port 9991: failed.
kex_exchange_identification: read: Connection reset by peer

I don't know what that means and why I'm told connecting to
port 9991 fails when I specified port 8081.

Can someone who understands how this reverse-tunnel process
should be working please explain what I need to do?

On Sun, 07 Nov 2021 16:21:15 -0500, Bob Tennent <rdtennent@tennent.ca> wrote:
> Can someone who understands how this reverse-tunnel process
> should be working please explain what I need to do?

I run sshd listening to port 59385 to avoid the brute force attacks filling logs
with failed attempts. Note that you need to setup the ssh keys to work with public
keys only. No password.

In my case George's computer is the one that normally cannot be accessed.
Under my id on that computer, in /home/dave/.ssh/config it has ...

Host mine
Hostname davidwhodgins.no-ip.biz
Port 59385
User dave
Compression yes
CompressionLevel 9
ServerAliveInterval 120

It runs autossh at bootup using ...
# cat /etc/rc.d/rc.local
#!/bin/bash
su -l dave -c /home/dave/bin/myautossh &

# cat /home/dave/bin/myautossh
#!/bin/bash
export AUTOSSH_POLL=90
> /home/dave/autossh.log
export AUTOSSH_LOGFILE=/home/dave/autossh.log
/usr/bin/autossh -f -N -M 0 -R 59387:localhost:59385 mine

On my computer /home/dave/.ssh/config has
Host george
Hostname localhost
Port 59387
User dave
Compression yes
ServerAliveInterval 120

So George's computer, at boot starts an ssh connection to my computer, setting
up the reverse tunnel, which listens to port 59387. From my computer I can then
ssh to george's computer, using my id on both.

Hope this helps.

Regards, Dave Hodgins

On Sun, 7 Nov 2021 21:21:15 -0000 (UTC), Bob Tennent wrote:
> On Sun, 7 Nov 2021 01:56:03 -0000 (UTC), Bob Tennent wrote:
> > On Sat, 06 Nov 2021 18:01:56 -0400, David W. Hodgins wrote:
> > > On Sat, 06 Nov 2021 17:57:50 -0400, David W. Hodgins
> > <dwhodgins@nomail.afraid.org> wrote:
> > >
> > >> On Sat, 06 Nov 2021 17:33:27 -0400, Bob Tennent
> > <rdtennent@tennent.ca> wrote:
> > >>> That doesn't work. The ISP doesn't allow access of any sort
> > >>> to the system.
> > >>
> > >> As long as one of the systems can access the other, use a
> > >> reverse ssh proxy to
> > >> allow access in the other direction.
> > >>
> > >> See http://www.harding.motd.ca/autossh/
> > >
> > > Sorry, meant to also include
> > > https://hobo.house/2016/06/20/
> > fun-and-profit-with-reverse-ssh-tunnels-and-autossh/
> >
> > Thanks. This looks like it might be the solution.
>
> So I'm trying this, following those instructions though I'm
> not sure I undestand what's going on.
>
> In my case I believe the "remoteserver" (that can initiate
> outbound SSH connections) is my home system called jimmy and
> the "homeserver" (that I control and can accept inbound SSH
> connections) is an AWS instance with a static IP address.
>
> So on jimmy I execute
>
> ssh AWS -p 9991 -R 8081:localhost:1991
>
> I've opened ports 9991 and 8081 on the AWS firewall and
> configured sshd to use port 9991. This command doesn't
> generate any error messages and I get connected to AWS.
>
> So then on AWS, I execute
>
> ssh localhost -p 8081
>
> and I get the following error messages:
>
> connect_to localhost port 9991: failed.
> kex_exchange_identification: read: Connection reset by peer
>
> I don't know what that means and why I'm told connecting to
> port 9991 fails when I specified port 8081.

It's occurred to me that on AWS, the relevant user is ubuntu
but on jimmy, it's rdt. When I (i.e., rdt) ssh to AWS, my
..ssh/config file specifies that the User is ubuntu. Where do
I (as ubuntu) specify on AWS that the relevant user on jimmy
is rdt? Executing

ssh localhost -p 8081 -l rdt

doesn't seem to make a difference.

On Sun, 07 Nov 2021 20:18:04 -0500, Bob Tennent <rdtennent@tennent.ca> wrote:
> It's occurred to me that on AWS, the relevant user is ubuntu
> but on jimmy, it's rdt. When I (i.e., rdt) ssh to AWS, my
> .ssh/config file specifies that the User is ubuntu. Where do
> I (as ubuntu) specify on AWS that the relevant user on jimmy
> is rdt? Executing
> ssh localhost -p 8081 -l rdt
> doesn't seem to make a difference.

Specify the user etc in ~/.ssh/config.
In /home/rdt/.ssh/config the user will be ubuntu.
In /home/ubuntu.ssh/config the user will be rdt.

Both of the computer's involved have sshd running.

I have it listening to port 59385. Avoid using port 22 both to avoid script kiddies
filling the logs and to avoid cases where the isp blocks connections.

On george's system (the one I normally can not ssh to), the command that connects
to mine and sets up the tunnel, run by autossh is
ssh -N -R 59387:localhost:59385 mine

The "mine" selects the system it connects to from ~/.config including the user,
port and ip address (dynamic dns in my case).
Host mine
Hostname davidwhodgins.no-ip.biz
Port 59385
User dave
Compression yes
CompressionLevel 9
ServerAliveInterval 120

The -N stops it from executing any commands after it connects.
The -R 59387:localhost:59385 tells it to open port 59387 on my computer after
it connects and forwards any connections I make on my computer's port 59387
to port 59385 on George's computer.

On my computer, I just type in ssh george and it gets the info from ~/.ssh/config
Host george
Hostname localhost
Port 59387
User dave
Compression yes
ServerAliveInterval 120

Does that help clarify things?

Regards, Dave Hodgins

David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Sun, 07 Nov 2021 16:21:15 -0500, Bob Tennent <rdtennent@tennent.ca> wrote:
> > Can someone who understands how this reverse-tunnel process
> > should be working please explain what I need to do?

> I run sshd listening to port 59385 to avoid the brute force attacks filling logs
> with failed attempts. Note that you need to setup the ssh keys to work with public
> keys only. No password...

Heh, my former security software employer blocked non-default outgoing
ports but kept the default 22 open.
--
It's too dark already. Can we please stick with daylight saving forever? :(
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
/ /\ /\ \ Please nuke ANT if replying by e-mail.
| |o o| |
\ _ /
( )

On Sun, 07 Nov 2021 21:25:49 -0500, David W. Hodgins wrote:
> On Sun, 07 Nov 2021 20:18:04 -0500, Bob Tennent <rdtennent@tennent.ca> wrote:
>> It's occurred to me that on AWS, the relevant user is ubuntu
>> but on jimmy, it's rdt. When I (i.e., rdt) ssh to AWS, my
>> .ssh/config file specifies that the User is ubuntu. Where do
>> I (as ubuntu) specify on AWS that the relevant user on jimmy
>> is rdt? Executing
>> ssh localhost -p 8081 -l rdt
>> doesn't seem to make a difference.
>
> Specify the user etc in ~/.ssh/config.
> In /home/rdt/.ssh/config the user will be ubuntu.
> In /home/ubuntu.ssh/config the user will be rdt.
>

Remember to set ~/.ssh permissions
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*

On Sat, 06 Nov 2021 15:28:52 +0000, Bob Tennent wrote:

> Outgoing ssh works fine and sshd is active. It's not my
> firewall and I use ddclient and zoneedit.com to deal with my
> dynamic IP address.
>
> When I complain to Support at my ISP I'm told to pay for a
> static IP address. Is there any other solution? I'm not a
> networking expert. I do have login access to a server with a
> static IP address but it's not the system I'm trying to ssh
> into.

It might be a little fiddly to maintain, but you could setup
a tunnel from your dynamic IP host to the static server using
ssh -R. Then, whenever you want, you can ssh into the tunnel
port on the static server which will dump you into the dynamic
host.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Carlos E. R. wrote:
> Or reverse ssh. I can not describe, I have not used it. Or a tunnel to
> some server out there.

Reverse-ssh is pretty nice, but would require a couple bucks a month to
say Linode (or Digital Ocean or any of the other VPS providers out
there).

It's been a little while since I've done this, so I might have an error
or two. Note that this requires sshd to be installed on the machine
behind CGNAT (I think it is, but...)

Hosts:
- PC-H --> the PC behind the CGNAT ISP
- VPS --> the intermediary VPS system
- Laptop --> the device we're carrying around / connecting from outside
with.

User accounts:
- dan@pc-h
- revssh@vps
- you@laptop

1. Setup the tunnel.
- As dan@pc-h, connect to the VPS with the command :
ssh -R 40022:localhost:22 revssh@vps

- This will open a connection to "revssh@vps". Leave it open, but
walk away from "PC-H" now.
- The port "40022" is arbitrary, it can be anything you like, that is
above 1024.
- The port "22" is the port that sshd is listening to on PC-H

2. Grab the laptop, and login to the VPS as normal (i.e. "ssh
revssh@vps".)
- Note: any valid account on the VPS will work for this step.

3. Test the tunnel from the VPS.
- Connect to the tunnel with "ssh -oPort=40022 dan@localhost"
- Authenticate with the proper ssh credentials (private key and/or
password, as appropriate) for the account "dan@pc-h"

4. You should now be sitting at your normal "dan@pc-h" prompt. Use PC-H
as normal, or jump to other hosts on your LAN, as necessary.

HTH :)

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmGLxZYACgkQbWVw5Uzn
KGCV6hAAkax/PjOZol2Gat6KyjN4g+esTsR3n1oND4fHMHC59vSz8oH4/GCtWEim
x5gS1pUzSBSYdT/KoIqw/krIDr/01tjcA6QWToP/nnwFVIjupKsRP5eTEnGdFacr
ksQiLi+JHRRFMWIYYzgNNGIQc4GEgeR6XTXBJHmNIlooKw86tyP7SS/14ZL+P2su
7RagkMvGE6S5ukgiCrjUKJq/O+8WV3Kln3LK9EjhggcPUQCCFCDP+teFWTMbv8tL
miNO2+jpH8wibOotazoKqb3gwtb4ojUniG2KvNgw09Q2/00OeUURbMHpZrDqmhsO
mtUMZV2Fx4p3xm2/PBGI4eVBfV8w1FEcUqJ4zwc2PyD6X6sWk8xUfTV3PmN4w5Rs
3fC91kz0X9G0tTvG3KLOZtiHAQOHbd3aYLeujiY/zSKPeNPhdoEUc11ahnqtOje5
mXfLAetF1TUYTj91X9DTajXC11bDWuKt0avZ3nA2GlAT6laSlvtqJhpXd/2JOkOJ
yE4XVehRSLxP/hK7+rrBImmiNX6lE/K/XCunOf5UuaabctyVwWSmvUVilLus3duN
LykYLg81KF9j8YDOKsPsmDL5j3CAzCFj1bk6+XUL/OYv8pYUYb8tdAh7SzaNiypZ
YrJeZw1OOq6EARLkDU6SJUMKjY2ce0F7bgZKaKcrxt1btSg8HNE=
=Tl56
-----END PGP SIGNATURE-----

--
|_|O|_| Github: https://github.com/dpurgert
|_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
|O|O|O| Former PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281

On Mon, 8 Nov 2021 14:52:17 -0000 (UTC), Joe Beanfish wrote:
> On Sat, 06 Nov 2021 15:28:52 +0000, Bob Tennent wrote:
>
>> Outgoing ssh works fine and sshd is active. It's not my
>> firewall and I use ddclient and zoneedit.com to deal with my
>> dynamic IP address.
>>
>> When I complain to Support at my ISP I'm told to pay for a
>> static IP address. Is there any other solution? I'm not a
>> networking expert. I do have login access to a server with a
>> static IP address but it's not the system I'm trying to ssh
>> into.
>
> It might be a little fiddly to maintain, but you could setup
> a tunnel from your dynamic IP host to the static server using
> ssh -R. Then, whenever you want, you can ssh into the tunnel
> port on the static server which will dump you into the dynamic
> host.

As suggested by you and others, I've been able to set up
a reverse ssh tunnel and can make it persistent by using
autossh.

But why does the original ssh connection die after about 10
minutes of inactivity (and have to be renewed by autossh)?
Is this a security feature on the server and beyond my
control (I don't have superuser privileges)?

Am Sun, 14 Nov 2021 16:42:41 -0000 (UTC)
schrieb Bob Tennent <rdtennent@tennent.ca>:

> But why does the original ssh connection die after about 10
> minutes of inactivity (and have to be renewed by autossh)?
> Is this a security feature on the server and beyond my
> control (I don't have superuser privileges)?
It is a security feature, like locking your screen after some minutes.

On Sun, 14 Nov 2021 11:42:41 -0500, Bob Tennent <rdtennent@tennent.ca> wrote:
> But why does the original ssh connection die after about 10
> minutes of inactivity (and have to be renewed by autossh)?
> Is this a security feature on the server and beyond my
> control (I don't have superuser privileges)?

That's why I put a line with ServerAliveInterval 120 in the stanza for the host in
~/.ssh/config

With that, autossh should only be needed to re-establish the link if the connection
drops for any reason, such as the remote system being rebooted.

Regards, Dave Hodgins

On Sun, 14 Nov 2021 13:08:10 -0500, David W. Hodgins wrote:
> On Sun, 14 Nov 2021 11:42:41 -0500, Bob Tennent <rdtennent@tennent.ca> wrote:
>> But why does the original ssh connection die after about 10
>> minutes of inactivity (and have to be renewed by autossh)?
>> Is this a security feature on the server and beyond my
>> control (I don't have superuser privileges)?
>
> That's why I put a line with ServerAliveInterval 120 in
> the stanza for the host in ~/.ssh/config
>
> With that, autossh should only be needed to re-establish
> the link if the connection drops for any reason, such as
> the remote system being rebooted.

Since I'm using ssh -R , it's not clear to me which
system should get that configuration option.

On Sun, 14 Nov 2021 14:20:49 -0500, Bob Tennent <rdtennent@tennent.ca> wrote:
> > That's why I put a line with ServerAliveInterval 120 in
> > the stanza for the host in ~/.ssh/config
> >
> > With that, autossh should only be needed to re-establish
> > the link if the connection drops for any reason, such as
> > the remote system being rebooted.
>
> Since I'm using ssh -R , it's not clear to me which
> system should get that configuration option.

Both systems. Also on both I have sshd running with ...
# grep -v -e ^'#' -e ^$ /etc/ssh/sshd_config
Port 59385
AddressFamily inet
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
LogLevel VERBOSE
PermitRootLogin without-password
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
UsePAM yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
GatewayPorts yes
X11Forwarding yes
ClientAliveInterval 45
PermitTunnel yes
Subsystem sftp /usr/libexec/openssh/sftp-server

Note the ClientAliveInterval setting.

Regards, Dave Hodgins

On Sun, 14 Nov 2021 15:06:03 -0500, David W. Hodgins wrote:
> On Sun, 14 Nov 2021 14:20:49 -0500, Bob Tennent <rdtennent@tennent.ca> wrote:
>> > That's why I put a line with ServerAliveInterval 120 in
>> > the stanza for the host in ~/.ssh/config
>> >
>> > With that, autossh should only be needed to re-establish
>> > the link if the connection drops for any reason, such as
>> > the remote system being rebooted.
>>
>> Since I'm using ssh -R , it's not clear to me which
>> system should get that configuration option.
>
> Both systems. Also on both I have sshd running with ...
> # grep -v -e ^'#' -e ^$ /etc/ssh/sshd_config
> Port 59385
> AddressFamily inet
> Protocol 2
> HostKey /etc/ssh/ssh_host_rsa_key
> HostKey /etc/ssh/ssh_host_dsa_key
> LogLevel VERBOSE
> PermitRootLogin without-password
> AuthorizedKeysFile .ssh/authorized_keys
> PasswordAuthentication no
> UsePAM yes
> AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
> AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
> AcceptEnv LC_IDENTIFICATION LC_ALL
> GatewayPorts yes
> X11Forwarding yes
> ClientAliveInterval 45
> PermitTunnel yes
> Subsystem sftp /usr/libexec/openssh/sftp-server
>
> Note the ClientAliveInterval setting.

Thanks. Unfortunately, I don't have su privileges on the
server system and hence can't edit /etc/ssh/sshd_config.

On Sun, 14 Nov 2021 16:03:12 -0500, Bob Tennent <rdtennent@tennent.ca> wrote:
> On Sun, 14 Nov 2021 15:06:03 -0500, David W. Hodgins wrote:
> > Note the ClientAliveInterval setting.

> Thanks. Unfortunately, I don't have su privileges on the
> server system and hence can't edit /etc/ssh/sshd_config.

It defaults to 15 seconds with ClientAliveCountMax defaulting to 3, meaning the
connection will drop after 45 seconds of inactivity.

To avoid having it drop set the ServerAliveInterval to 40 or less. The lower the
number the more overhead an inactive ssh connection generates.

Regards, Dave Hodgins

Bob Tennent <rdtennent@tennent.ca> wrote:
....
> But why does the original ssh connection die after about 10
> minutes of inactivity (and have to be renewed by autossh)?
> Is this a security feature on the server and beyond my
> control (I don't have superuser privileges)?

Enable the keep alive option in your SSH client.
--
It's summer again! Weather and life are loco! Being old sucks. :(
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
/ /\ /\ \ Please nuke ANT if replying by e-mail.
| |o o| |
\ _ /
( )

David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Sun, 14 Nov 2021 16:03:12 -0500, Bob Tennent <rdtennent@tennent.ca> wrote:
> > On Sun, 14 Nov 2021 15:06:03 -0500, David W. Hodgins wrote:
> > > Note the ClientAliveInterval setting.

> > Thanks. Unfortunately, I don't have su privileges on the
> > server system and hence can't edit /etc/ssh/sshd_config.

> It defaults to 15 seconds with ClientAliveCountMax defaulting to 3, meaning the
> connection will drop after 45 seconds of inactivity.

> To avoid having it drop set the ServerAliveInterval to 40 or less. The lower the
> number the more overhead an inactive ssh connection generates.

Interesting. I always wondered why the values were so low.
--
It's summer again! Weather and life are loco! Being old sucks. :(
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
/ /\ /\ \ Please nuke ANT if replying by e-mail.
| |o o| |
\ _ /
( )

On 2021-11-15, Ant <ant@zimage.comANT> wrote:
> David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>> On Sun, 14 Nov 2021 16:03:12 -0500, Bob Tennent <rdtennent@tennent.ca> wrote:
>> > On Sun, 14 Nov 2021 15:06:03 -0500, David W. Hodgins wrote:
>> > > Note the ClientAliveInterval setting.
>
>> > Thanks. Unfortunately, I don't have su privileges on the
>> > server system and hence can't edit /etc/ssh/sshd_config.
>
>> It defaults to 15 seconds with ClientAliveCountMax defaulting to 3, meaning the
>> connection will drop after 45 seconds of inactivity.
>
>> To avoid having it drop set the ServerAliveInterval to 40 or less. The lower the
>> number the more overhead an inactive ssh connection generates.
>
> Interesting. I always wondered why the values were so low.

When connections were 300Bd I can see this being a concern. With 1Gb/sec
connection, that overhead is surely completely trivial.