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.
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.
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.
Am Sat, 6 Nov 2021 15:28:52 -0000 (UTC)
schrieb Bob Tennent <rdtennent@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.
On Sat, 6 Nov 2021 19:54:48 -0000 (UTC), William Unruh wrote:
On 2021-11-06, Marco Moock <invalid@invalid.invalid> wrote:
Am Sat, 6 Nov 2021 15:28:52 -0000 (UTC)
schrieb Bob Tennent <rdtennent@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.
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.
On 2021-11-06, Marco Moock <invalid@invalid.invalid> wrote:
Am Sat, 6 Nov 2021 15:28:52 -0000 (UTC)
schrieb Bob Tennent <rdtennent@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.
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.
So the OP has to be a bit more forthcoming as what is happening.
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.
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.
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/
That doesn't work. The ISP doesn't allow access of any sort
to the system.
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.
I know what the IP address is by using checkip.dyndns.org
On Sat, 06 Nov 2021 21:33:27 +0000, Bob Tennent wrote:
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.
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?
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 <invalid@invalid.invalid> wrote:
Am Sat, 6 Nov 2021 15:28:52 -0000 (UTC)
schrieb Bob Tennent <rdtennent@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.
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 ?
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 theCheap ISP. The one I use this instant does that as well.
system", then what are you paying them for?
On Sat, 06 Nov 2021 18:13:50 -0400, Carlos E. R.
<robin_listas@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 theCheap ISP. The one I use this instant does that as well.
system", then what are you paying them for?
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.
On Sat, 06 Nov 2021 17:57:50 -0400, David W. Hodgins<dwhodgins@nomail.afraid.org> wrote:
<rdtennent@tennent.ca> wrote:On Sat, 06 Nov 2021 17:33:27 -0400, Bob Tennent
fun-and-profit-with-reverse-ssh-tunnels-and-autossh/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/
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.
On Sat, 06 Nov 2021 21:33:27 +0000, Bob Tennent wrote:
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.
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?
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
How is that different from IPv4 CGNAT ?It results in the same, but there is no direct IPv4 connection to the
Dual-Stack Lite is a promising approach that takes the best of NAT464https://www.networkworld.com/article/2232181/understanding-dual-stack-lite.html
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.
Maybe CG-NAT or directly Dual-Stack lite where IPv4 is tunneled over
IPv6 and IPv4 uses NAT.
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.
Nonsense. If your ISP blocks /all/ inbound ports, then your system is effectively /not/ connected to the internet: both TCP and UDP requireThey can block "incoming" traffic by running a stateful package
that /some/ port be open on each side of the conversation.
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:
<rdtennent@tennent.ca> wrote:On Sat, 06 Nov 2021 17:33:27 -0400, Bob Tennent
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 includefun-and-profit-with-reverse-ssh-tunnels-and-autossh/
https://hobo.house/2016/06/20/
Thanks. This looks like it might be the solution.
Can someone who understands how this reverse-tunnel process
should be working please explain what I need to do?
/home/dave/autossh.logexport AUTOSSH_LOGFILE=/home/dave/autossh.log
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:
<rdtennent@tennent.ca> wrote:On Sat, 06 Nov 2021 17:33:27 -0400, Bob Tennent
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 includefun-and-profit-with-reverse-ssh-tunnels-and-autossh/
https://hobo.house/2016/06/20/
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 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...
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.
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.
Or reverse ssh. I can not describe, I have not used it. Or a tunnel to
some server out there.
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.
But why does the original ssh connection die after about 10It is a security feature, like locking your screen after some minutes.
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)?
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)?
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.
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.
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.
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)?
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 79:33:15 |
| Calls: | 6,658 |
| Calls today: | 4 |
| Files: | 12,203 |
| Messages: | 5,333,088 |
| Posted today: | 1 |