Kerberizing Leopard’s Remote Login (built-in SSH) service
December 7th, 2007
0. Introduction
Enabling Kerberos/GSSAPI support in Leopard’s Remote Login (SSH) service is straightforward. As Leopard’s Remote Login is built using OpenSSH, most of what is described here applies perfectly to other flavors of UNIX.
Kerberos/GSSAPI authentication allows for Single Sign-On capabilities in OpenSSH in such a way that it makes very convenient to work with or manage multiple machines while only having to authenticate to the network every certain amount (Kerberos uses a form of cached credentials that expire within hours, typically). In this document I describe how to enable support for Kerberos/GSSAPI authentication to Leopard’s implementation of OpenSSH. Leopard includes many of the tools from the MIT’s implementation of Kerberos, so this makes the whole process even easier.
The process consists on:
- Creating the Kerberos principal
- Creating
/etc/krb5.conf - Adding the Kerberos principal to the keytab file
- Reconfiguring OpenSSH to support Kerberos authentication
- Restarting OpenSSH
- Enabling Kerberos authentication on OpenSSH clients
- Testing
1. Creating the Kerberos principal
When a Kerberized SSH client tries to authenticate to a Kerberized OpenSSH service, the client will request a Kerberos service ticket for that specific OpenSSH service. The Kerberos service ticket contains, among other things, a shared secret (for example, a 3DES private key) that has to be distributed to both the client and the server, called K<>client,server. The KDC will generate such shared secret and will encrypt it twice. Once, with a shared secret between the KDC and the client principal, called KKDC,client, and another one with a shared secret between the KDC and the server principal, KKDC,server.
In this step, we will create the Kerberos principal that represents the OpenSSH server and consequently its shared secret, KKDC,server. Later on, we will upload this shared secret to the OpenSSH server and install it into the Keytab file, so that the OpenSSH server can access it and use it to decrypt the user’s service ticket in order to retrieve the shared secret, Kclient,server.
$ kadmin Authenticating as principal alice/admin@LAN with password. Password for alice/admin@LAN: kadmin: addprinc -randkey host/ssh.lan WARNING: no policy specified for host/ssh.lan@LAN; defaulting to no policy Principal "host/ssh.lan@LAN" created.
NOTE: If you are logged in as root into the KDC, you can use kadmin.local instead of kadmin if you prefer, as the former doesn’t require any authentication (being able to run it as root is enough to prove yourself authorized).
The Kerberos principal associated with the OpenSSH has been created, the shared secrets generated, stored and protected by the stash key. We can check the status of the principal using the following command:
kadmin: getprinc host/ssh.lan Principal: host/ssh.lan@LAN Expiration date: [never] Last password change: Thu Dec 06 19:42:50 CET 2007 Password expiration date: [none] Maximum ticket life: 0 days 10:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Thu Dec 06 19:42:50 CET 2007 (root/admin@LAN) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 2 Key: vno 5, Triple DES cbc mode with HMAC/sha1, no salt Key: vno 5, DES cbc mode with CRC-32, no salt Attributes: Policy: [none] kadmin: exit
Now that the principal has been created, we can move onto the next step.
2. Creating /etc/krb5.conf
One of the requirements for Kerberizing OpenSSH server is configuring the Kerberos libraries via /etc/krb5.conf. These libraries are used by the OpenSSH server, kpasswd, the OpenSSH client and tools like kadmin or kinit.
This configuration file will also allow us to connect to the Kerberos administration server remotely by using kadmin, in order to download the OpenSSH shared secret. In my case, /etc/krb5.conf looks like this:
[libdefaults]
default_realm = LAN
dns_fallback = "no"
default_tgs_enctypes = des-cbc-crc
default_tkt_enctypes = des-cbc-crc
[realms]
LAN = {
kdc = kdc.lan:88
admin_server = kdc.lan:749
}
[domain_realm]
.lan = LAN
[login]
krb4_convert = true
krb4_get_tickets = false
3. Adding the Kerberos principal to the keytab file
root@ssh.lan:# kadmin Authenticating as principal root/admin@LAN with password. Password for root/admin@LAN: kadmin: ktadd -k /etc/krb5.keytab host/ssh.lan@LAN Entry for principal host/ssh.lan@LAN with kvno 7, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/ssh.lan@LAN with kvno 7, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
This will add the OpenSSH shared secret to the Kerberos /etc/krb5.keytab file. We need to add the shared secrets to this file properly, as Leopard has a built-in KDC service and machine-specific shared secrets in this file that are used, among others, by the Screen Sharing service, the AFP service and the SAMBA service.
To check that OpenSSH shared secret was added to the keytab file, we use ktutil to read and display the contents of the Keytab file:
root@ssh.lan:# ktutil ktutil: rkt /etc/krb5.keytab ktutil: list slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC... 2 3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC... 3 3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC... 4 3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC... 5 3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC... 6 3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC... 7 3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC... 8 3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC... 9 3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC... 10 7 host/ssh.lan@LAN 11 7 host/ssh.lan@LAN
Once installed in the keytab file, OpenSSH will be able to access the shared secret, KKDC,server used to decrypt Kerberos service tickets shown by clients.
It is also necessary to change OpenSSH’s server configuration file, /etc/sshd_config to explicitly enable Kerberos/GSSAPI authentication. To achieve this, modify /etc/sshd_config file and add the following lines (by default they are either uncommented or disabled):
# GSSAPI options GSSAPIAuthentication yes GSSAPICleanupCredentials yes
5. Restarting OpenSSH
To last step on the server side requires that we restart the OpenSSH service so the previous changes are taken into effect:
root@ssh.lan:# launchctl aunchd% stop com.openssh.sshd launchd% start com.openssh.sshd
6. Enabling Kerberos authentication on OpenSSH clients
Some OpenSSH clients have Kerberos authentication disabled by default. The easiest way to enable Kerberos/GSSAPI authentication in clients is by adding the following directives to $HOME/.ssh/config:
Host *
Protocol 2
GSSAPIAuthentication yes
GSSAPIKeyExchange yes
GSSAPIDelegateCredentials no
GSSAPITrustDns no
This will enable Kerberos/GSSAPI authentication on the client side. The fact that Kerberos/GSSAPI authentication succeeds depends on several factors, like the user having a valid Kerberos TGT, the remote server having Kerberos/GSSAPI authentication enabled, and that the clocks on both the client and server machines are synced (most implementations refuse Kerberos/GSSAPI authentication if the clocks differ more than 5 minutes).
7. Testing
First, we need to get a TGT from the Kerberos KDC:
$ kinit Please enter the password for falfaro@LAN:
To check that it worked, we list the tickets available to us, and make sure we see a ticket valid for service krbtgt/*:
$ klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: falfaro@LAN Valid Starting Expires Service Principal 12/06/07 18:06:26 12/07/07 04:06:26 krbtgt/LAN@LAN renew until 12/13/07 18:06:26
Now, let’s try to log in into the OpenSSH server. Kerberos/GSSAPI authentication should be negotiated, as shown by the debugging information:
core2:~ falfaro$ ssh -v solana OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006 debug1: Reading configuration data /Users/falfaro/.ssh/config debug1: Applying options for * debug1: Reading configuration data /etc/ssh_config debug1: Connecting to solana [10.42.242.12] port 22. debug1: Connection established. debug1: identity file /Users/falfaro/.ssh/id_rsa type -1 debug1: identity file /Users/falfaro/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5 debug1: match: OpenSSH_4.5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.5 debug1: Offering GSSAPI proposal: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==, gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==, gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==, gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==, gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==, gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==, gss-gex-sha1-bontcUwnM6aGfWCP21alxQ==, gss-group1-sha1-bontcUwnM6aGfWCP21alxQ==, gss-group14-sha1-bontcUwnM6aGfWCP21alxQ== 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(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'solana' is known and matches the RSA host key. debug1: Found key in /Users/falfaro/.ssh/known_hosts:8 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Authentication succeeded (gssapi-with-mic). debug1: channel 0: new [client-session] debug1: Entering interactive session. Last login: Thu Dec 6 20:29:59 2007 from foo.lan $ hostname ssh.lan $ exit logout Connection to solana closed.
If we run klist again, we will see that, in addition to the TGT we saw before, we will see the Kerberos service ticket for the OpenSSH server:
Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: alice@LAN Valid Starting Expires Service Principal 12/06/07 18:06:26 12/07/07 04:06:26 krbtgt/LAN@LAN renew until 12/13/07 18:06:26 12/06/07 18:07:27 12/07/07 04:06:26 host/ssh.lan@LAN renew until 12/13/07 18:06:26
8. Troubleshooting
The GSSAPI authentication mechanism is very picky about many things, and error codes and messages are usually very cryptic but not very helpful about what the cause of the error is.
I found that acommon source of authentication problems are entries in /etc/hosts confusing GSSAPi about the host name. For example, entries like this in /etc/hosts:
192.168.0.1 ssh ssh.lan
can cause SSH to think the host name is ssh instead of the expected FQDN — ssh.lan.The previous entry causes reverse name resolutions for IP 192.168.0.1 to return ssh as the host name, but not ssh.lan. Since the Kerberos keytab is host/ssh.lan but IP 192.168.0.1 is resolved to ssh this may cause authentication attempts to fail because no Kerberos keytab for host/ssh exists in /etc/krb5.keytab. The most common symptom is trying to SSH to localhost, getting a failed authentication and but ticket for the target host. Example:
$ kinit Password for alice@LAN: $ klist Ticket cache: FILE:/tmp/krb5cc_501 Default principal: alice@LAN Valid starting Expires Service principal 05/31/09 01:08:21 06/01/09 01:08:20 krbtgt/LAN@LAN
Then,
$ ssh ssh.lan alice@ssh.lan's password:
But no Kerberos ticket for ssh.lan was even requested:
$ klist Ticket cache: FILE:/tmp/krb5cc_501 Default principal: alice@LAN Valid starting Expires Service principal 05/31/09 01:08:21 06/01/09 01:08:20 krbtgt/LAN@LAN
One possible solution consists of removing the matching entry from /etc/hosts, provided that the existing DNS name server can properly resolve the IP address of the server to the correct FQDN. If this is not possible, another solution is making sure the FQDN name is listed before the non-FQDN name in the corresponding line in /etc/hosts.
8. References
Some additional and very useful references:
- Kerberos 5 setup for NFSv4.
Describes common pitfalls, like using a non-FQDN host name in
/etc/hostsor not using clock synchronization.
Leopard, NFS, Automounter and Finder
November 21st, 2007
The AutoFS service in Leopard, also known as automount, is configured by means of text files stored in /etc and the automount command-line utility. The standard automount configuration also allows for local directory service lookups and thus can also be configured by using Directory Utility.
The configuration of the automounter starts with the master configuration file, /etc/auto_master The contents of this file look like this:
# # Automounter master map # +auto_master # Use directory service /net -hosts -nobrowse,nosuid /home auto_home -nobrowse /Network/Servers -fstab /- -static
Here is a brief description of each one:
-
/net -hosts -nobrowse,nosuidThis configures automount of NFS servers in
/net. Automounting is done for any resolvable host name (it doesn’t have to have an entry in/etc/hostsand it’s browsable under/net. The problem is that/netis not linked from the sidebar in Finder, and thus not very useable except from the command-line. -
/home auto_home -nobrowseThis configures automounting of home directories via a directory service, as configured in
/etc/auto_home. -
/Network/Servers -fstabThis line states that all mount entries defined in
/etc/fstabshould be mounted in/Network/Servers. However, this is not entirely true as mount entries listed in/etc/fstabhave to specify an absolute mount point, or elseautomountwill complain. Since mount entries specify an absolute mount point, and it won’t be overridden byautomount, in order to make Finder show the entries in the sidebar it is recommended that the mount point is located in a subdirectory within/Networ/.For example, this how my
/etc/fstabfile looks like:media:/export /Network/media nfs nosuid,nodev 0 0
-
/- -staticThis entry is very similar to the previous one, but instead of using
/etc/fstabas the source of mount entries, this one uses the local directory service instead. Entries can be configured using Directory Utility, and stored as a plist file in/var/db/dslocal/nodes/Default/mounts.Here is an example of a file named
/var/db/dslocal/nodes/Default/mounts/media.lan\:%2Fexport.plist:<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>dir</key> <array> <string>/Network/media</string> </array> <key>generateduid</key> <array> <string>1895C8D3-7DBF-4857-8D61-04080DFA5B55</string> </array> <key>name</key> <array> <string>media.lan:/export</string> </array> <key>opts</key> <array> <string>nosuid</string> <string>nodev</string> </array> <key>vfstype</key> <array> <string>nfs</string> </array> </dict> </plist>
Reloading the automount configuration is just as simple as running:
automount -vc
automount will reload its configuration and will automatically mount any entry listed in /etc/fstab. Additionally, the Finder will display an All… link in the sidebar that makes very easy to get to the automounted volumes.
Mac OS X 10.5 Leopard built-in firewall
November 10th, 2007
The firewall in Mac OS X 10.5 Leopard is confusing, to say the least. It is not enabled by default, which is a huge mistake, in my humble opinion. Also, the graphical user interface offers less flexibility than in previous version while trying to configure it. Besides allowing you to independently control the blocking of incoming ICMP Echo Requests and logging via syslog, it has the following main operation modes:
-
Allow all incoming connections.
Seems obvious that choosing this setting means that the firewall is essentially disabled and any traffic can freely flow in and out of the computer.
I would not recommend this setting, even for trusted networks. It is easy for a laptop computer to attach to a different network at any time and have the user forget to re-enable the firewall, posing as a potential victim for other users or computers. For a desktop computer it is more and more common to be attached to a network that has some sort of wireless bridging or routing device that might be used by untrusted users to get access to the network, or by trusted users that carry (maybe without their knowledge) malware, for example.
This setting offers little or no security, but makes very easy to share contents or provide external services.
-
Block al incoming connections.
This seems the safest choice, but might not always be desirable if you are sharing content or have services running that you want to make accessible from the outside (like an SSH server, or even the iTunes music collection).
This is my preferred setting, I have to say. This setting offers adequate security, but stops you from sharing content or offering access to services externally. However, it seems that Leopard’s firewall does not block all services, and some of them are still accessible from the outside (see at the end of the post for more information).
-
Set access for specific services and applications.
This is by far the most confusing setting. First, because it doesn’t seem to add any rules to IPFW. I’m starting to believe that Leopard offers two layers of filtering. It seems IPFW is one of them, but it defaults to use a ruleset with only default accept entry in it (sequence 65535):
# ipfw list 65535 allow ip from any to any
(NOTE: if you enable the Stealth functionality, a IPFW rule is added before the default entry, and it looks like this:
33300 deny icmp from any to me in icmptypes 8
This blocks ICMP Echo Requests, but be aware that Stealth mode is not enabled by default).
About the other filtering layer, I’m not sure what it is used or how it is implemented, but it seems to be the result of some sort of kernel-level and user-space cooperation. The second reason why I think this setting can be confusing is because it seems to only affect a particular user (normally the logged user), but not the system or other users like
root.For example, I compiled
synergyand ran it as userroot. Then, I configured the Leopard’s firewall for access to specific services and applications, but I left the list empty. I verified that I could reach thesynergysserver at port 24800 from other computer in the same network segment. I was really surprised, to be honest.The next thing I tried is to kill
synergysand to re-run it as my currently logged in user. This time, Leopard presented me with a dialog box that asked whether to allowsynergysto accept incoming connections:Do you want the application “synergys” to accept incoming network connections?
Clicking Deny may limit the application’s behavior. This setting can be changed in the Firewall pane of Security Preferences.
This caused the expected behavior: any attempt to connect to port 24800 from the outside was blocked by Leopard’s firewall:
22:02:30.989097 IP 10.42.242.16.49950 > 10.42.242.12.24800: S 3207271609:3207271609(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 699234003 0,sackOK,eol> 22:02:31.913244 IP 10.42.242.16.49950 > 10.42.242.12.24800: S 3207271609:3207271609(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 699234012 0,sackOK,eol> 22:02:32.914300 IP 10.42.242.16.49950 > 10.42.242.12.24800: S 3207271609:3207271609(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 699234022 0,sackOK,eol> 22:02:33.915334 IP 10.42.242.16.49950 > 10.42.242.12.24800: S 3207271609:3207271609(0) win 65535 <mss 1460,sackOK,eol> 22:02:34.916398 IP 10.42.242.16.49950 > 10.42.242.12.24800: S 3207271609:3207271609(0) win 65535 <mss 1460,sackOK,eol> 22:02:35.917319 IP 10.42.242.16.49950 > 10.42.242.12.24800: S 3207271609:3207271609(0) win 65535 <mss 1460,sackOK,eol> 22:02:37.919629 IP 10.42.242.16.49950 > 10.42.242.12.24800: S 3207271609:3207271609(0) win 65535 <mss 1460,sackOK,eol> 22:02:41.924491 IP 10.42.242.16.49950 > 10.42.242.12.24800: S 3207271609:3207271609(0) win 65535 <mss 1460,sackOK,eol>
Note how the first three segments had the time-stamp and window scaling options activated. The remaining SYN segments didn’t. This is probably due to Leopard thinking that there was congestion or that it was talking to an old system.
Once I chose Always allow, Leopard added an entry into the Firewall list named
synergys. From here on, I was able connect to port 24800. This is the the network capture thattcpdumpdisplayed when trying to connect to port 24800 from another compuer aftersynergyshad been granted access:22:24:20.674656 IP 10.42.242.16.50055 > 10.42.242.12.24800: S 2514913060:2514913060(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 699247086 0,sackOK,eol> 22:24:20.675544 IP 10.42.242.12.24800 > 10.42.242.16.50055: S 812848149:812848149(0) ack 2514913061 win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 473026159 699247086,sackOK,eol> 22:24:20.675591 IP 10.42.242.16.50055 > 10.42.242.12.24800: . ack 1 win 65535 <nop ,nop,timestamp 699247086 473026159> 22:24:20.677911 IP 10.42.242.12.24800 > 10.42.242.16.50055: P 1:16(15) ack 1 win 33304 <nop ,nop,timestamp 473026159 699247086> 22:24:20.677959 IP 10.42.242.16.50055 > 10.42.242.12.24800: . ack 16 win 65535 <nop ,nop,timestamp 699247086 473026159>
Funny enough, keeping my telnet client running while trying to connect at port 24800, waiting for Leopard to remove the time-stamp and window scaling options, then allowing this traffic, didn’t make Leopard to try to re-negotiate the time-stamp and window scaling options.
Another thing worth mentioning is that once
synergyshad been granted access to incoming traffic at port 24800, removing it from the list of allowed applications and services didn’t stop it from receiving traffic. To blocksynergysfrom receiving traffic it was necessary to change Allow incoming connections to Block incoming connections (removing its entry from the list did still allow it to receive incoming traffic).Another interesting feature is that Leopard’s seems to be aware of service dependency. For example, enabling the Screen Sharing service also starts a local Kerberos 5 KDC which is used to authenticate users. This is fascinating since users of Screen Sharing, for example, will first request a TGT to this local Kerberos 5 KDC (and will be able to decrypt that TGT if they know the correct password), then using the TGT request a service ticket for the Screen Sharing service that can present to it in order to get authenticated. But moreover, trying to connect to the Screen Sharing service for a second time will not require the user to provide his credentials again because a Kerberos service ticket is already available (provided that it didn’t expire). This is Single Sign-On in its true form.
Conclusion
In conclusion, I can’t say that the graphical user interface provides a lot of room for configuration, neither does it offer any way to configure egress filtering (that is, traffic that originates on the local computer and is to be sent out externally via a network interface).
In general, Leopard’s default administration tools are probably on par with those from Windows Vista. Even though the underpinnings of the newest member of the Mac OS X family are powered by IPFW, I feel Leopard’s firewall has a long way to go to in order to get closer to the powerful functionality and configurability of PF or Netfilter/IPtables, for example.
Also, not enabling the firewall by default is a big mistake in my opinion. One of my Mac OS X laptops is listening on port 111/tcp, 1020/tcp and 1021/tcp. The first one is iCalAlarmAgent and the other two are related to launchd. Even if you configure the firewall to block all traffic, these three ports are still accessible from the outside.
Playing with Mac OS X 10.5 Leopard local directory service, II
November 10th, 2007
After experimenting with local files for Mac OS X 10.5 Leopard Directory Service, I read a hint on MacOSXHints name Manage users and groups using a GUI tool.
What this tip describes, basically, is that you can use Mac OS X Server Administration Tools to connect locally to the Directory Service running on Mac OS X Leopard. Just start Workgroup Manager, and authenticate to host localhost with the credentials of any user with administrative rights. Using Workgroup Manager it is possible to create and manage users and groups, but more important is that changes take effect immediately, without having to kill /usr/sbin/DirectoryService, rebooting or having to log out. Very nice!
Playing with Mac OS X 10.5 Leopard local directory service
November 6th, 2007
New with Mac OS X 10.5 is the replacement of the old NetInfo architecture. The new component, Directory Services, is a highly configurable service that can use many back-ends to store, retrieve and abstract concepts like users, groups, machines or mount points.
Directory Services sports LDAP, Active Directory and Open Directory support, and also local files. Local files seem to be stored directly in the root volume, in the /var/db/dslocal/nodes/Default/ directory. Within this subdirectory, we can found others that create a tree-like, hierarchical structure:
aliases/. Contains a one pList for every account alias that is registered in the Local directory service. There are some built-in aliases, plus additional aliases that can be created from the Accounts preference pane.config/. Contains several configuration files for components like Kerberos KDC (in a pretty funny format, that basically looks like XML-syntax wrapper that contains the traditional kdc.conf text-based configuration file as a string), Share points and so on.groups/. Contains one pList file for every known local group. The format is pretty straightforward and almost resembles the traditional UNIX/etc/groupfile, but expressed using XML.machines/. Contains one pList file for every known machine. It seems to me this is the equivalent of the/etc/hostsUNIX file where each machine entry is stored in as a single pList file. For a default Mac OS X installation, you will find a localhost.plist and a broadcasthost.plist entry.mounts/. Contains one pList for every automount point. By default, there are no automount points defined, and they can be created using the Directory Utility application,dsclor by manually creating or changing pList files.networks/. Contains one pList file for every known network. This seems like the equivalent of/etc/ethersin UNIX systems. By default, only a single pList file exists: loopback.plist, which lists 127.0.0.0/8 as a known network.users/. Contains one pList file for every known local user. This is the equivalent of/etc/passwdin any UNIX system. As in modern UNIX systems, the password is stored somewhere else (does anybody know where?).
By tweaking these files and restarting the Directory Service, it is possible to emulate the behavior of a UNIX-like system, with the difference that access to these entities is mediated by a service, as is not exposed via a POSIX API that, when configured to use local files, parses the contents of local files. In Mac OS X, it is necessary to notify the Directory Service when the contents of any of the pList files changes.
Another way of editing some of these components without having to use dscl or editing pList files by hand is by right-clicking a user or a group in the Accounts preference pane, then choosing Advanced Options ... from the menu.
Playing music remotely using MPD
July 16th, 2007
From the home page of MPD:
Music Player Daemon (MPD) allows remote access for playing music (MP3, Ogg Vorbis, FLAC, AAC, Mod, and wave files) and managing playlists. MPD is designed for integrating a computer into a stereo system that provides control for music playback over a local network. It is also makes a great desktop music player, especially if you are a console junkie, like frontend options, or restart X often.
The idea behind using MPD was to be able to set up a multimedia computer that I could manage either locally or remotely. When I mean remotely, I don’t mean via VNC or X11/NX. For example, I don’t need the overhead of a full X11 session just to play music over the sound card of my multimedia computer. I might do that using MPlayer over a SSH/screen session or a text-based, command-line music player, but sometimes I like GUI applications too!
Also, detaching the music player controller (the daemon) from the client allows me to use different clients from different computers. Sometimes I’m using one of my Apple computers. Sometimes I’m using one of Linux boxes. Using a client that matches natively my operating system is something that I really appreciate.
For Linux I use Sonata. For Mac OS X I use Theremin.
Installing MPD on Ubuntu Feisty Fawn
Installing MPD in Ubuntu Linux, as usual, it’s pretty straightforward:
sudo apt-get install mpd
By default, Ubuntu will install MPD, start it up and create the symbolic links under /etc/rc[0123456].d to make sure it gets started at the next system boot.
You might also want to edit MPD’s configuration file:
$EDITOR /etc/mpd.conf
In my case, the only thing I changed in this file is the bind_to_address directive to allow clients to connect remotely. It looks like this:
bind_to_address "0.0.0.0"
Installing Sonata on Ubuntu Feisty Fawn
Sonata is a nice Python-based, GTK+2.0-based MPD client. Thus, it’s multi-platform and can be run on Linux, *BSD, Solaris, Mac OS X and (I guess) even Windows.
To install Sonata on Ubuntu Linux, run apt-get as usual:
sudo apt-get install sonata
The first time you run Sonata, either from the command-line or from the menu, it will ask you where the MPD daemon is running. It defaults to localhost (and port 6600) so I changed that to point to the hostname of my multimedia computer.
Installing Sonata on Mac OS X
Installing Sonata on Mac OS X is a little bit more elaborated, since some of the components that Sonata requires are not installed by default on Mac OS X.
Sonata requires Python and, more concretely, PyGTK. Since I am already using MacPorts, getting PyGTK installed was a matter of running:
sudo /opt/local/bin/port install py-gtk2
The rest is pretty much the same as for Linux.
Installing Theremin.app on Mac OS X
Theremin.app is a nice, native Cocoa application for Mac OS X that sports Growl integration. For example, when MPD starts playing a new song, Theremin.app notifies the user via a Growl notification.
Download Theremin.app from Theremin’s Web site.
Extract it and run it:
tar jxvf Theremin_0.5.1.tbz open Theremin.app
Theremin.app can also be compiled from sources by downloading the source code from the Subversion repository and using Xcode to compile it. I must confess that I was lazy to that, so I chose to run the pre-compiled binaries.
Apple’s Safe-Sleep and privacy
July 13th, 2007
Safe-Sleep is a technology from Apple — similar to the hibernation in Windows systems — that allows Mac OS X to save the contents of the entire RAM into the filesystem when the computer is put to sleep. This helps the system surviving a complete power loss, for example, like when replacing batteries on the fly.
The entire contents of the RAM are stored in /private/var/vm/sleepimage completely un-encrypted, even if the user explicitly configured FileVault or an encrypted swap. A possible reasoning for this is that sleepimage is a per-system, and not a per-user, file and thus completely unrelated to FileVault and I guess that encryption is not possible since the firmware needs access to some contents of this file.
While Safe-Sleep could seem like a nice feature for Mac OS X, for me it constitutes a big threat to my privacy. In fact, I’ve seen my log-in password stored in plain text in /private/var/vm/sleepimage a couple of time which, of course, scares me.
To disable Safe-Sleep, run the following command:
sudo pmset -a hibernatemode 0
If you ever want to re-enable Safe-Sleep, run the following command:
sudo pmset -a hibernatemode 3
iTunes Plus: Is DRM dead, finally?
June 2nd, 2007
Today, while I was looking through my e-mails, I realized that one from the Apple iTunes Store had been sitting unread for a couple of days in my inbox. I usually don’t pay much attention to this kind of e-mails but I was bored enough to go and give it a try.
The e-mail was the announcement on the availability of iTunes Plus for the Spanish iTunes Store. I was so curious that I saw myself firing iTunes on Mac OS X up even before I finished on reading the e-mail. I looked around a little bit but wasn’t able to find any trace of any 1,29€ songs, anywhere. I searched for Paul McCartney, Coldplay and the like, but all I could find were the traditional 0,99€ songs. I felt disappointed, but after a closer look, I could find an iTunes Plus link on the Quick Links section on the main page, so badly placed to even not realize it is there.
I decided to give it a chance, so I clicked on the link. Next, I was presented with the typical incomprehensible use license, clicked Accept and jumped in to search for some music, specifically music from Enigma. I could see that all the songs listed 1,29€ under the price column plus a “+” (plus) sign besides it. I double clicked on “Return to Innocence” in order to hear a preview but iTunes was stuck for so long trying to connect to the server that I finally gave up and clicked on Cancel. I felt lucky so I clicked on the Purchase button. In general, the purchase process is identical to the one used by DRM-protected iTunes Store, except that it took unusually longer to complete. I don’t know the exact reasons for this. It could be because of iTunes Plus Store uses different back-ends servers that are not scaled up well enough for the demand of service, could be something else. In any case, I felt really happy when I told iTunes to display the file on Finder and saw the extension was “.m4a” instead of “.m4p” (typical of DRM-protected songs). The sound quality seems pretty good at 256kbps in AAC digital format and since MPlayer, Rhythmbox and many other open source, free players can play unprotected AAC songs with no trouble at all, it means this is big step forward in the right direction towards a DRM-free world (at least in the music world).
It was about time for the music industry to realize that DRM (Digital Restrictions Management) is not the answer. Finally!
Mac OS X, Bluetooth and Motorola UMTS phones
February 14th, 2007
NOTE: This post is a based on Mac OS X, Bluetooth and Nokia UMTS phones that I wrote some days ago, but adapted to Motorola 3G phones.
This brief post explains how to pair Mac OS X with a Motorola 3G/UMTS phone in order to access the Internet via a data packet connection. In my case, I’m using a Motorola RAZR V3xx phone but any other Motorola 3G phone should work.
Before you start, please make sure that your phone is properly configured and that you can browse the Web via a GPRS/UMTS connection. Also, make sure that Bluetooth support in your phone is configured and activated and, for phones that have temporary visibility (are only visible via Bluetooth for a limited period of time), make sure to enable Bluetooth just before the pairing process.
Initial configuration
First, download the Motorola 3G Modem Scripts for Mac OS X from Ross Barkman’s Home Page (the official site) or from here.
Second, uncompress the file and copy the files named “Motorola 3G CID1” and “Motorola 3G CID2” into “/Library/Modem Scripts“.
Next, pair your Mac OS X computer with the Motorola phone by clicking on the Bluetooth icon in the menu bar and then Set up Bluetooth Device…. When pairing make you sure you choose Use a direct, higher speed connection to reach your Internet Service Provider *GPRS, 1xRTT).
Enter guest as the Username, guest as the Password, the APN (CID String or Telephone number) and make sure Motorola 3G CID1 is selected as the Modem Script. For example:
For a detailed list of possible combinations of username, password and APN CID for a lot of providers around the world visit Ross Barkman’s GPRS Info Page.
Dialing out
To dial out, open Internet Connect, browse to the Bluetooth tab and make sure the right entry is selected from the drop down menu. Then click Connect. Mac OS X will authenticate to the remote PPP server and a new dynamic PPP subinterface should be configured:
$ ifconfig ppp0 ppp0: flags=8051mtu 1500 inet 10.142.15.9 --> 10.6.6.6 netmask 0xffffff00
In my case, browsing speed is very good (around 384Kbps), but it might vary according to placement, coverage, whether you are moving and so on (by the way, UMTS network planning, deployment and coverage is something not trivial).
Troubleshooting
Make sure all the information for the connection have been entered correctly, specially the APN/Telephone number. If it doesn’t work, try using Motorola 3G CID2 as the Modem Script instead.
iSync 2.3 and the Motorola RAZR V3xx
February 14th, 2007
It turns out that the Motorola RAZR V3xx cell phone is not yet supported by iSync 2.3. Fortunately enough, David has created an iSync 2.3 plugin.
David wrote a post named iSync and a Motorola RAZR V3xx and the iSync 2.3 plug-in that can be downloaded from here or from here.
Unfortunately, the version that is available at the moment of this writing is version 4 and, while it does support synching contacts, iCal synching is not yet supported or working. Anyways, thanks for the plug-in, David 