Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

SSH help for remote desktop (COTVNC)

gauchogolfer

gauchogolfer

macrumors 603
Original poster
Jan 28, 2005
5,551
6
American Riviera
Hi all,
I'm following the MR Guide on Remotely Controlling Another Mac here, and having trouble. We are all running the latest version of Tiger.

So far I've enabled Remote Login on my machine, created a dummy account, and installed COTVNC. I also set up a dynDNS account. My home network has 3 machines (only one Mac) behind a router, and I've forwarded ports 22, 3283, and 5900 to my specific IP address. So far so good, I thought.

My sister's machine (the one I'm trying to control) is also behind a router. She has enabled ARD in SysPrefs->Sharing according to the guide, and created the Terminal file to ssh to my machine.

So, here is where I believe the problem occurs. She types in the following:

ssh dummy@dbuell.homeip.net -R 5900:127.0.0.1:5900

where dbuell.homeip.net is the dynDNS name given to me by the provider.
Does this look like the right way to go about this?

When I open up COTVNC I see her computer (Emily's iBook), but when I try to connect I get 'Error 30' and 'Please configure the client to allow screen viewing'. We have also copied the public key generated on her machine onto my computer.

Using ssh, do I still need to have her open up/forward ports on her router? I was under the impression that this wouldn't be necessary.

Thanks for any help you can give regarding this, it's got me scratching my head.
 
I think your ssh command is a little backwards. I'd suggest this instead:

ssh -R 5900:127.0.0.1:5900 dummy@dbuell.homeip.net

Also, I use "Vine Server" rather than ARD, but that shouldn't stop things from working. You are correct that the only port you need to forward through the router is the ssh port (TCP port 22). After she starts ssh as above and you start COTVNC, you need to connect to 127.0.0.1, not her address (that's the port forwarding part of the ssh command). Assuming she's got ARD (or Vine Server) running you should be able to connect. The "public key" is only needed for ssh, so if she's getting connected with the above ssh command you don't need to worry about that. She should be able to enter various Unix command on your computer, such as "ls" and "date", if ssh is working. If she can't, then ssh isn't working yet and that's where you need to focus your attention.

HTH - Good luck!
 
Thanks folks, I figured that it was the ssh part that was holding us up. One question: if I've botched up the public key part (i.e. didn't append it to the right file in ~/.ssh/ ) would she be prompted to enter the user password for the dummy account? Because this would be ok with me also.

Also, I'm assuming I can connect to 'localhost' rather than typing in 127.0.0.1, since I think they're equivalent. True?
 
FWIW I have a bash script I created to simplify setting up an SSH tunnel for use with VNC:

Code: 
#!/bin/bash

if [ $1 ] ; then
  echo "Starting tunnel of port 5901 to $1"
  ssh -xNL 5901:localhost:5901 $1 &
else
  echo "usage start_vnc_tunnel <servername>"
fi
 
gauchogolfer said:
Hey thanks.
Can you explain a little bit about the code there, just so I have a better handle on what it's doing?
Click to expand...
It's just a wrapper that allows you to specify the hostname in the command below.

Code: 
ssh -xNL 5901:localhost:5901 <hostname> &

If you don't specify a hostname on the line it'll give you the usage help.

-x is no X11
-N is no remote command
-L is the local redirection
Click to expand...

B
 
gauchogolfer said:
Hey thanks.
Can you explain a little bit about the code there, just so I have a better handle on what it's doing?
Click to expand...

Sure.

The script is saved under the name "start_vnc_tunnel", which is probably obvious. :) If you are connecting to a remote machine named jennyspc.dydns.org, you'd run it as "start_vnc_tunnel jennyspc.dydns.org". You could also use the IP address of the remote machine instead of its name.

Basically the script looks to make sure you passed a remote machine's name on the command line (the "if [ $1 ] ; then" part). If you did, it prints out a line that tells you its trying to set up port forwarding to port 5901 on the remote machine. If you forgot to give it a remote name, it reminds you how you're supposed to run it.

The ssh variables are as follows:

-x disables X11 forwarding. Not strictly necessary, but no point in having it on when you're not going to use it (my ssh config file has X11 enabled) from a security standpoint.

-N tells ssh that we're not going to execute a remote command. If you don't do this, ssh tries to open a shell.

-L just tells ssh to handle the port forwarding at the local end of things. You used -R (handle it on the remote machine). I generally use -L because I have full control over the config on my local machine (and thus, if necessary, can adjust the config to make things work), while I may or may not have the rights to configure the ssh daemon on the remote machine. In your particular case it won't matter since you're configuring both machines.

The ampersand at the end of the ssh line sends the command into the background immediately. I use a public/private keypair (and SSHKeychain) for authentication - if a person is using passwords, then you wouldn't want to use the ampersand because you'd need to type the password.

Edit: All that typing, and then balamw beat me to it. :D
 
