Ssh – SELinux remove or leave the old SSH port label

I guess I'm a little late to the party here, but I encountered the exact same issue here, and resolved it.

First, decide on your new default SSH port. This will affect SSH in general (ie: when you want to connect to the server via SSH using command line, putty etc. The port cannot be changed JUST for SVN, unless you want to invoke multiple SSHD server instances, which is beyond the scope of the original question).

So, assuming the following:

• We want everything done over port 123456
• Your server's IP address is 192.168.1.100
• Your router/firewall has opened up port 123456
• Your router/firewall has setup port forwarding for external port 123456 routing to internal port 123456 for host 192.168.1.100

Client Side:

Anyhow, first, modify <~/.subversion/config> on the client machine, and under the line titled [tunnels], enter the following line:

ssh = ssh -p 123456

Server Side:

First, you need to setup the new default SSH port. On your SVN server, edit (in the case of Ubuntu) your SVN SERVER config file (note the 'd' after "SSH"): sudo vi /etc/ssh/sshd_config

Look for a line beginning with "Port" (by default, it says "Port 22"), and change "22" to "123456". Save and close the file. Now restart the SSHD server: sudo restart ssh

Assuming your SVN setup is working like how you already described above, you are set. If you insist on translating the port rather than just keeping it intact as a single-port-forward-passthrough rule, just change the SSH port used on the server side in , and you're set. I have tested the above setup from a client outside my LAN successfully via:

svn --username megaman ls svn+ssh://megaman@DrWileysFortress.dyndns.org/usr/local/svn/repos/private

Hope this helps!

A fair amount of testing (see comments) has revealed that you don't have a firewall or transport problem. The client is able to connect through to pptpd on the server, and any remaining issues are application-related (and I see you've opened a separate question for that).

In passing, I'd echo Jiri's comments about nmap; it's not a good tool for testing end-to-end connectivity on a single port; telnet serverip 1723 would've been much better.

I'm only writing this up so you can accept an answer and prevent this question from floating around like a ghost ship, forever; and because negative answers are useful, too, and the diagnostic process shown may be of use to someone else at some future date.