XPost: alt.os.linux

I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.

I run
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work

Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info

-------------------------------------------------------------

debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.xxx.xxx]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local address localhost:22
debug3: send packet: type 80
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug3: receive packet: type 4
debug1: Remote: Forwarding listen address "localhost" overridden by server GatewayPorts
debug3: receive packet: type 82
debug1: remote forward failure for: listen 8024, connect localhost:22
Warning: remote port forwarding failed for listen port 8024
debug1: All remote forwarding requests processed
debug3: send packet: type 1

-----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.

-----------------------------------------------------

debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.234.23]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local address localhost:22
debug3: send packet: type 80
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug3: receive packet: type 4
debug1: Remote: Forwarding listen address "localhost" overridden by server GatewayPorts
debug3: receive packet: type 81
debug1: remote forward success for: listen 8024, connect localhost:22
debug1: All remote forwarding requests processed
debug3: receive packet: type 90


The only difference seems to be that in second case it succeeded and the
first it failed. What could be the problem, and how can I track it down?
The second shows that the machine info does allow port forwarding. Why
could it be failing in the first case?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

William Unruh <unruh@invalid.ca> wrote:

I run
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work

Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info

[...]

debug3: receive packet: type 82
debug1: remote forward failure for: listen 8024, connect localhost:22 -----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.

[...]

debug3: receive packet: type 81
debug1: remote forward success for: listen 8024, connect localhost:22

Packet types 82 and 81 are SSH2_MSG_REQUEST_FAILURE and SSH2_MSG_REQUEST_SUCCESS respectively, so yes, all that these logs
tell us is that you asked the server nicely to listen on a particular
port, and in one case it said yes and in the other case it said no.
There's no field in the SSH2_MSG_REQUEST_FAILURE packet format for a
more detailed error message, unfortunately.

If you're able to run an ordinary shell session on the host that's
refusing your port forwarding requests, my first suggestion would be
to try to make an ordinary process listen on the same port number and
see what error message that gives. For example, something like 'nc -l port-number', if it's a Linux box with nc installed, and if not, some
local equivalent. With any luck that might narrow the problem down -
for example (my first guess) it might turn out that some other process
is already using that port number.

(Also I'm confused about the 'listen 8024' in both error messages,
when your command line suggested that the port you were asking the
server to listen on was 9000. But that's probably not important.)
--
import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1( m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r and m)(0xb80b5dacabab6145,0xf70027d345023,0x7643bc4018957897,0x11c2e5d9951130c9 ,0xa54d9cbe4e8ab,0x746c50eaa1910, "Simon Tatham <anakin@pobox.com>" ))

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On Mon, 20 May 2019 02:25:56 -0400, William Unruh <unruh@invalid.ca> wrote:

I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.
I run
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work
Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info
debug1: remote forward failure for: listen 8024, connect localhost:22 Warning: remote port forwarding failed for listen port 8024

See https://superuser.com/questions/1390259/how-do-i-forward-443-to-my-machine-from-remote
I strongly recommend using a high number port (higher than 1024) rather
then the default 22 to avoid bots trying to crack the password from
filling the disk with log entries. Even though password login is disabled,
that doesn't stop them from trying. Also, only root can open ports 1024
or less.

I'd back up a bit though. What you are trying to do sounds similar to
what I've done using autossh.

http://www.debianadmin.com/autossh-automatically-restart-ssh-sessions-and-tunnels.html
has pretty good starting instructions.

I set up my systems years ago, so would have to dig a bit to get the full details of what I currently have set up. I've just used upgrades since then making minor changes when needed.

If the above instructions are not enough, I can dig through what I have,
though it may take a while. In involves dyndns, router config, sshd
config, ssh, and autossh setup :-)

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2019-05-20, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

On Mon, 20 May 2019 02:25:56 -0400, William Unruh <unruh@invalid.ca> wrote:

I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.
I run
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work
Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info
debug1: remote forward failure for: listen 8024, connect localhost:22
Warning: remote port forwarding failed for listen port 8024

See https://superuser.com/questions/1390259/how-do-i-forward-443-to-my-machine-from-remote
I strongly recommend using a high number port (higher than 1024) rather
then the default 22 to avoid bots trying to crack the password from
filling the disk with log entries. Even though password login is disabled, that doesn't stop them from trying. Also, only root can open ports 1024
or less.

The machine with open port 22 is behind a natting router so there is no
way all those attackers can get at it anyway.

I'd back up a bit though. What you are trying to do sounds similar to
what I've done using autossh.

http://www.debianadmin.com/autossh-automatically-restart-ssh-sessions-and-tunnels.html
has pretty good starting instructions.

