ssh tunneling and "channel 2: open failed: administratively prohibited: open failed"

[Jonathan Underwood]

Hi,

I'm having a spot of bother getting an ssh tunnel to work. Here's the situation:

I am trying to connect to machine C via a tunnel to machine B from
machine A, with machine A being the local machine.

Machine C is behind a firewall, and so direct ssh from A to C isn't possible.

At the command line, once ssh'd into machine B from machine A, I can
ssh from machine B to machine A.

So, on machine A (local machine) I run in one terminal (Terminal 1):

ssh -R 8888:C:22 username at B cat -

which asks me for my password on machine B, which I duly enter.

Then, on machine A, in a second terminal (Terminal 2) I run

ssh -p 8888 localhost

On the terminal (Terminal 1) which is running the ssh tunnel I get this message:
channel 2: open failed: administratively prohibited: open failed

And on Terminal 2 I get
ssh_exchange_identification: Connection closed by remote host

Oddly, at no point have I been asked to enter login details for machine C.

I've ensured that port 22 is allowing incoming ssh connections on
machine C. I've tried turning off SElinux on machine C. Machnine B is
not under my control, so there's nothing much I can do there -- it is
a SunOS machine and the ssh client does support the options for port
forwarding (-L and -R).

Getting desperate - what am I doing wrong? :)

TIA
Jonathan.

[Jonathan Underwood]

I should have mentioned that machines A and C are running FC6, and

Post by Jonathan Underwood
Hi,
I am trying to connect to machine C via a tunnel to machine B from
machine A, with machine A being the local machine.
Machine C is behind a firewall, and so direct ssh from A to C isn't possible.
At the command line, once ssh'd into machine B from machine A, I can
ssh from machine B to machine A.
^^^^

Typo - that should read "machine B to machine C"

[Rick Sewill]

Post by Jonathan Underwood
Hi,
I am trying to connect to machine C via a tunnel to machine B from
machine A, with machine A being the local machine.
Machine C is behind a firewall, and so direct ssh from A to C isn't possible.
At the command line, once ssh'd into machine B from machine A, I can
ssh from machine B to machine A.
ssh -R 8888:C:22 username at B cat -

My first guess was to suggest using
ssh -N -L 8888:C:22 username at B

I believe -L 8888 forwards port 8888 on Machine A through ssh to machine
C, port 22.

I assume /etc/ssh/sshd_config, on Machine B, has not been changed from
the default of allowing TCP Forwarding (AllowTCPForwarding)

Post by Jonathan Underwood
which asks me for my password on machine B, which I duly enter.
Then, on machine A, in a second terminal (Terminal 2) I run
ssh -p 8888 localhost
channel 2: open failed: administratively prohibited: open failed
And on Terminal 2 I get
ssh_exchange_identification: Connection closed by remote host
Oddly, at no point have I been asked to enter login details for machine C.
I've ensured that port 22 is allowing incoming ssh connections on
machine C. I've tried turning off SElinux on machine C. Machnine B is
not under my control, so there's nothing much I can do there -- it is
a SunOS machine and the ssh client does support the options for port
forwarding (-L and -R).
Getting desperate - what am I doing wrong? :)
TIA
Jonathan.

[Jonathan Underwood]

Post by Rick Sewill

Post by Jonathan Underwood
ssh -R 8888:C:22 username at B cat -

My first guess was to suggest using
ssh -N -L 8888:C:22 username at B
I believe -L 8888 forwards port 8888 on Machine A through ssh to machine
C, port 22.

Ah, yes, sorry, that's exactly what I did do (I thinko'd -R instead of
-L in my description). I've just repeated these test using -L, and get
the error message in the subject.

Post by Rick Sewill
I assume /etc/ssh/sshd_config, on Machine B, has not been changed from
the default of allowing TCP Forwarding (AllowTCPForwarding)

Unfortunately I can't access /etc/ssh/sshd_config on that machine (B)
as I don't have route access. uname -ar on that machine gives SunOS
xxx.xx.xx.xxx. 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-V440.
ssh -V gives Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL. I don't know
any way of checking if TCP forwarding is allowed on that machine.

[Rick Sewill]

Post by Jonathan Underwood

Post by Rick Sewill

Post by Jonathan Underwood
ssh -R 8888:C:22 username at B cat -

My first guess was to suggest using
ssh -N -L 8888:C:22 username at B
I believe -L 8888 forwards port 8888 on Machine A through ssh to machine
C, port 22.

Ah, yes, sorry, that's exactly what I did do (I thinko'd -R instead of
-L in my description). I've just repeated these test using -L, and get
the error message in the subject.

Post by Rick Sewill
I assume /etc/ssh/sshd_config, on Machine B, has not been changed from
the default of allowing TCP Forwarding (AllowTCPForwarding)

