Switching My Mother to the Mac

At 9:02 AM -0700 2007/04/12, Jim Saklad wrote:
>I must admit my needs are simpler - I'm unlikely to want to control
>regularly anything not already on my local network.
>
>What advantage would I see in using Vine Server over simply turning on
>Apple Remote Desktop in Sharing preferences?

        Better compatibility with non-Apple (free) clients, more
configuration flexibility (localhost only, requiring ssh for access),
and easier to run only when needed (you can fairly easily ssh in,
start up the server over a tunnel, and kill it when done). Also
multi-user support tied to Fast User Switching.

        ARD has a bunch of other management features, including
inventory and one-to-many control, better compatibility with Apple's
ARD (VNC) agent, and integration with Mac OS X accounts.

        I can't compare speed.


                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
                              <http://www.extrapepperoni.com/>
The Rockefeller University: <http://www.rockefeller.edu/>

On Apr 12, 2007, at 9:02 AM, Chris Pepper wrote:

> At 7:17 PM -0700 2007/03/29, rmovin wrote:
>> A few people have asked why I didn't use the included VNC server
>> in OSX.
>>
>> Short answer: I didn't know it was there. I'm just a recent switcher
>> myself still :)
>>
>> My question to the community is, can you restrict the included VNC
>> server to accept local connections only? That was a key layer in my
>> security plan.
>
> Alas, no. At least in Tiger, if you turn on Remote Desktop,
> it's automatically allowed through the firewall (from the whole
> Internet), just like all the other items in SP:Sharing.

But what gets it through the lack of port forwarding setup in
whatever is (probably) doing NAT between the world and the machine?

Not applicable to (most) dialup--except dialup using the modem in
some Airport base stations and similar things. Not applicable to a
bridged connection where the routable address actually does belong to
the Mac (our DSL customers CAN do that, but we certainly don't
recommend it).

   --John

At 9:02 AM -0700 4/12/07, Jim Saklad wrote:
>I must admit my needs are simpler - I'm unlikely to want to control
>regularly anything not already on my local network.
>
>What advantage would I see in using Vine Server over simply turning on
>Apple Remote Desktop in Sharing preferences?

That may depend on what client you plan to use. For example,
Redstone says its commercial Vine Viewer (client) provides extra
features when working with Vine Server, primarily rich clipboard
sharing (including files and applications) and Bonjour support.
Other clients may also support some of those features.

--Mark

On 4/12/07 15:49 PM, "Robert Movin" <rmovingmail.com> wrote:

>> I must admit my needs are simpler - I'm unlikely to want to control
>> regularly anything not already on my local network.
>>
>> What advantage would I see in using Vine Server over simply turning on
>> Apple Remote Desktop in Sharing preferences?
>
> It's just security- if you are local network only, behind a good
> firewall, you are fine using ARD to control systems in your house.
>
> But if you plan on controlling (or being controlled by) anything
> outside of your local network, then you want to use SSH and Vine.

What's wrong with Apple Remote Desktop's encryption?

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 1:49 PM -0700 2007/04/12, Robert Movin wrote:
>On Apr 12, 2007, at 9:02 AM, Jim Saklad wrote:
>
>>I must admit my needs are simpler - I'm unlikely to want to control
>>regularly anything not already on my local network.
>>
>>What advantage would I see in using Vine Server over simply turning on
>>Apple Remote Desktop in Sharing preferences?
>
>It's just security- if you are local network only, behind a good
>firewall, you are fine using ARD to control systems in your house.
>
>But if you plan on controlling (or being controlled by) anything
>outside of your local network, then you want to use SSH and Vine.

        Actually, ARD3 can do easy SSH tunneling. There's a checkbox
in the prefs to use fully encrypted connections; with this on, it
sshes into the remote server, brings up a tunnel, and connects
through the tunnel. Very slick!

        Unfortunately, on non-Server Mac OS X, there's no way to
disable the ARD firewall ports if you don't need them (if you are
coming in through ssh tunnels).

        In ARD2 it's possible to VNC through an ssh tunnel, although
it's awkward.


At 1:49 PM -0700 2007/04/12, johnbaxterlistsmac.com wrote:
>On Apr 12, 2007, at 9:02 AM, Chris Pepper wrote:
>
>>At 7:17 PM -0700 2007/03/29, rmovin wrote:
>>>A few people have asked why I didn't use the included VNC server
>>>in OSX.
>...snip...
>>it's automatically allowed through the firewall (from the whole
>>Internet), just like all the other items in SP:Sharing.
>
>But what gets it through the lack of port forwarding setup in
>whatever is (probably) doing NAT between the world and the machine?

        If you reach it over the Internet, so can undesirables; ssh
