incoming ssh blocked by ISP

[Bob Tennent]

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.

[Lew Pitcher]

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?

ISPs sell "internet connectivity" to clients, and most consumer-
grade ISPs block datagrams coming from the internet to certain
well-known ports, often either because they "represent a security
exposure" to the client, or because the ISP would like to gain
an additional income from "power users" by up-selling them on
internet connectivity that they do not deliberately block.

It sounds like your ISP falls into that second category.

Outside of capitulating to the ISP's up-selling requirement,
or changing your ISP to one that does not block incoming SSH,
the only reliable way I can think of to bypass your ISP's
block is to change the port on which you listen for SSH connections.

While TCP and UDP port 22 are officially used for incoming SSH
connections, you /can/, through your ssh server's configuration,
change that port to any other value. If you choose a port number
that your ISP does /not/ block, then your SSH server will accept
incoming connections.

Of course, this means that you must instruct your outside SSH
client to use that port as well.

For the OpenSSH ssh server daemon, you would specify the new
port as part of the sshd_config(5) "ListenAddress" directive or
specify the "-p <portnumber>" option to in the sshd(1) command.

For the OpenSSH ssh client program, you would specify the
same port in the "-p <portnumber>" option of the ssh(1) command.

> 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.

HTH
--
Lew Pitcher
"In Skills, We Trust"

[David W. Hodgins]

Don't use port 22. Even if it's not blocked and you use keys only, not passwords,
all of the failed brute force attempts may fill the file system containing the logs.

In /etc/ssh/sshd_config specify a port such as Port 49775, then use that port
number when connecting, "ssh -p 49775 whatever.hostname".

Regards, Dave Hodgins

[Pascal Hambourg]

How do you know ?

[Marco Moock]

Am Sat, 6 Nov 2021 15:28:52 -0000 (UTC)
schrieb Bob Tennent <rdte...@tennent.ca>:

Tell you ISP to disable it and if it doesn't don't pay them anymore
because they restrict your access to the internet. Internet access
means that you are also be able to establish TCP connections to your
computer. This is regardless if you get a static IPv4 address/IPv6 net
or dynamic ones.

[William Unruh]

His post is woefully empty of facts, leading to all sorts of theories.

HIs theory is that the ISP is port blocking him.
His ISPs response has two possibilities-- that he is using a dynamic
adress and thus never knows what the IP address is of his machine. Or
that the ISP blocks most incoming ports on dynamic addresses. But not
static.

The above advice is pretty useless since the ISP will then simply block
all incoming abd outgoing ports (ie disconnect him), which will
accomplish what?

So the OP has to be a bit more forthcoming as what is happening.

[Bob Tennent]

On Sat, 6 Nov 2021 19:54:48 -0000 (UTC), William Unruh wrote:
> On 2021-11-06, Marco Moock <inv...@invalid.invalid> wrote:
>> Am Sat, 6 Nov 2021 15:28:52 -0000 (UTC)
>> schrieb Bob Tennent <rdte...@tennent.ca>:
>>
>>> 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.
>>
>> Tell you ISP to disable it and if it doesn't don't pay them anymore
>> because they restrict your access to the internet. Internet access
>> means that you are also be able to establish TCP connections to your
>> computer. This is regardless if you get a static IPv4 address/IPv6 net
>> or dynamic ones.
>>
>

> HIs theory is that the ISP is port blocking him.

Not my theory. The ISP is not allowing me to access the IP
address in any way. I believe they are using some sort of
NAT to conserve IP addresses.

> His ISPs response has two possibilities-- that he is
> using a dynamic adress and thus never knows what the IP
> address is of his machine.

I know what the IP address is by using checkip.dyndns.org
internally. But externally, that IP address is inaccessible,
even to pings.

> So the OP has to be a bit more forthcoming as what is happening.

What more can I say?

[Bob Tennent]

On Sat, 6 Nov 2021 16:28:16 -0000 (UTC), Lew Pitcher 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?
>
> ISPs sell "internet connectivity" to clients, and most consumer-
> grade ISPs block datagrams coming from the internet to certain
> well-known ports, often either because they "represent a security
> exposure" to the client, or because the ISP would like to gain
> an additional income from "power users" by up-selling them on
> internet connectivity that they do not deliberately block.
>
> It sounds like your ISP falls into that second category.
>
> Outside of capitulating to the ISP's up-selling requirement,
> or changing your ISP to one that does not block incoming SSH,
> the only reliable way I can think of to bypass your ISP's
> block is to change the port on which you listen for SSH connections.

That doesn't work. The ISP doesn't allow access of any sort
to the system.

[Carlos E. R.]

On 06/11/2021 22.18, Bob Tennent wrote:
> On Sat, 6 Nov 2021 19:54:48 -0000 (UTC), William Unruh wrote:
> > On 2021-11-06, Marco Moock <inv...@invalid.invalid> wrote:
> >> Am Sat, 6 Nov 2021 15:28:52 -0000 (UTC)
> >> schrieb Bob Tennent <rdte...@tennent.ca>:

...

