root has no shell

[Juan Gonzalez_2]

A person left and I ended up geting stuck with maintaining the server. When I try to login as root I get kicked off the server with a message saying No shell. I looked at the passwd file and the entry for root is root:x:0:3::/:/sbin/ksh

Is there any way I can change the root password entry without having to bring down the server. This is a production server.

[Geoff Wild · Accepted solution]

If you have a backup, which has the /etc/passwd with:

root:x:0:3::/:/sbin/sh

Then you could restore it - else you will have to boot to single user mode....

Rgds...Geoff

[Uday_S_Ankolekar]

If you have already logged in as root then change root entry in passwd file with /sbin/sh
or login as normal user and then run su , without (-)

If this does not work then you have boot server in single user mode and modify /etc/passwd file.

run vipw to see if passwd file is OK.

Goodluck

-USA..

[Rodney Hills]

Look for another user who has a user number of zero. It is possible the previous admin left a backdoor.

Also see if "sudo" is available. It is possible the previous admin had setup some tools for non-root users.

HTH

-- Rod Hills

[kamal_15]

hi juan
is ksh found in this path?!

try /usr/bin/ksh (default path for ksh in HP)
or
/sbin/sh (but you will logon in shell sh)

and what is your OS?

[Rick Garland]

Unless you have a root (UID=0) session already open, can restore from backup, you will need to reboot the server into single user mode.

[Steven E. Protter]

If you every think about changing the root shell. Think again.

Can't do that, makes the system unstable.

Boot to single user mode.

Interupt at the 10 second prompt after a hard boot, at the console

bo pri

Y (Yes, Interact)


hpux -is

after it boots



mount /var
mount /usr

vi /etc/passwd

Fix it.

NEVER let anyone change the root shell again.

SEP

[Juan Gonzalez_2]

Thanks for the information. Looks like I am going to have to reboot the server.

[RAC_1]

If you have root login at the moment on the server, (or alternate root), I think you can link /sbin/ksh to /sbin/sh

ln -s /sbin/sh /sbin/ksh

Anil

[Bill Hassell]

There is no such file: /sbin/ksh Someone thought this might work but never tested it. You cannot ever have root using a shell that uses shared libraries (programs in /usr/bin use shared libraries). The reason is that in single user mode, there is no /usr directory mounted so neither the program nor the /usr/lib libraries are available. The ONLY entry that can be used for root is /sbin/sh (which is NOT the Bourne shell).

Try using su root (not su - root) to login. This may give you the current shell but with root privilege. This situation is one of the many reasons that you need to install and use sudo in order to fix problems without having to login as root.

[John Atkinson_2]

This was probably done to allow ftp to root. If you need to ftp to root, copy ksh into /sbin. Do an actual copy. Do not soft link it as the original is in /usr which does not mount in single user mode.

This, of course assumes you got back in. I had the same thing happen to me. There was another user with UID 0 so I was able to get back in.

[Bill Hassell]

As mentioned, /usr/bin/ksh is a shared library executable. Everything in /sbin must be in archived library format so copying ksh to /sbin will solve the current problem without a reboot, but /sbin is only for archived library programs. Of course, in order to copy ksh to /sbin, you'll need to be root.

[Florian Heigl (new acc)]

#########################################
If this was done to allow ftp access for root, then this would be the ideal way of fixing it -
#########################################

ftp-get /bin/sh (binary!)
cd /sbin
ftp-put sh with remote name ksh (binary!)
chmod 755 ksh

login, chsh to /bin/sh, test login again, rm /sbin/ksh
put root back into /etc/ftpusers to block login.

Anyone will be pleased to help You find another solution for the issue that would have led to this shell-switch.

###########
and if it was not done for that reason, and You don't get in via ftp then yes, reboot and change shells, but before booting up again ensure there are *tested* backups of the system.
I'd get very suspicious in that situation You're in and would probably use diagnostics to make copies of the disks in vg00 or something like that, before running the startup scripts.
If the system comes up fine, at least get the 'rkhunter' perl script and hp-ux bastille and search for backdoors and rootkits.

the shell change might have been a mistake or a very weird way of saying 'learn to be careful with the box from the beginning' or the point where You have to suspect a classical internal attack and call in authorities.