If you have to change the password for a user, and you have a need to script this, for example if you have the password for multiple users, or on several different servers, then here's an easy way to change the password for a user, without having to type the password on the command line prompt:

# echo "user:password" | chpasswd

Sudosh is designed specifically to be used in conjunction with sudo or by itself as a login shell. Sudosh allows the execution of a root or user shell with logging. Every command the user types within the root shell is logged as well as the output.

This is different from "sudo -s" or "sudo /bin/sh", because when you use one of these instead of sudosh to start a new shell, then this new shell does not log commands typed in the new shell to syslog; only the fact that a new shell started is logged.

If this newly started shell supports commandline history, then you can still find the commands called in the shell in a file such as .sh_history, but if you use a shell such as csh that does not support command-line logging you are out of luck.

Sudosh fills this gap. No matter what shell you use, all of the command lines are logged to syslog (including vi keystrokes). In fact, sudosh uses the script command to log all key strokes and output.

Setting up sudosh is fairly easy. For a Linux system, first download the RPM of sudosh, for example from rpm.pbone.net. Then install it on your Linux server:

# rpm -ihv sudosh-1.8.2-1.2.el4.rf.i386.rpm
Preparing...  ########################################### [100%]
   1:sudosh   ########################################### [100%]

# sudosh -i
[info]: chmod 0733 directory /var/log/sudosh

username ALL=PASSWD:/usr/bin/sudosh

$ sudo sudosh
Password:
# whoami
root

# sudosh-replay
Date       Duration From To   ID
====       ======== ==== ==   ==
09/16/2010 6s       root root root-root-1284653707-GCw26NSq

Usage: sudosh-replay ID [MULTIPLIER] [MAXWAIT]
See 'sudosh-replay -h' for more help.
Example: sudosh-replay root-root-1284653707-GCw26NSq 1 2

# sudosh-replay root-root-1284653707-GCw26NSq 1 5

Always watch out for files with the SUID bit set; especially if these are files that are not on the AIX system by default. Before any vendor or application team installs additional software on the AIX system, it may be worth file to run the following command, to discover any files with the SUID bit set:

# find / \( -perm -2000 -o -perm -4000 \) -type f -ls

#include <stdio.h>
#include <time.h>

char *getlogin();

#define LOG_FILE "/tmp/sushilog"

main(argc, argv)
int argc;
char **argv;
{
  char buf[1024], *p=buf;
  int i, t;
  FILE *log;
  char msg[BUFSIZ], *ct, *name;

  *p='\0';
  for (i=1; i<argc; ++i)
  {
    strcpy(p, argv[i]);
    p += strlen(argv[i]);
    if (i < argc-1)
    {
      *p = ' ';
      ++p;
      *p = '\0';
    }
  }

  time(&t);
        ct = ctime(&t);
        name = getlogin();

  setuid(0);

  log = fopen(LOG_FILE, "a");
  if (!log)
    printf("Couldn't open log file!\n");
  else
    {
      sprintf(msg, "SUSHI: %s  %s  %s\n", name, buf, ct);
      fputs(msg, log);
      fclose(log);
      system(buf);
    }
}

################################################
# Make rules                                   #
################################################

all:    sushi

sushi: sushi.o
        $(CC) -o $@ sushi.o

clean:
        rm -f *.o sushi

install:
        cp -p sushi /bin
        chown root  /bin/sushi
        chmod a+rx  /bin/sushi
        chmod u+s   /bin/sushi

################################################
# Source/object rules                          #
################################################

sushi.o: sushi.c
        gcc -c $*.c

# ls -als /bin/sushi
8 -rwsr-xr-x  1 root root 6215 Sep  9 09:21 /bin/sushi

$ /bin/sushi ksh
# whoami
root

/exports/install:
        dev             = "/exports/install"
        vfs             = nfs
        nodename        = fileserver.company.com
        mount           = true
        options         = ro,bg,hard,intr,nodev,nosuid,sec=sys
        account         = false

