Archive for the ‘unix’ Category

MacOS Screen Sharing over the Internet using SSH

May 11, 2009

You don’t need to subscribe to iCloud (MobileMe) to access a Mac desktop remotely over the Internet from another Mac (“Back to My Mac”). You just need to do some setup. This description assumes (for simplicity) that you’re using Leopard (MacOS 10.5) or later on both Macs. If you’re still on Tiger (10.4) you’ll need a third-party VNC client like Chicken of the VNC; I haven’t tested that.

It’s also possible to access a Mac desktop from Windows or other operating systems using a VNC client such as UltraVNC. That is described here as well.

This setup runs the Apple Screen Sharing through an encrypted tunnel using SSH, for security.

  1. One-time setup on the Mac you’ll be connecting to, which we will call the “remote Mac”. In System Preferences>Sharing, turn on Remote Login (aka SSH). In System Preferences>Sharing, turn on Screen Sharing. In Computer Settings, select “VNC viewers may control screen with password:”. Choose a password.
  2. One-time setup on the Internet router/firewall for the network your remote Mac is on. Forward TCP port 22 (SSH) from the Internet to your remote Mac’s internal/private IP address. You might find this option under something like “NAT Rules” on your firewall’s setup screens, which are web pages for most routers. If you haven’t assigned the remote Mac a static IP address, you might want to. Otherwise, find out the IP address that your router assigned it by looking in System Preferences>Network.
  3. One-time setup of a host name for your remote Mac’s Internet connection. It’s convenient to give your your firewall’s external IP address a host name, especially if its IP address is dynamically assigned by DHCP and subject to change without notice. A dynamic DNS service like allows you to create an account and choose a host name for your Internet connection. Some router/firewalls have the ability to keep a DynDNS entry updated.
  4. One-time setup on your local Mac that you’ll be using to connect to the remote Mac. (Not applicable for a Windows or other client OS.) Allow Screen Sharing to connect to (aka localhost); in Terminal run (all on one line):

    sudo defaults write skipLocalAddressCheck -boolean YES

    and type your password when prompted.
  5. To prepare to access your remote Mac’s desktop over the Internet from the local Mac, in Terminal on your local Mac run (all on one line):

    ssh -N -L 6900:

    If it asks if you want to add or trust the host key or something like that, respond yes. That should only happen once. When prompted, type the password for your account on the remote Mac.

    your_login_short_name is the name of your home folder on the remote Mac; it will be lowercase with no spaces. The -L option creates a local tunnel which forwards TCP port 5900 (the standard VNC server port) on the remote Mac to port 6900 on your local Mac. The -N option to ssh prevents it from opening a command-line connection; omit it if you want one in addition to the port forwarding.

  6. For a Windows client, you can use the plink program from the PuTTY SSH package:

    "C:\Program Files\PuTTY\plink.exe" -N -L 6900:

    plink.exe might be in “C:\Program Files (x86)” or another folder on your computer.

    Alternately, you can use the graphical PuTTY program and in Connection>SSH>Tunnels set

    Source port 6900

    Then click Add.

  7. Run the Screen Sharing client on your local Mac; in Finder:
    Go>Connect to Server (or Command-k)
    In the Server Address box, type:


    A login box will pop up; enter your_login_short_name and your password for the remote Mac.
    You can click the + to save this address as a favorite for the future.

    Your remote Mac’s desktop should appear!

    In the Screen Sharing preferences, you might want to try the option “Show the screen at full quality (more detailed)” if needed and you have fast Internet connections at both ends.

  8. For a Windows client, UltraVNC Viewer is known to work. In the “VNC Server” box, enter “” (yes, two colons), then click Connect. Then enter the VNC password you set earlier on the remote Mac. You will see the Mac’s lock screen; type your account password to unlock it.
  9. When you’re done with your screen sharing session, quit the Screen Sharing app on your local Mac and press Ctrl-c in the Terminal window to disconnect the ssh tunnel.

Macs Needing Unix Network Geekery

February 9, 2009

Several years ago, I noticed that SMB file sharing between Macs (running 10.3 Panther at that time, I think) and Windows XP was a lot slower than it should have been. Copying a file took several times as long as between two PCs on the same 100 megabit LAN. Some research turned up the fact that the MacOS X default network parameters are suboptimal, at least when talking to Windows XP. The fix is to, in Terminal with sudo, create the file /etc/sysctl.conf and put some tweaked settings in it.

The same problem exists in Leopard. The sysctl settings to fix it are slightly different for Leopard and Gigabit networks. Here are some explanations. Here is my sysctl.conf for Leopard and Snow Leopard; omit the maxsockbuf line in Lion and later, and you need only the first two lines in Mavericks (I think) and later because Apple changed the defaults to these settings:


