Hi. On Tue, Jul 12, 2016 at 02:20:38PM +0200, to...@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
