Re: SSH v3.7.1p2 gotcha: illegal user

From: Darren Tucker (dtucker_at_zip.com.au)
Date: 01/27/04

  • Next message: Burak Bilen: "Re: password file syncing"
    Date: Tue, 27 Jan 2004 14:52:27 +1100
    To: schulz@videotron.ca
    
    

    schulz@videotron.ca wrote:
    > We use passwordless accounts with public_key authentication,
    > mainly for cvs access.
    >
    > We just upgraded to SSH v3.7.1p2, and the all connections
    > were refused, except the few accounts which had been used
    > for real. (this on Linux and Solaris)
    >
    > I sppose it's a feature

    It was mentioned in the 3.7 release notes:
    * Portable OpenSSH:
    [snip]
         - Deny access to locked accounts, regardless of authentication
           method in use.

    > but then it took a few hours to figure out
    > as there doesn't seem to be any precedence.

    The SSH v1 series checked for locked accounts on some platforms
    (including Solaris) going back to approximately 1998. Later patchsets
    of PAM on Solaris will do it too (try setting up a cron job as a user
    then passwd -l the account). For details see:
    http://bugzilla.mindrot.org/show_bug.cgi?id=442

    > Simply changing '!!' (disabled) to '*' solved the problem for us.
    >
    > I didn't track down when the change was made, it could have been
    > there waiting to bite us for a long time.

    It was first in 3.7p1.

    > So here goes (for google to know):
    [snip log]

    You should have read all of the debugging info, or wherever you send
    your sshd logs to via syslog (authlog, maybe?). You would have seen a
    line similar to:

    User [foo] not allowed because account is locked

    > ssh -vvv (this didn't provide a useful clue, though)
    [snip]

    As a general rule, the client will not be told why an authentication
    failed. This is a security Feature.

    -- 
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
         Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.
    

  • Next message: Burak Bilen: "Re: password file syncing"

    Relevant Pages

    • Re: ssh security
      ... what are valid accounts and what are not. ... It's considered axiomatic that security ... > system accounts (and over 99.9% are root, which does not get ssh access ... There are even some bots and apps that attack you from different IP ...
      (Fedora)
    • Re: The single best news for the publishing biz
      ... But since they allow ssh through, the "server of appropriate type" is ... knowledgeable user is likely to have several such accounts. ... actually have accessible shell accounts, the fact that it lets all your ...
      (rec.arts.sf.written)
    • Re: How can I block IP address range with sshd_config
      ... > only log in through ssh. ... would deny access to all hosts in that range. ... >> through sshd using accounts guest and test tried again yesterday. ... as well as reading the comments in the ...
      (Fedora)
    • Re: Hacked mac
      ... Secret accounts? ... Re-install the system using Archive and Install. ... Some would argue that this isn't reasonably safe. ... When you turn ssh back on, either take steps to make sure every ...
      (comp.sys.mac.system)
    • Re: mail program for FC6
      ... And I find the ability to drag messages among folders on different accounts on different machines to be much more convenient than whatever method you might use in mutt to accomplish that. ... it via SSH and putty from any Windows machine - I keep putty and my SSH ... This covers a lot more than email, but another approach to get better access than putty/ssh from a remote machine is with freenx on the fedora side and the NX client locally. ...
      (Fedora)