#737735 /usr/sbin/nologin shell change breaks SSH authentication in amanda

Package:
amanda
Source:
amanda
Submitter:
Sam Couter
Date:
2014-12-03 15:12:05 UTC
Severity:
normal
#737735#5
Date:
2014-02-05 13:18:39 UTC
From:
To:
Package: base-passwd
Version: 3.5.32

After upgrading base-passwd on the amanda clients, amcheck starts spitting
out messages like the following:

WARNING: fw: selfcheck request failed: tcpm_recv_token: invalid size: "This account is currently not available.\n"

I use the SSH authentication and transport method, which means Amanda uses
SSH to connect to the clients as the backup user to run amandad. I have set
the authorized_keys file for the backup user to force the amandad command,
but this is executed using the login shell.

Setting the shell to /bin/sh makes the error message go away, running
update-passwd brings it back.
#737735#10
Date:
2014-02-05 21:38:41 UTC
From:
To:
Sam Couter <sam@couter.id.au> writes:

I suspect that you have your debconf priority settings set to suppress
prompting.  If you change the shell and then run:

    dpkg-reconfigure base-passwd

and say no to the question of whether you want update-passwd to change the
shell, it will leave it alone and remember that response for all
subsequent upgrades.

You can also use debconf preseeding to set that answer across large
numbers of systems if needed.
#737735#15
Date:
2014-02-06 07:59:06 UTC
From:
To:
Russ Allbery <rra@debian.org> wrote:

This works. Thanks. I had already tried dpkg-reconfigure with low
priority, but not while the shell was changed.
#737735#20
Date:
2014-03-31 16:43:17 UTC
From:
To:
It worries me a bit that this breaks amanda.  I think this is the main
thing holding me back from closing #734946.  Russ, you have more
experience of dealing with security audits that pick this up than I do;
what would you think of flipping the backup user's shell back to
/bin/sh?  I don't see an obvious way to override this for amanda the way
we did for the various things that used su and broke with the change of
default shells.
#737735#25
Date:
2014-03-31 19:14:11 UTC
From:
To:
Colin Watson <cjwatson@debian.org> writes:

It's not a good idea if we can avoid it.

The problem from an audit perspective is that, to support a package that
the vast majority of installations don't use, one is creating a valid
account that an attacker could authenticate to.  Yes, it has a locked
password, but there are various ways that can be bypassed depending on
what the local PAM configuration is.

If Amanda needs a user with a valid shell, it should really be creating
its own _amanda user and using that instead.  I realize that may be easier
said than done.

That said, the new debconf prompting means that I can change the shell for
the backup user (or, more likely, just delete that user entirely) on all
of my systems and have upgrades of base-passwd not revert that change, so
I at least now have a mechanism to avoid audit problems that isn't as
annoying as it was previously.  So I can cope with that.
#737735#30
Date:
2014-08-27 06:47:34 UTC
From:
To:
reassign 737735 amanda
thanks

There's actually #737735 too; I'd just forgotten to usertag it (done
now).  But I think Russ's arguments there are probably sensible, as
usual - reassigning to amanda so they can fix this, but it doesn't look
like we need to block on this, so closing this blocker.

Thanks,
#737735#39
Date:
2014-12-03 15:01:05 UTC
From:
To:
Hi.

Even if amanda is able to fix the issue by using another dedicated user (if I understand correctly the suggested solution), I fear this may break on many users.

FYI, I've then made the suggestion for some release notes addition : see #771925.

Hope this helps.

Best regards,