On Tue, Jul 12, 2016 at 02:55:29PM +0200, to...@tuxteam.de wrote:
> On Tue, Jul 12, 2016 at 03:45:06PM +0300, Reco wrote:
> > On Tue, Jul 12, 2016 at 02:20:38PM +0200, to...@tuxteam.de wrote:
> > > I still think the OP has a point. [...]
>
> > I can think of several 'solutions for the problem', but most of them are
> > either unrealistic or redundant:
> >
> > 1) Change Debian Policy which mandates starting a daemon on package
> > install.
>
> I think this is the wrong alley: Making this a problem of "all daemons"
> renders the problem practically intractable.
>
> While it makes sense to keep a more general solution in sight, sshd
> is in many respects special.
Such as?
> > 2) Add 'AllowGroups ssh' to the stock sshd_config.
> >
> > 3) Add a debconf template to openssh-server package which allows to
> > choose local users for 'AllowUsers' stanza of sshd_config.
> >
> > 4) Block all incoming connections to tcp port 22 by default.
>
> And how about changing the default to "PasswordAuthentication no"?
There are several things that can go wrong here:
1) Headless systems.
PasswordAuthentication=no implies providing either public key or
certificate to the host (let's not go into kerberos-based setups for now).
Doing so via preseed file during the install is tricky, doing so after
the install would require a serial console or physical access to the
local storage. To sum it up - a complication at best.
2) Keypair type.
As of jessie stock sshd allows 6 ('ssh -Q key | grep -v cert') keypair
types, and of those one is secure - ed25519.
Assuming that we don't trust the end user to choose a reasonably strong
password we can safely assume that given the choice the same user will
choose worst keypair type possible (dsa) and "forgets" to
password-encrypt the private key.
Reco