# mount -o nosuid server:/filesystem /mountpoint

# mount | grep nfs
server   /filesystem   /mountpoint    nfs3   Sep 09 09:30 nosuid

The environment variable EXTENDED_HISTORY in AIX will timestamp your shell history. In ksh, you set it as follows:

# export EXTENDED_HISTORY=ON

# history
888 ? :: cd aix_auth/
889 ? :: vi server
890 ? :: ldapsearch
891 ? :: fc -lt
892 ? :: fc -l

# fc -t

Sudo is an excellent way to provide root access to commands to other non-root users, without giving them too much access to the system.

A very simple command to show you what a specific user is allowed to do:

# su - [username] -c sudo -l
User [username] may run the following commands on this host:
    (root) NOPASSWD: /usr/local/sbin/reset.ksh
    (root) NOPASSWD: /usr/local/bin/mkpasswd
    (root) NOPASSWD: !/usr/local/bin/mkpasswd root

On occasion I have the need to establish trust relationships between Unix boxes so that I can script file transfers. In short, here's how you leverage SSH to do that. Using the example of trying to connect from server "a" to get a file on "b" follow this example:

• Connect to "a".
• Type: ssh-keygen -t rsa
• The default directory for keyfiles will be ~/.ssh/ (if you do not want to be prompted, leave passphrase blank).
• Copy the contents of .ssh/id_rsa.pub (there should only be one line).
• Place this line on "b", in ~/.ssh/authorized_keys.

A very nice command to use when you either want to show someone remotely how to do something on AIX, or to allow a non-root user to have root access, is portmir.

First of all, you need 2 users logged into the system, you and someone else. Ask the other person to run the tty command in his/her telnet session and to tell you the result. For example:

user$ tty
/dev/pts/1

root# portmir -t /dev/pts/1

# portmir -o

If you wish to be able to access an HMC from the command line, without the need of logging in, you can use ssh (secure shell).

Set-up a secure shell connection to your HMC:

# ssh userid@hostname

# scp /tmp/authorized_keys2 hmcuser@hmcsystem:~hmcuser/.ssh/authorized_keys2

# ssh hmcuser@hmcsystem date

First, install OpenSSH and OpenSSL on two UNIX servers, serverA and serverB. This works best using DSA keys and SSH2 by default as far as I can tell. All the other HOWTOs I've seen seem to deal with RSA keys and SSH1, and the instructions not surprisingly fail to work with SSH2.

On each server type ssh someserver.example.com and make a connection with your regular password. This will create a .ssh dir in your home directory with the proper permissions. On your primary server where you want your secret keys to live (let's say serverA), type:

# ssh-keygen -t dsa

# scp ~/.ssh/id_dsa.pub serverB:.ssh/authorized_keys2

# ssh serverB

This describes how to get SSH access to a Linux system on a HP blade system, which requires you to work through the ILO:

First of all, you need to know the ILO IP address. Simply open up an SSH session to this IP address:

# ssh -l ilo-admin 10.250.21.37
ilo-admin@10.250.21.37's password:
User:ilo-admin logged-in to 10.250.21.37
iLO 2 Advanced 1.60 at 16:05:58 Jul 11 2008
Server Name:
Server Power: On

</>hpiLO->

hpiLO-> VSP
Starting virtual serial port
Press 'ESC (' to return to the CLI Session
</>hpiLO-> Virtual Serial Port active: IO=0x02F8 INT=3
[ENTER]
</>hpiLO-> Virtual Serial Port active: IO=0x02F8 INT=3
Red Hat Enterprise Linux ES release 4 (Nahant Update 8)
Kernel 2.6.9-89.ELsmp on an i686
hostname login:

mo1::off:/sbin/mgetty -x 0 -D -s38400 -a /dev/ttyS1

ilo:2345:respawn:/sbin/agetty ttyS1 115200 vt100

# echo "ttyS1" >> /etc/securetty

# kill -HUP 1