Hi,

To reset password in unix, the system will prompt 2 times for entering
the new password. The first time is to enter the new password and the
second time is to confirm the new password of the account. It is
tedious to perform this when there is a huge volume (>100) of user
accounts. Is it possible to write a perl script that read from a file
that contain the password of the user and automate this?

Any pointer is very much appreciated. Thanks in advance.


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

--90e6ba4fc2326ba04604a23fba1d
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 30, 2011 at 17:22, dolphin <yc282004 [at] yahoo.com.sg> wrote:

> Hi,
>
> To reset password in unix, the system will prompt 2 times for entering
> the new password. The first time is to enter the new password and the
> second time is to confirm the new password of the account. It is
> tedious to perform this when there is a huge volume (>100) of user
> accounts. Is it possible to write a perl script that read from a file
> that contain the password of the user and automate this?
>
> Any pointer is very much appreciated. Thanks in advance.
>
> You will need the Expect module from CPAN.

Ken Wolcott

--90e6ba4fc2326ba04604a23fba1d--

--0015174ff312fcc3a704a2400326
Content-Type: text/plain; charset=ISO-8859-1

On May 1, 2011 7:24 PM, "dolphin" <yc282004 [at] yahoo.com.sg> wrote:
>
> Hi,
>
> To reset password in unix, the system will prompt 2 times for entering
> the new password. The first time is to enter the new password and the
> second time is to confirm the new password of the account. It is
> tedious to perform this when there is a huge volume (>100) of user
> accounts. Is it possible to write a perl script that read from a file
> that contain the password of the user and automate this?
>

Sense the beginning of time it has been standard policy for non-root has to
confirm passwd (this might be in pam now) or 'sudo passwd <user>'.

To be on topic, use Unix::Password (IIRC). Either way, does your upstream
provider block Google? If not, head over there and try 'cpan passwd. If you
look, you might even find some full examples of what you're trying to do -
its a pretty popular thing to do.

If you want some fun, go download the gnu base util package and just reverse
engineer passwd.c (<500 lines IIRC)

> Any pointer is very much appreciated. Thanks in advance.
>

*pointer = Google.com
Error pointer.....
:)

--0015174ff312fcc3a704a2400326--

At 5:22 PM -0700 4/30/11, dolphin wrote:
>Hi,
>
>To reset password in unix, the system will prompt 2 times for entering
>the new password. The first time is to enter the new password and the
>second time is to confirm the new password of the account. It is
>tedious to perform this when there is a huge volume (>100) of user
>accounts. Is it possible to write a perl script that read from a file
>that contain the password of the user and automate this?

I do this once a year to update a set of passwords on a set of hosts
using a Perl script I wrote.

The procedure:

Manually change the password for all relevant accounts on one system.
Copy the password file (/etc/shadow on my Red Hat Linux systems) to a
file server accessible to all systems.
Place a copy of the script on the same server.
Log into to each system as root and run the script, which parses the
new password file and replaces the old encrypted passwords on the
target system with the new, encrypted passwords from the server copy
file.
Clean up by erasing the new password file and script from the server.
Done!

Password files are easy to parse, so I have never felt the need to
use a module.

You have to be very careful since you are running a script as root.
My program reads the local password file, reads the common password
file, writes a new local password file, runs the diff utility on the
old and new local files, and displays the result to the user, prompts
the user to proceed (or abort), then renames the old local file as a
backup, and renames the new local file as /etc/shadow.



--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

jim, you setup your boxes a certain way to make sure this doesn't fail?

On Sun, May 1, 2011 at 10:17 PM, Jim Gibson <jimsgibson [at] gmail.com> wrote:
> At 5:22 PM -0700 4/30/11, dolphin wrote:
>>
>> Hi,
>>
>> To reset password in unix, the system will prompt 2 times for entering
>> the new password. The first time is to enter the new password and the
>> second time is to confirm the new password of the account. It is
>> tedious to perform this when there is a huge volume (>100) of user
>> accounts. Is it possible to write a perl script that read from a file
>> that contain the password of the user and automate this?
>
> I do this once a year to update a set of passwords on a set of hosts using a
> Perl script I wrote.
>
> The procedure:
>
> Manually change the password for all relevant accounts on one system.
> Copy the password file (/etc/shadow on my Red Hat Linux systems) to a file
> server accessible to all systems.
> Place a copy of the script on the same server.
> Log into to each system as root and run the script, which parses the new
> password file and replaces the old encrypted passwords on the target system
> with the new, encrypted passwords from the server copy file.
> Clean up by erasing the new password file and script from the server.
> Done!
>

so, the problems i see with this:
1. password schema - newer systems use sha whereas older systems use md5.
2. seed - i 'think' pam with sha allows seeds - if the seeds aren't
the same, you break stuff this way.
3. don't put a password file on another machine unencrypted. that has
all sorts of 'not good' written all over it.

> Password files are easy to parse, so I have never felt the need to use a
> module.
>

