password always disabled in trusted server

[apple]

Dear HPUX Gurus,
Our vpars root password always disabled. each and every time we want to recover the root password, i need to go to management port and issue this command: # /usr/lbin/modprpw -k root
we implement hp system insight manager to collect all the information from this vpar, could it be the cause? how can i disable this password disable or increase the number of logins before it disabled? what is the best practise. hope to hear from you

[Khairy · Accepted solution]

hi,

usually, after a system convert to a trusted. It is recommended to run the following command:

# /usr/lbin/modprpw -V

This will avoid accounts expiration. But in this case, it seems maybe your root password expired.

After a successful root password reset, go to multiuser mode and execute :

# /usr/lbin/modprpw -m lftm=0,exptm=0,mintm=0,acctexp=-1 root

This will ensure root password never expire.

Pls assign some points if this answer yr questions..Thanks!

[apple]

# /usr/lbin/modprpw -V
what this command do? what is the effect? will assign good points, very great reply. thanks a lot

[apple]

i have run the command to set the root password to non-expiry, but it still give me the account is disabled as attached. hope to hear frm you

[Robert Fritz]

Note that there can be interaction with SIM.

SIM uses ssh and WBEM to auto-discover hosts. If it was configured with a default password to try (that is invalid for a given host), it can cause multiple authentication failures... which in turn lock the SIM-configured-default account on that host, when that account (in this case root) is configured to lock that account after a certain number of failures.

I'd suggest filing a defect with your support rep, if this causes problems for you.

-R

[apple]

Dear HPUX Gurus,
how can we check the SIM-configured-default account on the SIM host?
even for others non-root id we hit the account disabled thingy. how can we control this? would really appreciate your further advice. thanks a lot

[Duncan Edmonstone]

Well first, to confirm that SIM is truly the source of the problem, use the lastb command on the system which keeps getting its accounts locked to determine the source of the problem:

lastb -R

should show you failed login attempts and their source IP address.

Be careful about posting the output of lastb here though, as it can contain passwords (when people type in their password rather than their username in response to the login prompt)

HTH

Duncan

[apple]

unforunately, i tried to login to HP SIM, but the root id for HP SIM also disabled.
we don't have management port to enable back the id. i think the system is too secured
ive logged off from the vpar that is always disabled, after 3 mins i want to log in disabled again. i need to enable back frm our superdome management port. huhu

[apple]

dear HPUX gurus,
the output from lastb -R from vpar that is always having root disabled. can't find any catchy intruders. do we need to issue the command from the HP SIM itself? hope to hear from you. thanks a lot
root ssh:notty 10.120.0.180 Thu Mar 13 17:27
root ssh:notty 10.120.0.180 Thu Mar 13 15:45
root ssh:notty 10.120.0.180 Thu Mar 13 15:15
root console Thu Mar 13 13:11
root ssh:notty 10.120.0.180 Thu Mar 13 13:11
root ssh:notty 10.120.0.180 Wed Mar 12 11:09
e console Tue Mar 11 18:54
root ssh:notty 10.120.0.146 Fri Mar 7 18:52
root ssh:notty 10.120.0.146 Fri Mar 7 18:48
root ssh:notty 10.120.0.146 Fri Mar 7 18:48
root ssh:notty 10.120.0.146 Fri Mar 7 18:48
root ssh:notty 10.120.0.146 Fri Mar 7 18:48
root ssh:notty 10.120.0.146 Fri Mar 7 18:45
root ssh:notty 10.120.0.180 Fri Mar 7 18:28

[Duncan Edmonstone]

No, running lastb on the SIM server itself would only show you where there have been failed logins to the SIM server. Have you identified what the hosts mentioned in the output you posted are:

10.120.0.180 and 10.120.0.146

They seem to be the source of the failed logins which are locking your account.

HTH

Duncan

[apple]

dear hpux gurus,
Sir, I run the last the command in the server itself, one of the ip is mine and another one is another system admin ip. the disabled thing is due to these ip is it? we hv set the
Unsuccessful Login Tries Allowed to 5 times from SAM. appreciate your advice on the best configuration to mitigate our root password from disable too frequent..
hope to hear frm you. thanks a lot

[apple]

dear HPUX gurus,
additional output from server:
our SIM ip is 10.103.1.100
i got this entries from our syslog, is it because of the authentication to SIM failed and cause the root password to be disabled?

Mar 13 19:35:18 emu sshd[20640]: Did not receive identification string from 10.1
03.1.100
Mar 14 00:10:54 emu sshd[8956]: Did not receive identification string from 10.10
3.1.100

errmm

[Bill Hassell]

