I have a remote ssh connection problem I need help with.
I have machine A which is a vps running centos 6 on the internet with public ip address.
I have two centos6 machines at home on my LAN, machine B and machine C.
Machine B ssh access is on the default port 22
Machine C ssh access is on a different port - 1234.
From machine B I can run:
# sshpass -p <password> ssh -t -t -R8023:localhost:22 <user>@<ip-addrr-machine-A)
and then I can log in to machine B remotely from machine A using this command:
# ssh -p8023 localhost
However if I try the same thing from machine C (ssh port 1234) machine A throws error:The command I run on machine C is:
# sshpass -p <password> ssh -t -t -R8025:localhost:22 <user>@<ip-addrr-machine-A)
and on machine A I then run:
# ssh -p8025 localhost
and that's when I get the ssh_exchange... error.
The problem is machine C is talking on ssh port 1234 and machine A is coming back on port 22. I've checked this by changing machine C temporarily back to the default port 22 and the remote connection from machine A then works fine.
So to connect to machine C how can I make machine A come back on port 1234?

Shouldn't you make the reverse tunnel that originates from C use port 1234 instead of 22?

Rather than "sshpass", I would recommend using keys for the connection instead. You can make an extra key just for the purpose of tunneling, give it a dummy ForceCommand and then connect using -f to make sure that the connection goes into the background.

thanks for your response but making the reverse tunnel that originates from C use port 1234 instead of 22 doesn't work because no matter what port number I use machine A always comes back on port 22. Unfortunately I don't know how to use the keys method you mentioned.

Ok. We'll deal with the keys later.

Just for clarification, is this what you have?

Machine A is on the open Internet and listening for SSH on port 22
Machine B is on the LAN and listening for SSH on port 22
Machine C is on the LAN and listening for SSH on port 1234

You have a reverse tunnel from B to A.
You have a reverse tunnel from C to A.

And you are trying to connect via A to either B or C using said tunnels?

yes all correct
yes and it works
yes that tunnel connects but A can't come back to C because of the port number.
yes correct, A --> B works but A --> C fails with "ssh_exchange_identification: Connection closed by remote host"

Ok. Then I am puzzled. If you create a tunnel from C to A:

Then you should be able to connect from A to C with port 8025.

Or is there something listening already on port 1234 on machine C?

1) yes you're right, I should be able to connect from A to C with port 8025 but it won't let me unless machine C is on port 22, it won't do it while it's on port 1234.
2) there's nothing on machine C already listening on 8025, I've verified this by running # fuser 8025/tcp, it comes back with nothing.
3) just for more info: I've watched the log on machine C, it verifies the connection to A with this line:
"Last login: Thu Sep 15 13:02:12 2016 from <my public ip addres>"
And on machine A /var/log/secure also verifies the connection with:
Sep 15 13:14:13 vps sshd[21145]: pam_unix(sshd:session): session opened for user <user> by (uid=0)
Sep 15 13:15:03 vps sshd[21201]: Accepted password for <user> from <my-public-ip-address> port 49791 ssh2
However when I run #ssh -p8025 localhost on machine A the log on machine C shows:
"[<user>@<machine A>]$ connect_to localhost port 22: failed."
Machine A is coming back on port 22.

With the setup you have described, 8025 is used on machine A. It is machine C that would be using port 1234, according to the plan above. On machine C, check port 1234 with fuser 1234/tcp It should say that it being used. You should be able to see more clearly using the "netstat" options in the earlier post that it is use by "sshd".

Edit: Just to be sure, what are you typing on Machine C?

ah yes that works!
ssh -t -t -R8025:localhost:1234 <user>@<ip-addrr-machine-A>
silly me I was initiating the original tunnel on port 22. I can now remotely log in to machine C from machine A. Thanks very much for your help on this turbocapitalist.

You're welcome. I'd recommend arranging for key-based authentication next. And then once you have that, it's simple once you know how, some single purpose keys that do nothing but make a tunnel. Password authentication is almost universally frowned upon these days.

1 members found this post helpful.