Thanks, and one final question (for the moment :p).

If I'm using the ssh -R formalism, does the public key generation need to be done on her machine (the target, to be controlled) or on my machine (the one running COTVNC)? On our first attempt we generated the key on her machine, and then copied it to my machine, renaming it ~/.ssh/authorized_keys as described in the Guide.
 
gauchogolfer said:
Thanks, and one final question (for the moment :p).

If I'm using the ssh -R formalism, does the public key generation need to be done on her machine (the target, to be controlled) or on my machine (the one running COTVNC)? On our first attempt we generated the key on her machine, and then copied it to my machine, renaming it ~/.ssh/authorized_keys as described in the Guide.
Click to expand...

Technically it doesn't matter where the key is generated - you could do it on a separate Linux box if you wanted. But the private key needs to be connected to the account from which you will be initiating the ssh session (your box); and from a security standpoint that private key should not be transferred around at all, if you can help it - so that means you really should generate the keypair on your own box. Then you can put the public key on her box and on any other boxes you desire.

Also, I don't seen any mention (in your posts) about a passphrase for the public-private keypair. Hopefully that's because it's just too obvious to mention, but if not - you MUST have a good passphrase on the keypair. Otherwise you're basically opening up your boxes to password-less logins from any hacker that wants to try, since recovering a public key is fairly trivial.
 
Westside guy said:
Technically it doesn't matter where the key is generated - you could do it on a separate Linux box if you wanted. But the private key needs to be connected to the account from which you will be initiating the ssh session (your box); and from a security standpoint that private key should not be transferred around at all, if you can help it - so that means you really should generate the keypair on your own box. Then you can put the public key on her box and on any other boxes you desire.

Also, I don't seen any mention (in your posts) about a passphrase for the public-private keypair. Hopefully that's because it's just too obvious to mention, but if not - you MUST have a good passphrase on the keypair. Otherwise you're basically opening up your boxes to password-less logins from any hacker that wants to try, since recovering a public key is fairly trivial.
Click to expand...

So, I should generate the public key on my box, then send that to her?
Also, I'm using a pretty strong password on the public key, thanks for checking on me.
 
gauchogolfer said:
So, I should generate the public key on my box, then send that to her?
Click to expand...

Yes, exactly. (Maybe over-explaining here) the thing about public-private key cryptography is that everyone and his brother can have your public key. You could publish it on the web if you wanted. :D The security of your private key is what matters - without the private key, having the public key doesn't accomplish anything.
 
Westside guy said:
Yes, exactly. (Maybe over-explaining here) the thing about public-private key cryptography is that everyone and his brother can have your public key. You could publish it on the web if you wanted. :D The security of your private key is what matters - without the private key, having the public key doesn't accomplish anything.
Click to expand...


Thanks.

I suppose I didn't phrase my question very well. It's my understanding that using ssh -R as the MR Guide says initiates a reverse tunnel from my machine to hers. I just wanted to make sure that I'm generating the appropriate key. As in, if I use ssh -R from her machine, pointing towards mine, I need to send her my public key. And, if I were to ssh -R from my machine, pointing towards hers, she would need to send me her public key. Is this true? I suppose in the end it may be easier if we both swap keys, just to cover our bases.

Cheers.
 
gauchogolfer said:
Thanks.

I suppose I didn't phrase my question very well. It's my understanding that using ssh -R as the MR Guide says initiates a reverse tunnel from my machine to hers. I just wanted to make sure that I'm generating the appropriate key. As in, if I use ssh -R from her machine, pointing towards mine, I need to send her my public key. And, if I were to ssh -R from my machine, pointing towards hers, she would need to send me her public key. Is this true? I suppose in the end it may be easier if we both swap keys, just to cover our bases.

Cheers.
Click to expand...

Here's the way I understand it (though I could be wrong).

-R creates a tunnel on the remote machine so that the remote port XXX gives access to the local port YYY.

-L creates a tunnel on the local machine so that local port XXX gives access to remote port YYY

In either case the machine initiating the ssh connection should be the one with the public key and the one accepting has the corresponding private key.

B
 
Westside guy said:
I believe you've got that exactly backwards.
Click to expand...

:confused:

I know that's how I use it with my Linux boxes at work. The private key is only on the servers and the clients only have the public key and initiate the connection.

Unless you're counting the one running sshd as the initiator.

EDIT: Now you've got me doubting it. It's been quite a few years since I set it all up. :p

B
 
Westside guy said:
Here's a link to one of the better-written how-tos:

http://sial.org/howto/openssh/publickey-auth/#s2

That section talks specifically about where your public and private keys should go.
Click to expand...

FWIW I checked my work setup and it is as described. Private keys genreated/stored on the clients (ssh/putty), and public keys on the server (sshd). :eek:

I guess it's true what they say. Memory's the first thing to go. :p

B
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back