I have used autossh from a number of machines without trouble. The
direct use of ssh in my tests was so I could see the logs (-vvv) to see
what the trouble was. As mentioned I tried the same test from two
outside machines and from one it worked and the other not. And this is
very consistant (ie I have tried both many ties and it never works from
arby but always works from barby.)
So there must be some difference but I cannot figure out what.

I set up my systems years ago, so would have to dig a bit to get the full details of what I currently have set up. I've just used upgrades since then making minor changes when needed.

If the above instructions are not enough, I can dig through what I have, though it may take a while. In involves dyndns, router config, sshd
config, ssh, and autossh setup :-)

Regards, Dave Hodgins

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On Mon, 20 May 2019 11:55:48 -0400, William Unruh <unruh@invalid.ca> wrote:

I have used autossh from a number of machines without trouble. The
direct use of ssh in my tests was so I could see the logs (-vvv) to see
what the trouble was. As mentioned I tried the same test from two
outside machines and from one it worked and the other not. And this is
very consistant (ie I have tried both many ties and it never works from
arby but always works from barby.)
So there must be some difference but I cannot figure out what.

Check ~/.ssh/known_hosts

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2019-05-20, Simon Tatham <anakin@pobox.com> wrote:

William Unruh <unruh@invalid.ca> wrote:

I run
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work

Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info

[...]

debug3: receive packet: type 82
debug1: remote forward failure for: listen 8024, connect localhost:22
-----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.

[...]

debug3: receive packet: type 81
debug1: remote forward success for: listen 8024, connect localhost:22

Packet types 82 and 81 are SSH2_MSG_REQUEST_FAILURE and SSH2_MSG_REQUEST_SUCCESS respectively, so yes, all that these logs
tell us is that you asked the server nicely to listen on a particular
port, and in one case it said yes and in the other case it said no.
There's no field in the SSH2_MSG_REQUEST_FAILURE packet format for a
more detailed error message, unfortunately.

If you're able to run an ordinary shell session on the host that's
refusing your port forwarding requests, my first suggestion would be
to try to make an ordinary process listen on the same port number and
see what error message that gives. For example, something like 'nc -l port-number', if it's a Linux box with nc installed, and if not, some
local equivalent. With any luck that might narrow the problem down -
for example (my first guess) it might turn out that some other process
is already using that port number.

The two tests were run from different local machines, behind different
natting routers to the same remote machine (at diff times making sure
they did not interfere with each other). So the fact that one did work
means that there is not something else listening to that port.