Unfortunately I can't access /etc/ssh/sshd_config on that machine (B)
as I don't have route access. uname -ar on that machine gives SunOS
xxx.xx.xx.xxx. 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-V440.
ssh -V gives Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL. I don't know
any way of checking if TCP forwarding is allowed on that machine.

When you ssh from machine A to machine B,
can you ssh from machine B to machine C?

It may not provide much information, but my next instinct would be to
turn on verbose mode, "man ssh"
ssh -v -v -v -p 8888 localhost
The reason I say it may not provide much information is because, for
security reasons, sshd on machine B (or sshd on machine C if you are
actually getting to machine C) will wish to divulge as little
information as possible why the connection is being administratively
prohibited.

[Jonathan Underwood]

Hi Rick,

Post by Rick Sewill
When you ssh from machine A to machine B,
can you ssh from machine B to machine C?

Yes, I can.

Post by Rick Sewill
It may not provide much information, but my next instinct would be to
turn on verbose mode, "man ssh"
ssh -v -v -v -p 8888 localhost

ssh -vvv -p 8888 localhost
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 8888.
debug1: Connection established.
debug1: identity file /home/jgu/.ssh/identity type -1
debug1: identity file /home/jgu/.ssh/id_rsa type -1
debug1: identity file /home/jgu/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

and, also, if I start up the tunnel with -vvv, I get this each time I
try to connect to port 8888 on the local host:

debug1: Connection to port 8888 forwarding to withnail.phys.ucl.ac.uk
port 22 requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: administratively prohibited: open failed
debug1: channel 3: free: direct-tcpip: listening port 8888 for
withnail.phys.ucl.ac.uk port 22, connect from ::1 port 36180,
nchannels 4
debug3: channel 3: status: The following connections are open:
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 8888 for withnail.phys.ucl.ac.uk
port 22, connect from ::1 port 36180 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)

debug3: channel 3: close_fds r 9 w 9 e -1 c -1
debug1: Connection to port 8888 forwarding to withnail.phys.ucl.ac.uk
port 22 requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: administratively prohibited: open failed
debug1: channel 3: free: direct-tcpip: listening port 8888 for
withnail.phys.ucl.ac.uk port 22, connect from ::1 port 36181,
nchannels 4
debug3: channel 3: status: The following connections are open:
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 8888 for withnail.phys.ucl.ac.uk
port 22, connect from ::1 port 36181 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)

debug3: channel 3: close_fds r 9 w 9 e -1 c -1

Does that shed any light ?
J.

[Rick Sewill]

Post by Jonathan Underwood
Hi Rick,

Post by Rick Sewill
When you ssh from machine A to machine B,
can you ssh from machine B to machine C?

Yes, I can.

Post by Rick Sewill
It may not provide much information, but my next instinct would be to
turn on verbose mode, "man ssh"
ssh -v -v -v -p 8888 localhost

ssh -vvv -p 8888 localhost
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 8888.
debug1: Connection established.
debug1: identity file /home/jgu/.ssh/identity type -1
debug1: identity file /home/jgu/.ssh/id_rsa type -1
debug1: identity file /home/jgu/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host
and, also, if I start up the tunnel with -vvv, I get this each time I
debug1: Connection to port 8888 forwarding to withnail.phys.ucl.ac.uk
port 22 requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: administratively prohibited: open failed
debug1: channel 3: free: direct-tcpip: listening port 8888 for
withnail.phys.ucl.ac.uk port 22, connect from ::1 port 36180,
nchannels 4
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 8888 for withnail.phys.ucl.ac.uk
port 22, connect from ::1 port 36180 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)
debug3: channel 3: close_fds r 9 w 9 e -1 c -1
debug1: Connection to port 8888 forwarding to withnail.phys.ucl.ac.uk
port 22 requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: administratively prohibited: open failed
debug1: channel 3: free: direct-tcpip: listening port 8888 for
withnail.phys.ucl.ac.uk port 22, connect from ::1 port 36181,
nchannels 4
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 8888 for withnail.phys.ucl.ac.uk
port 22, connect from ::1 port 36181 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)
debug3: channel 3: close_fds r 9 w 9 e -1 c -1
Does that shed any light ?
J.

It says it is an administrative issue. I am guessing authentication.

I have a long-shot guess...after trying some local tests here.
I have one user name, USERA, on machine A,
user name, USERX, on machine B and machine C

I did the same (names of machines are different)

Post by Jonathan Underwood
From machine A> ssh -N -L 8080:C:22 B
From machine A> ssh -p 8080 localhost

-- and it failed because my name on machine A is different
from my name on machine B and ssh on machine A was passing
the equivalent of "USERA at localhost"
When I did from machine A> ssh -p 8080 USERX at localhost
I succeeded because machine C knew about and wanted USERX

Another possibility...when you connect from machine B to machine C,
do you have anything special in ~/.ssh/config file on machine B
that is not being triggered when you ssh through the tunnel?

