SSH, vnc and desktop sharing

OK, here’s the deal. We have a dedicated computer running Mac OS X 10.3 that does a variety of services including ssh, vnc and running (via Virtual PC) UPS Worldship.

What I want to do is have two Clients be authorized and set up so that they both are able to ssh tunnel into this machine, use vnc and run UPS Worldship in Virtual PC in the same desktop.

I thought I could just authorize them each to share a desktop in COTvnc and permit client sharing in OSXvnc. And, before using ssh tunneling this worked great.

The problem is the ssh. It appears the tunnels get confused if both clients try to tunnel into 5900. It keeps shutting down when both are connected.

So, I thought, I would have each client tunnel into OSXvnc and connect using separate ports, specifying in the tunnel that Client A’s vnc port will go to 5906 for Client B’s to 5908.

The problem that I’m having is that, for whatever reason, OSXvnc will only let one client connect at a time on these ports when what I want it to do is let Client A connect to the same desktop on port 5906 that Client B is connected to on port 5908.

Is this possible? For now, I am only ssh tunneling one client.

Oh, and why do I want both to be sharing one desktop? Because in case one user forgets to close out their session, I don’t want it to lock out the other.

Ok, OSXvnc will only let you specify a single port on which clients can connect. So if you want to go with that approach you will need to launch two OSXvnc’s (either two GUI’s or you can launch two from command-line).

I’m surprised about the SSH tunnel not allowing multiple forwards onto 5900 though. I just ran a simple test here and that seemed to work just fine (a Mac and PC both logging in via SSH with a tunnel to a 2nd Mac).

So if you can describe your SSH Tunnel setup in greater detail maybe we can figure out why that’s only allowing a single connection.

Thanks for the prompt reply.

I suppose it is possible it isn’t a conflict with ssh that is causing a client to get kicked off but thought it was worth trying.

You mention starting multiple instances of OSXvnc but I don’t see how to do that using the GUI (which as a newb, I am more familiar with).

It seems that you can only start one session and that a new Startup Service just replaces a prior one.

This is one place where the faq seems a bit cryptic.

Hmmm. Another update.

While it works fine when NOT running Virtual PC, once Virtual PC boots then one of the sessions gets booted.

So I don’t know whether it is ssh or osxvnc that is getting confused by running two sessions.

Do you have a suggestion as to logs to look over?

You’ll need to copy OSXvnc to launch a second one.

You’ll also probably want to modify the second one. This will allow them to have different preferences.

If you control click the new OSXvnc application you can select “Show Package Contents”, then go into the “Contents” folder you will see an Info.plist file. Open that file using TextEdit and modify these lines


To be


The OSXvnc logs can be found in your User ~/Library/Logs/ directory.

I don’t know that SSH keeps a connection log, but if you create your tunnels AND have them create a terminal session then you might see an error reported to the terminal session when you launch VirtualPC.

OK, this is from the System Log and, based on what I see, it looks like the tunnels are getting closed down.

Jul 12 16:43:05 localhost xinetd[407]: service ssh, IPV6_ADDRFORM setsockopt() failed: Protocol not available (errno = 42)
Jul 12 16:43:05 localhost xinetd[407]: START: ssh pid=580 from=
Jul 12 16:43:19 localhost sshd[580]: Accepted publickey for jehrler from port 56579 ssh2
Jul 12 16:43:48 localhost sshd[582]: Received disconnect from 2: Corrupted MAC on input.
Jul 12 16:43:50 localhost xinetd[407]: service ssh, IPV6_ADDRFORM setsockopt() failed: Protocol not available (errno = 42)
Jul 12 16:43:50 localhost xinetd[407]: START: ssh pid=583 from=
Jul 12 16:44:13 localhost sshd[583]: Accepted publickey for jehrler from port 56583 ssh2

Yeah, that looks like it might be some kind of a bug with VirtualPC, bizarre.

Another idea, those SSH tunnels can be coming from ANOTHER machine in the same subnet which then sends them on to the mac (on port 5900) so if you have a different machine (that you can SSH to), you can setup so they send to the VPC Mac and would probably NOT be effected by VirtualPC.

Good thought. I kinda only wanted SSH connections for vnc.

Is two running versions of osxvnc going to put a lot of extra stress on the machine?

Not unless they are both connected simultaneously and even then it’s manageable, just not as efficient as with a single server.

I really appreciate your helping me out.

OK, I created a second GUI version of OSXvnc (named it OSXvnc2) and made the modifications you suggested.

Set it up to listen on 5902 and clicked on Startup Item.

What it appeared to do was shut down OSXvnc on 5901 so that only connections on OSXvnc2 on 5902 were allowed.

Is there something else I need to do to keep OSXvnc2 from knocking out OSXvnc?

I wouldn’t set these as startup items, just run them from the GUI. So just hit “Start Server” and see that they say “Server Running”.

(That being said, you SHOULD be able to run them as startup items individually so I’m not sure what that problem could be).

Hmm. Would prefer they both startup when the system boots but can live with having one work as startup and the other can be a Startup Item in the main user.

Thanks again for the help!!!

But if you do figure out why they can’t both be startup items, do let me know. I’d be happy to do some hunting.

BTW, thought maybe I’d try rebooting the system to see if they both worked. No dice. Only the last OSXvnc server that I select as startup item is the one that actually acts as a startup item.

Well, this morning I have been testing out a theory and, so far, I am able to share the same ssh and vnc ports without Virtual PC 6.1.1 kicking me off.

I changed the networking preference for VPC from Shared Networking (where the Mac and the Windows virtual machine both share the same tcp/ip address) to Virtual Switch where the Windows virtual machine gets its own separate tcp/ip address.

Don’t know why it helped (or maybe the sunspots are less today) but it seems to be working fine.

Just an FYI.