(Also I'm confused about the 'listen 8024' in both error messages,
when your command line suggested that the port you were asking the
server to listen on was 9000. But that's probably not important.)

Sorry, I tested various ports.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2019-05-20, William Unruh <unruh@invalid.ca> wrote:

I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.

I run
ssh -vvv -nN -R 9000:localhost:info info

----

that bit might be wrong. should be the sshd port number.




--
When I tried casting out nines I made a hash of it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2019-05-21, Jasen Betts <jasen@xnet.co.nz> wrote:

On 2019-05-20, William Unruh <unruh@invalid.ca> wrote:

I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.

I run
ssh -vvv -nN -R 9000:localhost:info info

----

that bit might be wrong. should be the sshd port number.

yes it was, That should have read
ssh -vvv -nN -R 9000:localhost:22 info
(thats what comes of not cutting and pasting inti newsnet. I did have it
right in the command I used)






--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 20/05/2019 08.25, William Unruh wrote:

I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.

I run
ssh -vvv -nN -R 9000:localhost:22 info
where info is the outside machine.
Unfortunately it does not work

Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info

debug1: remote forward failure for: listen 8024, connect localhost:22 Warning: remote port forwarding failed for listen port 8024

-----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.

debug1: remote forward success for: listen 8024, connect localhost:22
debug1: All remote forwarding requests processed

Feels more like you tested barby before you tested arby, so the port
9000 would already be occupied on the remote machine, you need to see to
that each machine you connect to the remote one will use it's own port.

--

//Aho

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2019-05-21, J.O. Aho <user@example.net> wrote:

On 20/05/2019 08.25, William Unruh wrote:

I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.

I run
ssh -vvv -nN -R 9000:localhost:22 info
where info is the outside machine.
Unfortunately it does not work

Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info

debug1: remote forward failure for: listen 8024, connect localhost:22
Warning: remote port forwarding failed for listen port 8024

-----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.

debug1: remote forward success for: listen 8024, connect localhost:22
debug1: All remote forwarding requests processed

Feels more like you tested barby before you tested arby, so the port
9000 would already be occupied on the remote machine, you need to see to
that each machine you connect to the remote one will use it's own port.

Nope. arby was first. I went to barby only to see if I could make things
work from another machine. I also made sure that any ssh port forwarding
was killed before trying it from another machine. I do and did recognise
the possibility of port blocking.




--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

Groovy hepcat William Unruh was jivin' in alt.os.linux on Mon, 20 May
2019 04:25 pm. It's a cool scene! Dig it.

I am trying to open an ssh tunnel from a machine (let me call it
arby) behind a natting router to another machine, so I can sign in to
that hidden computer from the outside machine, let me call it info.
Info is the name of the outside machine. I can log on to info from
arby using passwordless logon without trouble.

I'm not sure I understand you. You're at arby and trying to create a
tunnel to info so that you can log into arby from info? If that's
correct, why not just ssh to arby from info? You can use dyndns and
your router's port forwarding.

I run
ssh -vvv -nN -R 9000:localhost:info info

I could be wrong here, so please forgive me if I am, but I think what
you are doing here is telling the ssh daemon on the remote host (info)
to make a tunnel to localhost. That is localhost as seen from the
remote side (info), not the local machine (arby), I think. So you're effectively trying to connect from one port on info to another port on
info.
Also I think you need a port number in the third field of the argument
to the -R option, not a host name. (According to man ssh on my system
it's a port number or a socket.)
And if you do sort out those problems, does your router have port
forwarding from outside to arby enabled?

where info is the outside machine.
Unfortunately it does not work

Here is the end of the log produced by -vvv, after logs state tht
there was a successful logon onto info

-------------------------------------------------------------

debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.xxx.xxx]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local
address localhost:22 debug3: send packet: type 80

See here it says "Remote connections from LOCALHOST:8024 forwarded to
local address localhost:22". That is, I believe, coming from the remote
machine (info) and saying that it has tunnelled its own port 8024 to
its own port 22.

debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com
want_reply 0 debug3: receive packet: type 4
debug1: Remote: Forwarding listen address "localhost" overridden by
server GatewayPorts debug3: receive packet: type 82
debug1: remote forward failure for: listen 8024, connect localhost:22 Warning: remote port forwarding failed for listen port 8024
debug1: All remote forwarding requests processed
debug3: send packet: type 1

-----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.

-----------------------------------------------------

debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.234.23]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local
address localhost:22 debug3: send packet: type 80
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com
want_reply 0 debug3: receive packet: type 4
debug1: Remote: Forwarding listen address "localhost" overridden by
server GatewayPorts debug3: receive packet: type 81
debug1: remote forward success for: listen 8024, connect localhost:22
debug1: All remote forwarding requests processed
debug3: receive packet: type 90

The only difference seems to be that in second case it succeeded and
the first it failed. What could be the problem, and how can I track it
down? The second shows that the machine info does allow port
forwarding. Why could it be failing in the first case?

I can't explain why this seems to work from barby while failing from
arby. Have you actually been able to use the created tunnel to access
barby from info? My guess is you haven't.
Anyhow, if I'm correct about what the problem is, you may get better
results by:

a) enabling port forwarding on your router to a login port on arby,
b) using a service like dyndns to determine your router's IP address
(actually your ISP's, but ports should be forwarded from there to
equivalent ones on your router),
c) using that and the forwarded port number in the argument to the -R
option of ssh.

For example, suppose you forward port 1234 on your router to port 22
(the ssh daemon so you can get a login shell) on arby and your router's
IP address is 12.34.56.78, you might do something like:

ssh -vvv -nN -R 9000:12.34.56.78:1234 info

I just want to reiterate that I am not certain about all this. I could
be completely wrong. Also I wasn't entirely sure I understood what
you're trying to do. So please take my comments with due caution.

--


----- Dig the NEW and IMPROVED news sig!! -----


-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2019-05-21, Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> wrote:

Groovy hepcat William Unruh was jivin' in alt.os.linux on Mon, 20 May
2019 04:25 pm. It's a cool scene! Dig it.

I am trying to open an ssh tunnel from a machine (let me call it
arby) behind a natting router to another machine, so I can sign in to
that hidden computer from the outside machine, let me call it info.
Info is the name of the outside machine. I can log on to info from
arby using passwordless logon without trouble.

I'm not sure I understand you. You're at arby and trying to create a
tunnel to info so that you can log into arby from info? If that's
correct, why not just ssh to arby from info? You can use dyndns and
your router's port forwarding.

Because arby is behind a natting router. Ie, there is no way to reach
arby from the internet (the router does not do port forwarding and there
is no way I can set it up to do so).

I run
ssh -vvv -nN -R 9000:localhost:info info