I might as well ask if there is anything special in ~/.ssh/config file
on machine A that might be specifying something machine C does not
support. Such things might be a certain kind of encryption or
compression or ....

Sorry I am not being as much help as I would like to be.

You may need to ask the administrator for machine C what is showing up
in the syslog.

[Jonathan Underwood]

Post by Rick Sewill
It says it is an administrative issue. I am guessing authentication.
I have a long-shot guess...after trying some local tests here.
I have one user name, USERA, on machine A,
user name, USERX, on machine B and machine C
I did the same (names of machines are different)

Post by Jonathan Underwood
From machine A> ssh -N -L 8080:C:22 B
From machine A> ssh -p 8080 localhost

-- and it failed because my name on machine A is different
from my name on machine B and ssh on machine A was passing
the equivalent of "USERA at localhost"
When I did from machine A> ssh -p 8080 USERX at localhost
I succeeded because machine C knew about and wanted USERX

My usernames on machines A and C are the same, and different to the
username on machine B. So, I tried this suggestion, to no avail --
same general result I'm afraid.

Post by Rick Sewill
Another possibility...when you connect from machine B to machine C,
do you have anything special in ~/.ssh/config file on machine B
that is not being triggered when you ssh through the tunnel?

I checked, and there's nothing in my .ssh/config files on any of the
machines. Machines A and C are freshly installed FC6 boxes, identical
(actually, I have even tried using the same machine as machine A and
C), and machine B is a sun machine with a clean account. Machine B is
the one not under my control.

Post by Rick Sewill
I might as well ask if there is anything special in ~/.ssh/config file
on machine A that might be specifying something machine C does not
support. Such things might be a certain kind of encryption or
compression or ....

Nope, nothing like that.

Post by Rick Sewill
Sorry I am not being as much help as I would like to be.

No need for apologies - you've been incredibly helpful with your
suggestions, as I feel more confident I've ruled everything else out,
and it must be that TCPForwarding on the box in the middle (B) is
disallowed.

Post by Rick Sewill
You may need to ask the administrator for machine C what is showing up
in the syslog.

That's me :) There's nothing in the logs that gives a clue - I think
the logs on machine B would be more interesting, but those are not
available to me :).

Thanks again Rick.
Jonathan.

[Jonathan Underwood]

Post by Rick Sewill
It says it is an administrative issue. I am guessing authentication.
I have a long-shot guess...after trying some local tests here.
I have one user name, USERA, on machine A,
user name, USERX, on machine B and machine C
I did the same (names of machines are different)

Post by Jonathan Underwood
From machine A> ssh -N -L 8080:C:22 B
From machine A> ssh -p 8080 localhost

-- and it failed because my name on machine A is different
from my name on machine B and ssh on machine A was passing
the equivalent of "USERA at localhost"
When I did from machine A> ssh -p 8080 USERX at localhost
I succeeded because machine C knew about and wanted USERX

My usernames on machines A and C are the same, and different to the
username on machine B. So, I tried this suggestion, to no avail --
same general result I'm afraid.

Post by Rick Sewill
Another possibility...when you connect from machine B to machine C,
do you have anything special in ~/.ssh/config file on machine B
that is not being triggered when you ssh through the tunnel?

I checked, and there's nothing in my .ssh/config files on any of the
machines. Machines A and C are freshly installed FC6 boxes, identical
(actually, I have even tried using the same machine as machine A and
C), and machine B is a sun machine with a clean account. Machine B is
the one not under my control.

Post by Rick Sewill
I might as well ask if there is anything special in ~/.ssh/config file
on machine A that might be specifying something machine C does not
support. Such things might be a certain kind of encryption or
compression or ....

Nope, nothing like that.

Post by Rick Sewill
Sorry I am not being as much help as I would like to be.

No need for apologies - you've been incredibly helpful with your
suggestions, as I feel more confident I've ruled everything else out,
and it must be that TCPForwarding on the box in the middle (B) is
disallowed.

Post by Rick Sewill
You may need to ask the administrator for machine C what is showing up
in the syslog.

That's me :) There's nothing in the logs that gives a clue - I think
the logs on machine B would be more interesting, but those are not
available to me :).

Thanks again Rick.
Jonathan.

[Rick Sewill]

Post by Jonathan Underwood
Hi Rick,

Post by Rick Sewill
When you ssh from machine A to machine B,
can you ssh from machine B to machine C?

Yes, I can.

Post by Rick Sewill
It may not provide much information, but my next instinct would be to
turn on verbose mode, "man ssh"
ssh -v -v -v -p 8888 localhost

