Remote SSH access via internet

David,
I would start by first asking the administrator of the remote network to give me the information to access the remote Mac.
Nevertheless, the command to use should look like +ssh -l remoteusername IP_ADDRESS+.

Mihalis.

Are you suggesting the ssh port is Timbuktu 407 instead of the default 22?

Is the screen sharing server running? Try to bring up this URL in a browser:

http://«address»:5900/

If you do not get an error, screen sharing is running and you are connected to that port.

So this is your Mac in China that you are wanting to ssh when you are not in China? If you enabled remote login on that Mac in China then it is listening on port 22, and if port 22 traffic is forwarded through that Mac's local router, then you can ssh into it.

There are a number of posts in either this forum and/or in the networking&web forum about how to run ssh over a non-standard port (≠22) if you want/have to. I don't think that things will work out very well for you, though, if you have multiple services trying to listen on the same port, though.

The number of other posts also discuss tunneling things like unencrypted VNC and unencrypted AFP/AFS connections through ssh (giving the added benefit of being able to close the vnc and afp ports in the local router). Of course, the tunneled traffic is delivered to the correct and appropriate port when it comes out of the tunnel, so the services at the far end are not listening to port 22, they are listening to the port that they normally listen. I don't know if you could have a Timbuktu client connect to localhost on a port other than 407 or not, but if you could, you should be able to tunnel that connection through ssh to the Timbuktu session on the other end of the ssh tunnel as well. Many client applications do allow you to do that, so they are all securely tunneled through ssh, so you only need that one single port open in your router for ssh.

Personally, I really like tunneling everything through ssh because I gain comfort knowing that most eavesdroppers can't glean any intelligence from any intercepted traffic, and because I like public key authentication, which you can do with ssh, way better than username/password authentication; the former I believe to be way superior in preventing break-ins.

ssh is a secure method. do you mean you want to change the port sshd listens on, or otherwise improve the security of ssh?

to start, use keys, not passwords. edit your /etc/sshd with the following lines:

ChallengeResponseAuthentication no
PasswordAuthentication no
AllowUsers (your short user name)

generate a public/private key pair and copy the key to your remote mac. you might want to do this before disabling ssh password logins.

then if you really want to change the listening port, you can do that by changing that in the sshd_config file and in the ssh.plist launchd item in /System/Library/LaunchDaemons/.

you can also use the /etc/hosts.deny and /etc/hosts.allow files to define access to specific IPs, hostnames, or ranges of machines.

clarify what you want to do, and we can help.

to revert the sshd_config, just comment out those lines or add "yes" instead of "no" to the password options.

check this for a decent tutorial on locking down ssh. there are many more, but this is a recent one. all of the basic principles apply.

Best solution is to use the hosts.allow file to limit requests to a range of IPs you know you will be connecting from. For example

ALL : .hsd1.nm.comcast.net

will refuse all connections from an address that is not Comcast New Mexico.

NOTE file MUST include final lineending or it will not work!

oops… it's sshd_config.

yes, add the AllowUsers line, as it's not there by default.

I'd be worrying a helluvalot more about leaving ports 407 and 5900 open than I would 22! I'd be tunneling that traffic through 22 if I were you.

All of the ssh lockdown suggestions put forth here are good; personally I prefer public key authentication using dsa keys only with username/password authentication disabled (common username with weak password doesn't protect you much - but a PGP-like key exchange does) (in terminal, see "man ssh-keygen") coz' I can't always guarantee what domain or IP I may be affiliated - all this is discussed in numerous posts in this forum and I believe over in the Networking&Web forum, too, as well as the numerous online tutorial sites (Bill Scott and Tim Haigh, regulars here, have put together some pretty decent OSX-flavored tutorials on this stuff).