I could be wrong here, so please forgive me if I am, but I think what
you are doing here is telling the ssh daemon on the remote host (info)
to make a tunnel to localhost. That is localhost as seen from the
remote side (info), not the local machine (arby), I think. So you're effectively trying to connect from one port on info to another port on
info.

Nope. That command tells ssh to build a tunnel from info localhost port
9000 to arby localhost port 22.

Also I think you need a port number in the third field of the argument
to the -R option, not a host name. (According to man ssh on my system

Agreed. That was a misprint due to typing rather than copy/pasting.

it's a port number or a socket.)
And if you do sort out those problems, does your router have port forwarding from outside to arby enabled?

No, and I cannot set it up to do so (owned and operated by a landlord
not me-- and he would have no idea what I am talking about if I asked
him to do so, and would certainly not trust me with the router's
password.) And ssh tunnel is the only option. Note that I have done this
many times in the past. This is the first time that I have had trouble
and it seems to be sporadic. Sometimes it works and sometimes not it
seems.

where info is the outside machine.
Unfortunately it does not work

Here is the end of the log produced by -vvv, after logs state tht
there was a successful logon onto info

-------------------------------------------------------------

debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.xxx.xxx]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local
address localhost:22 debug3: send packet: type 80

See here it says "Remote connections from LOCALHOST:8024 forwarded to
local address localhost:22". That is, I believe, coming from the remote machine (info) and saying that it has tunnelled its own port 8024 to
its own port 22.

No it has tunneled its own port 8024 to the port 22 on barby.
I tested it. It works.
ssh localhost 8024 on info connects me to port 22 on barby.

debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com
want_reply 0 debug3: receive packet: type 4
debug1: Remote: Forwarding listen address "localhost" overridden by
server GatewayPorts debug3: receive packet: type 82
debug1: remote forward failure for: listen 8024, connect localhost:22
Warning: remote port forwarding failed for listen port 8024
debug1: All remote forwarding requests processed
debug3: send packet: type 1

-----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.

-----------------------------------------------------

debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.234.23]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local
address localhost:22 debug3: send packet: type 80
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com
want_reply 0 debug3: receive packet: type 4
debug1: Remote: Forwarding listen address "localhost" overridden by
server GatewayPorts debug3: receive packet: type 81
debug1: remote forward success for: listen 8024, connect localhost:22
debug1: All remote forwarding requests processed
debug3: receive packet: type 90


The only difference seems to be that in second case it succeeded and
the first it failed. What could be the problem, and how can I track it
down? The second shows that the machine info does allow port
forwarding. Why could it be failing in the first case?

I can't explain why this seems to work from barby while failing from
arby. Have you actually been able to use the created tunnel to access
barby from info? My guess is you haven't.

Oh, yes. I have. And yes, I cannot understand why it does not work on
arby either.

Anyhow, if I'm correct about what the problem is, you may get better results by:

a) enabling port forwarding on your router to a login port on arby,

As I said, not an option.

b) using a service like dyndns to determine your router's IP address (actually your ISP's, but ports should be forwarded from there to
equivalent ones on your router),

Yes, but when it gets to the router, it dies, see point a

c) using that and the forwarded port number in the argument to the -R
option of ssh.

For example, suppose you forward port 1234 on your router to port 22
(the ssh daemon so you can get a login shell) on arby and your router's
IP address is 12.34.56.78, you might do something like:

ssh -vvv -nN -R 9000:12.34.56.78:1234 info

I just want to reiterate that I am not certain about all this. I could
be completely wrong. Also I wasn't entirely sure I understood what
you're trying to do. So please take my comments with due caution.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/21/19 4:51 PM, William Unruh wrote:

ssh tunnel is the only option. Note that I have done this many times
in the past. This is the first time that I have had trouble and it
seems to be sporadic. Sometimes it works and sometimes not it seems.

ProTip: Specify "127.0.0.1" instead of "localhost" to avoid issues with "localhost" resolving to "::1" unexpectedly. (Or make sure that ::1
works in addition to 127.0.0.1.)

I trust that the ssh remote port forwarding can work. As such, I'm
questioning if the connection between arby and info is going down or
being closed by a naive firewall.

Check to make sure that TCP keep-alive packets are being sent
(TCPKeepAlive, both client and server).

You might also be dealing with some stale forwarding on info if the
connection goes down and tries to come back up before info has detected
this and cleared the old port forwarding.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2019-05-22, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 5/21/19 4:51 PM, William Unruh wrote:

ssh tunnel is the only option. Note that I have done this many times
in the past. This is the first time that I have had trouble and it
seems to be sporadic. Sometimes it works and sometimes not it seems.