> > HIs theory is that the ISP is port blocking him.
>
> Not my theory. The ISP is not allowing me to access the IP
> address in any way. I believe they are using some sort of
> NAT to conserve IP addresses.

GNAT. That is not blocking, it is a limitation of the technology. Change
ISP or pay.

Look what it means in the wikipedia.

--
Cheers,
Carlos E.R.

[Carlos E. R.]

On 06/11/2021 17.28, Lew Pitcher 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?
>
> ISPs sell "internet connectivity" to clients, and most consumer-
> grade ISPs block datagrams coming from the internet to certain
> well-known ports,

Here they don't. Not at all.

What some do is GNAT, though.

> often either because they "represent a security
> exposure" to the client, or because the ISP would like to gain
> an additional income from "power users" by up-selling them on
> internet connectivity that they do not deliberately block.
>
> It sounds like your ISP falls into that second category.
>
> Outside of capitulating to the ISP's up-selling requirement,
> or changing your ISP to one that does not block incoming SSH,
> the only reliable way I can think of to bypass your ISP's
> block is to change the port on which you listen for SSH connections.

Or reverse ssh. I can not describe, I have not used it. Or a tunnel to
some server out there.


--
Cheers,
Carlos E.R.

[Lew Pitcher]

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.

However, if your ISP really "doesn't allow access of any sort to the
system", then what are you paying them for?

[David W. Hodgins]

On Sat, 06 Nov 2021 17:57:50 -0400, David W. Hodgins <dwho...@nomail.afraid.org> wrote:

> On Sat, 06 Nov 2021 17:33:27 -0400, Bob Tennent <rdte...@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/

Regards, Dave Hodgins

[David W. Hodgins]

On Sat, 06 Nov 2021 17:33:27 -0400, Bob Tennent <rdte...@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/

Regards, Dave Hodgins

[Carlos E. R.]

His ISP uses CGNAT. Sorry for the typo, not GNAT.

https://es.wikipedia.org/wiki/Carrier_Grade_NAT

>
> However, if your ISP really "doesn't allow access of any sort to the
> system", then what are you paying them for?

Cheap ISP. The one I use this instant does that as well.

--
Cheers,
Carlos E.R.

[Pascal Hambourg]

Le 06/11/2021 à 22:18, Bob Tennent a écrit :
>
> Not my theory. The ISP is not allowing me to access the IP
> address in any way.

How do you know ? What tests did you do ?

> I believe they are using some sort of
> NAT to conserve IP addresses.

We do not care about your beliefs. We need facts.

> I know what the IP address is by using checkip.dyndns.org

The IP address of what device ?

[Carlos E. R.]

CGNAT, sorry.

You might request your ISP to put you out of the CGNAT and give you
actual Internet service.

Or to put you on IPv6, which is another can of worms.

If they don't, switch ISP.

--
Cheers,
Carlos E.R.

[Carlos E. R.]

On 06/11/2021 23.44, Pascal Hambourg wrote:
> Le 06/11/2021 à 22:18, Bob Tennent a écrit :
>>
>> Not my theory. The ISP is not allowing me to access the IP
>> address in any way.
>
> How do you know ? What tests did you do ?
>
>> I believe they are using some sort of
>> NAT to conserve IP addresses.
>
> We do not care about your beliefs. We need facts.

That paragraph describes perfectly what CGNAT is, and the symptoms match
perfectly. It is impossible to connect to any client of that ISP, they
are on a 10.*.*.* network, behind a NATting router, which as you know,
is not routable and inaccessible from Internet.

He is telling facts, just not in recognizable words for geeks :-P

>
>> I know what the IP address is by using checkip.dyndns.org
>
> The IP address of what device ?

Unfortunately, not his actual IP.

--
Cheers,
Carlos E.R.

[David W. Hodgins]

On Sat, 06 Nov 2021 18:13:50 -0400, Carlos E. R. <robin_...@es.invalid> wrote:
> His ISP uses CGNAT. Sorry for the typo, not GNAT.
> https://es.wikipedia.org/wiki/Carrier_Grade_NAT
>> However, if your ISP really "doesn't allow access of any sort to the
>> system", then what are you paying them for?
> Cheap ISP. The one I use this instant does that as well.

Does ipv6 work on that system? If so, I'd expect the ipv6 address to be accessible.
The isp may still be blocking standard service ports up to 1024, but ports above
that should be accessible with ipv6.

Regards, Dave Hodgins

[Carlos E. R.]

AFAIK, they are not blocking anything, they are just using CGNAT, which
simply makes impossible to connect from outside; same as it is
impossible to connect from internet to any normal home using a normal
router and normal NAT.

All the users of such an ISP are on LAN, not on Internet. Thus not
accessible.

The ISP does this simply because they do not have a large enough pool of
IPv4 addresses, they are impossible buy, they are extinct. But buying
billions of IPv6 addresses is easy and cheap. So, if the ISP wants to
provide IPv6 addresses, the problem is solved. As long as the sites the
customer wants to access or be accessed from also have IPv6.

--
Cheers,
Carlos E.R.

[Bob Tennent]

Thanks. This looks like it might be the solution.

[William Unruh]

