No shell

[hari jayaram]

When I try to rlogin or telnet from one HP box to another I sometimes get the error message No Shell and the connection is closed. I have to ftp a new password fileto resolve this. Has anybody seenthis problem before

[James R. Ferguson]

Hi:

Make sure the shell you are trying to use is declared in /etc/shells (r-r-r and owned by root).

...JRF...

[hari jayaram]

james I do not have a /etc/shells.

Thanks

[Alan Riggs]

Is something destroying/corrupting the passwd file on the remote server? You state that replacing the passwd file resolves the problem, which makes me think that the shell field in the original passwd file is the cause of the problem. The next time this happens, try saving off the remote passwd file before overwriting and compare the entry for the ID in question.

[James R. Ferguson]

Hari:

Other causes for "no shell" are:

1. A corrupted entry in /etc/passwd for the user receiving the error.

2. Too restrictive $HOME directory permissions -- the directory into which they login must be 75x. If this is OK, check backwards to the root directory which should be 755.

...JRF...

[hari jayaram]

James, Allan

This happens only to root and not to any other user. All users are able to login perfectly without any problems. I have already checked on the passwd files by comparing the corrupted on and a non corrupted one(backups of password files are kept) I could not find any corruption.
Thanks

Regards

Hari

[Alan Riggs]

What shell is being specified for root in /etc/passwd? It should be /sbin/sh -- accept no substitutes.

[hari jayaram]

alan,

It is /sbin/sh.

Regards

Hari

[Kofi ARTHIABAH]

could it be that one of your users/root is changing the shell for root in the passwd file? when the problem occurs again, could you log in as another user, create a copy of the passwd file and THEN compare it to the one what you ftp to the server.

Also note that the permissions on an ftp'ed file by default allows other users to modify it... so an ordinary user can modify the passwd file - you do not want that to happen.

so I would say copy a new version of the passwd file over, make sure that you have permissions of r--r--r-- (ie. chmod 444 /etc/passwd)

mind you, what you have on backups may also have had a problem...

good luck

[James R. Ferguson]

Hari:

Check, also that the permissions on /sbin & /usr & /usr/bin are 755.

...JRF...

[hari jayaram]

James , Kofi,

Thanks For ur replies. Checked out and the permissions look fine on all the directories and file. With regard to changes by users this has happened on multiple boxes in the last few days and on systems which have been running for a year. The users are different on these boxes.
I would like any of your inputs on how an sh in one of the application cron jobs would affect the shell or this particular problem. One of the apps pukes recently added a cron job to these boxes and this is the only change.

Regards

Hari

[Jay Kerley]

Hari,

Jay here looking over the same issues. Another thing that has changed is our use of netvackup from Veritas. Explore this avenue and maybe someone has seen this problem before.

cheers,
Jay

[hari jayaram]

Problem resolved by loading patch PHKL_20356 and associated patches.Problem was due to net backup . Thank you all .