Skip navigation

Failed publickey with SSFT

3839 Views 4 Replies Latest reply: Nov 5, 2010 2:40 AM by Patrick Van Nerum2 RSS
Patrick Van Nerum2 Level 1 Level 1 (30 points)
Currently Being Moderated
Sep 27, 2010 1:36 AM
Since last week I have one user who's homedirectory doesn't sync with server side file tracking anymore.
I can completely move his account from his laptop and start with a new fresh homedirectory from the server (Which homedir I also moved for a fresh new one).

It goed wrong with the ssh connection that the filesync deamon starts. In the security logfile I see entry's like: Sep 27 10:08:17 habitat1 sshd[38092]: Failed publickey for user1 from port 49196 ssh2

I've had this problem with this user a couple of times. The only remedy was to create a new user in OD, therefore changing his login name. But this isn't a real solution.

Does anybody have a clue?

With kind regards,

ACSA, Mac OS X (10.6.1)
  • Brian Warsing Level 1 Level 1 (10 points)
    Currently Being Moderated
    Oct 5, 2010 2:30 PM (in response to Patrick Van Nerum2)
    I might take a look at what the server thinks is the user's NFSHomeDirectory is...

    dscl /Search read /Users/the_user NFSHomeDirectory

    This is where the SSFT's sshd looks for the user's public key, but further up the tree like...


    If the value that is returned cannot be accessed by the sshd process, SSFT will fail with the message you described, but without any reason as to why. Furthermore, if the file permissions on the ~/Library/FileSync folders on the server or the client have been changed, it could result in the same error -- SSH doesn't allow world writable or readable private keys, these must be secure.
    Too many to name, Mac OS X (10.6.3)
  • Brian Warsing Level 1 Level 1 (10 points)
    Currently Being Moderated
    Oct 6, 2010 8:45 AM (in response to Patrick Van Nerum2)
    First, thanks for providing that one-liner for testing a user's key pair -- I never considered doing that before but that is sure to come in handy.

    Secondly, this is really strange. A few questions...

    1. What is the setup here? Is this a single XServe serving OpenDirectory and AFP homes?
    2. Are the client and server both Snow Leopard? Do they have the same patch levels?
    3. Is this authentication failure limited to just a single machine, or does it happen on any machine?
    4. If creating a new OD account for the user is a reliable workaround, have you considered inspecting the differences between the bad account and the newly created one?
    5. When you say "I can completely move his account from his laptop" -- do you mean that you purged both portions of the mobile account record (the record in the dslocal node), or just the user's home directory?

    Based on your description, I think it's pretty clear that there's more to this than just an SSH auth failure, it almost sounds as though the local mobile account record, or the user's OD record are malformed. Very strange indeed.
    Too many to name, Mac OS X (10.6.3)


More Like This

  • Retrieving data ...

Bookmarked By (0)


  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.