Print

SSH on Mac OS X for Worry-Free Wireless

by Derrick Story and Rob Flickenger

11/21/2001

Network security for projects such as webcam broadcasting isn't as much of an issue when your device is hard-wired into the desktop computer sitting on your office desk. But if you set up a wireless transmitter using an 802.11b network as described in my last article, The Industrial-Strength Wireless Webcam, you need to evaluate your environment and establish the appropriate level of security.

Once you start sending private data over the radio waves, such as your FTP user name and password, you are increasing the likelihood that some unauthorized snoop can "listen in" and grab your data.

In most home 802.11b situations, I still believe that the combination of common sense and the use of WEP provides you with the security you need for broadcasting to your hobby Web site. But what if you want to use a webcam in public and send images to a business site? Certainly you don't want to take a chance on compromising security.

In situations like this, the Unix underpinnings of Mac OS X begin to show their value. In this article, I'm going to suggest a safe solution for broadcasting your webcam images, or any other data for that matter, using the Terminal application in Mac OS X to establish a secure connection with your Web server.

Since we're talking Unix here, these techniques will work in any command line environment capable of using SSH, and we're definitely not limited to using Mac OS X for this project. So let's pop the hood and get to work.

A few words about SSH and SCP

Comment on this articleDo those of you who have some experience using pico and Mac OS X have any additional pointers?
Post your comments

SSH Secure Shell is a protocol for secure remote logins. Its key function is to prevent hackers from stealing passwords that give them unauthorized access to Web sites. SSH does this by encrypting the data (including passwords) to eliminate eavesdropping. It connects to the specified hostname, making the user prove his/her identity to the remote machine.

Once the SSH connection is established, SCP (secure copy) copies files between hosts on a network. It uses SSH for data transfer, and uses the same authentication by asking for passwords or phrases.

Mac OS X users can set up these secure connections via the Terminal application. If you haven't worked with command lines before, I suggest that you you practice first by building a couple of basic scripts. You can get more information on this from a variety of places, such as the Project Freedom Web site, or via downloadable PDFs such as Griffman's Terminal Guide. Once you're comfortable with the Terminal application, then you're ready to set up a SSH session.

Basic steps for establishing a secure wireless session with a Mac OS X client

The process for establishing secure transmission of webcam images on a public wireless network is:

  • Create a directory on your local drive and tell CoolCam to send the captured images to that directory.
  • Generate an ssh public/private key pair.
  • Set up the ssh directory on the Web server, and copy the new public key to it.
  • Test a secure copy to ensure everything is working properly.
  • Set up a cron job so that your images are are automatically sent from the local directory to the server in regular intervals.
  • Disable the cron once your webcam session is over.

Setting up your secure session on Mac OS X

Related Articles

Network Test Automation with Mac OS X and Tcl


Industrial-Strength Wireless Webcam


Life After AirPort -- New Wireless Base Stations


Using SSH Tunneling


Once you have the webcam software saving to a file in the filesystem, you're ready to set up ssh for public key operation. Both ssh and scp use the same keys to do their work, so once ssh is set up, scpwill work.

These steps assume that you don't have any other keys present on your Web server. If you do, then you already know what you're doing, and don't need this article... =)

1) Generate a new key:


rob@entropy$ ssh-keygen -d
Generating public/private dsa key pair.
Enter file in which to save the key (/home/rob/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/rob/.ssh/id_dsa.
Your public key has been saved in /home/rob/.ssh/id_dsa.pub.
The key fingerprint is:
33:3c:5c:41:98:1b:fc:f5:9e:69:56:2e:0b:f1:24:7f rob@entropy

* The -d option specifies DSA keys (instead of RSA keys). The ssh v2 protocol uses DSA keys, and is widely regarded as more secure than v1.

* After entering the command, hit enter three times (to take the default filename, and to enter no passphrase.)

* Congratulations. Your public and private keys are now saved to ~/.ssh/id_dsa.pub and ~/.ssh/id_dsa, respectively.

2) Copy the key to your Web server:


rob@entropy$ scp ~/.ssh/id_dsa.pub www.mydomain.net:.ssh/authorized_keys2

* At this point, if you've never used ssh from your OS X box before, you'll be prompted to verify the fingerprint of the server's key. Answering "yes" will save the server's fingerprint in a local cache. Should the fingerprint ever change, ssh (and scp) will sound an alarm, as this could be an indication of a man-in-the-middle attack in progress.

* You will be prompted for your password on the Web server. Enter it, and the key file will be copied.

3) Test the ssh key:


rob@entropy$ ssh www.mydomain.net
ogin: Mon Oct 29 10:58:32 2001 from entropy.oreilly.com rob@www$

* It should log you in without a password. If not, check your work. Also check that your Web server allows public key exchange (it's on by default, and is rarely disabled. Check with your friendly local sysadmin if you're not sure.)

5) Log out, and try an scp:


rob@www$ exit
Connection to www closed.
rob@entropy$ scp /path/to/my/webcam.jpg www.mydomain.net:/path/to/graphic/
webcam.jpg           100% |*****************************|   601       00:00 
rob@entropy$

* It should copy the file without asking for a password. The syntax is:


scp [source file] [hostname]:[destination directory]

* This example also assumes that you have the same username on your Mac OS X client as on your Web server. If not, you can also specify a different username on the scpcommand line. For example, if your login on the Web server is webadmin:


rob@entropy$ scp /path/to/my/webcam.jpg webadmin@www.mydomain.net:/path/to/graphic/

6) Set up cron:

Before adding a new entry to cron (sometimes called your crontab), you may want to set your editor to the user-friendly editor pico by using this command:


name% setenv EDITOR pico

Now that you've established pico as your default editor, you can set up the cron entry:


rob@entropy$ crontab -e

(This will start pico with the contents of your current crontab. Unless you've added some lines yourself, this will probably be an empty file.)

Add this line:


*/5 * * * * /usr/bin/scp /path/to/my/webcam.jpg www.mydomain.net:/path/

(This means, every five minutes of every day, do this...)

7) In five minutes, check your Web site with a browser. The updated picture should magically appear. Congratulations! Your webcam images are now being updated over a cryptographically secure channel, safe from wireless eavesdroppers.

When you are finished with your webcam, it's a good idea to tell cron to stop trying to update your Web site. To disable the cron entry, run another crontab -e in your terminal window, and comment out the line with a # symbol:


# */5 * * * * /usr/bin/scp /path/to/my/webcam.jpg

Now, whenever you want to start the auto-update process again, just delete the #, and away you go.

If you have trouble getting it going, there are excellent man pages available for ssh-keygen, ssh, and scp. You might also take a look at Rob's article on using SSH with wireless networks.

Final thoughts

This probably feels like a lot of work just to set up a webcam session. But the risks of transmitting unsecured data over a public network far outweigh the effort to set up ssh/scp. The good news is, once you've established your system, it's easy to turn on and off. As a bonus, with ssh keys in place, you can securely copy files and log in to your Web server without needing to use passwords.

If you discover a clever workaround that saves time or improves performance, be sure to let us know via the TalkBacks.

Derrick Story is the author of The Photoshop CS4 Companion for Photographers, The Digital Photography Companion, and Digital Photography Hacks, and coauthor of iPhoto: The Missing Manual, with David Pogue. You can follow him on Twitter or visit www.thedigitalstory.com.

Rob Flickenger is a long time supporter of FreeNetworks and DIY networking. Rob is the author of three O'Reilly books: Building Wireless Community Networks, Linux Server Hacks, and Wireless Hacks.


Return to the Wireless DevCenter.


  • SSH Problem with Instructions
    2001-11-28 13:58:11  cochella [View]

    No; this is the convention used by the SSH server from HREF="http://www.ssh.com/">ssh.com. It will not work with OpenSSH
    (which is what you say is running on the server). And if the server
    were ssh.com, you would need to convert the key format in any
    case.

    On the remote server there is OpenSSH and I was using the wrong convention; I did not realize there were different conventions--silly. The server OpenSSH version is: openssh-2.2.0p1-2

    So, I have changed conventions to thosethat your article describes: using .ssh with an authorized_keys2 file with the public key in this file on the remote machine.

    After making these changes I still only get password authentication:


    [localhost:~/.ssh] cochella% ssh -2 -l chris -i /Users/cochella/.ssh/identity cochella.com
    chris@myhostname.com's password:
    Last login: Wed Nov 28 15:01:07 2001 from 166.70.xxx.xxx
    [chris@server1 cochella]$

    As suggested I am trying to do version 2 with the switch "-2"


    So, I do not understand what the problem is?

    Any further advice would be most helpful.

    Thanks.

    Chris
    • SSH Problem with Instructions
      2001-11-28 15:20:30  res [View]


      Use "ssh -v ..." to see what it's doing.

      Why are you using -i to tell it to use the wrong key? As I pointed out last time, ~/.ssh/identity contains a protocol-1-only key.
      • SSH Problem with Instructions
        2001-11-30 05:05:10  ahinds [View]

        I too am having the same problem with automatic logins.

        I followed the instructions to the letter. Here is part of my session transcript. Any help would be appreciated. Thanks!

        ---
        [localhost:~/.ssh] ahinds% ssh -v xxx.com
        OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
        debug1: Reading configuration data /etc/ssh_config
        debug1: Seeding random number generator
        debug1: Rhosts Authentication disabled, originating port will not be trusted.
        debug1: restore_uid
        debug1: ssh_connect: getuid 501 geteuid 501 anon 1
        debug1: Connecting to xxx.com [xxx.xx.xxx.xx] port 22.
        debug1: restore_uid
        debug1: restore_uid
        debug1: Connection established.
        debug1: identity file /Users/ahinds/.ssh/identity type -1
        debug1: identity file /Users/ahinds/.ssh/id_rsa type -1
        debug1: identity file /Users/ahinds/.ssh/id_dsa type 2
        debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2
        debug1: match: OpenSSH_2.9p2 pat ^OpenSSH
        Enabling compatibility mode for protocol 2.0
        debug1: Local version string SSH-2.0-OpenSSH_2.9p2
        debug1: SSH2_MSG_KEXINIT sent
        debug1: SSH2_MSG_KEXINIT received
        debug1: kex: server->client aes128-cbc hmac-md5 none
        debug1: kex: client->server aes128-cbc hmac-md5 none
        debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
        debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
        debug1: dh_gen_key: priv key bits set: 125/256
        debug1: bits set: 1049/2049
        debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
        debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
        debug1: Host 'xxx.com' is known and matches the RSA host key.
        debug1: Found key in /Users/ahinds/.ssh/known_hosts2:1
        debug1: bits set: 1012/2049
        debug1: ssh_rsa_verify: signature correct
        debug1: kex_derive_keys
        debug1: newkeys: mode 1
        debug1: SSH2_MSG_NEWKEYS sent
        debug1: waiting for SSH2_MSG_NEWKEYS
        debug1: newkeys: mode 0
        debug1: SSH2_MSG_NEWKEYS received
        debug1: done: ssh_kex2.
        debug1: send SSH2_MSG_SERVICE_REQUEST
        debug1: service_accept: ssh-userauth
        debug1: got SSH2_MSG_SERVICE_ACCEPT
        debug1: authentications that can continue: publickey,password,keyboard-interactive
        debug1: next auth method to try is publickey
        debug1: try privkey: /Users/ahinds/.ssh/identity
        debug1: try privkey: /Users/ahinds/.ssh/id_rsa
        debug1: try pubkey: /Users/ahinds/.ssh/id_dsa
        debug1: authentications that can continue: publickey,password,keyboard-interactive
        debug1: next auth method to try is password
        ahinds@xxx.com's password:
        • SSH Problem with Instructions
          2001-12-31 06:52:52  cochella [View]

          Have you found a solution yet?

          Thanks,

          Chris
          • SSH Problem with Instructions
            2007-04-02 08:32:59  bglnelissen [View]

            i have had the same problems, it worried me the whole day, one way was doing ok, the other way was asking my password.

            But now it is fixed. My problem where the permissions of my home folder, .ssh folder and the content of the .ssh folder.
            I did a (i can be wrong, if so corrent me but i dont know the default permissions of the home folder so i took 755)

            change the rights of EVERY file in my homefolder, this is done with the -R flag. It might be nicer if you dont use it at all and type (chmod 755 /Users/USERNAME/)
            $ chmod -R 755 /Users/USERNAME/

            change the permissions of the .ssh folder
            < code >$ chmod 700 ~/.ssh

            change the permissions of the .ssh folders content
            < code >$ chmod 600 ~/.ssh/*

            good luck.
      • SSH Problem with Instructions
        2001-12-31 07:02:22  cochella [View]

        Here is the -v output. It appears, from what I can understand, that public key authentication is taking place. But, I get asked for the password and not the passphrase.

        Thanks,

        Chris


        _________

        [localhost:~/.ssh] cochella% ssh -2 -v -l chris myhost.com
        OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
        debug1: Reading configuration data /etc/ssh_config
        debug1: Seeding random number generator
        debug1: Rhosts Authentication disabled, originating port will not be trusted.
        debug1: restore_uid
        debug1: ssh_connect: getuid 501 geteuid 501 anon 1
        debug1: Connecting to myhost.com [209.55.121.12] port 22.
        debug1: restore_uid
        debug1: restore_uid
        debug1: Connection established.
        debug1: identity file /Users/cochella/.ssh/id_rsa type -1
        debug1: identity file /Users/cochella/.ssh/id_dsa type 2
        debug1: Remote protocol version 1.99, remote software version OpenSSH_2.2.0p1
        debug1: match: OpenSSH_2.2.0p1 pat ^OpenSSH[-_]2\.[012]
        Enabling compatibility mode for protocol 2.0
        debug1: Local version string SSH-2.0-OpenSSH_2.9p2
        debug1: SSH2_MSG_KEXINIT sent
        debug1: SSH2_MSG_KEXINIT received
        debug1: kex: server->client 3des-cbc hmac-md5 none
        debug1: kex: client->server 3des-cbc hmac-md5 none
        debug1: dh_gen_key: priv key bits set: 197/384
        debug1: bits set: 524/1024
        debug1: sending SSH2_MSG_KEXDH_INIT
        debug1: expecting SSH2_MSG_KEXDH_REPLY
        debug1: Host 'myhost.com' is known and matches the DSA host key.
        debug1: Found key in /Users/cochella/.ssh/known_hosts2:3
        debug1: bits set: 506/1024
        debug1: len 55 datafellows 49296
        debug1: ssh_dss_verify: signature correct
        debug1: kex_derive_keys
        debug1: newkeys: mode 1
        debug1: SSH2_MSG_NEWKEYS sent
        debug1: waiting for SSH2_MSG_NEWKEYS
        debug1: newkeys: mode 0
        debug1: SSH2_MSG_NEWKEYS received
        debug1: done: ssh_kex2.
        debug1: send SSH2_MSG_SERVICE_REQUEST
        debug1: service_accept: ssh-userauth
        debug1: got SSH2_MSG_SERVICE_ACCEPT
        debug1: authentications that can continue: publickey,password
        debug1: next auth method to try is publickey
        debug1: try privkey: /Users/cochella/.ssh/id_rsa
        debug1: try pubkey: /Users/cochella/.ssh/id_dsa
        debug1: authentications that can continue: publickey,password
        debug1: next auth method to try is password
        chris@myhost.com's password:
        debug1: ssh-userauth2 successful: method password
        debug1: channel 0: new [client-session]
        debug1: channel_new: 0
        debug1: send channel open 0
        debug1: Entering interactive session.
        debug1: client_init id 0 arg 0
        debug1: channel request 0: shell
        debug1: channel 0: open confirm rwindow 0 rmax 32768
        Last login: Mon Dec 31 08:11:09 2001 from 166.55.565.65
        [chris@server1 cochella]$
  • corrections, clarifications, comments
    2001-11-26 20:06:16  res [View]


    I'd like to make a few corrections, clarifications, and further comments
    regarding this article, which may be of help to your readers.




    rob@entropy$ ssh-keygen -d
    ...
    * The -d option specifies DSA keys (instead of RSA keys).


    The version of OpenSSH which comes with Mac OS X is 2.3.0, and it does use
    the ssh-keygen -d command to generate a DSA key. It's useful to
    note, however, that later versions of OpenSSH (3.0.1 is the current
    release) use different switches; the equivalent would be ssh-keygen -t
    dsa
    .


    The ssh v2 protocol uses DSA keys, and is widely regarded as more secure
    than v1.


    In fact, the SSH-2 protocol defines the use of either RSA or DSA keys, and
    can accomodate any public-key authentication method.



    The procedure described here makes a few unstated assumptions:





    • That the SSH server supports protocol 2. It may not, in which
      case the public-key authentication will not work, since DSA keys may only
      be used with protocol 2.

    • That the SSH server is in fact also OpenSSH. The details of
      how to authorize a key for login are not part of the SSH protocol, and
      vary from one implementation to another. Placing the public key in
      ~/.ssh/authorized_keys2 on the server will not work if the server
      is the ssh.com software, for example.

    • That the server supports only protocol 2. The OpenSSH
      2.3 client prefers protocol 1 if available (this default was changed in
      OpenSSH 2.9). Thus, if you follow these directions and connect to a
      server which supports both protocol versions, the client will select
      protocol 1 and fail public-key authentication, even though it could have
      succeeded by using protocol 2. You can force the use of protocol 2 with
      the -2 switch to ssh.




    After entering the command, hit enter three times (to take the default
    filename, and to enter no passphrase.)
    ...
    It should log you in without a password.


    This describes the use of an unencrypted private key file. While there
    can be situations in which this is acceptable, I don't think it's a good
    idea to recommend this without further comment -- it is not the normal way
    of using SSH, and it is a security risk. With this setup, anyone who can
    read the private key file has immediate access to all remote accounts
    accessible with that key. If someone breaks security on this machine, the
    attacker has immediate transitive access to all these remote accounts with
    no further effort. It is equivalent to putting your account password in a
    file in your home directory named PASSWORD.PLEASE-STEAL-ME. If
    your home directory is shared via unsecured NFS (as most NFS installations
    are), your key can be read off the network by a passive snooper.



    For interactive use, a better way to achieve automatic public-key
    authentication, is to use ssh-agent. Now, the purpose of the
    procedure described here is to set up SSH for use in a non-interactive
    batch ("cron") job, which requires unattended authentication. A plaintext
    key is one way of achieving this, but there are others, and it has risks
    which should be carefully understood before doing it. At the very least,
    this key should not be the user's default key for SSH authentication (as
    is done here), and one must carefully limit what the key can do using the
    command option in the authorized_keys file on the
    server.


    +-----------------------------------------------------------------------------+
    | Richard Silverman | co-author: SSH, The Secure Shell (The Definitive Guide) |
    | slade@shore.net | O'Reilly, 2001 -- http://www.oreilly.com/catalog/sshtdg |
    +-----------------------------------------------------------------------------+

  • Works for me, after some effort
    2001-11-27 22:03:27  offwhite [View]

    I originally thought authorized_keys2 was a directory so when I followed the instructions I copied the file into that directory and it did not work. After correct it I was still not able to connect without a password.

    Since my key was putting localhost into the key I figured that would not be a very helpful to identify a remote host. Since I am doing this on my iBook and I set up that as my hostname, I wanted to change the ibook to replace localhost. Apparently MacOS X does not have an easy way to do it from Networking Preferences. I had to dig into sysctl and set kern.hostname.

    sysctl -w kern.hostname=ibook

    But this does not stay the same after a reboot, so I had to configure a script in StartupItems to set the hostname at startup.

    After changing the hostname I figured it would be a good idea to regenerate the server keys before generating my personal keys. I found a site which had directions which worked fine for me...

    http://igloo.its.unimelb.edu.au/Webmail/tips/msg00520.html

    Then after I generated my personal key and uploaded it as the filename as in the article it started to work for me.
    • Works for me, after some effort
      2001-11-28 09:34:33  res [View]



      Since my key was putting localhost into the key I figured that would not
      be a very helpful to identify a remote host...


      I assume you mean by this that your public key file had something like
      "username@localhost" at the end of the line. That is a comment, and it
      does not matter or affect anything in any way. "Fixing" it was
      unnecessary.


      After changing the hostname I figured it would be a good idea to
      regenerate the server keys before generating my personal keys.


      Also unnecessary; the server host keys have no connection with the
      hostname, except inasmuch as they are associated with hostnames in various
      known-hosts lists.


      Then after I generated my personal key and uploaded it as the filename as
      in the article it started to work for me.


      See my earlier post here; you may not want to leave things this way, as
      anyone who steals your laptop will have easy access to your remote
      accounts.


      --
      Richard Silverman
      slade@shore.net
  • Thank you many times over
    2002-01-15 12:32:43  semios [View]

    I have with great difficulty achieved this in the past after much effort and time spent pouring over ssh man pages and learning a great deal more than I needed to know in order to enable this simple task of not requiring a password everytime I want to login or copy a file.

    Thank you for making this information so concise and accessible.
  • wc for Philips TouCam pro & Pan&tilt-asonic
    2002-02-02 23:52:05  tz [View]

    I created a very similar setup to watch my mother when I was away. Mac OS (9 at the time)/Coolcam, store pictures on a server, and pull them via SSH.

    Now there's wc 0.3 (see Versiontracker) which includes a quicktime component for Philips TouCam Pro - a $60 camera. It doesn't do the highest rez (640x480) and you need lots of bandwidth (I got a 4 channel card for 3 cams), but works well.

    But a different approach is the Panasonic KX-HCM10 which is a camera with built-in webserver that can tilt, pan, change brightness and resolution. Using SSH to create a pipe so you can access the camera's webserver from the outside is even better since you can scan around the room. The camera uses ethernet, so would plug into any laptop where it could then go wireless. The Panasonic camera is just under $400 street price though - more expensive.
  • Mac-less in Seattle - Options for Win2k?
    2002-03-23 05:33:21  scottyb [View]

    I don't have a Mac with OS X, but I would still like to implement the same level of security in my wireless network on my Windows 2000 platform.

    Anyone have any suggestions?

    Scott.
  • thanks
    2003-04-08 15:23:18  anonymous2 [View]

    after searching for hours and hours I finally found a site which gave me the info I needed. The key roadblock for me was that I kept putting in 'passphrases' when I needed to leave them blank (or maybe it was the fact that my SSH daemon wasn't running--quickly remedied by turning on 'remote login' in the pref pane) so it would always ask for the passphrase.

    Now I tar my files and SCP them to the needed server and automatically back up my files overnight via the crontab thingy. Wonderful.
  • scp with crontab:Excellent
    2005-10-17 13:55:16  mc1392 [View]

    I have been scouring the web. I came across many articles, but none were as clear as this one.
    I love you!
    Mc1392
  • Thank you
    2006-02-20 20:37:12  Mar11b [View]

    Information is just what I was after. Simple and straight-forward. All you need to make it work!
  • SSH Problem with wifi
    2006-04-07 02:19:58  Vibhore [View]

    Hi,
    I have recently got an ibook and i am new to the ways of the mac os.
    I am easily able to ssh into one of my linux box on the internet if i am on the lan but unable to do so thru a wireless connection on the same lan.

    <--snip-->

    OpenSSH_3.8.1p1, OpenSSL 0.9.7i 14 Oct 2005
    debug1: Reading configuration data /etc/ssh_config
    debug1: Connecting to xxx.xxx.xxx.xxx port 22.
    debug1: Connection established.
    debug1: identity file /Users/vibhore/.ssh/identity type -1
    debug1: identity file /Users/vibhore/.ssh/id_rsa type -1
    debug1: identity file /Users/vibhore/.ssh/id_dsa type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_3.6.1p2
    debug1: match: OpenSSH_3.6.1p2 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1

    <--snip-->

    It just does not go beyond this.

    Thanks
    Vibhore