I have used ssh port forwarding before, but I have not used it in a
while. I would be grateful if someone has any ideas to help me out.
Background:
I am attempting connect via remote desktop from my home computer
running Windows XP to a Windows Vista machine at work, which is behind
a router. My home computer is directly on the internet – so I was
attempting to ssh from the Vista computer to my home machine, and port
forward the necessary ports, so that my home computer could then
remote desktop to the Vista machine. Unfortunately, it seems that the
ports get forwarded, but the moment a connection is attempted to the
port, it seems to close?? I hope someone has some idea?
I don’t have control over the router at work, but I know I can ssh to
my home machine fine. I am using Cygwin to ssh and port forward from
Vista, and have a Cygwin sshd server at home.
Problem:
Let us keep the remote desktop aspect out of this loop. Let us assume
that I port forward from the Windows Vista machine using Cygwin:
$ ssh -v -R 3390:127.0.0.1:3391 user...@70.173.152.6
(3389 is the remote desktop port – and I have verified that there is
nothing else using these ports on both machines.) Now from my home XP
machine, I do a
telnet localhost 3390
It seems to connect – but then I get back the prompt again after
typing something or pressing Enter. On the Vista machine, I see the
following output:
$ ssh -v -R 3390:127.0.0.1:3391 username @70.173.152.6
OpenSSH_5.1p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to 70.173.152.6 [70.173.152.6] port 22.
debug1: Connection established.
debug1: identity file /home/username/.ssh/identity type -1
debug1: identity file /home/username/.ssh/id_rsa type 1
debug1: identity file /home/username/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version
OpenSSH_4.6
debug1: match: OpenSSH_4.6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '70.173.152.6' is known and matches the RSA host key.
debug1: Found key in /home/ username/.ssh/known_hosts:16
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/username/.ssh/identity
debug1: Offering public key: /home/username/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/username/.ssh/id_dsa
debug1: Next authentication method: password
user...@70.173.152.6's password:
debug1: Authentication succeeded (password).
debug1: Remote connections from LOCALHOST:3390 forwarded to local
address 127.0.0.1:3391
debug1: channel 0: new [client-session]
debug1: Requesting no-more-...@openssh.com
debug1: Entering interactive session.
debug1: remote forward success for: listen 3390, connect
127.0.0.1:3391
debug1: All remote forwarding requests processed
Last login: Sat Aug 29 20:01:30 2009 from
wsip-24-234-75-44.lv.lv.cox.net
username@WinXP ~
$ debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win
131072 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 3390,
originator 127.0.0.1 port 12909
debug1: connect_next: host 127.0.0.1 ([127.0.0.1]:3391) in progress,
fd=7
debug1: getsockopt TCP_NODELAY: Invalid argument
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connection failed: Connection refused
connect_to 127.0.0.1 port 3391: failed.
debug1: channel 1: free: 127.0.0.1, nchannels 2
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win
131072 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 3390,
originator 127.0.0.1 port 12910
debug1: connect_next: host 127.0.0.1 ([127.0.0.1]:3391) in progress,
fd=7
debug1: getsockopt TCP_NODELAY: Invalid argument
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connection failed: Connection refused
connect_to 127.0.0.1 port 3391: failed.
debug1: channel 1: free: 127.0.0.1, nchannels 2
I made two telnet attempts above. So in the last few lines you see two
“Connection refused”. I have attempted the above using Putty plink –
and the result is the same, but the debug messages are not as detailed
as the above.
I would be grateful if someone has any ideas on how to fix this.
Thanks a lot,
O.O.
Isn't this what you'd expect, given that you've verified that nothing
is listening on localhost:3391 on the client (Vista) machine?
It's not clear to me whether you've chosen an unused port on the
client end to "keep the remote desktop aspect out of this loop" for
the purpose of this example. If you were expecting to connect to the
remote desktop service on the client machine, I'd expect an invocation
like "-R 3390:127.0.0.1:3389" (where "3390" was a free port on the
server -- XP -- machine). (Otherwise, what connects port 3391 to your
remote desktop service?)
Thanks Jacob,
Actually I did not do -R 3390:127.0.0.1:3389 – because I thought that
someone would complain that the Remote Desktop is interfering with the
result. I think you raised a valid point that nothing is listening to
3391 on the Remote Vista machine. So does it mean that because of that
the connection is getting refused? I was thinking that error “debug1:
getsockopt TCP_NODELAY: Invalid argument” might have been causing
this.
But you have a valid point. You post pointed me to the fact that my
Vista Home Premium does not have Remote Desktop. I would need to
install a hack to enable this. I would get back to this thread when I
have done that.
Thanks again,
O.O.
Thanks for you help,
O.O.