SSH Weirdness On OS X

Saturday, 3. January 2009

I use ssh all the time, but I rarely use it to connect to my MacBook. Today my MacBook froze hard and I tried to ssh to it from my Linux box in an attempt to recover. The ssh failed with the following error message:

    dean@xbrain:~$ ssh 192.168.1.200

    Received disconnect from 192.168.1.200: 2: Too many authentication failures for dean

My first thought was that DenyHosts had borked me but that turned out not to be the case. (If you aren't running DenyHosts you should be.) I tried ssh with debug messages turned on and the client was offering the correct public key but the server was rejecting it. I ended up just doing a hard reboot of the MacBook but I still wanted to solve the prolem.

Next I assumed that something in my private or public ssh keys was borked. Searching on the error message I was getting led me to believe that I had file permission problems somewhere but my .ssh directory had all the correct permissions – 0700 for the directory and 0600 for all the files inside. I edited sshd_config with the intention of enabling PAM and password authentication. Instead the following two lines caught my eye:

    StrictModes yes

    MaxAuthTries 1

First I changed the value of MaxAuthTries to 3. I was rewarded with a new error message from the ssh client.

    dean@xbrain:~$ ssh 192.168.1.200

    Permission denied (publickey).

After that when I turned on debug messages for the ssh client I could see that after the initial public key authentication failed it tried to find other allowed authentication methods and when it failed gave me the error above. Next I changed the value of StrictModes to no. After making that change I could successfully ssh. This confirmed that there was a file permission problem on the server side.

    StrictModes

    Specifies whether sshd(8) should check file modes and

    ownership of the user's files and home directory before

    accepting login. This is normally desirable because

    novices sometimes accidentally leave their directory or

    files world-writable. The default is "yes".

I had always assumed that StrictModes only applies to the user's .ssh directory. It turns out that it also checks the file permissions on the user's home directory and will balk if the home directory is writable by group or other (everyone). My home directory was writable by group and this was the root cause of the errors I had been getting. (The default user group is staff on OS X but it varies on different operating systems and distributions.) After removing group write permissions from my home directory and restoring my original sshd_config settings everything started working the way it was supposed to. From a review of my Time Machine backups it looks like some time in December I accidentally (or perhaps even intentionally) changed my home directory to a drop box which turned on group write permissions. Doh!

Tags: , , .

Share 'SSH Weirdness On OS X' on Delicious Share 'SSH Weirdness On OS X' on Facebook Share 'SSH Weirdness On OS X' on Google Buzz Share 'SSH Weirdness On OS X' on Google Reader Share 'SSH Weirdness On OS X' on LinkedIn Share 'SSH Weirdness On OS X' on Email

One Response to “SSH Weirdness On OS X”

  1. james says:

    I ran into this,but the cause was a bit different. Since this was the first hit for osx + the error message, I’ll add my solution here.

    I use quite a few ssh keys. When ssh logs into a client, it iterates through all the available keys and attempts them. If this number exceeds that allowed by the ssh servers MaxAttempts setting the user never gets an opportunity to enter their pass and is instead presented with this error message.

    The solution is to create an ssh config entry that directs ssh to only use explicity set IdentityFiles, e.g.

    ~/.ssh/config

    Host SomeHostAlias
    Hostname ip.or.fqdn.com
    IdentitiesOnly yes

    You can set the option globally with:

    Host *
    IdentitiesOnly yes