ftp is not working

[223848]

Hi Gurus,

               Today i faced the issue from a user telling that for him ftp is not working  but for his collegues its wokring fine .. He tried to do ftp from his collegues PC also but didnt help  ,... Till yesterday it was wokring . He is sure he didnt change anything in his account and from server side also we didnt make any chnages or any security policies also ...

From the syslog i got the below error

****** ftpd[24642]: FTP LOGIN REFUSED (shell not in /etc/shells) FROM ****[******], to67926
 ***** ftpd[27456]: FTP LOGIN REFUSED (shell not in /etc/shells) FROM ****[******], to67926

In my server there is not /etc/shells file

However i solved the issue in such a way that i asked for the log in details of his collegue for whom its wokring.

Then i found that the shells are differnet, so i changed the shell of that user and he confirmed that its working fine

My doubts are  ,

1) why suddenly he was not able to do ftp,

2) since there is no /etc/shells file  then there should not be any shell restriction for doing ftp

3) the action whihc i performed is correct or not ?

Please help me out on this

Regards

Laiju

[Matti_Kurkela]

When /etc/shells does not exist, the system falls back to a factory-default list of standard shells. Run "man getusershell" to find the default list. If the user's shell was not exactly one of the listed standard shells, ftpd would not allow him to login, exactly as if /etc/shells existed and contained the default list.

The user might not remember the shell change... or if he left his terminal unattended while logged in, someone might have played a prank on him. Or worse: the user may have been tricked to change the shell by executing a malicious script, whose stated purpose was something different and supposedly useful.

What was the user's shell set to when he had the problem? Whatever it was, it obviously behaved similarly enough to the user's default shell to not be noticed. It might have been a malicious program, intended to stay undetected and spy on the user.

[223848 · Accepted solution]

Hi MK,

         Thanks a lot for your answer .

When the problem was happening  his shell was /bin/sh.. This shell is not listed is getusershell...

Shell of the user for whom the it was working is /usr/bin/sh which is listed in getusershell...

Thanks a lot for your answer ...

[Dennis Handly]

>When the problem was happening  his shell was /bin/sh.. This shell is not listed is getusershell...

The same thing happened with me years ago.  I have /bin/ksh so it works over NIS to Linux.

And of course it worked on one system and not another, due to a missing /etc/shells.