ProTip: Specify "127.0.0.1" instead of "localhost" to avoid issues with "localhost" resolving to "::1" unexpectedly. (Or make sure that ::1
works in addition to 127.0.0.1.)

OK, that is a possibility. I will try that.

I trust that the ssh remote port forwarding can work. As such, I'm questioning if the connection between arby and info is going down or
being closed by a naive firewall.

Yes, it can work. It works from barby, and it worked in the past from a different machine called arby. And now it suddenly started to sometimes
work and sometimes not.

Check to make sure that TCP keep-alive packets are being sent
(TCPKeepAlive, both client and server).

The problem is that the tunnel never gets set up. The log in works,
everything (on the arby side) looks like it is getting set up, and then
at the end it says that the tunnel has not been set up.

You might also be dealing with some stale forwarding on info if the connection goes down and tries to come back up before info has detected
this and cleared the old port forwarding.

I do not think so. It did not work even even a day after ( and a
shutdown on arby-- its a laptop) the last time I tried.

I have tried it onto another remote machine (call it message) and the
tunnel works. Bizarre.





--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2019-05-20, William Unruh <unruh@invalid.ca> wrote:

I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.

I run
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work

Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info

fist things first:

what does "ssh localhost" do arby?

if that looks good. doing

arby$ ssh -nN -R 9000:localhost:22 info

followed by

info$ ssh -o HostKeyAlias=arby localhost -p 9000

should work.
(where ...$ is the prompt naming the machine)

if not there should be sufficient error messages to diagnose the problem.

-------------------------------------------------------------

debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.xxx.xxx]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local address localhost:22

???? 9000 or 8024 ????

debug1: remote forward failure for: listen 8024, connect localhost:22 Warning: remote port forwarding failed for listen port 8024

I think that means the port 8024 was already busy.

--
When I tried casting out nines I made a hash of it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On Tue, 21 May 2019 16:09:43 -0400, William Unruh <unruh@invalid.ca> wrote:

Feels more like you tested barby before you tested arby, so the port
9000 would already be occupied on the remote machine, you need to see to
that each machine you connect to the remote one will use it's own port.

Nope. arby was first. I went to barby only to see if I could make things
work from another machine. I also made sure that any ssh port forwarding
was killed before trying it from another machine. I do and did recognise
the possibility of port blocking.

Are they on the same isp? I'm thinking the one isp may be blocking
the connection. I've seen isp do pretty crazy things in the name of
preventing abuse.

I'd try having ssh listen on a port other then 22, like 22222, to see
if that makes a difference.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2019-05-22, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

On Tue, 21 May 2019 16:09:43 -0400, William Unruh <unruh@invalid.ca> wrote:

Feels more like you tested barby before you tested arby, so the port
9000 would already be occupied on the remote machine, you need to see to >>> that each machine you connect to the remote one will use it's own port.

Nope. arby was first. I went to barby only to see if I could make things
work from another machine. I also made sure that any ssh port forwarding
was killed before trying it from another machine. I do and did recognise
the possibility of port blocking.

Are they on the same isp? I'm thinking the one isp may be blocking
the connection. I've seen isp do pretty crazy things in the name of preventing abuse.

No. One is an ISP in the UK, One in Vancouver, and info is on a
University system.

I'd try having ssh listen on a port other then 22, like 22222, to see
if that makes a difference.

Direct ssh (ie, not attempt to set up a tunnel) from arby to info works fine.

The isp at the arby end should not be able to see that an connection is eventually going to port 22 on arby, since it is encrypted in the ssh
tunnel. It should think there is just an ssh connection from arby to
port 22 on info, which it has no trouble with if it is a regular ssh connection.

Regards, Dave Hodgins

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/21/19 11:33 PM, William Unruh wrote:

OK, that is a possibility. I will try that.

Yes, it can work. It works from barby, and it worked in the past
from a different machine called arby. And now it suddenly started to sometimes work and sometimes not.

Does it sometimes work and not work from the same system? Or different systems?

The problem is that the tunnel never gets set up. The log in works, everything (on the arby side) looks like it is getting set up, and
then at the end it says that the tunnel has not been set up.

Check the ssh daemon logs on info. OpenSSH is usually quite good about indicating if it can't establish a tunnel, and why not.

I do not think so. It did not work even even a day after ( and a
shutdown on arby-- its a laptop) the last time I tried.

I'm more convinced by the time than I am the shutdown of arby. What
does "(sudo) netstat -lntp" show on info, particularly about the port
that you're trying to bind to on info, when it fails?