ssh -vvv -p 8888 localhost
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 8888.
debug1: Connection established.
debug1: identity file /home/jgu/.ssh/identity type -1
debug1: identity file /home/jgu/.ssh/id_rsa type -1
debug1: identity file /home/jgu/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host
and, also, if I start up the tunnel with -vvv, I get this each time I
debug1: Connection to port 8888 forwarding to withnail.phys.ucl.ac.uk
port 22 requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: administratively prohibited: open failed
debug1: channel 3: free: direct-tcpip: listening port 8888 for
withnail.phys.ucl.ac.uk port 22, connect from ::1 port 36180,
nchannels 4
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 8888 for withnail.phys.ucl.ac.uk
port 22, connect from ::1 port 36180 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)
debug3: channel 3: close_fds r 9 w 9 e -1 c -1
debug1: Connection to port 8888 forwarding to withnail.phys.ucl.ac.uk
port 22 requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: administratively prohibited: open failed
debug1: channel 3: free: direct-tcpip: listening port 8888 for
withnail.phys.ucl.ac.uk port 22, connect from ::1 port 36181,
nchannels 4
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 8888 for withnail.phys.ucl.ac.uk
port 22, connect from ::1 port 36181 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)
debug3: channel 3: close_fds r 9 w 9 e -1 c -1
Does that shed any light ?
J.

It says it is an administrative issue. I am guessing authentication.

I have a long-shot guess...after trying some local tests here.
I have one user name, USERA, on machine A,
user name, USERX, on machine B and machine C

I did the same (names of machines are different)

Post by Jonathan Underwood
From machine A> ssh -N -L 8080:C:22 B
From machine A> ssh -p 8080 localhost

-- and it failed because my name on machine A is different
from my name on machine B and ssh on machine A was passing
the equivalent of "USERA at localhost"
When I did from machine A> ssh -p 8080 USERX at localhost
I succeeded because machine C knew about and wanted USERX

Another possibility...when you connect from machine B to machine C,
do you have anything special in ~/.ssh/config file on machine B
that is not being triggered when you ssh through the tunnel?

I might as well ask if there is anything special in ~/.ssh/config file
on machine A that might be specifying something machine C does not
support. Such things might be a certain kind of encryption or
compression or ....

Sorry I am not being as much help as I would like to be.

You may need to ask the administrator for machine C what is showing up
in the syslog.

[Jonathan Underwood]

Hi Rick,

Post by Rick Sewill
When you ssh from machine A to machine B,
can you ssh from machine B to machine C?

Yes, I can.

Post by Rick Sewill
It may not provide much information, but my next instinct would be to
turn on verbose mode, "man ssh"
ssh -v -v -v -p 8888 localhost

ssh -vvv -p 8888 localhost
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 8888.
debug1: Connection established.
debug1: identity file /home/jgu/.ssh/identity type -1
debug1: identity file /home/jgu/.ssh/id_rsa type -1
debug1: identity file /home/jgu/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

and, also, if I start up the tunnel with -vvv, I get this each time I
try to connect to port 8888 on the local host:

debug1: Connection to port 8888 forwarding to withnail.phys.ucl.ac.uk
port 22 requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: administratively prohibited: open failed
debug1: channel 3: free: direct-tcpip: listening port 8888 for
withnail.phys.ucl.ac.uk port 22, connect from ::1 port 36180,
nchannels 4
debug3: channel 3: status: The following connections are open:
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 8888 for withnail.phys.ucl.ac.uk
port 22, connect from ::1 port 36180 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)

debug3: channel 3: close_fds r 9 w 9 e -1 c -1
debug1: Connection to port 8888 forwarding to withnail.phys.ucl.ac.uk
port 22 requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: administratively prohibited: open failed
debug1: channel 3: free: direct-tcpip: listening port 8888 for
withnail.phys.ucl.ac.uk port 22, connect from ::1 port 36181,
nchannels 4
debug3: channel 3: status: The following connections are open:
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cfd -1)
#3 direct-tcpip: listening port 8888 for withnail.phys.ucl.ac.uk
port 22, connect from ::1 port 36181 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)

debug3: channel 3: close_fds r 9 w 9 e -1 c -1

Does that shed any light ?
J.

[Rick Sewill]

Post by Jonathan Underwood

Post by Rick Sewill

Post by Jonathan Underwood
ssh -R 8888:C:22 username at B cat -

My first guess was to suggest using
ssh -N -L 8888:C:22 username at B
I believe -L 8888 forwards port 8888 on Machine A through ssh to machine
C, port 22.

Ah, yes, sorry, that's exactly what I did do (I thinko'd -R instead of
-L in my description). I've just repeated these test using -L, and get
the error message in the subject.

Post by Rick Sewill
I assume /etc/ssh/sshd_config, on Machine B, has not been changed from
the default of allowing TCP Forwarding (AllowTCPForwarding)

Unfortunately I can't access /etc/ssh/sshd_config on that machine (B)
as I don't have route access. uname -ar on that machine gives SunOS
xxx.xx.xx.xxx. 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-V440.
ssh -V gives Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL. I don't know
any way of checking if TCP forwarding is allowed on that machine.

When you ssh from machine A to machine B,
can you ssh from machine B to machine C?

