NON-expiry account

Following command is used to set users password to never expire.

/usr/lbin/modprpw -l -m mintm=0,exptm=0,expwarn=0,lftm=0 ABCD

/usr/lbin/getprpw ABCD
uid=192, bootpw=NO, audid=458, audflg=1, mintm=0, maxpwln=-1, exptm=0, lftm=0, spwchg=Sun Dec 3 02:36:53 2006, upwchg=-1, acctexp=-1, llog=-1, expwarn=0, usrpick=DFT, syspnpw=DFT, rstrpw=DFT, nullpw=DFT, admnum=-1, syschpw=DFT, sysltpw=DFT, timeod=-1, slogint=Sun Dec 3 02:59:41 2006, ulogint=-1, sloginy=tty, culogin=-1, uloginy=-1, umaxlntr=-1, alock=NO, lockout=0000000

ABCD is the user account.

HP-UX Secure Shell - Setting up SSH to Use Public Key Authentication.

HP-UX Secure Shell - Setting up SSH to Use Public Key Authentication.

Overview

Using public key authentication while setting up Secure Shell (SSH) on HP-UX systems

Procedures

Public key authentication is a good choice for user authentication since it provides some of the best security available. The steps outlined below assume that both the client and server are running the HP-supplied version of Secure Shell. This version will interoperate with other platforms and implementations but specific configuration options may differ. On the client node: Generate a key pair using the SSH-keygen program while logged in with the regular user's ID. Generate at least one key pair. If SSH-2 protocol is being used (the default on HP-UX), key types of either DSA or RSA may be chosen. If SSH-1 protocol is going to be used, a key type of RSA1 will need to be used. Generate the keys as:      # ssh-keygen -t dsa        Generating public/private dsa key pair.       Enter file in which to save the key (/home/flyingfox/.ssh/id_dsa):       Enter passphrase (empty for no passphrase):       Enter same passphrase again:       Your identification has been saved in /home/root/.ssh/id_dsa.       Your public key has been saved in /home/root/.ssh/id_dsa.pub.       The key fingerprint is:       a9:11:f6:af:31:45:31:fc:52:25:a1:52:da:bc:0e:3e flyingfox@lei Take the default file name for the location of the key(s) by hitting the Enter key . It is also suggested to use a passphrase to protect the private key. The passphrase may be any string of characters or a phrase, including white space. The SSH-keygen program may be run once for each key type that needs to be generated. Unless there is a reason to use non-default values, just generate the single DSA key pair as shown above. The public key that was just generated must be copied over to the SSH server. The public key will have been placed in a file as noted by the SSH-keygen program but with a .pub at the end of the name. Example: /home/flyingfox/.ssh/id_dsa.pub . Any mechanism may be used to get the key over to the SSH server. For example:    $scp /home/flyingfox/.ssh/id_dsa.pub server:/home/flyingfox/client.key       wilfor@gozo's password:       id_dsa.pub           100% |*****************************|   601       00:00     $ On the server node: Append the client's public key copied over in step 2 above to the end of the file: # cat /home/flyingfox/client.key >> /home/flyingfox/.ssh/authorized_keys If the file or the .ssh subdirectory does not exist, they must be created manually. The SSH daemon (sshd) on the server will check the owner and permissions on the authorized_keys file to be sure it is writable only by the user (and root). If it is not safe , then sshd will ignore the file. A mode of 600 should work well. The SSH server will also check the modes and owners of all the directories in the path to the authorized_keys file to be sure that they are safe as well. Typically, /home should be writable only by root, and the users home directory and the .ssh subdirectory should be writable only by the user (and root). If both the client and server are set up correctly, then there should be a prompt for the passphrase when connecting from the client to the server via SSH (or scp/sftp). If the private key was not protected with a passphrase, then there will not be any prompt and will automatically log in to the server. If providing a passphrase each time the SSH is run is not desired, it is recommended to use the ssh-agent(1) program to cache the keys for an entire session rather than leave the private key un-protected (null passphrase). Leaving the private key un-protected is a security risk if anyone can obtain a copy of the private key file.

Keywords.

RSA,SCP.

HPUX: Root Password issue.

Root Password issue.

Overview

Root Passwd : After repeat of reseting the password and still Login prompt is not accepting the root passwd.

Procedures

Root Passwd : After repeat of reseting the password and still Login prompt is not accepting the root passwd. [root@Mickey:/sbin/init.d]# #-> /usr/lbin/getprpw root user password file not found: root [root@Mickey:/sbin/init.d]# Root login is not able to accept the root password above error is encounter. [root@Mickey:/tcb/files/auth/r]# #-> /usr/lbin/getprpw root user password file not found: root It was later found that nsswitch.conf file which refer the Database for user ,group, host  etc has been change. Some pplication replace it with formate which is used in Linux System.   /etc/nsswitch.conf  DESCRIPTION       The operating system uses a number of "databases" of information about       hosts, users (passwd), groups and so forth.  Data for these can come       from a variety of sources:  host-names and -addresses, for example,       may be found in /etc/hosts, NIS, LDAP, or DNS.  One or more sources       may be used for each database; the sources and their lookup order are       specified in the /etc/nsswitch.conf file. [root@Mickey:/tcb/files/auth/r]# #-> cat /etc/nsswitch.conf # # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Legal entries are: # #       compat                  Use Libc5 compatibility setup #       nisplus                 Use NIS+ (NIS version 3) #       nis                     Use NIS (NIS version 2), also called YP #       dns                     Use DNS (Domain Name Service) for IPv4 only #       dns6                    Use DNS for IPv4 and IPv6 #       files                   Use the local files #       db                      Use the /var/db databases #       [NOTFOUND=return]       Stop searching if not found so far # # For more information, please read the nsswitch.conf.5 manual page. # # passwd: files nis # shadow: files nis # group:  files nis passwd: centrifydc  compat group: centrifydc   compat hosts:      files dns dns6 networks:       files services:       files protocols:      files rpc:            files ethers:         files netmasks:       files netgroup:       files publickey:      files bootparams:     files automount:      files aliases:        files [root@Mickey:/tcb/files/auth/r]# . RESOLUTION. Format of nsswitch.conf file has been correct as per HPUX System. Then root password issue has been resolved.

Keywords.

Passwd, getprpw

HPUX : Umask wrapper for account

Umask wrapper for account.

Overview

Umask wrapper for account

Procedures

Create a file /usr/local/bin/umask-wrapper with the following contents #!/usr/bin/ksh umask 022 exec /usr/bin/ksh -c "${SSH_ORIGINAL_COMMAND:-$SHELL}" #make the file executable : /usr/local/bin/umask-wrapper and then edit the ssh configuration file /etc/opt/ssh/sshd_config and add the following lines in the end Match User monora ForceCommand /usr/local/bin/umask-wrapper This should help in picking up the desired umask value  for monora user. It will not affect other users as the script will only be executed for monora user.

Keywords.

Sshd, umask.