--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: ssh: /usr/sbin/nologin used for shell, not present in /etc/shells
- From: Brian Clark <bjclark@helios.unwell.org>
- Date: Fri, 13 Apr 2007 16:20:06 -0400
- Message-id: <20070413202006.16423.42132.reportbug@helios.unwell.org>
Package: ssh
Version: 1:4.3p2-9
Severity: minor
The openssh install process should detect whether /usr/sbin/nologin
isn't present in /etc/shells, and it should add it if necessary if ssh
is going to use /usr/sbin/nologin as its shell.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.34.1-helios
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages ssh depends on:
ii openssh-client 1:4.3p2-9 Secure shell client, an rlogin/rsh
ii openssh-server 1:4.3p2-9 Secure shell server, an rshd repla
ssh recommends no packages.
-- debconf information:
* ssh/privsep_tell:
ssh/insecure_rshd:
ssh/privsep_ask: true
ssh/ssh2_keys_merged:
* ssh/user_environment_tell:
* ssh/forward_warning:
ssh/insecure_telnetd:
ssh/new_config: true
* ssh/use_old_init_script: true
* ssh/protocol2_only: false
ssh/encrypted_host_key_but_no_keygen:
* ssh/run_sshd: true
* ssh/SUID_client: true
ssh/disable_cr_auth: false
--- End Message ---
--- Begin Message ---
tags 419132 wontfix
thanks
On Mon, Dec 28, 2009 at 06:43:51PM +0059, Han Boetes wrote:
> The point of /sbin/noreply is to put up a decent message telling
> the guy who logged in that the account is disabled and then return
> 1. Read the code and see for yourself. It's not more or less
> secure than /bin/false, it's just less annoying than logging in
> and getting kicked out again without an errormessage. That's what
> it's meant for.
I agree that the point of nologin was not to gain security. For the
history, see this bug:
http://bugs.debian.org/366541
The point of using nologin as ssh's shell as per that bug report was
primarily to get improved system logging, not necessarily to provide a
more informative error message to the person trying to log in as the
sshd user. I'm not actually all that bothered about this because at
least login(1) produces other syslog messages in this case, but it seems
pretty harmless to have nologin in there as well.
As it happens, though, I just tested this, on a system that of course
doesn't have nologin in /etc/shells. If you don't have a password set
for sshd, which of course is the default, then it makes no difference
what the shell is because login never gets that far. But, if you're
misguided enough to set a password, then a user attempting to log in as
sshd gets "This account is currently not available." on the login tty,
and auth.log gets "nologin: Attempted login by sshd on /dev/tty1". This
seems like a pretty clear improvement over /bin/false to me.
> But if /sbin/nologin is not in /etc/shells you get the identical
> behaviour from using /bin/false.
No, you don't. login(1) does not consult /etc/shells at all, as far as I
can see and test. su(1) consults it but only to disable the
-m/-p/--preserve-environment option. chsh(1) prevents you from changing
your login shell if it isn't listed in /etc/shells.
Not being listed in /etc/shells doesn't prevent you from logging in. If
it did, all manner of interesting schemes involving users with special
restricted shells would break, such as the trick to do anonymous CVS
over SSH rather than having to use pserver, and no doubt other more
modern things too. The point of having a shell that's not in /etc/shells
isn't that you can't use it to log in, but that it's not a normal shell
and that users with that shell set can't change it to something else.
Adding nologin to /etc/shells would be very likely to open security
vulnerabilities, and I will not do it.
Anyway, I hope the explanation above clarifies the situation, so I'll
close this bug with no other action. Sorry for my delay in responding to
this.
Regards,
--
Colin Watson [cjwatson@debian.org]
--- End Message ---