It may not provide much information, but my next instinct would be to
turn on verbose mode, "man ssh"
ssh -v -v -v -p 8888 localhost
The reason I say it may not provide much information is because, for
security reasons, sshd on machine B (or sshd on machine C if you are
actually getting to machine C) will wish to divulge as little
information as possible why the connection is being administratively
prohibited.

[Jonathan Underwood]

Post by Rick Sewill

Post by Jonathan Underwood
ssh -R 8888:C:22 username at B cat -

My first guess was to suggest using
ssh -N -L 8888:C:22 username at B
I believe -L 8888 forwards port 8888 on Machine A through ssh to machine
C, port 22.

Ah, yes, sorry, that's exactly what I did do (I thinko'd -R instead of
-L in my description). I've just repeated these test using -L, and get
the error message in the subject.

Post by Rick Sewill
I assume /etc/ssh/sshd_config, on Machine B, has not been changed from
the default of allowing TCP Forwarding (AllowTCPForwarding)

Unfortunately I can't access /etc/ssh/sshd_config on that machine (B)
as I don't have route access. uname -ar on that machine gives SunOS
xxx.xx.xx.xxx. 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-V440.
ssh -V gives Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL. I don't know
any way of checking if TCP forwarding is allowed on that machine.

[Mike Cohler]

Post by Jonathan Underwood
I am trying to connect to machine C via a tunnel to machine B from
machine A, with machine A being the local machine.
Machine C is behind a firewall, and so direct ssh from A to C isn't possible.
At the command line, once ssh'd into machine B from machine A, I can
ssh from machine B to machine A.
ssh -R 8888:C:22 username <at> B cat -
which asks me for my password on machine B, which I duly enter.
Then, on machine A, in a second terminal (Terminal 2) I run
ssh -p 8888 localhost

I had a similar problem a few months ago which took me some time to fathom the
solution needed.
I found the following for my case:
1) From machine A do "ssh -L 12345:C:5900 B" (where B and C are your machine
names in question)
in a first terminal window.

This allows an ssh login from A to machine B where the firewall is, but once
connected is set up to forward in this case port 12345 from the originating
machine A to port 5900 on machine C. Once connected to machine B, then login to
machine C on the standard ssh port. Now the tunnel should be set up with the
correct port forwarding that you want - in this case anything going to poert
12345 on machine A will be forwarded through to 5900 on machine C which is the
standard vnc port.

2) Once this is running then start the vnc connection command in a second
terminal session on machine A going to port 12345, and this will then have the
vnc command running and communicating to port 5900 (default) on machine C via
the tunnel.

It did take me quite some time to work this out, but it has worked consistently
ever since.

[Mike Cohler]

Post by Mike Cohler
1) From machine A do "ssh -L 12345:C:5900 B" (where B and C are your machine
names in question)
in a first terminal window.
This allows an ssh login from A to machine B where the firewall is, but once
connected is set up to forward in this case port 12345 from the originating
machine A to port 5900 on machine C. Once connected to machine B, then login to
machine C on the standard ssh port. Now the tunnel should be set up with the
correct port forwarding that you want - in this case anything going to poert
12345 on machine A will be forwarded through to 5900 on machine C which is the
standard vnc port.
2) Once this is running then start the vnc connection command in a second
terminal session on machine A going to port 12345, and this will then have the
vnc command running and communicating to port 5900 (default) on machine C via
the tunnel.

I should add that if you want to tunnel a different application than vnc then
the port number on the final machine should be the port for the application you
want to run and use its default port or change it to one of your own choice.

[Jonathan Underwood]

Post by Mike Cohler
1) From machine A do "ssh -L 12345:C:5900 B" (where B and C are your machine
names in question)
in a first terminal window.
This allows an ssh login from A to machine B where the firewall is, but once
connected is set up to forward in this case port 12345 from the originating
machine A to port 5900 on machine C. Once connected to machine B, then login to
machine C on the standard ssh port. Now the tunnel should be set up with the
correct port forwarding that you want - in this case anything going to poert
12345 on machine A will be forwarded through to 5900 on machine C which is the
standard vnc port.
2) Once this is running then start the vnc connection command in a second
terminal session on machine A going to port 12345, and this will then have the
vnc command running and communicating to port 5900 (default) on machine C via
the tunnel.

Thanks Mike - this is what I did already except replace "vnc" with
"ssh" and "5900" with "22" in your description. It relies upon machine
B allowing TCPforwarding, which seems not to be the case for my local
setup. Thanks for the suggestion tho.

Jonathan

[Rick Sewill]

Post by Jonathan Underwood
Thanks Mike - this is what I did already except replace "vnc" with
"ssh" and "5900" with "22" in your description. It relies upon machine
B allowing TCPforwarding, which seems not to be the case for my local
setup. Thanks for the suggestion tho.
Jonathan

I scanned the Internet. Indications were administratively prohibited
either meant "AllowTCPForwarding" was no in the sshd_config file on
machine B or the target machine (machine C) was not being found.