You said you do have another machine which you can reach from elsewhere.
You can run and ssh tunnel from your isolated machine to that other
machine. Then going into that other machine you can get to the isolated
one through the tunnel. It is an extra hop, but as mentioned there is
not way you can get to NATted machine from outside. The NAT router has
no way of knowing where to deliver the packets addressed to it.
But if you set up a tunnel, then it does since the tunnel has a NAT
address on the router for that ssh tunnel.


Look for example at autossh which you can start up when you boot up that
isolated machine.

Or you can use ssh itself to open up a tunnel from the isolated machine
to the accessible machine.

[William Unruh]

It is a NATted system. He has a local address of something like
10.5.23.199 The ISPs router than takes an outgoing packet addressed
say as orginating from 10.5.23.199 port 22 and translates that from
address as originating from the router's address (say 137.29.13.114) and
some random high port, say 22945. It keeps a tanslation table which says
if a packet comes to that port then send it out to the internal address
10.5.23.199 port 22.

That translation table keeps changing and thus there is no way that
anyone outside would know which port to send anything to. HOwever
external machines now how to replay to packets because the proper reply
address and port is part of the packet. Thus nothing independent can get
in, but the inside machines can connect to the outside.


>

[Pascal Hambourg]

Le 06/11/2021 à 23:54, Carlos E. R. a écrit :
> On 06/11/2021 23.44, Pascal Hambourg wrote:
>> Le 06/11/2021 à 22:18, Bob Tennent a écrit :
>>>
>>> Not my theory. The ISP is not allowing me to access the IP
>>> address in any way.
>>
>> How do you know ? What tests did you do ?
>>
>>> I believe they are using some sort of
>>> NAT to conserve IP addresses.
>>
>> We do not care about your beliefs. We need facts.
>
> That paragraph describes perfectly what CGNAT is

And other things too. CGNAT is only one possible explanation, like the
OP's own NAT router is not set up for port forwarding.

> and the symptoms match perfectly.

SymptomS ? All we have is one vague symptom "ISP does not allow access
to the IP address".

> It is impossible to connect to any client of that ISP, they
> are on a 10.*.*.* network, behind a NATting router

I did not see any mention of 10.*.*.* in this thread. Do you have
another information source ?

[Marco Moock]

Am Sat, 6 Nov 2021 21:18:30 -0000 (UTC)
schrieb Bob Tennent <rdte...@tennent.ca>:

> Not my theory. The ISP is not allowing me to access the IP
> address in any way. I believe they are using some sort of
> NAT to conserve IP addresses.

Maybe CG-NAT or directly Dual-Stack lite where IPv4 is tunneled over
IPv6 and IPv4 uses NAT. If you have that you can't connect from the
outside by IPv4. Use IPv6 is possible.

[Pascal Hambourg]

Le 07/11/2021 à 10:22, Marco Moock a écrit :
>
> Maybe CG-NAT or directly Dual-Stack lite where IPv4 is tunneled over
> IPv6 and IPv4 uses NAT.

How is that different from IPv4 CGNAT ?

[Marco Moock]

Am Sun, 7 Nov 2021 10:51:59 +0100
schrieb Pascal Hambourg <pas...@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

[Marco Moock]

Am Sat, 6 Nov 2021 21:54:50 -0000 (UTC)
schrieb Lew Pitcher <lew.p...@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.

[Bob Tennent]

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?

[David W. Hodgins]

On Sun, 07 Nov 2021 16:21:15 -0500, Bob Tennent <rdte...@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

[Bob Tennent]

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.

[David W. Hodgins]

On Sun, 07 Nov 2021 20:18:04 -0500, Bob Tennent <rdte...@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

[Ant]

David W. Hodgins <dwho...@nomail.afraid.org> wrote:

> On Sun, 07 Nov 2021 16:21:15 -0500, Bob Tennent <rdte...@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| |
\ _ /
( )

[Bit Twister]

On Sun, 07 Nov 2021 21:25:49 -0500, David W. Hodgins wrote:
> On Sun, 07 Nov 2021 20:18:04 -0500, Bob Tennent <rdte...@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/*

[Joe Beanfish]

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.

[Dan Purgert]

-----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

[Bob Tennent]

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)?

[Marco Moock]

Am Sun, 14 Nov 2021 16:42:41 -0000 (UTC)
schrieb Bob Tennent <rdte...@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.

[David W. Hodgins]

On Sun, 14 Nov 2021 11:42:41 -0500, Bob Tennent <rdte...@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

[Bob Tennent]

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

[David W. Hodgins]

On Sun, 14 Nov 2021 14:20:49 -0500, Bob Tennent <rdte...@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

[Bob Tennent]

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

[David W. Hodgins]

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

[Ant]

Bob Tennent <rdte...@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. :(

[Ant]

Interesting. I always wondered why the values were so low.

[William Unruh]

On 2021-11-15, Ant <a...@zimage.comANT> wrote:
> David W. Hodgins <dwho...@nomail.afraid.org> wrote:
>> On Sun, 14 Nov 2021 16:03:12 -0500, Bob Tennent <rdte...@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.