ssh tunnel how to set up in SL?

On your router, you need to direct a port to port 22 on the target computer on your network. Port 22 is a natural option, but you can specify a target port number to SSH, so it's not essential. You would provide your SSH client with the WAN-facing IP address of your router (who will then forward it to your computer), and the port you selected (22 is the default). You need not open/redirect any other ports on your router.

I would suggest that you familiarize yourself with SSH and how to use a certificate-based login instead of a password-based one, as that will be far more secure. You'll want to change /etc/sshd.conf on your Mac to disable password-based logins and use only certificates.

Of course, make sure that you have SSH enabled on your Mac (called "Remote Login" in the Sharing pane of System Preferences).

Can you provide a more specific question?

SSH Tunnel Manager is pretty simplistic. There are very few options.

On my router I opened port 3283 and 5900. Correct?

Those ports are associated with System Preferences -> Sharing -> Remote Management (or Screen Sharing)

If you intend to do everything over ssh tunnels, then you do not need either of those ports open, as you will be tunneling everything over port 22.

OK Bob, thanks. So I can close both those ports on my router, correct? Even though I want to go in (once my tunnel is there) with Chicken of the VNC to control the screen.

If you create an ssh tunnel between your systems where you are associating some local port with port 5900 on the remote system, AND if your Chicken connection is something along the lines of

Host: localhost (or maybe 127.0.0.1)

Display or port: <local_tunnel_port>

then yes, I would say you are using the ssh tunnel to connect to the remote system.

If your Chicken connection is NOT using 'localhost' (or 127.0.0.1), but instead is using the IP address of the router in front of the Snow Leopard server, then that is not tunneling.

I'm assuming you are using the Snow Leoopard Server's System Preferences -> Sharing -> Screen Sharing as the VNC server on the server. If that is the case, you can also use your local Mac's Screen Sharing client via Finder -> Go -> Connect to server -> vnc://localhost:<local_tunnel_port>

I tend to use the Connect to server approach, except if the bandwidth is really slow. Then I use a combination of Vine Server on the remote system and Chicken on my Mac. The reason I do this is because Chicken allows me to use reduced colors (like 8-bit colors), and the Vine Server both honors my reduced color request and it actually plays nice with reduced colors (the Mac OS X Screen Sharing server does not alway play nice with anything less then 32-bit colors, which needs a lot more bandwidth).

So connecting to work, or any of my Macs at home, I use the Mac OS X Screen Sharing client, but when connecting to my Mom's iMac, I use Chicken and the Vine Server (Mom has a much slower internet connection). Or if I'm stuck in a Panera Bread (shared bandwidth and often slow), and I cannot avoid connecting to another system, I'll go for the Chicken/Vine Server combo and reduced colors.

"The computer "localhost" is running a VNC server that does not support Screen Sharing keystroke encryption. ..."

I suppose this is not a problem as I am tunnelling in over SSH, but would like to make sure.

Yes, the ssh tunnel is encrypting everything to and from the server. My first use fo tunnels was for just this reason. Basically securing the typically unsecured VNC connection between my Mom and me.

I suspect you get this message if you use the build-in Mac Screen Sharing client via vnc://localhost on the local Mac to connect with the Vine Server on the remote.

If you are running the Vine Server on the remote, make sure you either configure it with its own port number, such as 5901, or you turn off Screen Sharing and Remote Management Sharing System Preferences. Otherwise you are going to have them fighting over the use of port 5900. If you give Vine Server its own port number, make sure you setup your tunnel so that remote side of the tunnel setup points to the Vine Server port you configured.

To get reduced colors (and note, it is not pretty), you configure an 8-bit profile for Chicken of the VNC.

I generally use System Preferences -> Sharing -> Screen share instead of Remote Management. Remote Management is more intended for use with the Apple Remote Desktop (you gotta pay for it) software. And ARD is intended for managing a room full of Macs, such as a class room, or corporate setting. For what you are talking about, Sharing -> Screen Sharing is more than enough.

Chicken of the VNC -> Connection -> Connection Profiles - Default -> Color -> 256 Colors

Now when you connect, the Vine Server will ONLY send 8-bits per pixel, instead of 32-bits per pixel which will reduce the amount of data sent with each screen update. Of course the screen you see will be all blotchy, but it does improve the speed a little bit. But if the connection is very slow, you are at the mercy of the internet connection.

I use both, depending on the situation.

First, an easy to remember, easy to type password is often much more secure than a short complex mess of upper/lower/numbers/special characters.

Second, if you are going for ssh-keygen keys, test, test, test, before disabling ssh password logins.

BobHarris wrote:

First, an easy to remember, easy to type password is often much more secure than a short complex mess of upper/lower/numbers/special characters.

why would that be? Because lenght matters more than a convoluted password.

The bad guys have to guess, and unlike TV, they cannot guess the first letter, then guess the 2nd letter, then the 3rd letter etc... They need to guess every character of your password perfectly or they get rejected and they do not get any hints about how close they were.

So if you have a 1 character password, it takes 255 guesses (tops). If you have 2 character password, it takes maybe 65 thousand guesses, if you have a 3 character password it takes on the order of 16 million guesses, etc... So the longer the password the more guesses the bad guys need to try before they guess your password. Read the following web site: <http://www.grc.com/haystacks.htm>

Second, if you are going for ssh-keygen keys, test, test, test, before disabling ssh password logins.

I understand, and ask why? do you have bad experiences? is it not working some of the time? Hard to remove later?

If I screw up configuring the remote site (like my Mom's system), I have to travel to the remote site (Mom is 300 miles away), and that is not fun.

Also for systems such as my Mom's I configure the router to listen on a high numbered port and redirect that to port 22 on my Mom's iMac. Since the high numbered port is not a standard port number, the typical malware trying to break in, typically stick to well known ports and ignore the uninteresting high numbered port. So while this is NOT security, it reduces the noise my Mom's iMac sees as well as the number of possible break-in attempts. Then add in a long password, and I'm confortable that my Mom's iMac is secure.

Systems at work I frequently use ssh-keygen keys, but there I do that to make my life easy, as there are way too many software developers running around with sudo access, so I either need to trust them on go insane :-)