It would surprise me if one cannot do ssh -N -L 8080:C:22 B
but perhaps the name, C, is not being resolved to an IP address.

Could you try the actual IP address for machine C in the command?

Otherwise, I fear the problem is AllowTCPForwarding on machine B.

[Jonathan Underwood]

Post by Rick Sewill
I scanned the Internet. Indications were administratively prohibited
either meant "AllowTCPForwarding" was no in the sshd_config file on
machine B or the target machine (machine C) was not being found.
It would surprise me if one cannot do ssh -N -L 8080:C:22 B
but perhaps the name, C, is not being resolved to an IP address.
Could you try the actual IP address for machine C in the command?

Yes - I tried that to no avail I'm afraid.

Post by Rick Sewill
Otherwise, I fear the problem is AllowTCPForwarding on machine B.

It looks that way.

Jonathan

[Tony Nelson]

Post by Jonathan Underwood

Post by Rick Sewill
I scanned the Internet. Indications were administratively prohibited
either meant "AllowTCPForwarding" was no in the sshd_config file on
machine B or the target machine (machine C) was not being found.
It would surprise me if one cannot do ssh -N -L 8080:C:22 B
but perhaps the name, C, is not being resolved to an IP address.
Could you try the actual IP address for machine C in the command?

Yes - I tried that to no avail I'm afraid.

Post by Rick Sewill
Otherwise, I fear the problem is AllowTCPForwarding on machine B.

It looks that way.

Have you tried forwarding from A to B to A?

[Jonathan Underwood]

Post by Tony Nelson
Have you tried forwarding from A to B to A?

Yes; same deal - same error message. (And just to be sure, I
succesfully forwarded A to A to A).

Jonathan

[Tony Nelson]

Post by Jonathan Underwood

Post by Tony Nelson
Have you tried forwarding from A to B to A?

Yes; same deal - same error message. (And just to be sure, I
succesfully forwarded A to A to A).

Well, I guess that settles it.

[Tony Nelson]

Post by Jonathan Underwood

Post by Tony Nelson
Have you tried forwarding from A to B to A?

Yes; same deal - same error message. (And just to be sure, I
succesfully forwarded A to A to A).

Well, I guess that settles it.

[Tony Nelson]

Post by Jonathan Underwood

Post by Rick Sewill
I scanned the Internet. Indications were administratively prohibited
either meant "AllowTCPForwarding" was no in the sshd_config file on
machine B or the target machine (machine C) was not being found.
It would surprise me if one cannot do ssh -N -L 8080:C:22 B
but perhaps the name, C, is not being resolved to an IP address.
Could you try the actual IP address for machine C in the command?

Yes - I tried that to no avail I'm afraid.

Post by Rick Sewill
Otherwise, I fear the problem is AllowTCPForwarding on machine B.

It looks that way.

Have you tried forwarding from A to B to A?

[Jonathan Underwood]

Post by Tony Nelson
Have you tried forwarding from A to B to A?

Yes; same deal - same error message. (And just to be sure, I
succesfully forwarded A to A to A).

Jonathan

[Jonathan Underwood]

Post by Rick Sewill
I scanned the Internet. Indications were administratively prohibited
either meant "AllowTCPForwarding" was no in the sshd_config file on
machine B or the target machine (machine C) was not being found.
It would surprise me if one cannot do ssh -N -L 8080:C:22 B
but perhaps the name, C, is not being resolved to an IP address.
Could you try the actual IP address for machine C in the command?

Yes - I tried that to no avail I'm afraid.

Post by Rick Sewill
Otherwise, I fear the problem is AllowTCPForwarding on machine B.

It looks that way.

Jonathan

[Mike Cohler]

Post by Jonathan Underwood
Thanks Mike - this is what I did already except replace "vnc" with
"ssh" and "5900" with "22" in your description. It relies upon machine
B allowing TCPforwarding, which seems not to be the case for my local
setup. Thanks for the suggestion tho.

One thing worth thinking about is that you are using ssh from A into B, and then
going from B to C with ssh presumably all using port 22? That is fine. But
additionally you are poer forwarding some private port on machine A into port 22
on C, and in that case if you tunnel from A to C going to port 22 on C for the
tunnel, then would this not clash with the ssh connection from B to C which is
already using port 22?

Just a thought

[Dylan Semler]

Post by Jonathan Underwood
Thanks Mike - this is what I did already except replace "vnc" with
"ssh" and "5900" with "22" in your description. It relies upon machine
B allowing TCPforwarding, which seems not to be the case for my local
setup. Thanks for the suggestion tho.

I've been following this thred as I was having the same problem (although
only with tunneling a port between two machines). I solved it by replacing
the host name with the ip address in the ssh command, ie:

ssh -R 8888:<ip address of C>:22 username@<ip address of B> cat -

instead of