helps a lot with this.


                                                Chris

--
Chris Pepper: <http://www.reppep.com/~pepper/>
                              <http://www.extrapepperoni.com/>
The Rockefeller University: <http://www.rockefeller.edu/>

On Apr 12, 2007, at 1:49 PM, Mark R. Williamson wrote:

> At 9:02 AM -0700 4/12/07, Jim Saklad wrote:
>> I must admit my needs are simpler - I'm unlikely to want to control
>> regularly anything not already on my local network.
>>
>> What advantage would I see in using Vine Server over simply
>> turning on
>> Apple Remote Desktop in Sharing preferences?
>
> That may depend on what client you plan to use. For example,
> Redstone says its commercial Vine Viewer (client) provides extra
> features when working with Vine Server, primarily rich clipboard
> sharing (including files and applications) and Bonjour support.
> Other clients may also support some of those features.

My problem with Vine Server is that it doesn't show (me) the server
machine mouse pointer when I use Chicken of the VNC. Chicken does
show the pointer for other server machines (Linux) I use it with. (I
do see the little black dot showing where the client-driven cursor is
on the server, IF I'm doing the driving. Not good for being a
spectator. (We do lots of show and tell sessions with one driver and
several spectators (and Skype conference for audio).

This could be because the only server machine on which I've tried
Vine Server is PowerPC--it could be fine Intel Macs. (It would
probably be possible to reveal the pointer using a suitable mode in
OmniDazzle, but that shouldn't be necessary.)

I haven't (yet) asked Redstone about this. (I also haven't advocated
use of Vine Server to my co-workers because of the problem.)

   --John

On Apr 13, 2007, at 4:31 AM, Chris Pepper wrote:

> At 1:49 PM -0700 2007/04/12, johnbaxterlistsmac.com wrote:
>> On Apr 12, 2007, at 9:02 AM, Chris Pepper wrote:
>>
>>> At 7:17 PM -0700 2007/03/29, rmovin wrote:
>>>> A few people have asked why I didn't use the included VNC server
>>>> in OSX.
>> ...snip...
>>> it's automatically allowed through the firewall (from the whole
>>> Internet), just like all the other items in SP:Sharing.
>>
>> But what gets it through the lack of port forwarding setup in
>> whatever is (probably) doing NAT between the world and the machine?
>
> If you reach it over the Internet, so can undesirables; ssh
> helps a lot with this.

Agreed. (And so does a proper firewall configuration on the Mac,
rather than Apple's all or nothing approach.)

But that wasn't the situation I was answering. I was answering in a
thread which spoke of accessing only over the LAN.

   --John

<x-sigsep>

-- 

</x-sigsep>

On May 2, 2007, at 10:03 AM, Daniel Cohen wrote:

> Create a one line text file named tunnel.command that opens with
> Terminal. The text, suggested by Tom Stiller, is
>
> /usr/bin/ssh -R 5900:localhost:5900 -p22 -N -t -x -f myNamemyAddress
>
> This can be emailed as an attachment and then moved somewhere
> convenient. One may have to give instructions about this.

The one piece missing from this explanation of how it works is that
you then connect your VNC viewer to your local (helper's) machine's
appropriate port (in this case, port 5900, or display 0), and it'll
get forwarded to the remote machine.

This is a great trick, and thanks a bunch for sharing it! I have one
question for the wizards here: How can I make a similarly easy script
that will activate and de-activate the remote desktop/VNC server on a
given Mac? I'd rather not leave my parents/brother/grandfather stuck
with a VNC-server-sized security hole 24/7 just against the off-
chance I want to connect to them. Any thoughts?

--Nik

On May 5, 2007, at 18:14, Nik wrote:

> On May 2, 2007, at 10:03 AM, Daniel Cohen wrote:
>
>> Create a one line text file named tunnel.command that opens with
>> Terminal. The text, suggested by Tom Stiller, is
>>
>> /usr/bin/ssh -R 5900:localhost:5900 -p22 -N -t -x -f
>> myNamemyAddress
>>
>> This can be emailed as an attachment and then moved somewhere
>> convenient. One may have to give instructions about this.
>
> The one piece missing from this explanation of how it works is that
> you then connect your VNC viewer to your local (helper's) machine's
> appropriate port (in this case, port 5900, or display 0), and it'll
> get forwarded to the remote machine.
>
> This is a great trick, and thanks a bunch for sharing it! I have one
> question for the wizards here: How can I make a similarly easy script
> that will activate and de-activate the remote desktop/VNC server on a
> given Mac? I'd rather not leave my parents/brother/grandfather stuck
> with a VNC-server-sized security hole 24/7 just against the off-
> chance I want to connect to them. Any thoughts?

Somebody else might be able to script this . . . but if you're only
likely to need to connect to provide them some support . . . then
it's pretty easy to talk them through turning it on in the Sharing
pref pane.

If they're on broadband and protected by a firewall though . . .
you're not leaving a vnc-server-sized security hole anyway . . . the
port you need to set at the router for port forwarding is the SSH
port. As far as the firewall and target Mac are concerned . . . it's
a local VNC port connection but since it's forwarded over SSH the
hole is protected.

You can even set up key pairs and only allow particular machines to
connect if you want to . . . or you can set it up so only your home
machine's IP can connect . . . either of which adds a little more
security but given that it's SSH anyway I'm not sure that you gain
enough to make the lowered convenience of connect from anywhere worth
it.

At one point, Daniel Cohen wrote, in part:

This can be emailed as an attachment and then moved somewhere convenient. One may have to give instructions about this.

I have a problem in that the tunnel.command file described by Daniel is not executable in Terminal on my machine. How does one make it executable before emailing it to the person needing remote help?

Thanks! John

At 5:31 AM -0700 2007/05/07, jiclark wrote:
>I have a problem in that the tunnel.command file described by Daniel
>is not executable in Terminal on my machine. How does one make it
>executable before emailing it to the person needing remote help?

.command files are launchable like applications in the finder
-- you can double-click them, or drop them in the (right side of the)
Dock.

--
Chris Pepper: <http://www.reppep.com/~pepper/>
                              <http://www.extrapepperoni.com/>
The Rockefeller University: <http://www.rockefeller.edu/>

At 5:31 AM -0700 2007/05/07, Neil Laubenthal wrote:
>On May 5, 2007, at 18:14, Nik wrote:

>If they're on broadband and protected by a firewall though . . .
>you're not leaving a vnc-server-sized security hole anyway . . . the
>port you need to set at the router for port forwarding is the SSH
>port. As far as the firewall and target Mac are concerned . . . it's
>a local VNC port connection but since it's forwarded over SSH the
>hole is protected.

        Well, no. There's an ingress point for your Mac, it just
happens to be on another machine. It still connects back to your Mac.
It also may connect to the VNC or ssh server -- depending on how you
configure the tunnel.

        For better security, the tunnel can only accept connections
from 127.0.0.1, so people must have access to the intermediate
machine (either via console, another ssh tunnel, or another VNC-style
connection).

--
Chris Pepper: <http://www.reppep.com/~pepper/>
                              <http://www.extrapepperoni.com/>
The Rockefeller University: <http://www.rockefeller.edu/>

At some point, Chris Pepper wrote:

> .command files are launchable like applications in the finder
> -- you can double-click them, or drop them in the (right side of the)
> Dock.

Well, for some reason, my 'tunnel.command' file gives me this error
when double-clicked:

"The .command file ‘/Users/jc/Desktop/tunnel.command’ could not
open. Most likely it is not executable."

What's going on there? More importantly, how do I know it will run on
a remote user's computer?

I'm struggling to find the best tool for this job, since I'm doing
more remote consulting all the time. I've looked at both Copilot:

<https://www.copilot.com/>

and SpyMe: <http://www.readpixel.com/spyme/>

…as well as the numerous other techniques, like the one linked to
previously at Mac OS X Hints.com. The problem is, none of them seem
to be as simple and reliable as claimed. Just look at that Mac OS X
Hints thread:

<http://www.macosxhints.com/article.php?story=20070302234400232>

…and read the comments to see how common it is for people to try
these techniques out and fail. This thread regarding your original
article bears this out as well!

I realize it's because no two setups are the same, and all the port
forwarding etc. required is just not simple stuff (not to mention
what's involved if the connection must be secure!).

I guess I'd just like to know if perhaps someone here could create a
more complete description of how to make this particular
"tunnel.command" technique work, or if I'm just going to be better
off going with one of the other fee-based solutions like Copilot
(which I haven't been able to test yet).

TIA,
John

At 12:09 PM -0700 2007/05/10, John I. Clark wrote:
>At some point, Chris Pepper wrote:
>
>>.command files are launchable like applications in the finder
>>-- you can double-click them, or drop them in the (right side of the)
>>Dock.
>
>Well, for some reason, my 'tunnel.command' file gives me this error
>when double-clicked:
>
>"The .command file Œ/Users/jc/Desktop/tunnel.command¹ could not
>open. Most likely it is not executable."
>
>What's going on there? More importantly, how do I know it will run on
>a remote user's computer?

        Hmm. I don't remember any trouble with
this, but I suggest you start the file with
"#!/bin/sh" by itself as the first line; this
specifies it should run in bash.

        Yes, I see what you mean; the shell
invocation header doesn't make it executable. If
you can't get it to the user with the executable
bit set, they can run it with sh, using something
like "sh /Users/jc/Desktop/tunnel.command", but
that defeats the point of using a
double-clickable .command file.


>I realize it's because no two setups are the same, and all the port
>forwarding etc. required is just not simple stuff (not to mention
>what's involved if the connection must be secure!).

        I have high hopes for iChat to fix this
in Leopard. In the meantime, you're right -- it's
a complicated problem and there's no simple and
general solution.

>I guess I'd just like to know if perhaps someone here could create a
>more complete description of how to make this particular
>"tunnel.command" technique work, or if I'm just going to be better
>off going with one of the other fee-based solutions like Copilot
>(which I haven't been able to test yet).

        I will add something about executable
bits to TCoSSH and
<http://www.extrapepperoni.com/2007/03/24/tcossh-reverse-tunnels/>.


                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
                              <http://www.extrapepperoni.com/>
The Rockefeller University: <http://www.rockefeller.edu/>

On May 10, 2007, at 3:09 PM, John I. Clark wrote:

> Well, for some reason, my 'tunnel.command' file gives me this error
> when double-clicked:
>
> "The .command file ‘/Users/jc/Desktop/tunnel.command’ could not
> open. Most likely it is not executable."

You need to set the execute mode bit.

I just did a test with a file named test.command containing the
following

> #! /bin/bash
>
> echo this is a test

Creating it with TextEdit and double clicking led to the behavior you
describe. So, I opened Terminal and typed

> chmod +x

then dragged the file into the terminal window so now the line looked
like

> chmod +x /Users/fbrehm/Desktop/test.command

and then hit return. Double clicking the file now opened a terminal
window with the "this is a test" line on it (along with a bunch of
other stuff).

Fred

On May 10, 2007, at 12:09 PM, John I. Clark wrote:

> Well, for some reason, my 'tunnel.command' file gives me this error
> when double-clicked:
>
> "The .command file ‘/Users/jc/Desktop/tunnel.command’ could not
> open. Most likely it is not executable."

Well, most likely the command file is not executable.

To check:
Launch Terminal

cd Desktop
ls -l tunnel.command

You might see
-rw-r--r-- 1 jc jc 23 May 11 08:15 tunnel.command

You should see
-rwxr--r-- 1 jc jc 23 May 11 08:15 tunnel.command

(Assuming you do own the file, the important part is the rw- vs rwx
and you MIGHT not want the other two rs--Finder can fix those for you.)

chmod u+x tunnel.command

Now the command file should execute when double-clicked.

   --John (My hovercraft is full of eels.)

On May 10, 2007, at 12:09 PM, John I. Clark wrote:

> "The .command file ‘/Users/jc/Desktop/tunnel.command’ could not
> open. Most likely it is not executable."
>
> What's going on there? More importantly, how do I know it will run
> on a remote user's computer?

It's probably missing the "executable" permission flag, which you can
add via Terminal with the command:

   chmod +x /Users/jc/Desktop/tunnel.command

In order to deliver this to someone else with the "executable" flag
(s) set, you'll need to store it in an archive that preserves this
flag, which you can create in Finder with the File > Create Archive of….

If the user downloads this with Safari they should get a warning that
the archive contains an application.

--
Chris Page - Text Editor

An ASCII character walks into a bar. Bartender asks, “What’ll you
have?” ASCII character says, “Give me a double.” Bartender asks,
“Having a bad day?” ASCII character says, “Yeah, I have a parity
error.” Bartender says, “Hmmm. I thought you looked a bit off.”

Thanks to all that replied with instructions for setting the
executable bit on the tunnel.command file. And especially to Chris
Page for the additional instructions for making it work on a remote
user's Mac.

In the meantime, I've managed to get the technique described in the
aforementioned MacOSXHints.com hint working, the one using the cool
little Schnitz Remote Lite program. I now have a little AppleScript
app bundle that works quite easily and reliably to create the
connection from the remote user's machine to mine, with no extra
configuration required on the remote Mac. Phew! What an ordeal, even
if it was an educational one!

I'm guessing the tunnel.command file would have worked as well, if
not quite as easily, once the executable bit had been set. With the
technique I've gotten working, we avoid the need get Terminal involved.

Thanks again,
John

thanks for the article. I'm setting up a Mac Book for my dad and want to implement this. Not succeeding yet. I get refused on "ssh -L 5900:127.0.0.1:5900 <my username><Mom's IP>" or nothing happens. I can make it work on local network, but no over Internet, probably a problem setting up my Verizon FiOS router.