SUMMARY: [simple question] lock and unlock a user

From: Michael Wang (
Date: Thu Jun 17 1999 - 17:21:21 CDT

Thanks for everyone responded. I will first recap the question,
and then list the answers. [...] is my comment. Thanks again.

// Here is what I would like to do:
// There is a FTP user. I do not know if it is still active.
// So I want to lock. If someone calls, then I will un-lock it
// without resetting the passwd. Why not resetting the passwd?
// Because people may automate the FTP and it is hard to go through
// the script to change the passwd.
// I know that I can do "passwd -l" and this will lock the user.
// But then I will lose the original passwd. So I am thinking
// manually put LK in front the encripted passwd, and I can remove
// LK to unlock it. I would like to know how you think about this,
// and why "passwd -l" does not do this. Thanks.

Chad Price <>
  Instead of locking the account, expire the account. This allows one to
  unlock it without password changes.
  [for telnet, if you expire the passwd, then user has a chance to
   change the passwd. I don't know how ftp treats expired passwd.]
Michael Cunningham <>
  putting LK in front of the passwd will be fine to lock it.
Andrew M TOWNSEND <>
  I'd suggest remarking out the original user name in the passwd file,
  making a copy of the line, and putting an asterix in the password
"David L. Markowitz" <>
  That works fine. I use it all the time.
  how about adding them to /etc/ftpusers?
  [did not think in that direction. Thanks.]
Christian Pinheiro <>
  In some UNIX systems, you can just replace the "x" character to
  "*" in the second field of passwd. Try it.
"Franczyk, Gary" <>
  That should work fine... Good idea.
  Test it out and make sure it works first....
  How about writing a script that would simply replace the passwd field with
  an LK and put the username and the original passwd in a temp file. This
  would require a lock and an unlock procedure which could be in the same
  script but called via a command line argument or flag.
  Are you adept enough in scripting to do this?
  [temporary file may represent a problem. how happens if you lock twice?]
Dave McFerren <>
  The way I lock a user is to edit the shadow file and put an & in front of the
  endcrypted passwd. This locks the user (& are not allowed as part of the
  encryption, but you do not lose the encrypted passwd. When he needs to be
  unlocked, I edit the shadow file again, and take out the & in front. It also
  give me a method to parse the file and find out who is locked.
James Ford <>
  1. Munge a script to add a "*" (or whatever) to the end of their password
  entry in /etc/shadow. Password now invalid...however if/when they call
  in, just remove the "*".
  2. Install wu-ftpd on your server and add everyone in your /etc/passwd
  file to /etc/ftpusers - thus not allowing them to ftp into the system. If
  they call and are authorized, then remove their entry from /etc/ftpusers
  and they can get in - all the while your not having to mess with any
  passwords. Plus you get the added bonus of creating restricted FTP
  accounts similar to anonymous FTP...but for real users. Thus you can lock
  them into a specific area of the system.
Marty Bullock <>
  That will work fine. I don't know why the "passwd -l" doesn't do it...
  I've always done it the manual way. You can actually add *any*
  character in front or behind the encrypted password to disable the
Phil Barone <>
  Don't know about passwd -l but we manipulate accounts exactly how you
  thought. Write a script that finds the users entry in passwd or shadow file
  and add LK to the beginning of the encrypted token. Another script to remove
  the lock.
Jim Bacon <>
  If you use the wu-ftpd package with the academ patches, you can simply lock
  out an ftp user by adding the username to a file in /etc that explicitly
  lists users denied ftp access. Saves a whole lot of trouble and it also has
  many other useful features.
Thomas Carter <>
  I'm assuming this is just for "cleaning up" a system. If so, that
  sounds like a good plan to me, jsut remember to follow safety measures
  (make a backup copy of files before editing, etc). If this was
  something you did on a regular basis, I think I would write a script
  that moved the user's /etc/shadow entry to /etc/shadow.lock (or
  something like that), and a script that moved it back if necessary.
  You could also make an at job that sends you email in XX days if the
  user is still in /etc/shadow.lock telling you to delete the user and
  directory (or whatever).

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:21 CDT