ssh -R 8888:C:22 username at B cat -

or whatever variation you think would be more successful. This certainly
doesn't make any sense to me, but with the hostnames in place, I was unable
to connect and getting "channel 2: open failed: connect failed: Connection
refused." Hopefully you're having the same issue.

[Mike Cohler]

Dylan Semler <dylan.semler <at> gmail.com> writes:

doesn't make any sense to me, but with the hostnames in place, I was unable to
connect and getting "channel 2: open failed: connect failed: Connection
refused." Hopefully you're having the same issue.

Yes the original command in the first posting on this thread would only work
provided machine B has access to a dns that can provide the ip for the machine
name specified in the original port forwarding definition defined in the first
ssh command. If there is no dns to do this on machine B then the ip has to be
specified instead.

[Mike Cohler]

Dylan Semler <dylan.semler <at> gmail.com> writes:

doesn't make any sense to me, but with the hostnames in place, I was unable to
connect and getting "channel 2: open failed: connect failed: Connection
refused." Hopefully you're having the same issue.

Yes the original command in the first posting on this thread would only work
provided machine B has access to a dns that can provide the ip for the machine
name specified in the original port forwarding definition defined in the first
ssh command. If there is no dns to do this on machine B then the ip has to be
specified instead.

[Dylan Semler]

Post by Jonathan Underwood
Thanks Mike - this is what I did already except replace "vnc" with
"ssh" and "5900" with "22" in your description. It relies upon machine
B allowing TCPforwarding, which seems not to be the case for my local
setup. Thanks for the suggestion tho.

I've been following this thred as I was having the same problem (although
only with tunneling a port between two machines). I solved it by replacing
the host name with the ip address in the ssh command, ie:

ssh -R 8888:<ip address of C>:22 username@<ip address of B> cat -

instead of

ssh -R 8888:C:22 username at B cat -

or whatever variation you think would be more successful. This certainly
doesn't make any sense to me, but with the hostnames in place, I was unable
to connect and getting "channel 2: open failed: connect failed: Connection
refused." Hopefully you're having the same issue.

[Rick Sewill]

Post by Jonathan Underwood
Thanks Mike - this is what I did already except replace "vnc" with
"ssh" and "5900" with "22" in your description. It relies upon machine
B allowing TCPforwarding, which seems not to be the case for my local
setup. Thanks for the suggestion tho.
Jonathan

I scanned the Internet. Indications were administratively prohibited
either meant "AllowTCPForwarding" was no in the sshd_config file on
machine B or the target machine (machine C) was not being found.

It would surprise me if one cannot do ssh -N -L 8080:C:22 B
but perhaps the name, C, is not being resolved to an IP address.

Could you try the actual IP address for machine C in the command?

Otherwise, I fear the problem is AllowTCPForwarding on machine B.

[Mike Cohler]

Post by Jonathan Underwood
Thanks Mike - this is what I did already except replace "vnc" with
"ssh" and "5900" with "22" in your description. It relies upon machine
B allowing TCPforwarding, which seems not to be the case for my local
setup. Thanks for the suggestion tho.

One thing worth thinking about is that you are using ssh from A into B, and then
going from B to C with ssh presumably all using port 22? That is fine. But
additionally you are poer forwarding some private port on machine A into port 22
on C, and in that case if you tunnel from A to C going to port 22 on C for the
tunnel, then would this not clash with the ssh connection from B to C which is
already using port 22?

Just a thought

[Mike Cohler]

Post by Mike Cohler
1) From machine A do "ssh -L 12345:C:5900 B" (where B and C are your machine
names in question)
in a first terminal window.
This allows an ssh login from A to machine B where the firewall is, but once
connected is set up to forward in this case port 12345 from the originating
machine A to port 5900 on machine C. Once connected to machine B, then login to
machine C on the standard ssh port. Now the tunnel should be set up with the
correct port forwarding that you want - in this case anything going to poert
12345 on machine A will be forwarded through to 5900 on machine C which is the
standard vnc port.
2) Once this is running then start the vnc connection command in a second
terminal session on machine A going to port 12345, and this will then have the
vnc command running and communicating to port 5900 (default) on machine C via
the tunnel.

I should add that if you want to tunnel a different application than vnc then
the port number on the final machine should be the port for the application you
want to run and use its default port or change it to one of your own choice.

[Jonathan Underwood]

Post by Mike Cohler
1) From machine A do "ssh -L 12345:C:5900 B" (where B and C are your machine
names in question)
in a first terminal window.
This allows an ssh login from A to machine B where the firewall is, but once
connected is set up to forward in this case port 12345 from the originating
machine A to port 5900 on machine C. Once connected to machine B, then login to
machine C on the standard ssh port. Now the tunnel should be set up with the
correct port forwarding that you want - in this case anything going to poert
12345 on machine A will be forwarded through to 5900 on machine C which is the
standard vnc port.
2) Once this is running then start the vnc connection command in a second
terminal session on machine A going to port 12345, and this will then have the
vnc command running and communicating to port 5900 (default) on machine C via
the tunnel.

