If I can step in I would like to share my experience about the SSH topic. I'm a Systems Administrator, worked in three different companies by now and in all three cases there is always a common problem, among others: users asking, ignoring, misusing, having problem setting up SSH keys. So I would like to make the humble suggestion of not disabling password auth by default for users. You are going to confuse the crap out of normal users. It's easier to explain then how to make a good password by linking https://xkcd.com/936/ then having them understanding ssh keys. Not to talk about the problems about using the SSH agent, proxy commands, rsync from / to servers where you don't have your keys. On my side instead I love to use passwords access instead of SSH keys for servers I don't use frequently or to transfer between two servers. A strong password makes the setup a lot easier than SSH keys (you require the ssh agent and the like, I don't like this usually and I keep my key on my laptop only encrypted and on an encrypted partition). Also if I can't access my laptop I can still work from another place without even touching my backup. I recall most of the passwords by memory even if unique. I can understand disabling root password login by default, looking at how many servers are easily compromised by common or short passwords for user root makes it clear than by default this should be disabled. I'll be annoyed and will enable it again, but it's for the good. To be honest I think part of the fault lies in the most common SSH server / client used: openssh. The doc is a bit confusing, it is easy to misconfigure and when the auth fails the client doesn't really give the user any useful information about the reason. Most of the time I ask the user to show me the output of ssh -v and they solve the problem themselves. And just now the changed the fingerprint hash format, making confusing even for me. Was not trivial to find how to get it in the old format out of the client in Fedora (my servers mostly run Red Hat or CentOS where it is not possible to output the new format). SSH utilities have to become a bit more user friendly before moving to keys by default. This doesn't really solve the password strength problem anyway, since you should encrypt your key with a very strong one eheheh. Returning more on topic. Allowing just 6 chars passwords is just allowing the user to get a bad habit, and sort of legitimate the use of weak (in the broad usage) passwords. Yes "butter" might keep local users away from your PC, but if you just get used to longer passwords for everything, and you need to do that anyway... who doesn't have an email, it's a good thing. That said enforcing a longer password (like 12 or even more) without pissing off the user completely requires a little bit of education. What about adding few lines to the anaconda installer to explain the 4 random (unrelated) words or some rule like that? May bundle the xkcd comic as well if possible (only half kidding, but blacklist "correcthorsebatterystaple"). Sorry this was way longer than I initially intended. Best regards! On 24 July 2015 at 12:45, Michael Stahl <mstahl@xxxxxxxxxx> wrote: > On 23.07.2015 18:55, Michael Catanzaro wrote: >> 4) Our requirements for local password strength will allow passwords >> that would be much too weak were remote access via SSH to be enabled. >> We should have some user interaction when enabling SSH in the Sharing >> panel to force the user to pick a much stronger password. > >> Point (4) above sets the goal of setting stricter password requirements >> when remote access is enabled. Remote access is disabled by default and >> will remain disabled forever for most Workstation users, so it's not >> appropriate for that case to dictate our default password requirements. > > i've never understood why the sshd_config by default allows password > auth; first thing i do when installing SSH is to configure it to only > allow public keys. > > that would avoid the password strength problem too, since you can set a > different and better password on the private key. > > would it be reasonable to expect the sort of user that wants to use SSH > to be able to set that up? maybe provide some GNOME UI to generate a > key and copy it to .ssh/authorized_keys? > > > > -- > desktop mailing list > desktop@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/desktop -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