I also got errors when on a Windows XP client trying to copy files from an OS X share. Windows says it can’t read the source file. Going over to the Mac and copying the same files onto a shared folder on the PC works. Some Googling revealed that there’s a bug in the version of Samba that ships with Leopard. It doesn’t properly support extended attributes (an alternate data stream). I don’t need those anyway, so the fix is to turn off the buggy feature unless it gets fixed in a future release. Here’s the diff:

--- /etc/smb.conf	2009/01/04 22:39:52	1.1
+++ /etc/smb.conf	2009/02/08 14:20:50
@@ -44,7 +44,7 @@
     display charset = UTF-8-MAC
     dos charset = 437

-    vfs objects = darwinacl,darwin_streams
+    vfs objects = darwinacl

     ; Don't become a master browser unless absolutely necessary.
     os level = 2
@@ -56,8 +56,8 @@
     use sendfile = yes

     ; The darwin_streams module gives us named streams support.
-    stream support = yes
-    ea support = yes
+    stream support = no
+    ea support = no

     ; Enable locking coherency with AFP.
     darwin_streams:brlm = yes

In Snow Leopard (10.6.6), the changes needed are as follows:

--- /etc/smb.conf	2010/01/22 00:04:17	1.4
+++ /etc/smb.conf	2010/04/20 13:14:28
@@ -44,7 +44,7 @@
     display charset = UTF-8
     dos charset = 437
-    vfs objects = notify_kqueue,darwinacl,darwin_streams
+    vfs objects = notify_kqueue,darwinacl
     ; Don't become a master browser unless absolutely necessary.
     os level = 2
@@ -58,10 +58,12 @@
     mangled names = no
     stat cache = no
     wide links = no
+    ; Preserve performance.
+    getwd cache = yes
     ; The darwin_streams module gives us named streams support.
-    stream support = yes
-    ea support = yes
+    stream support = no
+    ea support = no
     ; Enable locking coherency with AFP.
     darwin_streams:brlm = yes

Restarting the Mac is the easiest way to make these changes take effect.

Lion (10.7) and later use smbd instead of Samba and don’t have this configuration file.

The Mac lover in me is annoyed that Apple ships poor defaults for this important function. How much do they care about Windows file sharing? The Unix geek in me is glad that the free software underpinnings of OS X are configurable enough that I can fix them by editing a couple of text files!

And if you experience a delay of several seconds when connecting to a Windows file share from a Mac, e.g. using “Go->Connect to Server”, make sure to use the full name of the Windows server. On our Active Directory network at the office, when I connected using the form “smb://servername/sharename”, there was about a 6-second delay before the share mounted. When I switched to the form “smb://servername.dom.ain/sharename”, it went down to under a second to connect.

Introduction To Kerberos

August 5, 2008

(Written in June, 2000)

What Is Kerberos?

This is an introduction to the concepts and conventions used in Kerberos. It is intended to give system administrators and software developers an overview of how Kerberos works. It does not contain step by step, detailed instructions on setting up or using Kerberos.

For more information on Kerberos, see its home page at
and Microsoft’s Windows 2000 Kerberos page at

Kerberos is a software package providing authentication between clients (typically run interactively by people) and servers (such as a telnet or POP mail daemon). It consists of several C libraries, several standard client and server programs, a database, and some configuration files. Programs that are not part of the Kerberos software distribution can be Kerberos-enabled by adding calls to the Kerberos libraries.

Kerberos was developed at MIT as part of Project Athena. It is named after the three-headed dog who guarded the entrance to Hades in Greek mythology (called Cerberus by the Romans). The C API is called the General Security Service (GSSAPI). The current version of Kerberos is v5, though v4 is still in widespread use. v5 and v4 are not directly compatible, but v5 has a v4 compatibility mode. This document discusses only v5, as v4 is being phased out.

What techniques does it use?

Kerberos uses private keys (a.k.a. secret keys) to provide authentication. This is unlike SSH, which uses public-private key pairs. In Kerberos, each client has its own private key (your password) and each server also has its own private key (which is stored in a file called a keytab on that server host). Automated clients (such as cron jobs) also have private keys stored in keytabs. Kerberos private keys are never sent over the network in cleartext (that’s what keeps them private). Kerberos does not depend on IP addresses or DNS names for providing authentication, so if they are spoofed, connections will not succeed.

