Extra Pepperoni

To content | To menu | To search

Tag - Apple

Entries feed - Comments feed

Tuesday, November 6 2007

Leopard: Minor authorization bug

System Preferences has a security feature whereby you must "unlock" and authenticate as an admin to change sensitive settings, including Network settings. Ethernet & AirPort both have "Advanced..." buttons behind which Apple hides most of the actual controls -- the non-Advanced settings are cut down and simplified (but definitely fine for normal use). Unfortunately, once you click Advanced... to change the settings, there's no authenticate button. I've found myself in the Advanced sheet, unable to make a change, and had to back out of the sheet, unlock, and then click Advanced... again to make a change.

Apple declines to address this issue, so I'm documenting it here for others annoyed by this bug.

Saturday, November 3 2007

Screen Sharing replaces Apple Remote Desktop

Update 2009/01/15 If you connect to a particular machine frequently, you could put a clickable icon into the Dock.

  1. Put these two lines into a plain text file (I'll call it myserver.command). The filename must end with .command to be launchable from the Finder.
  2. Make sure it has UNIX line breaks.
  3. Make it executable (chmod +x myserver.command).
  4. If you use it a lot, drag it into the Dock for quick access.
#!/bin/sh
(sleep 4; open vnc://127.0.0.1:5901) & ssh -C -4 -L 5901:127.0.0.1:5900 myserver

That will ssh to myserver, pop back a tunnel for VNC, and point Screen Sharing to the tunnel. After you close the Screen Sharing connection and log out of the ssh session, the tunnel will be closed automatically.


Update 2008/2/3: Adam, thanks for the suggestion -- I'd forgotten about the vnc:// scheme. But who's Geoff?? I prefer aliases to functions because they're simpler, and like to leave an ssh shell open, both for my own use and as a reminder to close the tunnel when done. Here's a simpler alias -- note that you must still supply the hostname on the command line after the alias, e.g., "stss salt".

alias stss="(sleep 4; open vnc://127.0.0.1:5901) & \
ssh -C -4 -L 5901:127.0.0.1:5900"

Update 2007/12/14: I added a pbcopy command to put '127.0.0.1:5901' on the Clipboard (pasteboard), so now I can just Paste and then delete (pbcopy appends an undesired Return to the Clipboard), which makes the whole thing easier. New alias (note that this is really properly one line, but it doesn't wrap properly without help):

alias stss='echo 127.0.0.1:5901 | pbcopy; open \
/System/Library/CoreServices/Screen\ Sharing.app; \
ssh -C -4 -L 5901:127.0.0.1:5900'

I have a couple licenses for Apple Remote Desktop at work, for managing our 8+1 Mac cluster ("the orchard") and for managing other Mac servers on campus. I find ARD very useful because although Remote Desktop uses VNC as the underlying protocol, Apple's compatibility has been poor, so I had lots of trouble connecting from Chicken of the VNC and other clients. While I like ARD (particularly the automatic ssh tunneling in v3), I only use the remote control feature, never its other management capabilities.

With Mac OS X 10.5 Leopard, Apple has bundled /System/Library/CoreServices/Screen Sharing.app, which provides the VNC capabilities I use from ARD and skips the other features I don't care about. It's my favorite Leopard feature, accessible from the Finder Sidebar, iChat, Server Admin, and through Back to My Mac (which seems to have some problems with security).

The only thing I don't like about Screen Sharing is that Apple apparently built encryption into the VNC protocol in an incompatible way. Apple's encryption is of course incompatible with all the other clients & servers, since it's Apple proprietary (just like their proprietary compression encodings). It's confusing because the Preferences options look identical to the ones in ARD3, which actually uses an ssh tunnel to provide encryption. It's a firewall problem because there are lots of places we a) allow ssh, b) block unencrypted VNC, and c) would allow encrypted VNC. ARD3's ssh tunneling is usable here but Screen Sharing's port 5900 connection is blocked. Fortunately the workaround is simple -- build the ssh tunnel manually, as is normal for non-ARD3 VNC users. I have this alias:

alias stss='open /System/Library/CoreServices/Screen\ Sharing.app/; ssh -C -4 -L 5901:127.0.0.1:5900'

I use it with a hostname, as in: stss www

That makes an ssh connection to the specified host (www in this case), sets up a tunnel from 5901 on my admin workstation to 5900 on the server (since the admin workstation is likely to be running the Remote Management/Screen Sharing agent on 5900 already), and gives me a shell on www. As a convenience, it also launches Screen Sharing for me. In the Screen Sharing Connect window, I type 127.0.0.1:5901, and connect to the local end of the tunnel on port 5901; it goes through ssh and I get secure remote control via the ssh port (so it works across any firewalls that allow ssh). It's actually doubly encrypted if I'm going across the Internet, since I always leave Screen Sharing's encryption on too -- if I forget to start the tunnel or connect to a machine that's not firewalled on port 5900, I want to be sure I'm not transmitting passwords in plaintext.

Friday, November 2 2007

Mac OS X: Authentication Timers

I have been reading about Mac OS X 10.5 Leopard Server and non-Server lately, and I was surprised to realize how many different authentication & authorization systems are running each with its own timer.

  1. Access to the "console" (keyboard/video/mouse): Ends when you log out or the locking screen saver kicks in.
  2. Authentication for administrative actions in Carbon/Cocoa programs (such as modifying system directories in the Finder): 5 minutes (I believe).
  3. Apple Keychain: Doesn't lock automatically unless you configure it in Keychain Access.
  4. ssh-agent (now linked to the Apple keychain): Clears when you reboot or when the Apple keychain locks.
  5. Kerberos V (both client-server and client-client): Apparently TGTs expire after 10 hours by default.
  6. sudo: 5 minutes by default.

Thursday, November 1 2007

Leopard: Turn "Allow guests to connect to shared folders" off

Setting up new Leopard (user) and Leopard Server systems, I was shocked to discover that, in System Preferences:Accounts:Guest, "Allow guests to connect to shared folders" is enabled by default. This is lousy security. Fortunately file sharing is off by default, but I turned file sharing on a day or two before I noticed guest access was enabled. I don't want guest access enabled, and it shouldn't be on without a conscious decision.

Thursday, October 4 2007

New uses for passwords

I was walking down the street this morning, burning a piece of paper with some old passwords on it, and holding the box of matches I had used to light it. A woman saw me, and said "Hi. Gimme a match?" I got out a match and prepared to light it for her. Before I could strike flame, the woman leaned over to my burning password paper and lit a cigarette from it, then said "Thank you."

There I was, standing on the street, thinking "Smoking's bad, mm-kay," and wondering why she asked for a match when she wanted a light (yes, I know, I cannot turn off being an editor), and thinking this was probably actually not the first time someone's lit a cigarette from a burning password, but it's still unusual.

Monday, September 24 2007

iPhones are not high-security devices

It's worth pointing out that iPhones are not designed to be highly secure. Apple has quite deliberately designed and marketed them as consumer devices, declining to officially enter the "enterprise" market. This lets Apple ignore several of the thornier security features of devices like BlackBerries, such as remote erasure of data. A 4-digit PIN is obviously not intended for high security, and even that is awkward if you use the iPhone many times a day (as I do).

Unfortunately, it also means Apple sees no need to provide strong security on the iPhone. At this point, the thing I miss most from my Treo is the Palm version of Web Confidential. One possibility is to create a web page of passwords, protecting it with SSL/TLS and a strong password (and likely IP restrictions to my home and work networks as well). For ease of adding/updating passwords, it could be a private wiki. Hopefully Web Confidential or something else will be available for iPhone (and Apple won't effectively block it) before I find myself installing a wiki on www.reppep.com.

Since there's no cryptographically protected keychain, I seem to be stuck without IM. Apollo IM, at least, stores the password in its binary configuration file, so Apollo IM is no longer on my iPhone. In addition, hahlo.com, itweet.net, & ipheedr.com all stored my password in plaintext in ~/Library/Cookies/cookies.plist on the iPhone. I deleted the cookies and won't be going back to them. Fortunately twitter.comand m.newsgator.com at least avoid plaintext passwords in cookies...

Monday, September 10 2007

FIPS 140-2 for Mac OS X

I got a very interesting (and unexpected) email today. Apparently Apple is in the process of certifying Mac OS X to Federal Information Processing Standard 140, which is used to validate encryption and security technologies -- it's commonly associated with SSL/TLS hardware and software; I know OpenSSL was being validated against FIPS too, but haven't kept track of that progress. I had no idea Apple was working on this, but if and when it's completed, it should be a useful credential for Apple in security-sensitive environments. Note that I make no claims as to the meaning of FIPS certification, but it will be used as a simple checkbox for trustworthiness, so can't hurt Apple to have this particular tick-mark.

From: "Shawn A. Geddis" <geddis@>
To: Fed Talk <fed-talk@lists.apple.com>
Date: Mon, 10 Sep 2007 04:57:51 -0400
Subject: [FIPS 140-2] Mac OS X - Implementation Under Test (IUT)

It's Official -- Mac OS X is now in "Pre-Validation" for FIPS 140-2 Level 1 (Software) Conformance Validation

Everyone has been eager to know the status of FIPS 140-2 Conformance Validation for Apple's Mac OS X and we are happy to finally announce that as of Friday September 7, 2007 the Apple Cryptographic Service Provider (CSP) Module is officially now in "Pre-Validation".

Listed on NIST (CMVP) Pre-Validation List

You will now find the Apple "Cryptographic Service Provider (CSP)" on line 5 of page 2 on the Pre-Validation List (PDF) posted on the NIST CMVP website. To view that list now or reference it in the future, use the following link to download the PDF document:

http://csrc.nist.gov/cryptval/140-1/140PreVal.pdf

What will be covered by this validation

A Cryptography Architecture is built into Mac OS X and is the foundation for services critical to the protection and privacy of data. The key Apple Cryptographic Services which will be covered by this validation are:

FileVault (Encrypted Container - User's Home Directory)

Encrypted Disk Images (Encrypted Container - Stored on any accessible media)

Keychains (Credential Storage)

The FIPS 140-2 Conformance Validation Process

For those who are not familiar with the process and requirements, they can be found on the NIST website at:

http://csrc.nist.gov/cryptval/140-1/preval.htm

  1. Implementation Under Test (IUT)
  2. Validation Review Pending
  3. Validation Review
  4. Validation Coordination
  5. Validation Finalization

When it will be done

Many have asked when Mac OS X's cryptographic algorithms and cryptography conformance validation against FIPS 140-2 Level 1 will be complete. Apple is unable to provide you with a more specific timeframe than the first half of 2008 due to the extensiveness of the process. Apple will make every effort to post status updates on the Federal website [ http://www.apple.com/itpro/federal/] as well as occasional updates posted to the Fed-Talk Mailing list [ http://lists.apple.com/mailman/listinfo/fed-talk ].

Meeting OMB Recommendations (M-06-16)

To assist Federal Agency IT Staff in understanding how Apple's Mac OS X Operating System can help them meet OMB guidelines, the Apple Enterprise Team had developed and presented the "Meeting OMB Encryption Guidelines with Mac OS X Today" briefing to a large Federal IT Staff on August 17, 2006. Many additional Federal Staff had indicated that they were unable to attend the all day briefing and technical discussion due to scheduling conflicts, but said they were extremely interested in getting access to the presentation.

"Meeting OMB Encryption Guidelines"

http://idisk.mac.com/geddis-Public/security/Meeting_OMB_Encryption_Guidelines.pdf

Background on FileVault

FileVault provides full 128-bit AES encryption of the User's Home Directory where the user has full, direct access to read and write their data. The underlying Encrypted Disk Image architecture also provides services to create, manage and store the encrypted containers on any accessible storage media. This storage includes external volumes such as thumb drives, CDs/DVDs, USB/FireWire HDs and even network accessible volumes.

Background on Apple's Cryptographic Architecture

The Cryptography and PKI Services within Mac OS X and Mac OS X Server are provided through the CDSA - Common Data Security Architecture . The CDSA architecture is the core part of Apple's Security framework which is available from The Open Group and available as open source for review, use and modification.

Open Group - CDSA: http://www.opengroup.org/security/l2-cdsa.htm

Apple source can be found at: http://developer.apple.com/opensource/security/

If you have any additional questions at this time regarding the FIPS 140-2 Level 1 Conformance Validation of Mac OS X , please contact me directly via email at: geddis@

Tuesday, August 21 2007

SSHKeychain Is Unsafe

Eric Warnke has discovered that, if asked nicely, SSHKeychain will print out the passphrase used to encrypt a loaded private key. This is bad, as the whole point of an ssh agent/keychain is to provide secure access to encrypted keys, meaning you cannot get the passphrases or plaintext keys out.

http://www.sshkeychain.org/pipermail/users/2007-August/000098.html

Crud on a cracker, Batman!

Verified in the latest (v0.8.1) -- hopefully there will be a patch soon, but this just shouldn't be possible.

http://www.sshkeychain.org/

Friday, August 3 2007

Laptops in Hostile Environments

The Register has an interesting article on how to "safely" take your computer to Defcon, with the very wise suggestion that you're safer if your laptop does not go to Defcon. Cellular phones without 802.11 are probably okay for this year at least. They refer back to a much more hard-core SANS post on the same topic.

The exercise is more involved for the fully paranoid, or generally when preparing to enter a truly hostile network. I assume that someone at Black Hat/Defcon has an unannounced exploit that I'd be vulnerable to. This implies you shouldn't have any sensitive data or access to sensitive machines. Since you wouldn't need a laptop without data or access, you probably need to mitigate the consequences of getting hacked.

  1. Make up a couple disposable passwords just to use at the conference, one for this machine and one for outside accounts. Destroy them later.
  2. Bring an empty USB thumb drive.
  3. Create a new email account, so you can send yourself notes/presentations for later.
  4. Forward your important email accounts to the new one (keep copies on the normal accounts), so you don't have to check them.
  5. Note that if you have a hosting plan like DreamHost's, you can create brand-new ssh and email accounts free. I believe DH offers SSL webmail, if you can ignore the certificate warnings.
  6. Get a cheap monthly VPN account, as suggested by Glenn Fleishmann; this is much simpler than establishing a trusted Squid proxy on a non-sensitive box, as originally suggested by SANS; note that you are then trusting the VPN provider.
  7. If you have any untrusted protocols, try to access them from your temporary shell account via ssh, or though an ssh tunnel.
  8. Back up your data (image the drive -- you will need it later, and a full image is fastest to restore).
  9. Wipe your laptop.
  10. Install your OS, creating a new account with your new local password.
  11. If you have a built-in webcam with an independently software-controlled active light, tape over it. If you feel comfortable opening up your laptop, disconnect its internal microphone.
  12. Create a new ssh keypair. If you know the netblock, only allow access from Defcon machines and your own personal host(s); I have some info on doing this in authorized_keys in Take Control of SSH, Draft Excerpt: Public Key Authentication. Make sure your laptop trusts your other (home) machines.
  13. Only as needed, trust this new key on your other systems.
  14. In your local firewall, block outbound access except to the ports you intend to use; this is easy in Linux, but a bit more complicated on Macs, where you need to write your own startup script (or .command script in Login Items). This is obviously overridable, but an effective way to make sure you don't accidentally connect without encryption, either from habit or because a website redirects you to unencrypted HTTP to save encryption cycles (common). For services where you know what host you'll be connecting to, embed that. Here's a sample of what you might add to add Apple's ipfw. Note that it's easy to shoot your own foot off with outbound firewall restrictions.

    ipfw add 01010 allow tcp from any to 4.2.2.1 dst-port 53 out
    ipfw add 01020 allow udp from any to 4.2.2.1 dst-port 53 out
    ipfw add 01030 allow tcp from any to 4.2.2.2 dst-port 53 out
    ipfw add 01040 allow udp from any to 4.2.2.2 dst-port 53 out
    ipfw add 01110 allow tcp from any to any dst-port 22 out
    ipfw add 01120 allow tcp from any to any dst-port 443 out
    ipfw add 01030 allow tcp from any to smtp.dreamhost.com dst-port 587 out
    ipfw add 01040 allow tcp from any to mail.dreamhost.com dst-port 993 out
    ipfw add 01900 deny tcp from any to any out
    
  15. Restore only required information to your laptop.


Enjoy the conference. Hi, Rich!


When you're back home, connect from your home machines to the untrusted laptop, rather than the other way around, retrieve any data on it, and then boot from CD/DVD/PXE and reinstall, or restore from your image if you can do that without using the untrusted OS on the laptop's hard drive.

Friday, July 20 2007

iPhone Observations

I had an iPhone on eval for a couple of days, and have learned many things.

iPhone VPN is buggy -- it only accepts numeric passwords (many people have gotten around this; mine hung when I tried), tends to forget them (these are well documented online). It's quite limited -- not compatible with RU's IPsec configuration (we could perhaps fix this if we weren't concerned about attackers using the VPN protocols); not compatible with our (preferred) SSL VPN. It's insufficient -- as Glenn Fleishman pointed out for Macworld, the iPhone won't store multiple IPsec or multiple PPTP VPN configurations, and cannot be configured to always reconnect to VPN when moving between networks.

The iPod functionality doesn't support shuffle by album! It's only by song (which I don't like).

Several people have complained that the iPhone doesn't work with their older earphones. I was pleasantly surprised that it works with my older Apple iPod In-Ear Headphones, although unfortunately it doesn't accept the higher quality UltimateEars 'phones Amy and Julia gave me for my birthday. Most earphone cables have a thicker area around the connector for grabbing to extract the 'phones, and Apple recessed the jack without leaving enough room for those 'handles'.

I thought I could just dump the full-quality MPEGs from our TiVo onto the iPhone, saving the considerable H.264 recompression & scaling time, but they don't work. On the other hand, Dr. Who at 480x320 looks and sounds great. As I try them out, though, I find myself cursing whoever decided not to show file suffixes on the iPhone, or in iTunes, or in the error messages that a file can't be transferred because it's the wrong type. Okay, but which one??? I have a .mov, a .mpeg, and a .m4v -- which is the tall one, which is the good one, and which won't go??? I've made some guesses based on graniness and proportions, but they are guesses, and I shouldn't have to rename the files and spend a few hours transferring and deleting and retransferring to discover what Apple refuses to tell me.

It's great that the iPhone can display PDFs, but annoying that it seems they must be received via email or accessed in real-time via a website.

Pinching doesn't work well one-handed. I tend to spend 2h+ per day walking around or sitting with my Treo 650 in hand, reading or watching video. It's easy to use my thumb to drive the iPhone (or hit keys on the Treo), but no pinch. So to zoom I bring my other thumb to bear, which doesn't work terribly well. Also, due to its size and slipperiness, the iPhone is harder to hold. I dropped it within 24h of getting it. I know the screen is bulletproof, but not the back. I can see marks on the bottom black and the top silver. This is minor, but how many times will I drop an iPhone during its 2-3 year lifetime?

It's annoying that movies must be manually selected in iTunes before they will sync over.

I wish I could set a home page; I have a list of links, and have to keep telling the iPhone to go there. I understand the desire to avoid a heavy page load on connect, but we should be able to have a home page (perhaps even a local one, or start with the Bookmarks list). A wiki would be even better for this; perhaps I'll set up a private one after I get a real iPhone, someday.

Despite the claims that iPhones don't have scrollbars, they actually do. As you flick-scroll through a long document, the iPhone shows a small dark grey proportional scrollbar to give you a sense of position within the document -- a welcome aid to navigation, since when reading there's no indication of how far down the page you are.

I think Apple overcommitted to the "real" Internet in your pocket (meaning something very like Safari on Mac/Windows). Comparing reading the same pages between the Treo 650 and the iPhone, the iPhone was actually inferior. The page loading was slower, since each page had to be downloaded; in contrast, Plucker documents are already in flash, although the CPU can take a few seconds to render them. The iPhone renders all the images, even though on many sites they're purely advertising. Here's a case where Apple's delivering on their claims, but it's a bad thing for usability; a setting (ideally per site) to skip images would be a boon.

Plucker reflows paragraphs to fit the narrow screen width; this works well except on rare pages with hard-wrapped lines. Mobile Safari tries too hard to keep the original web page's column width, meaning many pages are either too tiny to read or can only be read sideways (scrolling twice per line is a non-starter). There's no reason to slavishly honor web designers' specifications for width on a new platform with such different characteristics than these sites were coded for -- perhaps if the iPhone finds an iPhone-specific style sheet its width should be taken seriously, but most web sites just assume 1024x768 or better, and the iPhone suffers needlessly when it tries to play that game. In fairness, some sites, like The Onion AV Club look much better on the iPhone, but the news sites I mostly read don't.

I'm disappointed by the iPhone's font rendering. I can tell it's using 'real' fonts, but anti-aliased Gothic 18 on the Treo is crisper and more readable.

Additionally, when reading web pages and email, you almost always want to scroll a full page. Safari tends to scroll half a page, or a page + 2 lines, or a page down and 1/4" to the right. It's erratic enough that I spend time looking for the last line I read, which is a recurring waste of time. I see that the iPod is trying very hard to respect what I did, but I shouldn't have to start at the bottom, drag to the top, and watch how far it went. I should just make the "scroll" gesture and it should Do the Right Thing, since WIM is obvious.

I do like that (unlike the iPod) the iPhone is usable while plugged in, and can always be disconnected quickly (the iPhone Dock connector doesn't lock like the iPod connector); this is partially because it's not accessed as a hard disk, and partially because people like to charge their phones but still need to answer (make) calls. In contrast, iPods are largely superseded by iTunes and speakers on the computer they plug into.

Bug or design flaw? With the mute button engaged, iPod mode still plays sound on videos. If I have mute engaged, the speaker should be off. Not "only on for those things Apple believes I probably really want to hear anyway", but off. I haven't checked YouTube.

Speaking of which, it's ironic that a small screen with a relatively slow CPU and network connection is such an excellent YouTube device, but that will remain true until Google makes the H.264 streams available through their normal website.

I haven't really used the MobileMail. The PIN isn't adequate security, so I've only trusted it with my unused .Mac account.

I haven't used the calendar much -- I'm working under some unusual constraints, and 2 days isn't enough to switch myself to looking at the iPhone for calendaring, but I find the absence of Week view inexplicable.

I haven't used Visual Voicemail! Rockefeller has a (poor) Windows-based voicemail app which I use sometimes, either to avoid switching headsets or for better control than button mashing. Interestingly, Apple's iPhone implementation looks substantially better, despite the physical constraints. I always knew the app stunk, but apparently the modern ones are all purely Exchange based. Perhaps we'll see some improvements in this area.

Here's a silly one: the iPhone gets dirty so easily that wiping it off wastes a few minutes each day. I have better things to do with my time than polish an (admittedly beautiful) Apple iPhone. Watching video is the worst, since the controls are all onscreen and don't work well with fingernails. After picking a video and hitting Play/Pause a couple times, it gets notably harder to see.

Video controls are poor. They're hard to hit, don't always trigger, and accelerate as you hold them down. The result is that by the end of a commercial break, once I see the show and release, the iPhone has jumped substantially past the end. Then I go back, and often have to watch the last commerical again (3x total: once fast forward, once fast backward, once normal forward) to get to the resumption of the program. Dragging the time slider is way too imprecise. These are fixable in software, and hopefully they will be soon.

Monday, June 25 2007

Securing Communications with SSL/TLS: A High-Level Overview

I wrote a long article for TidBITS about SSL/TLS, attempting to explain it to a lay audience. I wrote another piece for admins on how to use CA.pl, which TidBITS didn't pick up, and a third piece about a couple shell scripts I wrote to help run a Certificate Authority, called cert.command & sign.command. I hope you find them interesting and useful.

Saturday, June 23 2007

Cool Tool: ssldump

We were trying to figure out what was wrong with communications between our load balancers and Oracle Application Server this week, and the F5 rep whipped out ssldump. With the SSL key, ssldump can decrypt captured traffic from tcpdump just like wireshark (ethereal) does for unencrypted traffic; apparently it can also do live display of SSL traffic like wireshark, but I haven't tried.

Good stuff!

Friday, June 15 2007

Jury Duty

I just sat with (not quite on) a civil jury this week. I was Alternate #2, which meant I was the same as the other jurors until the very end, but while they deliberated I (and Alternate #1) sat next door; we were the same except in the jury room for final deliberations. Apparently in federal court, alternates participate in deliberation the same as other jurors, which would have made it feel like less of a waste of time.

To my pleasant surprise, the jury selection pool sported an open wireless network and a bunch of PC "terminals" so we could surf while cooling our heels before being empaneled. Unfortunately, apparently nobody in the area knew the PCs' Windows passwords, so logging out was a big no-no, but I brought a laptop and didn't really care. The actual jury rooms were not online, but we didn't spend much time waiting there, except during the actual deliberations.

Fortunately the trial was relatively simple and fast -- we started Monday with jury selection, heard a half-day of testimony on Tuesday and again on Wednesday, heard closing arguments and (they) deliberated on Thursday, and heard the verdict read out and got our jury service receipts Thursday. This last part is important, as the receipts keep us from being called back to jury duty for (at least) 8 years -- not bad!


In 2000 a music studio was burglarized, and most of the equipment was stolen, including a Harrison MR2 56-channel console. We later heard parts of it were found (apparently in 2003) in boxes, and in a dumpster somewhere. There was a previous lawsuit on this insurance claim in 2006, and there (and perhaps in a negotiated settlement) all issues were settled except the insurance value of this audio recording console. Our only charge as a jury was to determine the value of the console, so the insurance company could reimburse for the loss. It was obvious we were missing a lot of the backstory and case history.

I was amazed by the discrepancies in expert opinions. The plaintiff's expert claimed the console was worth $75-$85k in 2000, while the defense expert claimed $7,500 as its value. Both claimed (credibly) to be quite familiar with the market for this piece of equipment. I wonder how much of it is markup and attitude -- "I can buy one that could be fixed up for $X." is not the same as "I can put a price tag on this, reading $Y." The actual purchase price (6 months before the burglary) was $28,000, so we all felt somewhat at sea -- no two pieces of information corroborated each other.

Wednesday, June 6 2007

DreamHost Screwed the Pooch

This sucks, Beavis!

I had to change the school's panel password (which will only be changed again in 24 days when I hand over the reins to my successor, who will change it again), plus my personal panel password, 3 shell passwords, 12 list passwords, this blog's password, and possibly the Analog passswords, and what will I forget?

Crud. Crud. Crud.

DreamHost's next failure is not telling us what the spam links look like. I can't read the source of every page on the site, but if they would tell us what to look for, I could grep for the suspect sites quite easily. I actually found them elsewhere (see the Andy Hagan link below) -- no thanks to DH, whose screw-up I'm now attempting to fix.

Adding injury to injury, I just got the cheery/goofy montly DreamHost email, with no mention of the hack, even though they must have been dealing with the break-in when the message was sent.

To make things worse, the status page where they promise to post updates on this incident doesn't even mention it! This is 2 1/2 hours after they sent me email, and they still haven't come clean in public. On the other hand, oscandy.com had a posting about it a couple days earlier http://www.oscandy.com/hacking/454-dreamhost-hosting-platform-hacked.

From a couple other blogs, this may have shown up a week ago:


To: "Chris Pepper"
From: DreamHost Security Team
Subject: [reppep 11988754] URGENT: FTP Account Security Concerns...
Date: Tue,  5 Jun 2007 18:52:42 -0700 (PDT)

Hello -

This email is regarding a potential security concern related to your  
'reppep' FTP account.

We have detected what appears to be the exploit of a number of  
accounts belonging to DreamHost customers, and it appears that your  
account was one of those affected.

We're still working to determine how this occurred, but it appears  
that a 3rd party found a way to obtain the password information  
associated with approximately 3,500 separate FTP accounts and has  
used that information to append data to the index files of customer  
sites using automated scripts (primarily for search engine  
optimization purposes).

Our records indicate that only roughly 20% of the accounts accessed -  
less than 0.15% of the total accounts that we host - actually had  
any changes made to them. Most accounts were untouched.

We ask that you do the following as soon as possible:

1. Immediately change your FTP password, as well as that of any other  
accounts that may share the same password. We recommend the use of  
passwords containing 8 or more random letters and numbers. You may  
change your FTP password from the web panel ("Users" section, "Manage  
Users" sub-section).

2. Review your hosted accounts/sites and ensure that nothing has been  
uploaded or changed that you did not do yourself. Many of the  
unauthorized logins did not result in changes at all (the intruder  
logged in, obtained a directory listing and quickly logged back out)  
but to be sure you should carefully review the full contents of your  
account.

Again, only about 20% of the exploited accounts showed any  
modifications, and of those the only known changes have been to site  
index documents (ie. 'index.php', 'index.html', etc - though we  
recommend looking for other changes as well).

It appears that the same intruder also attempted to gain direct  
access to our internal customer information database, but this was  
thwarted by protections we have in place to prevent such access.  
Similarly, we have seen no indication that the intruder accessed  
other customer account services such as email or MySQL databases.

In the last 24 hours we have made numerous significant behind-the- 
scenes changes to improve internal security, including the discovery  
and patching to prevent a handful of possible exploits.

We will, of course, continue to investigate the source of this  
particular security breach and keep customers apprised of what we  
find. Once we learn more, we will be sure to post updates as they  
become available to our status weblog:

      http://www.dreamhoststatus.com/

Thank you for your patience. If you have any questions or concerns,  
please let us know.

- DreamHost Security Team

Tuesday, May 22 2007

Adobe Lies, Badly

Adobe just posted a workaround for a security bug in their installer: Security bulletin: Workaround available for security vulnerability caused by installing Adobe Version Cue CS3 Server on some Mac systems.

Thanks to Daring Fireball for the heads-up.

In the Details section of the advisory, Adobe says:

To be granted access to these ports, the installer must first turn off the personal firewall. Currently, it is not automatically re-activating the firewall once it sets up Version Cue CS3 Server, creating a potential security vulnerability.

This is a lie. There is no need to turn off the firewall to add rules. I just discovered that Apple's System Preferences appears to flip the firewall off and on to pick up new rules. This makes things simpler, as Apple can just use existing code to a) edit the configuration file, b) turn the firewall off, and c) turn the firewall on, rather than doing "live insertion" of rules. The truth is, though, that there are two different ways to add rules such as Adobe requires. Both are described in Apple's ipfw manual page.

Adobe's Details tells you what they require:

On Mac OS X, customers can turn on a personal firewall to control how Internet services communicate with their systems. During the installation of Adobe Creative Suite 3, the installer sets TCP ports 3703, 3704, 50900, and 50901, in accordance with Appleā€™s specification, to allow controlled access to Adobe Version Cue CS3 Server through the Mac OS X firewall service.

One way is to simply add rules individually, such as:

ipfw add 8001 allow tcp from any to any dst-port  3703 in
ipfw add 8002 allow tcp from any to any dst-port  3704 in
ipfw add 8003 allow tcp from any to any dst-port 50900 in
ipfw add 8004 allow tcp from any to any dst-port 50901 in

This is tricky, since Adobe doesn't know what rules their users have, and it's important to insert them into the right place in the sequence.

Another way is to update the rules file and then reload it, as described in the manual page:

 To ease configuration, rules can be put into a file which is processed
 using ipfw as shown in the last synopsis line.  An absolute pathname must
 be used.  The file will be read line by line and applied as arguments to
 the ipfw utility.

In Tiger, Apple's dispensed with the BSD-style rules file, and replaced it with an XML document. I don't know how Apple manages the XML configuration, and perhaps they don't provide a hook to update the live ruleset. Apple's tools should be doing this, but don't. At a guess, someone at Adobe decided to follow Apple's (bad) example and stop & start the firewall, rather than updating the XML configuration file (as they already do), figuring out where the new rules would show up, and then live inserting them (see "ipfw add", above).

Stopping the firewall temporarily is opening customers to unnecessary risk. It's bad, but Adobe's in good company here. On the other hand, saying this is necessary is either a lie about security (never a good idea) or gross technical incompetence (not a real improvement).

If they didn't have the unfortunate bug, whereby the installer neglects to restart the firewall after it's disabled it, we might never have noticed.

Wednesday, May 9 2007

Can anyone get a CSR out of Certificate Assistant?

I'm testing Apple's Certificate Assistant, and when I generate a CSR, I get a Conclusion dialog that tells me my CSR has been emailed to my CSR for action.

Unfortunately, I never get the CSR (I'm the CA in this case). I have confirmed no mail was ever actually sent (see http://www.extrapepperoni.com/2007/05/09/restarting-syslogd/), and I even fired up Mail.app to make sure there was nothing waiting in my Drafts there -- no dice.

So as far as I can tell the CSR functionality is completely useless, because I'm completely unable to lay my virtual hands on the CSR CA claims to generate.

Does anyone know better? Do you use CA and get the emails? Do you know where I can find the CSR files, at least?

Thanks for any pointers.

PS-Yes, I filed a bug.

PPS-I have confirmed, using 6 shell accounts across 4 machines, 2 email accounts on different servers, mail.log, & tcpdump, that no mail is ever sent. Apparently it works for other people, though, so I'm at a loss.

Saturday, May 5 2007

iSync Finally Behaving again

I have a lot of trouble with iSync (to my Treo) and .Mac sync. A few weeks ago, it was generating bogus complaints and bloating ~/Library/Application Support/SyncServices (up to 9gb in a single HotSync, which ran the PowerBook's hard disk out of space). I eventually cleared that one.

I had to abort a HotSync a couple days ago. Yesterday, Palm syncs (which I do twice per day or more, to get fresh plucker content) stopped updating my calendar. I cleared iSync's state, cleared .Mac's state, completely erased my Treo (scary, when the master data on the PowerBook might have been [and in the end actually was] corrupt), yada yada yada. I got different (related) errors, but nothing actually did the trick, until I backed up my data from iCal and reloaded it (luckily, this apparently blew away the corruption). Even this was fraught. I tested by loading it on another system -- trying to make sure the export was good, as I didn't trust the source. But when I attempted to open the iCal backup on the other system, iCal just spun and spun but never seemed to get anywhere. Eventually I realized it was calculating the disk size on the iCal backup. iCal backups are actually packages (folders), and it was taking much longer than it should have to total up the size of the folder, during which iCal was unresponsive (I actually force quit it a few times before I figured out what was going on).

Lesson for Apple is (aside from please fix synching in Leopard!!!): when complaining about a database synchronization error, identify the database you're complaining about! The iSync conduit was spewing errors about updating a specific record number. Of course, I have no reference for what that record number means. Had it mentioned that this was a problem in the iCal database, not the Palm DB or the "Truth database" (on iDisk), I could have saved hours and skipped erasing the Treo.

Another bug, just confirmed and reported. In the .Mac sync reconciliation dialog, I can't activate the "default" (blue throbbing) button with Return/Enter; it gets passed through to the window behind the dialog, although I can change the dialog's pop-up menu from the keyboard.


As it turned out, i started this posting prematurely last month. iSync was still corrupted. I had to wipe my Palm a couple more times, delete all my .Mac sync clients a couple more times, and even enable synching from iCal's & Address Book's preferences because System Preferences:.Mac:Sync wasn't usable -- it would just spin forever, never letting me actually click on the check-boxes to enable synching or specific types of data.

A week later, that part of System Preferences works again, and I have no idea why.

I also don't know how much longer it will continue to work. I was very intrigued by SyncTogether, until I discovered it just uses the same Sync Services infrastructure that keeps breaking so badly on me. I basically pay $100/year for .Mac sync, since I don't use their promo software and I run a more reliable mail server myself (on Apple hardware and software, no less!), so I'd love to find a cheaper alternative, but it's not clear if SyncTogether would really be cheaper (depends on upgrade schedule and pricing, and how many machines, and would require me to poke additional holes in my firewall). Unless and until Apple's syching gets stable, it doesn't make sense to invest more in it than I already am. Additionally, I don't know how soon Mark/Space will have Leopard support.

Wednesday, April 11 2007

Backups and Moving into Subversion

I do not have a comprehensive backup strategy. I keep reading well-reasoned arguments for at least 3 complete (bootable) backups, scratching my head, and saying, "Yeah, if I had a couple thousand unused, I could do that." Yes, I know drives are cheap, but I have 3 important systems to back up, and 4 more where perhaps a dozen files matter combined. Between the important systems, I'd need about 600gb usable, and Joe thinks you need 3 bootable backups, and I'm a strong believer in keeping the backups permanently away from the originals (not on a rotating cycle, but never-the-twain-shall-meet time -- what else is broadband for?).

http://www.takecontrolbooks.com/backup-macosx.html

Unfortunately, whenever I kick off an rsync job to update my remote backups (one set, not 3), Amy complains every day because Internet access is so slow. I think I have throttled it back enough to be unintrusive, but I just don't remember, and (especially at an unobtrusive fraction of our 384kbps DSL uplink), it just takes so dang long.

http://rsync.samba.org/

But I'm not too worried, because 95%+ of my important data is in Eudora on my iPod (yes, I know iPods die -- I've killed more than my fair share, along with Zip disks, Orb disks, and even a 2.5" FireWire drive), and I use Synchronize Plus X to back up my iPod to my primary home and work machines automatically, every time I plug it in. This is a great feature of Synchronize, which mitigates my annoyance with their licensing.

Every morning when I get to work, I dock the iPod; Synchronize sees it, launches Eudora, backs up changed files to my work desktop's hard disk, and launches an AppleScript to bring up a couple applications. When I'm done, I type eject in a Terminal window, my iPod unmounts, and login.keychain is locked (flushing ssh keys in the process). On my home PowerBook, the process is the same.

So I know my backup system works well, because I test restores whenever there's a problem with the iPod (perhaps twice a year). But I still feel nervous erasing it before sending it away. I actually did this today -- a couple months after its 2-year anniversary, my 60gb iPod photo's battery won't last an hour. Apple told me they'd fix it under extended AppleCare, but changed their minds and cancelled the repair -- without telling me. I paid the $70 and sent it in today; I'm running off our old 10gb iPod in the interim.

For the next step, I'm moving my website into Subversion. I already keep Julia's school site & Bjorn's site & documentation in Subversion, and last week I got sick of making manual backups of a piece I'm writing for TidBITS, so I reorganized and checked in my writing (not that there's much of it). Tonight, I threw out 4gb of my 7gb ~/public_html in preparation for checking in (most of) the rest of it.

Backing up a Subversion repository is easy, and will bring me to about 99% of important data backed up (not counting MP3s -- are already replicated to 2 Macs & an iPod -- or iPhoto libraries, which require different handling, but should back up quite well via rsync; but I have to get Julia's few [important] pages into Subversion too).

Tuesday, April 3 2007

Today's Accomplishment: SSO ssh Upgrades

Today I upgraded our 8 core authentication ("Single Sign On") servers from commercial ssh to OpenSSH (it was a 2-year battle to standardize on OpenSSH, but in the end the right product won).

http://www.openssh.org/

The tricky things are: a) These machines are critical enough that they're not directly accessible from campus, so everything must be done through an intermediary machine. This complicates everything. b) Upgrading ssh is problematic because it's the remote control tool, so working on sshd implicitly interferes with your own control. Fortunately we have good terminal servers, which make this much less problematical; when sshd is down, you can get in the back door to bring it up.

One of the neat things about UNIX is that you can delete a file, but if it's open the file is not actually deleted until that filehandle is no longer in use (when the last filehandle is closed, the disk space is reclaimed), so for non-terminal-server systems, I've actually done the whole upgrade through an sshd binary which is deleted at the beginning of the upgrade, replaced during the upgrade, and still in use until the very end.

I (we) have been doing this long enough, and refined the procedure sufficiently, that the whole upgrade took under 90 minutes total for 8 machines, although there was a lot of prep and follow-up, cleaning up accounts, /etc/sudoers, installing public keys, etc.

Overwriting /etc/passwd, /etc/shadow, and /etc/groups with copies from the intermediate machine was particularly stressful; I was highly relieved that nothing broke.

Saturday, March 24 2007

Take Control of SSH, Draft Excerpt: Public Key Authentication

I've started writing something I hope will be an ebook called Take Control of SSH. It's an amazingly long process, so here's an excerpt on private and public key authentication, the most important part of SSH. Note that this was not written as a stand-alone piece, so please excuse the rough edges.

If you'd like to read the rest, please vote for Take Control of SSH.

Part II: Public Key Authentication (Practice)

Private keys are much more secure than passwords (which must be short enough for people to remember and easy to type), but fundamentally they're still large numbers which function as password equivalents. This means that anyone who has your private key can use it to authenticate as you to an SSH server. Files containing private keys (such as ~/.ssh/id_rsa) are therefore as security sensitive as passwords.

On the server side, public keys serve identify users to the SSH server. If someone can manipulate your ~/.ssh/authorized_keys file, they can insert their own key and impersonate you. To protect against this, sshd ignores authorized_keys files with insecure permissions. Unfortunately, sshd doesn't complain about this in a visible way, so mysterious failures of public key authentication are often traced back to inadequate permissions. The rule is that the ~./ssh/authorized_keys file and all the directories that contain it, up to the root of the filesystem, must not be writable by any account except the owner. File system permissions cannot stop a system administrator from accessing the key files (both private and public, although the private keys should be encrypted), of course. Similarly, anyone with access to the machine or unencrypted backups could copy the key files.

Create a Public/Private Keypair

To get started with public key authentication, first generate a new rsa key in Terminal with "ssh-keygen -t rsa". Let ssh-keygen create ~/.ssh/id_rsa, and provide a good password you will remember, because keys cannot be recovered if you forget your password. ssh-keygen will create ~/.ssh if it doesn't already exist, as well as ~/.ssh/id_rsa (your new private key, encrypted with the provided passphrase) and ~/.ssh/id_rsa.pub (your new public key).

pepperbook:~ sample$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/sample/.ssh/id_rsa): 
Created directory '/Users/sample/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/sample/.ssh/id_rsa.
Your public key has been saved in /Users/sample/.ssh/id_rsa.pub.
The key fingerprint is:
ba:d1:0c:43:93:a8:d5:5a:b8:a2:4b:29:ae:34:ee:3f sample@pepperbook.reppep.com
pepperbook:~ sample$ ls -ld .ssh
drwx------   4 sample  sample  136 Apr  6 00:22 .ssh
pepperbook:~ sample$ ls -l .ssh
total 16
-rw-------   1 sample  sample  736 Apr  6 00:22 id_rsa
-rw-r--r--   1 sample  sample  618 Apr  6 00:22 id_rsa.pub
pepperbook:~ sample$ 

To use the new public key for logging into this account on this machine, copy id_rsa.pub to authorized_keys: "cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys". Test it with "ssh 127.0.0.1". First, you will be asked to accept the public key for 127.0.0.1 (recall that keys are used to identify servers, as well as users); it's then automatically copied into ~/.ssh/known_hosts. Second, you will be asked for the passphrase for your private key, instead of the account password for the remote system (note that the passphrase might be the same same as the account password). Finally, you will get a UNIX shell dmg pt on the "remote" system once the ssh session is established. Log out to terminate the ssh session.

Warning: Some Mac OS X versions suffer confusion between the current IPv4 Internet Protocol and the newer IPv6 protocol; IPv6 enables more computers to connect to the Internet but is not yet in wide use. To avoid these issues, use 127.0.0.1 in commands instead of localhost. They should be equivalent, but are not (at least in early versions of Mac OS X 10.4 "Tiger", and I believe in "Panther" as well). Fortunately, Apple fixed this by 10.4.8, but it caused a lot of confusion before that, and still does for people using older versions.

pepperbook:~ sample$ cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
pepperbook:~ sample$ ssh 127.0.0.1
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
RSA key fingerprint is 8a:d3:22:82:f5:2b:88:f0:20:1b:72:bd:aa:30:e0:e2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '127.0.0.1' (RSA) to the list of known hosts.
Enter passphrase for key '/Users/sample/.ssh/id_rsa': 
Welcome to Darwin!
pepperbook:~ sample$ ls -l .ssh
total 32
-rw-r--r--   1 sample  sample  618 Apr  6 00:23 authorized_keys
-rw-------   1 sample  sample  736 Apr  6 00:22 id_rsa
-rw-r--r--   1 sample  sample  618 Apr  6 00:22 id_rsa.pub
-rw-r--r--   1 sample  sample  219 Apr  6 00:23 known_hosts
pepperbook:~ sample$ exit
logout
Connection to 127.0.0.1 closed.
pepperbook:~ sample$ 

Now that you've confirmed your public and private keys work, it's time to copy authorized_keys to some other SSH servers. First, make sure there's a suitable ~/.ssh directory, next send the file, and then login using the key to confirm it works.

pepperbook:~ sample$ ssh www "mkdir -p .ssh ; chmod 700 .ssh"
The authenticity of host 'www (66.92.104.200)' can't be established.
RSA key fingerprint is 53:66:e9:b5:92:e1:5f:d9:71:fa:87:7b:35:99:f2:d3.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'www,66.92.104.200' (RSA) to the list of known hosts.
Password:
pepperbook:~ sample$ scp ~/.ssh/authorized_keys www:.ssh/
Password:
authorized_keys                               100%  618     0.6KB/s   00:00    
pepperbook:~ sample$ ssh www
Enter passphrase for key '/Users/sample/.ssh/id_rsa': 
Welcome to Darwin!
www:~ sample$ exit
logout
Connection to www closed.
pepperbook:~ sample$ 

Once that's tested, you're ready to copy authorized_keys to more computers. You can also put the id_rsa file on other machines, but be careful with this file! Don't put it on any machines you don't completely trust.

Remember that you can use multiple private and public keys. The id_rsa and id_rsa.pub filenames are just defaults -- keys don't need to have any special names, although agents tend to assume that the public key filename is the private key filename plus ".pub", and may get confused otherwise.

SSH Authentication Agents

So far you've replaced password authentication with public key authentication. This is valuable, because it means someone who controls an sshd server which you log into will not get a chance to steal your password. The way SSH handles plain password authentication (against the built-in UNIX or Windows account databases) is by taking the password typed in and sending it through the ssh connection; at the other end the username and password are decrypted and checked against the remote account's password on file. Both the local ssh program you run and the remote sshd program work with the unencrypted password. There have been major incidents in the past where a popular site (such as SourceForge.net) was broken into, and the crackers recorded all the usernames and passwords used to ssh into SourceForge until people noticed something was wrong. The crackers then used those username/password pairs to log into other sites. It was a colossal mess. Public keys avoid this risk, because the remote system only gets the public key. It doesn't need the private key, and cannot determine it from the public key.

Warning: It is possible to use unencrypted private keys, but this is generally a very bad idea, because anyone who gains access to the private key file (trivial, with physical access to the computer) then controls that identity, and can impersonate or eavesdrop on the owner. About the only time unencrypted private keys are appropriate is for automated tasks, run when nobody is available, if using an agent is not feasible. Such keys should be restricted as much as possible in authorized_keys, and the accounts they access should be restricted as much as possible as well.

Key agents make use of SSH much more efficient, at the cost of a small reduction in security. Agents read encrypted key files; the agent keeps the unencrypted key in memory (never in a file on disk), making it immediately accessible without further decryption or password entry. This makes use SSH dramatically more efficient. Without an agent, connecting to 5 systems 3 times each would require typing one's password correctly 15 times; with a loaded agent, all the connections are automatic. As an example, consider checking a file on several machines. An SSH agent automatically provides the private key for each connection, making large-scale operations quick and convenient.

The risk in using an agent is that anyone who can control the agent or its socket (such as a root user) can use it to authenticate, although the private keys themselves are not available directly from the agent. This makes agents (and agent forwarding) unsuitable for use on untrusted machines.

SSHKeychain

On the Mac, SSHKeychain is an excellent SSH agent. It can automatically load keys when needed, forgetting them when the system sleeps. SSHKeychain is accessible through the Dock or the SSHKeychain menu, and integrates with Apple's Keychain, optionally automatically loading and unloading SSH keys as the Apple Keychain unlocks and locks, and it works with other SSH-supporting programs such as BBEdit.

Once you've created and tested your private/public keypair, there are several simple steps to activate SSHKeychain.

  1. Open SSHKeychain.dmg to mount it.
  2. Install SSHKeychain (I just dragged SSHKeychain.app into /Applications).
  3. Unmount SSHKeychain.dmg.
  4. Open /Applications/SSHKeychain.app.
  5. Configure SSHKeychain's preferences (accessible from the new SSHKeychain menu on the right side of the menu bar); the critical parts are to enable "Manage (and modify) global environment variables", and configure specify your private keys if you used nonstandard filenames.
  6. Use Agent > Add All Keys from SSHKeychain's menu to confirm it can load your encrypted keys, and that now you can ssh into systems without entering a password. If you check "Add passphrase to the Apple keychain", SSHKeychain will no longer prompt you for the key's passphrase, although it may prompt to unlock your keychain to retrieve the key's passphrase.
  7. Set SSHKeychain to run automatically (I control-clicked on its Dock icon and set Open at Login).
  8. From now on, whenever you log into Mac OS X, SSH programs will use SSHKeychain for key management.

The SSHKeychain menu shows either of two icons. When it has one or more keys loaded, it shows a keyring with three keys. When it doesn't hold any keys, the ring is missing, but the keys are still shown.

There are a couple bugs in Mac OS X 10.4.x's authentication and the Apple Keychain. In theory, unlocking the screensaver should unlock the user's default keychain (if it uses the account's login password, which is Apple's default configuration), but this doesn't work properly. Additionally, while a keychain is unlocked, the system does not need to prompt the user to "unlock" that keychain again until it's re-locked, but this is also broken -- Mac OS X prompts to "unlock" keychains that are already unlocked.

In reality, if the system is running with the screensaver and Keychain locked, applications tend to bring up their own Keychain dialogs behind it. Unlocking the screensaver or the Keychain does not dismiss these dialogs. The upshot is that, with SSHKeychain set to lock the Apple Keychain on screen activation (its default behavior), unlocking the screensaver may reveal multiple Keychain dialog boxes which must each be addressed individually. With .Mac synching set to Auto, I often saw three authentication dialogs when I unlocked the screensaver.

As a partial workaround, open Keychain Access, create a new keychain (I called mine "lowsec"), select the new keychain, and use "Edit > Change Settings for Keychain "lowsec" to disable locking entirely for this keychain. Then go back to your main (login) keychain, and move the ".Mac password" item (its name will be your .Mac username) from the main login keychain into the new one. Additionally, enable "Use custom security settings" in SSHKeychain, and set "On screensaver:" to "No action". With this configuration, the lowsec keychain will be unlocked once at login time and then available until logout or reboot. For higher security I set my main login keychain to automatically lock after 30 minutes of inactivity. Ideally, both Keychain Access and SSHKeychain would allow locking specific keychains when the screen locks, leaving other keychains unlocked, but this is not currently implemented.

Key Restrictions and Forced Commands

It can be very useful to provide restricted access to an account. In SSH, this is possible by adding restrictions to specific keys in authorized_keys. Some of the possible restrictions include disabling interactive login; restricting agent, X11, or port forwarding (tunneling); and specifying a "forced command", which is always run when the associated key is used, regardless of what is requested by the ssh client. These restrictions are particularly useful for non-interactive tasks such as backup scripts. Such tasks may require SSH connectivity with unencrypted private keys, which should not provide unrestricted ssh access.

Note that multiple keys may provide access to the same account. This is handy for people sharing single accounts, or for using special-purpose keys with different forced commands. For more information on key restrictions and forced commands, see the "AUTHORIZED_KEYS FILE FORMAT" section of the sshd manual page.

Public keys can be further restricted by allowing access to carefully circumscribed accounts; unencrypted public keys which give access to "real" user or root accounts should be avoided as much as possible.

Raising the Bar: Requiring Stronger Security

There are several ways to protect a server against ssh-based attacks, including firewalls, TCP Wrapper, not creating or distributing UNIX passwords (forcing ssh public key authentication), and disabling password access for all accounts or the root account. To read about using firewalls and TCP Wrapper with ssh, please vote for Take Control of SSH.

UNIX passwords present several problems for administrators. What legitimate users can remember and type (generally considered to be 8 letters and numbers) is a small enough range of possibilities for attackers to try all possibilities. "Account lockout" is a feature of some systems (including Mac OS X Server) to disable accounts after several failed guesses -- which often identifies an attack. Unfortunately, this means legitimate users get blocked when their accounts are attacked, and locking legitimate users out of their own accounts is a successful attack (although not as serious as gaining illicit access). System administrators would often prefer to avoid this by not allowing password access at all. On Mac OS X, it is difficult to set up an account without a password; it's easier to create a long random password (12+ characters -- Keychain Access can do this for you), and never write it down or give it to the account user, requiring public key authentication or some other high security authentication (such as smart cards) instead. On other systems, it's easy to simply not set UNIX passwords for accounts (although there are complications).

OpenSSH has its own features to help force users to use public keys, blocking password guessing over the Internet. If you have enabled the root account (which is technically accomplished by setting a password for it), you should definitely set "PermitRootLogin without-password" in /etc/sshd_config; this will prevent people from breaking into the root account by guessing its password -- an amazingly common and disturbingly successful Internet attack. Even better, set "PasswordAuthentication no" to prevent sshd from accepting passwords for any account -- thus requiring keys for ssh access. For more about how to configure sshd and ssh, and enhance security with ssh, please vote for Take Control of SSH.

- page 2 of 3 -