Re: User?s and Shells
From: Scott Gifford (email@example.com)
- Previous message: Cameron Simpson: "Re: User?s and Shells"
- Maybe in reply to: Brian Hatch: "Re: User?s and Shells"
- Next in thread: Steven J. Sobol: "Re: User?s and Shells"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: "'firstname.lastname@example.org'" <email@example.com> From: Scott Gifford <firstname.lastname@example.org> Date: 21 Dec 2002 03:28:42 -0500
Brian Hatch <email@example.com> writes:
> > I'm wondering why I would want that - until now nobody could give me a
> > good argument although everybody learns to remove the shells :-(
> > * If I give my users a disabled password, they cannot? login via passwd
> > based ssh/ftp/pop3 etc.
> Not true. Say you disable the passwd (put "*" in /etc/shadow
> file, for example) but they have already enabled SSH identity
> authentication so they never use actual password authentication.
> You think they can't log in because there's no legal password,
> but SSH lets them in before it gets there.
In the past, many people have had similar issues using the r*
commands. If the user has a shell and ssh or any of the r* commands
are running, you have to protect the user's home directory from
writing just as diligently as you would have to protect their
passwords, and a nonexistent shell in /etc/passwd provides another
layer of protection.
And it's not just a matter of the user creating a .rhosts file before
their password is disabled. Writing to a home directory is one way to
escalate privileges; for example, your news user was:
. If news has write permission in /etc/news, a bug in your newsserver
that provides only the ability to create arbitrary files owned by news
can suddenly be leveraged into a shell on your system if you have ssh
or r* running and news has a real shell.