Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #4971 > unrolled thread

incoming ssh blocked by ISP

Back to article view | Back to comp.os.linux.networking

Contents

  incoming ssh blocked by ISP Bob Tennent <rdtennent@tennent.ca> - 2021-11-06 15:28 +0000
    Re: incoming ssh blocked by ISP Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-11-06 16:28 +0000
      Re: incoming ssh blocked by ISP Bob Tennent <rdtennent@tennent.ca> - 2021-11-06 21:33 +0000
        Re: incoming ssh blocked by ISP Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-11-06 21:54 +0000
          Re: incoming ssh blocked by ISP "Carlos E. R." <robin_listas@es.invalid> - 2021-11-06 23:13 +0100
            Re: incoming ssh blocked by ISP "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2021-11-06 19:16 -0400
              Re: incoming ssh blocked by ISP "Carlos E. R." <robin_listas@es.invalid> - 2021-11-07 00:28 +0100
          Re: incoming ssh blocked by ISP William Unruh <unruh@invalid.ca> - 2021-11-07 03:03 +0000
          Re: incoming ssh blocked by ISP Marco Moock <invalid@invalid.invalid> - 2021-11-07 12:44 +0100
        Re: incoming ssh blocked by ISP "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2021-11-06 17:57 -0400
          Re: incoming ssh blocked by ISP "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2021-11-06 18:01 -0400
            Re: incoming ssh blocked by ISP Bob Tennent <rdtennent@tennent.ca> - 2021-11-07 01:56 +0000
              Re: incoming ssh blocked by ISP Bob Tennent <rdtennent@tennent.ca> - 2021-11-07 21:21 +0000
                Re: incoming ssh blocked by ISP "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2021-11-07 19:05 -0500
                  Re: incoming ssh blocked by ISP ant@zimage.comANT (Ant) - 2021-11-07 22:51 -0600
                Re: incoming ssh blocked by ISP Bob Tennent <rdtennent@tennent.ca> - 2021-11-08 01:18 +0000
                  Re: incoming ssh blocked by ISP "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2021-11-07 21:25 -0500
                    Re: incoming ssh blocked by ISP Bit Twister <BitTwister@mouse-potato.com> - 2021-11-07 23:35 -0600
        Re: incoming ssh blocked by ISP William Unruh <unruh@invalid.ca> - 2021-11-07 02:51 +0000
      Re: incoming ssh blocked by ISP "Carlos E. R." <robin_listas@es.invalid> - 2021-11-06 22:47 +0100
        Re: incoming ssh blocked by ISP Dan Purgert <dan@djph.net> - 2021-11-10 13:13 +0000
    Re: incoming ssh blocked by ISP "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2021-11-06 13:43 -0400
    Re: incoming ssh blocked by ISP Pascal Hambourg <pascal@plouf.fr.eu.org> - 2021-11-06 19:18 +0100
    Re: incoming ssh blocked by ISP Marco Moock <invalid@invalid.invalid> - 2021-11-06 19:35 +0100
      Re: incoming ssh blocked by ISP William Unruh <unruh@invalid.ca> - 2021-11-06 19:54 +0000
        Re: incoming ssh blocked by ISP Bob Tennent <rdtennent@tennent.ca> - 2021-11-06 21:18 +0000
          Re: incoming ssh blocked by ISP "Carlos E. R." <robin_listas@es.invalid> - 2021-11-06 22:47 +0100
            Re: incoming ssh blocked by ISP "Carlos E. R." <robin_listas@es.invalid> - 2021-11-06 23:56 +0100
          Re: incoming ssh blocked by ISP Pascal Hambourg <pascal@plouf.fr.eu.org> - 2021-11-06 23:44 +0100
            Re: incoming ssh blocked by ISP "Carlos E. R." <robin_listas@es.invalid> - 2021-11-06 23:54 +0100
              Re: incoming ssh blocked by ISP Pascal Hambourg <pascal@plouf.fr.eu.org> - 2021-11-07 10:07 +0100
          Re: incoming ssh blocked by ISP Marco Moock <invalid@invalid.invalid> - 2021-11-07 10:22 +0100
            Re: incoming ssh blocked by ISP Pascal Hambourg <pascal@plouf.fr.eu.org> - 2021-11-07 10:51 +0100
              Re: incoming ssh blocked by ISP Marco Moock <invalid@invalid.invalid> - 2021-11-07 11:09 +0100
    Re: incoming ssh blocked by ISP Joe Beanfish <joebeanfish@nospam.duh> - 2021-11-08 14:52 +0000
      Re: incoming ssh blocked by ISP Bob Tennent <rdtennent@tennent.ca> - 2021-11-14 16:42 +0000
        Re: incoming ssh blocked by ISP Marco Moock <mo01@posteo.de> - 2021-11-14 18:01 +0100
        Re: incoming ssh blocked by ISP "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2021-11-14 13:08 -0500
          Re: incoming ssh blocked by ISP Bob Tennent <rdtennent@tennent.ca> - 2021-11-14 19:20 +0000
            Re: incoming ssh blocked by ISP "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2021-11-14 15:06 -0500
              Re: incoming ssh blocked by ISP Bob Tennent <rdtennent@tennent.ca> - 2021-11-14 21:03 +0000
                Re: incoming ssh blocked by ISP "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2021-11-14 16:28 -0500
                  Re: incoming ssh blocked by ISP ant@zimage.comANT (Ant) - 2021-11-15 04:19 -0600
                    Re: incoming ssh blocked by ISP William Unruh <unruh@invalid.ca> - 2021-11-15 20:18 +0000
        Re: incoming ssh blocked by ISP ant@zimage.comANT (Ant) - 2021-11-15 04:18 -0600

Page 1 of 3  [1] 2 3  Next page →

#4971 — incoming ssh blocked by ISP

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.

[toc] | [next] | [standalone]

#4972

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"

[toc] | [prev] | [next] | [standalone]

#4978

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.

[toc] | [prev] | [next] | [standalone]

#4981

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?


-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#4984

On 06/11/2021 22.54, Lew Pitcher wrote:
> 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.

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.

[toc] | [prev] | [next] | [standalone]

#4988

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

[toc] | [prev] | [next] | [standalone]

#4989

On 07/11/2021 00.16, David W. Hodgins wrote:
> 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 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.

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.

[toc] | [prev] | [next] | [standalone]

#4992

On 2021-11-06, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> 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?
>

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. 


>

[toc] | [prev] | [next] | [standalone]

#4997

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.

[toc] | [prev] | [next] | [standalone]

#4982

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/

Regards, Dave Hodgins

[toc] | [prev] | [next] | [standalone]

#4983

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/

Regards, Dave Hodgins

[toc] | [prev] | [next] | [standalone]

#4990

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.

[toc] | [prev] | [next] | [standalone]

#4998

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?

[toc] | [prev] | [next] | [standalone]

#4999

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

[toc] | [prev] | [next] | [standalone]

#5002

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| |
   \ _ /
    ( )

[toc] | [prev] | [next] | [standalone]

#5000

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.

[toc] | [prev] | [next] | [standalone]

#5001

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

[toc] | [prev] | [next] | [standalone]

#5003

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

[toc] | [prev] | [next] | [standalone]

#4991

On 2021-11-06, Bob Tennent <rdtennent@tennent.ca> 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.

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. 

[toc] | [prev] | [next] | [standalone]

#4980

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.os.linux.networking

csiph-web