Re: SSH ignores locked accounts

From: Nico Kadel-Garcia (nkadel_at_comcast.net)
Date: 11/24/03

  • Next message: jpm: "Re: Chroot Environment crazy" 
    Date: Sun, 23 Nov 2003 23:48:24 -0500

    "Darren Tucker" <dtucker@dodgy.net.au> wrote in message
    news:bpri5i$b08$1@gate.dodgy.net.au...
    > In article <ULidnWwof8SrRF2iRVn-gw@comcast.com>,
    > Nico Kadel-Garcia <nkadel@comcast.net> wrote:
    > >
    > >"Darren Tucker" <dtucker@dodgy.net.au> wrote in message
    > >news:bp6gfk$21m$1@gate.dodgy.net.au...
    > >> You can still get this behaviour if that's what you want, just not by
    > >> locking the account.
    > >>
    > >> Set the passwd entry to something that isn't the lock string but isn't
    a
    > >> valid password either. Solaris, for example, uses the literal string
    "NP"
    > >> for "Not Participating". This is mentioned in the sshd man page.
    > >
    > >True! But it's information stored in a rather non-standard way. Many user
    > >configuration tools use their own default string, usually "*", to lock
    > >accounts. And the console "passwd" or "yppasswd" command does not usually
    > >allow the use of pre-encrypted passwords, so you have to either edit
    > >/etc/shadow or /etc/passwd by hand (always dangerous and prone to
    typos!),
    > >or re-rewritng your user configuration tools to add a new "NP" option,
    etc.
    >
    > If you're squeamish about editing /etc/password (or shadow, or whatever)
    > or can't for some reason, you could set a random password, not tell
    > anyone what it is and forget it.
    >
    > I use something like this to generate random passwords I won't reuse:
    > $ dd if=/dev/random bs=6 count=1 | mimencode

    Which works fine on systems with /dev/random, but discards the "mark this
    account as 'LK' to give it an unusable password but still denote it as
    usable or not for SSH accounts" requirement of this discussion.

  • Next message: jpm: "Re: Chroot Environment crazy"