yeah, he could look at what pam is using (or maybe something else) and
use one of the crypt:: modules to write the hash, but...

> You have to be very careful since you are running a script as root. My
> program reads the local password file, reads the common password file,
> writes a new local password file, runs the diff utility on the old and new
> local files, and displays the result to the user, prompts the user to
> proceed (or abort), then renames the old local file as a backup, and renames
> the new local file as /etc/shadow.
>

hummm, i'm sure there's a way for a user to poison a password file so
that when you parse it, some evil happens. maybe make the full name
field 'rm -rf /' or maybe unlink something... just saying system calls
like that need to be thought out pretty carefully.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

At 10:46 PM -0400 5/1/11, shawn wilson wrote:
>jim, you setup your boxes a certain way to make sure this doesn't fail?


No. The systems are plain vanilla Red Hat Linux (old versions because
they run proprietary software).

>
>so, the problems i see with this:
>1. password schema - newer systems use sha whereas older systems use md5.
>2. seed - i 'think' pam with sha allows seeds - if the seeds aren't
>the same, you break stuff this way.
>3. don't put a password file on another machine unencrypted. that has
>all sorts of 'not good' written all over it.


It doesn't matter what encryption scheme the systems are using, as
long as they all use the same one. I am distributing the encrypted
versions of the passwords from one machine (the master) to the rest.
I am not generating the encrypted passwords myself.

>
>hummm, i'm sure there's a way for a user to poison a password file so
>that when you parse it, some evil happens. maybe make the full name
>field 'rm -rf /' or maybe unlink something... just saying system calls
>like that need to be thought out pretty carefully.


These systems are not on the internet. When I am changing the
password files, I am the only user on the system. My program is not
making any system calls. It is modifying the password file directly
with simple string replacement.

--
Jim Gibson
Jim [at] Gibson.org

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Mon, May 2, 2011 at 08:17, Jim Gibson <jimsgibson [at] gmail.com> wrote:
>
> At 10:46 PM -0400 5/1/11, shawn wilson wrote:
>>
>> jim, you setup your boxes a certain way to make sure this doesn't fail?
>
>
> No. The systems are plain vanilla Red Hat Linux (old versions because the=
y run proprietary software).
>
>>
>> so, the problems i see with this:
>> 1. password schema - newer systems use sha whereas older systems use md5=
..
>> 2. seed - i 'think' pam with sha allows seeds - if the seeds aren't
>> the same, you break stuff this way.
>> 3. don't put a password file on another machine unencrypted. that has
>> all sorts of 'not good' written all over it.
>
>
> It doesn't matter what encryption scheme the systems are using, as long a=
s they all use the same one. I am distributing the encrypted versions of th=
e passwords from one machine (the master) to the rest. I am not generating =
the encrypted passwords myself.
>
>>
>> hummm, i'm sure there's a way for a user to poison a password file so
>> that when you parse it, some evil happens. maybe make the full name
>> field 'rm -rf /' or maybe unlink something... just saying system calls
>> like that need to be thought out pretty carefully.
>
>
> These systems are not on the internet. When I am changing the password fi=
les, I am the only user on the system. My program is not making any system =
calls. It is modifying the password file directly with simple string replac=
ement.

Jim;

