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 <email@example.com>
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 <firstname.lastname@example.org>
putting LK in front of the passwd will be fine to lock it.
Andrew M TOWNSEND <ATOWNSEND@doleta.gov>
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" <David.Markowitz@litronic.com>
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 <email@example.com>
In some UNIX systems, you can just replace the "x" character to
"*" in the second field of passwd. Try it.
"Franczyk, Gary" <firstname.lastname@example.org>
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 <email@example.com>
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 <firstname.lastname@example.org>
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 <email@example.com>
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 <firstname.lastname@example.org>
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
Jim Bacon <email@example.com>
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 <firstname.lastname@example.org>
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