Thanks Mike - this is what I did already except replace "vnc" with
"ssh" and "5900" with "22" in your description. It relies upon machine
B allowing TCPforwarding, which seems not to be the case for my local
setup. Thanks for the suggestion tho.

Jonathan

[Jonathan Underwood]

Hi,

I'm having a spot of bother getting an ssh tunnel to work. Here's the situation:

I am trying to connect to machine C via a tunnel to machine B from
machine A, with machine A being the local machine.

Machine C is behind a firewall, and so direct ssh from A to C isn't possible.

At the command line, once ssh'd into machine B from machine A, I can
ssh from machine B to machine A.

So, on machine A (local machine) I run in one terminal (Terminal 1):

ssh -R 8888:C:22 username at B cat -

which asks me for my password on machine B, which I duly enter.

Then, on machine A, in a second terminal (Terminal 2) I run

ssh -p 8888 localhost

On the terminal (Terminal 1) which is running the ssh tunnel I get this message:
channel 2: open failed: administratively prohibited: open failed

And on Terminal 2 I get
ssh_exchange_identification: Connection closed by remote host

Oddly, at no point have I been asked to enter login details for machine C.

I've ensured that port 22 is allowing incoming ssh connections on
machine C. I've tried turning off SElinux on machine C. Machnine B is
not under my control, so there's nothing much I can do there -- it is
a SunOS machine and the ssh client does support the options for port
forwarding (-L and -R).

Getting desperate - what am I doing wrong? :)

TIA
Jonathan.

[Jonathan Underwood]

I should have mentioned that machines A and C are running FC6, and

Post by Jonathan Underwood
Hi,
I am trying to connect to machine C via a tunnel to machine B from
machine A, with machine A being the local machine.
Machine C is behind a firewall, and so direct ssh from A to C isn't possible.
At the command line, once ssh'd into machine B from machine A, I can
ssh from machine B to machine A.
^^^^

Typo - that should read "machine B to machine C"

[Rick Sewill]

Post by Jonathan Underwood
Hi,
I am trying to connect to machine C via a tunnel to machine B from
machine A, with machine A being the local machine.
Machine C is behind a firewall, and so direct ssh from A to C isn't possible.
At the command line, once ssh'd into machine B from machine A, I can
ssh from machine B to machine A.
ssh -R 8888:C:22 username at B cat -

My first guess was to suggest using
ssh -N -L 8888:C:22 username at B

I believe -L 8888 forwards port 8888 on Machine A through ssh to machine
C, port 22.

I assume /etc/ssh/sshd_config, on Machine B, has not been changed from
the default of allowing TCP Forwarding (AllowTCPForwarding)

Post by Jonathan Underwood
which asks me for my password on machine B, which I duly enter.
Then, on machine A, in a second terminal (Terminal 2) I run
ssh -p 8888 localhost
channel 2: open failed: administratively prohibited: open failed
And on Terminal 2 I get
ssh_exchange_identification: Connection closed by remote host
Oddly, at no point have I been asked to enter login details for machine C.
I've ensured that port 22 is allowing incoming ssh connections on
machine C. I've tried turning off SElinux on machine C. Machnine B is
not under my control, so there's nothing much I can do there -- it is
a SunOS machine and the ssh client does support the options for port
forwarding (-L and -R).
Getting desperate - what am I doing wrong? :)
TIA
Jonathan.

[Mike Cohler]

Post by Jonathan Underwood
I am trying to connect to machine C via a tunnel to machine B from
machine A, with machine A being the local machine.
Machine C is behind a firewall, and so direct ssh from A to C isn't possible.
At the command line, once ssh'd into machine B from machine A, I can
ssh from machine B to machine A.
ssh -R 8888:C:22 username <at> B cat -
which asks me for my password on machine B, which I duly enter.
Then, on machine A, in a second terminal (Terminal 2) I run
ssh -p 8888 localhost

I had a similar problem a few months ago which took me some time to fathom the
solution needed.
I found the following for my case:
1) From machine A do "ssh -L 12345:C:5900 B" (where B and C are your machine
names in question)
in a first terminal window.

This allows an ssh login from A to machine B where the firewall is, but once
connected is set up to forward in this case port 12345 from the originating
machine A to port 5900 on machine C. Once connected to machine B, then login to
machine C on the standard ssh port. Now the tunnel should be set up with the
correct port forwarding that you want - in this case anything going to poert
12345 on machine A will be forwarded through to 5900 on machine C which is the
standard vnc port.

2) Once this is running then start the vnc connection command in a second
terminal session on machine A going to port 12345, and this will then have the
vnc command running and communicating to port 5900 (default) on machine C via
the tunnel.

It did take me quite some time to work this out, but it has worked consistently
ever since.