Disable Logins

[Brian Bientz]

For security reasons, we would like to disable remote logins to certain user accounts (in particular, root and oracle). We want to force people to login using there specific user account and su as necessary.

How can this be accomplished? We are running HP UX 11.00.

[Vincenzo Restuccia]

For root edit /etc/securetty:
CONSOLE=/dev/console.

[Edward Sedgemore]

Create the file /etc/securetty and insert the word console into it. This means root accounts can only use the console to log direct into the server (which means physical machine room access) otherwise they must use their own personal accounts then su - root

[Rob Smith]

In the /etc/securetty file put the work console. That will cause root logons to fail unless they are attempted from the system console. I believe you can do the same thing for the oracle account with that file but I am not 100% positive as to what the syntax would be.

Hope this helps.
Rob

[Steffi Jones_1]

Hello,

Root access can be denied to any port on the system by the use of the /etc/securetty file. If not present (the default), anyone who knows the root password can login as root regardless of their location (modem, DTC port, tty port, network login).

Steffi Jones

[Brian Bientz]

Thanks for the replies. We certainly seem to have the problem solved for root user. Does this same logic apply to other user accounts as well? That is, how can I disable logins to the oracle account?

[Vincenzo Restuccia]

You can see /etc/pam_user.conf and man pam_user.conf.

[Patrick Wallek]

What we have done for oracle is to set the oracle password to something like a *, and then set up sudo to allow the users that need to get to oracle to do that via sudo.

'sudo su - oracle' for example.

You can get sudo at the HP-UX porting center.

[Steven Sim Kok Leong · Accepted solution]

Hi,

After some thinking, I thought of an easy solution to your problem, and that is to make use of the differences in the commands "who am i" and "whoami". In an su situation, "who am i" will report the user you su from while "whoami" will report the user you su to.

In this way, depending on the login shell you are using, you can modify .profile/.cshrc/.login of your Oracle account accordingly to suit your needs.

For example, add the following to the beginning of your oracle's .profile:
=============================================
trap "" 1 2 3
if [ "who am i|awk '{print $1}' != "whoami" ]
then
# this implies an su, thus proceed on
# with the rest of your command executions.
else
# this user must have logged on direct
# without su'ing thus logout this user
logout
fi
trap 1 2 3
=============================================

To prevent your user from modifying his own .profile to workaround it, remember to change the ownership of oracle's .profile to root and chmod 755 the .profile.

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com

[Patrick Wallek]

Here is the link to sudo:

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/sudo-1.6.2b1/

[Joseph C. Denman]

If the users know the oracle passwd anyway, why not just make them part of the dba group and not give them the oracle passwd. Being part of the dba group should give them permissions to do what they need to do? Just a thought...


...jcd...

[Jacques Simon]

Why not just check `tty` in the users profile?!
if test -t 0
then
if [ ! `tty` = "/dev/console" ]
then
...
exit
fi
fi

[Greg OBarr]

You might want to check out ssh (Secure Shell)...very versatile and secure.

http://www.ssh.com

Features listed on web site:

Protects all passwords and data.
Full replacement for telnet, rlogin, rsh, rcp, and ftp.
Fully integrated secure file transfer and file copying. Really cool graphical user interface on Windows.
Automatic authentication of users, no passwords sent in cleartext to prevent the stealing of passwords.
Multiple strong authentication methods that prevent such security threats as spoofing identity.
Authentication of both ends of connection, the server and the client are authenticated to prevent identity spoofing, trojan horses, etc.
Automatic authentication using agents to enable strong authentication to multiple systems with a single sign-on.
Transparent and automatic tunneling of X11 sessions.
Tunneling of arbitrary TCP/IP-based applications, such as e-mail.
Encryption and compression of data for security and speed.
Multiple built-in authentication methods, including passwords, public key, and host-based authentication.
Multiple ciphers for encryption, including e.g. 3DES, Blowfish and the AES candidate TWOFISH.

[Joseph A Benaiah_1]

Brian,

In addition to the use of /etc/securetty and checks in the /etc/profile, I would also comment out the exec service in /etc/inetd.conf. Otherwise a user could enter the following command in from a PC running Exceed or another X server:

rexec -l root "xterm -display :0.0"

This would load up an xterm as root on the host bypassing /etc/profile and roots .profile. Ofcourse, the person running this would have to provide the correct root password.

Cheers,

Joseph.