Kerberos divides the world into administrative realms, with names based on hosts’ DNS domain names but in all capital letters. In each realm is a physically secure host with a database containing the private keys of all clients and servers in that realm. That way, each organization can control its own private keys. The host with this database is a trusted third party. It is running a Kerberos server, and is called the Key Distribution Center, or KDC. The KDC database can be replicated onto other hosts for redundancy. (Kerberos calls this propagation.) The host with the master copy is called the primary KDC, and the hosts with the copies are called secondary KDCs.

A client might actually have several private keys, for authenticating to different services. For example, a person might have one private key for logging in as themself, and another private key for logging in as the superuser (root). To figure out which of a client’s private keys to use when authenticating to a server, each private key is labeled with an principal name, which is their user name with an optional instance name. The default instance for a user is empty and is used for logging in, and the principal name looks like “username@REALMNAME” (similar to an email address). The other principal names look like “username/instancename@REALMNAME”, for example, “djm/root@VA.PUBNIX.COM”. (Although any number of instance names separated by slashes can be used, in practice only one level of instance names is ever used.) The “@REALMNAME” is optional, and defaults to the realm of the local host.

Servers’ private keys are also labeled by principal names, with the same format except the user name is replaced by the service name. They look like “servicename/hostname@REALMNAME”, for example, “imap/”. For logins, the service name is “host”.

You can see from the previous example that each Kerberos realm can authenticate for servers in multiple DNS domains. But each DNS domain can be served by only one Kerberos realm. However, clients can authenticate to servers in any realm in which they have principals.

Each request for authentication to the Kerberos server sends the client a sesssion key, which the client caches in a credentials cache file locally. The session keys are used to encrypt connections to servers instead of using the client’s private keys. Session keys are valid only for a few hours, to prevent replay attacks.

The authenticated information for a connection between a particular client and server is called a ticket. A client’s tickets are stored in the credentials cache along with the session key. The first ticket which is issued to a client, and can be decrypted using that client’s private key, is called a ticket-granting ticket, or TGT. It is used for authenticating all services, instead of using the client’s private key, to avoid having to type your password every time you check your email or login to another host.

After an authenticated connection to a server is established, whatever protocol that server uses can either pass information in cleartext, or encrypt it in the session key, as desired. For example, Kerberos “rcp” copies files in cleartext unless the “-x” option is given.

How Is It Configured?

Every host using Kerberos needs a copy of the master configuration file, called “krb5.conf” on Unix, and usually located in /etc or /etc/krb5. The main functions of this file are to specify the KDC(s) for each realm, which DNS domains each realm services, and some optional parameters. There is no distributed lookup service (analogous to DNS) for Kerberos realms. You need to create or copy a krb5.conf that contains information about the realms that you want to access servers in.

In addition, the KDC has a “kdc.conf” giving some parameters and file locations, and ACL files for Kerberos administration and database replication.

On Unix, entries in “/etc/inetd.conf” for the standard versions of servers such as “telnetd” and “rshd” are replaced with entries for the Kerberos versions.

Semi-standard locations for the Kerberos programs and libraries on Unix are /usr/krb5 or /usr/local/krb5.

How Is It Administrated?

Kerberos administration consists mostly of creating principals for new clients and servers, deleting principals for retired clients and servers, creating keytabs for servers and automated clients, and changing passwords.

After the initial setup, most Kerberos administration is done with the “kadmin” program, which uses a separate protocol to connect to a Kerberos administration server on the primary KDC for a realm. Administrative connections can not be made to the secondary KDCs. kadmin uses an “admin” instance to authenticate Kerberos system administrators. There is another version of it called “kadmin.local” that runs only on the primary KDC and does not require a password.

Any client can change their own Kerberos passwords using the “kpasswd” program. Note that the kpasswd protocol changed between Kerberos v5 release 1.0 and release 1.1.

How Does It Authenticate?

As mentioned above, Kerberos uses a trusted third party model. Authentication is initiated by a client, which contacts the KDC to get a TGT, which it decrypts using its own private key. The client then uses the TGT to get a ticket for a particular server from the KDC, and then connects to that server. This process is illustrated in the accompanying diagram (click to enlarge).

Kerberos authentication

More concretely, a user runs “kinit”, which prompts for a password, to get a TGT. Alternately, some login programs and graphical telnet clients get a TGT with the password provided, as does the Kerberos “su” program, “ksu”. kinit can get a private key from a keytab instead of prompting for a password, for use with automated clients.

You can list your current credentials (tickets and session keys) using “klist” and remove them (when you log out) using “kdestroy”.

For remote logins, there is an optional file similar to the non-Kerberos “.rhosts” file, called “.k5login”, which a user can create in their home directory. This file lists principals who are allowed to login
as that user from other hosts using Kerberos, or “ksu” to that user on that host.