I have tried it onto another remote machine (call it message) and
the tunnel works. Bizarre.

I'm guessing that there is something that is preventing the tunneling
from working. The trick is to find what that something is.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2019-05-22, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 5/21/19 11:33 PM, William Unruh wrote:

OK, that is a possibility. I will try that.

Yes, it can work. It works from barby, and it worked in the past
from a different machine called arby. And now it suddenly started to
sometimes work and sometimes not.

Does it sometimes work and not work from the same system? Or different systems?

Yes, same system.

The problem is that the tunnel never gets set up. The log in works,
everything (on the arby side) looks like it is getting set up, and
then at the end it says that the tunnel has not been set up.

Check the ssh daemon logs on info. OpenSSH is usually quite good about indicating if it can't establish a tunnel, and why not.

Where are the sshd logs? I cannot find almost any info from sshd, except
a couple of lines in /var/log/auth.log

I do not think so. It did not work even even a day after ( and a
shutdown on arby-- its a laptop) the last time I tried.

I'm more convinced by the time than I am the shutdown of arby. What
does "(sudo) netstat -lntp" show on info, particularly about the port
that you're trying to bind to on info, when it fails?

I have tried it onto another remote machine (call it message) and
the tunnel works. Bizarre.

I'm guessing that there is something that is preventing the tunneling
from working. The trick is to find what that something is.

Yes, that is what I am trying to do here in this thread-- hints as to
where I could look for that "something"





--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/22/19 5:29 PM, William Unruh wrote:

Yes, same system.

Okay.

Then it's likely not a configuration issue per say. (It might be
something related to timeouts / retries.)

Where are the sshd logs? I cannot find almost any info from sshd, except
a couple of lines in /var/log/auth.log

I'd expect them to be in /var/log. Usually /var/log/syslog or /var/log/messages. Do an "ls -l /var/log" and look at the files that
were recently modified.

Yes, that is what I am trying to do here in this thread-- hints as to
where I could look for that "something"

ACK

You can crank verbosity up on the server side. You could run the ssh
daemon interactively, though doing so can be tricky.

Check the logs mentioned above.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2019-05-23, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 5/22/19 5:29 PM, William Unruh wrote:

Yes, same system.

Okay.

Then it's likely not a configuration issue per say. (It might be
something related to timeouts / retries.)

Where are the sshd logs? I cannot find almost any info from sshd, except
a couple of lines in /var/log/auth.log

I'd expect them to be in /var/log. Usually /var/log/syslog or /var/log/messages. Do an "ls -l /var/log" and look at the files that
were recently modified.

Nope. Nor in journalctl. (Yes, I run both rsyslog and systemd journal).
All you get are some basic posts to auth.log, which tell one nothing. /var/log/messages and esp /var/log/syslog are altered abount once per
second by all sorts of stuff.

Yes, that is what I am trying to do here in this thread-- hints as to
where I could look for that "something"

ACK

You can crank verbosity up on the server side. You could run the ssh
daemon interactively, though doing so can be tricky.

Yes, it can be tricky, esp for a server machine.

I have looked at man sshd, and there does not seem to be a way of
increasing the verbosity which is logged to syslog.
The only opion is the -d option which
"Debug mode. The server sends verbose debug output to standard error, and does not put itself in the background. The server also will not fork and will only process one
connection. This option is only intended for debugging for the server. Multiple -d options increase the debugging level. Maximum is 3.
"
which is not very helpful.

I would like an option which increases the verbosity, but dumps the
stuff into the system log, not into stderr.

Check the logs mentioned above.

Yes. Nothing there of any help.




--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2019-05-23, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 5/22/19 5:29 PM, William Unruh wrote:

Yes, same system.

Okay.

Then it's likely not a configuration issue per say. (It might be
something related to timeouts / retries.)

Where are the sshd logs? I cannot find almost any info from sshd, except
a couple of lines in /var/log/auth.log

I'd expect them to be in /var/log. Usually /var/log/syslog or /var/log/messages. Do an "ls -l /var/log" and look at the files that
were recently modified.

Yes, that is what I am trying to do here in this thread-- hints as to
where I could look for that "something"

ACK

You can crank verbosity up on the server side. You could run the ssh
daemon interactively, though doing so can be tricky.

Actually I finally found the sshd_config LogLevel directive. However, the syslog
LogLevel does NOT have a DEBUG1, DEBUG2 and DEBUG3 Loglevels which
apparently (nothing documented anywhere) sshd uses for the debug levels. I have no
idea what loglevels for syslog these map to.
Sheesh.

Check the logs mentioned above.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/23/19 1:43 AM, William Unruh wrote:

Actually I finally found the sshd_config LogLevel directive. However,
the syslog LogLevel does NOT have a DEBUG1, DEBUG2 and DEBUG3 Loglevels
which apparently (nothing documented anywhere) sshd uses for the
debug levels. I have no idea what loglevels for syslog these map to.

LogLevel (and it's values) have nothing to do with syslog. Instead they
are parameters to tell the ssh daemon how much detail / data to log.
Further, this logging will be independent of the location that logs are
sent to, STDOUT, STDERR, syslog, etc. They don't have anything to do
with which syslog log level is used.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/23/19 1:11 AM, William Unruh wrote:

Nope. Nor in journalctl. (Yes, I run both rsyslog and systemd journal).
All you get are some basic posts to auth.log, which tell one nothing. /var/log/messages and esp /var/log/syslog are altered abount once
per second by all sorts of stuff.

Okay. Try "grep ssh /var/log/*" as a user with permission to read the
files.

Yes, it can be tricky, esp for a server machine.

Or if you want to change the ssh daemon in a way that requires
restarting ssh when you're using ssh to connect to said machine.

I have looked at man sshd, and there does not seem to be a way of
increasing the verbosity which is logged to syslog.

Search the sshd_config man page for "LogLevel".

The only opion is the -d option which "Debug mode. The server sends
verbose debug output to standard error, and does not put itself
in the background. The server also will not fork and will only
process one connection. This option is only intended for debugging
for the server. Multiple -d options increase the debugging level.
Maximum is 3." which is not very helpful.

It can be helpful in some situations.

I would like an option which increases the verbosity, but dumps the
stuff into the system log, not into stderr.

"LogLevel"

You may even be able to use the -o option to specify the LogLevel config parameter on the command line.

-o is a way to specify config parameters on the command line that don't
have a command line option themselves, like "LogLevel".

Yes. Nothing there of any help.

That surprises me.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2019-05-24, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 5/23/19 1:43 AM, William Unruh wrote:

Actually I finally found the sshd_config LogLevel directive. However,
the syslog LogLevel does NOT have a DEBUG1, DEBUG2 and DEBUG3 Loglevels
which apparently (nothing documented anywhere) sshd uses for the
debug levels. I have no idea what loglevels for syslog these map to.

LogLevel (and it's values) have nothing to do with syslog. Instead they
are parameters to tell the ssh daemon how much detail / data to log.
Further, this logging will be independent of the location that logs are
sent to, STDOUT, STDERR, syslog, etc. They don't have anything to do
with which syslog log level is used.

Well, not really true. For example SyslogFacility is the syslog
facility. And at least the higher levels of LogLevel ARE the syslog
loglevels (ie, using /etc/syslog.conf you can restrict the output.)





--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2019-05-24, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 5/23/19 1:11 AM, William Unruh wrote:

Nope. Nor in journalctl. (Yes, I run both rsyslog and systemd journal).
All you get are some basic posts to auth.log, which tell one nothing.
/var/log/messages and esp /var/log/syslog are altered abount once
per second by all sorts of stuff.

Okay. Try "grep ssh /var/log/*" as a user with permission to read the
files.

Yes, it can be tricky, esp for a server machine.

Or if you want to change the ssh daemon in a way that requires
restarting ssh when you're using ssh to connect to said machine.

Actually it is not too bad.
When you ssh in, the sshd starts up another instance of itself to handle
your connection. When you kill the main sshd daemon (or restart sshd
from whatever init system youuse) you copy of ssh does not get altered.

I have looked at man sshd, and there does not seem to be a way of
increasing the verbosity which is logged to syslog.

Search the sshd_config man page for "LogLevel".

The only opion is the -d option which "Debug mode. The server sends
verbose debug output to standard error, and does not put itself
in the background. The server also will not fork and will only
process one connection. This option is only intended for debugging
for the server. Multiple -d options increase the debugging level.
Maximum is 3." which is not very helpful.

It can be helpful in some situations.

It is the fact that it dumps
stuff onto stderr which is not helpful, and only responds to one
connection.

I would like an option which increases the verbosity, but dumps the
stuff into the system log, not into stderr.

"LogLevel"

You may even be able to use the -o option to specify the LogLevel config parameter on the command line.

-o is a way to specify config parameters on the command line that don't
have a command line option themselves, like "LogLevel".

Yes. Nothing there of any help.

That surprises me.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <qc7vt7$jim$2@dont-email.me> William Unruh <unruh@invalid.ca> writes:

On 2019-05-24, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 5/23/19 1:43 AM, William Unruh wrote:

Actually I finally found the sshd_config LogLevel directive. However,
the syslog LogLevel does NOT have a DEBUG1, DEBUG2 and DEBUG3 Loglevels
which apparently (nothing documented anywhere) sshd uses for the
debug levels. I have no idea what loglevels for syslog these map to.

LogLevel (and it's values) have nothing to do with syslog. Instead they
are parameters to tell the ssh daemon how much detail / data to log.
Further, this logging will be independent of the location that logs are
sent to, STDOUT, STDERR, syslog, etc. They don't have anything to do
with which syslog log level is used.

Well, not really true. For example SyslogFacility is the syslog
facility. And at least the higher levels of LogLevel ARE the syslog
loglevels (ie, using /etc/syslog.conf you can restrict the output.)

Yes, and it would indeed be useful to have the relationship
documented, but there's always the source:-) - from OpenSSH log.c:

switch (level) {
case SYSLOG_LEVEL_FATAL:
if (!log_on_stderr)
txt = "fatal";
pri = LOG_CRIT;
break;
case SYSLOG_LEVEL_ERROR:
if (!log_on_stderr)
txt = "error";
pri = LOG_ERR;
break;
case SYSLOG_LEVEL_INFO:
pri = LOG_INFO;
break;
case SYSLOG_LEVEL_VERBOSE:
pri = LOG_INFO;
break;
case SYSLOG_LEVEL_DEBUG1:
txt = "debug1";
pri = LOG_DEBUG;
break;
case SYSLOG_LEVEL_DEBUG2:
txt = "debug2";
pri = LOG_DEBUG;
break;
case SYSLOG_LEVEL_DEBUG3:
txt = "debug3";
pri = LOG_DEBUG;
break;
default:
txt = "internal error";
pri = LOG_ERR;
break;
}

--Per Hedeland
per@hedeland.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/23/19 11:33 PM, William Unruh wrote:

Actually it is not too bad.

Meh. (See below.)

When you ssh in, the sshd starts up another instance of itself to handle
your connection. When you kill the main sshd daemon (or restart sshd
from whatever init system youuse) you copy of ssh does not get altered.

That's the ideal way to do it.

I've administered multiple platforms (and multiple versions there of)
that do a killall sshd, thus killing your active connection, if you use
the init script to restart the ssh daemon.

So, know how the platform you're working on behaves.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/23/19 11:36 PM, William Unruh wrote:

Well, not really true.

I disagree.

For example SyslogFacility is the syslog facility.

SyslogFacility is a separate parameter from LogLevel. The former
specifies what syslog facility sshd should log as. The latter specifies
what amount of detail sshd should log as.

I don't see how the syslog facility used has any influence on the amount
/ detail of logs that sshd generates. (Of course it's independent of
what the syslog daemon actually filters and records.)

And at least the higher levels of LogLevel ARE the syslog loglevels (ie, using /etc/syslog.conf you can restrict the output.)

The name collision is immaterial. The fact that some, but not all,
LogLevels correlate with syslog levels supports that they are not the
same. The names could be SLAAAAAAAAAA, SLBBBBBBBB, SLCCCCCC, SLDDDD,
SLEE for all it matters. The parameter that sshd uses is matched in a
case statement (thank you Per H.) and translated to a syslog level.
Hence why I say that there is no direct correlation between LogLevel and
syslog level. There is a loose correlation with some overlap. But they
are decidedly not the same thing.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2019-05-24, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 5/23/19 11:36 PM, William Unruh wrote:

Well, not really true.

I disagree.

For example SyslogFacility is the syslog facility.

SyslogFacility is a separate parameter from LogLevel. The former
specifies what syslog facility sshd should log as. The latter specifies
what amount of detail sshd should log as.

I don't see how the syslog facility used has any influence on the amount
/ detail of logs that sshd generates. (Of course it's independent of
what the syslog daemon actually filters and records.)

And at least the higher levels of LogLevel ARE the syslog loglevels (ie,
using /etc/syslog.conf you can restrict the output.)

The name collision is immaterial. The fact that some, but not all,
LogLevels correlate with syslog levels supports that they are not the
same. The names could be SLAAAAAAAAAA, SLBBBBBBBB, SLCCCCCC, SLDDDD,
SLEE for all it matters. The parameter that sshd uses is matched in a
case statement (thank you Per H.) and translated to a syslog level.
Hence why I say that there is no direct correlation between LogLevel and syslog level. There is a loose correlation with some overlap. But they
are decidedly not the same thing.

Yes, I learned that from Per H. as well. All the debug levels go out to
syslog DEBUG it seems. It seems a bit perverse to use the same
nomenclature as the syslog to name debug levels for sshd.





--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)