=A0 It looks like you have a great working system for annually forcing
the change of UNIX passwords in a systematic manner, but it would
definitely not be good to emulate your system in the general case
because very few people on this list (I'm betting here) are in such a
situation, as you have described in your answer to Shawn.=A0 Your
script(s) work almost flawlessly without the controls normally very
necessary because you have externally controlled the conditions so
thoroughly.=A0 Therefore your solution is definitely not one that can be
emulated generally.

IMNSHO,
Ken Wolcott

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

--0016e6db6c05f0610c04a24f8393
Content-Type: text/plain; charset=ISO-8859-1

On May 2, 2011 2:14 PM, "Kenneth Wolcott" <kennethwolcott [at] gmail.com> wrote:
>
> It looks like you have a great working system for annually forcing
> the change of UNIX passwords in a systematic manner, but it would
> definitely not be good to emulate your system in the general case
> because very few people on this list (I'm betting here) are in such a
> situation, as you have described in your answer to Shawn. Your
> script(s) work almost flawlessly without the controls normally very
> necessary because you have externally controlled the conditions so
> thoroughly. Therefore your solution is definitely not one that can be
> emulated generally.
>

This is almost certainly ot here but there are very popular solutions for
doing this that are most certainly more fault tolerant and secure. I submit
ldap, nis, and ypbind (in order of preference).

Jim might be working with systems that are normally kept offline (metal
detectors and chemical monitoring come to mind) where this might not be a
viable solution. Or there are political reasons (probably both). However for
most, this is (badly) reinventing the wheel.

Actually, if anyone thinks of implementing security on their own, they will
probably fail BADLY. I can think of two examples off hand and probably find
at least a dozen more public examples where this has happened. So, if you
are dealing with access control (passwords apply here), databases, web
design, and physical access, think very long (and I do mean long) if you are
considering not using a prebuilt api.

--0016e6db6c05f0610c04a24f8393--

On May 2, 11:51=A0pm, ag4ve... [at] gmail.com (shawn wilson) wrote:
> On May 2, 2011 2:14 PM, "Kenneth Wolcott" <kennethwolc... [at] gmail.com> wrot=
e:
>
>
>
> > =A0 It looks like you have a great working system for annually forcing
> > the change of UNIX passwords in a systematic manner, but it would
> > definitely not be good to emulate your system in the general case
> > because very few people on this list (I'm betting here) are in such a
> > situation, as you have described in your answer to Shawn. =A0Your
> > script(s) work almost flawlessly without the controls normally very
> > necessary because you have externally controlled the conditions so
> > thoroughly. =A0Therefore your solution is definitely not one that can b=
e
> > emulated generally.
>
> This is almost certainly ot here but there are very popular solutions for
> doing this that are most certainly more fault tolerant and secure. I subm=
it
> ldap, nis, and ypbind (in order of preference).
>
> Jim might be working with systems that are normally kept offline (metal
> detectors and chemical monitoring come to mind) where this might not be a
> viable solution. Or there are political reasons (probably both). However =
for
> most, this is (badly) reinventing the wheel.
>
> Actually, if anyone thinks of implementing security on their own, they wi=
ll
> probably fail BADLY. I can think of two examples off hand and probably fi=
nd
> at least a dozen more public examples where this has happened. So, if you
> are dealing with access control (passwords apply here), databases, web
> design, and physical access, think very long (and I do mean long) if you =
are
> considering not using a prebuilt api.

Expect is the best language for this. We use it for the same purpose
(bulk user password change). The script would

1. login as normal user to the system using SSH ( from some
controlling or centralized system).
2. su as root user by providing root pass
3. change password of particular user ( or get back with any result).

Since all the arguments,

user to login
password for login user
root password
user to change password
password to change

are passed as arguments, its not stored any where.

Hope this helps. find the script below

# This script is to change a AIX System user pasword, through
telnet login.
#
# Usage:
# <login_user> - user id to login for passwd change
(root)
# <login_pass> - login user password
# <userid> - userid for which password to be
changed
# <newpasswd> - New password for userid <userid>
# <rootpasswd> - Root password for su -
#
# Assumptions:
# * telnet client progam available at /bin/telnet in local system
# * Telnet is enabled in the AIX Server <---- CHANGE THIS TO SSH
# * normal user is used to login to the server
# * shell prompts always derives to "# " or "$ " format.
# * Other errors are throwed appropriately.


if { $argc !=3D 6 } {
send_user " <login_pass> - login user password\n" ;
exit 1;
}

set serverip [lindex $argv 0]
set ruser [lindex $argv 1]
set rpass [lindex $argv 2]
set userid [lindex $argv 3]
set newpasswd [lindex $argv 4]
set root_password [lindex $argv 5]

set shell_prompt ".*(#|\\$) *"
set login_prompt "(.*login: )"
set passwd_prompt "Password: "
set invld_login "invalid login.*"
set su_prompt "root's Password: "

#send_user "$serverip $ruser $rpass $userid $newpasswd\n" ;
exp_internal 0
set timeout 5

set retcode 0
send "$ruser\r" ;
expect {
$passwd_prompt {
}

expect {
-re $invld_login {
send_user "Wrong login user ($ruser) password. Exiting
\n" ;
}
-re $shell_prompt {
send_user "Logged in successfully\n"
# Start Task to do in the AIX Server
send "su - \r" ;
expect {
-re $su_prompt {
send "$root_password\r" ;
expect {
-re ".* denied" {
}
}
}
expect {
}
expect {
-nocase -re "New password: " {
send "$newpasswd\r"
expect -nocase -re "new password again: *" {
send "$newpasswd\r"
expect -re $shell_prompt {
send_user "Password for user
$userid successfully changed\n" ;
send "exit\r"
set retcode 0 ;
}
}
}
-nocase -re "does not exist" {
send_user "User $userid not exist in system
\n";
set retcode 1
exit $retcode
}
timeout { send_user "Error Occured while changing
password\n" ; set retcode 1 }
eof { send_user "Error Occured while changing
password\n" ; set retcode 1 }
}
# End Task
}
eof { send_user "Shell prompt not appeared\n"; set retcode
2 }
timeout { send_user "Timeout happened while waiting for Prompt
\n" ; set retcode 3 }
}
}
timeout { send_user "Connection to $serverip failed. Login
Prompt not appeared\n" ; set retcode 1 }
eof { send_user "Connection to $serverip failed. Login
Prompt not appeared\n" ; set retcode 1 }
}

#send_user "\nExiting at last with Retcode: $retcode\n";
exit $retcode


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/