This is a 'feature' of ssh when it is run in batch (automated) programs and scripts. If ssh is configured properly with public keys so that no password is required, then all will be well. But if the public key has not been stored on the remote system (or possibly corrupted), then in batch mode, ssh will keep trying to supply a null password until the account is locked out. In batch mode there is no one to answer the password question so increasing the retry count won't help -- batch mode will try forever.

While it is possible to configure your ssh daemon to only allow public key and not fallback to asking for a password, this may create a problem in logging in when there has been a public/private key change.

So you need to setup public keys between all the machines that will use ssh communication. This is done for specific users (which should be documented in the Insight Manager documents.

[apple]

very interesting reply.
quoted: "If ssh is configured properly with public keys so that no password is required"
may be the authentication to our SIM has caused this thing.
how can we configure the public keys to our HP SIM so that no password is required?
thanks a lot

[Bill Hassell]

Configuring public keys is fairly easy. This is how to do it for two HP-UX systems:

1. Given a specific user (user1 for example) on the local machine, check to see if the $HOME/.ssh directory exists. If not, have the user run the command:

ssh-keygen -t dsa

and answer all questions with just a carriage return. Now there will be a .ssh directory with a few files.

2. On the remote system, login as the target user and setup .ssh as in step 1. Set umask to 077 and copy the public key from the local machine (ftp, scp, etc) to the remote machine's $HOME directory. Then put the public key into place and remove the temporary copy:

cat $HOME/id_dsa.pub >> $HOME/.ssh/authorized_keys
rm $HOME/id_dsa.pub

This can be done with vi and copy/paste but the key is one long line and terminal emulators as well as vi settings can put extra spaces in the line. The authorized_keys file will bea public key from one or more systems, allowing passwordless access. Make sure .ssh and the contents are secure:

chmod og-rx $HOME/.ssh $HOME/.ssh/*

Now from the local system, test using ssh:

ssh remote_system uname -a

The command should complete without a password prompt. If ssh asks for a password then the authorized_keys file may not have the public key, or the permissions on the files and .ssh directory are too open.

[apple]

great. but is it safe if i use root id?

[apple]

i just checked the server, there is .ssh directory inside the /.

attached is the screen capture. thanks a lot

[Bill Hassell]

> i just checked the server, there is .ssh directory inside the /.

So this means that root's HOME is /...not a good place at all but that is a subject covered in other threads. Check your local system for the same .ssh directory. Now if you are talking different platforms (Insight Manager runs on several platforms), the location of the local public key will be different. But the concept is the same and you just need to add the local public key to the remote .ssh/authorized_keys file.

[apple]

>> So this means that root's HOME is /...not a good place at all but that is a subject covered in other threads.
interesting, sir, where can i find the thread?
i was not able check the file from to our SIM server (the operating system is HPUX) as our SIM root password is disabled. we don't have management port yet to enable back the root password. last time HP engineer has helped us to go using serial cable directly to his notebook.

[Bill Hassell]

>> subject covered in other threads.
> interesting, sir, where can i find the thread?

Alas, I could not locate it even with Mr. Google's help, so here it is again...

Almost all Unix systems have been shipped with root's $HOME directory located in /, the worst possible location for the most powerful user on the system. As syadmins, we often do far, far too many things as root and eventually, we make a mistake. Consider this short set of commands:

# cd /temp
# rm -r *

This has just destroyed the ENTIRE computer system!! The problem is that root just logged in and is sitting in / (the bad place). The cd command actually failed because there is no /temp in a standard HP-UX system (it was a spelling error on the keyboard). But the poor sysadmin was on the phone and overlooked the small message:

sh: /temp: not found.

That was a critical message and the poor sysadmin then became a member of the "rm -r *" Club (because the root user was in /) by removing all the files and directories in / (which is the entire computer).

If root's HOME directory was moved to /root then the mistake would be slight and the files recovered from the previous night's backup tape.

The / directory should NEVER contain any files, just directories. And the directories must only be mountpoints found in /etc/fstab with the exception of /sbin and /etc. Now will the system work with root's HOME = /? Yes it will. Will there be a big mistake someday? Probably.

Steps to move root's HOME:

1. mkdir /root
2. chmod 700 /root
3. mv .profile .ssh .exrc .sh_history Mail /root
4. change the root login to use /root for HOME. Use vipw or sam to make the change.
5. Do not close the current window! Open another window and login as root. Look at the files and check the current directory:

pwd
echo $HOME

If all is well, check / again for any additional files that need to be moved.


> we don't have management port yet to enable back the root password. last time HP engineer has helped us to go using serial cable directly to his notebook.

If this is a production server, you need to get yourself a simple terminal. HP terminals such as the 700/92 sell for as little as $50-100 USD.