Re: openssh-server's default config is dangerous
Hi.
On Tue, Jul 12, 2016 at 02:20:38PM +0200, tomas@tuxteam.de wrote:
> On Tue, Jul 12, 2016 at 03:05:35PM +0300, Reco wrote:
> > Hi.
> >
> > On Tue, Jul 12, 2016 at 11:26:10AM +0200, mwnx wrote:
> > > Currently, after installing openssh-server, anyone can gain access
> > > to any user's account on the system using only the corresponding
> > > user's password. As we know, people do not necessarily use the most
> > > secure of passwords. This will especially be the case if the user
> > > does not expect his computer to be accessible in any way from the
> > > outside.
> >
> > So, you're blaming a perfectly good (and reasonably secure) way of
> > remote access, but somehow assume that weak passwords are ok.
> > By that logic you should not stop there. Why not blame any remote access
> > mechanism that uses PAM for password checking as well?
>
> I still think the OP has a point. I don't know how a solution might look
> which makes sense (a default config with password disabled seems a bit
> strong, TBH), but IMHO it's worth thinking about the problem instead
> of dismissing it off-hand.
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.
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.
But I still fail to understand why one should consider openssh
'dangerous' (when openssh merely does what it's intended to do), but
assume that dropbear, vsftpd and telnetd (to name a few) are somehow
'safe'.
Using openssh in a public environment requires (IMO) paranoid custom
configuration anyway.
Using openssh in a trusted LAN requires (duh!) trust on all participants
of such LAN.
Reco
Reply to: