https://bugzilla.mindrot.org/show_bug.cgi?id=2164
--- Comment #2 from Philip Hands <[email protected]> --- Just out of interest, was there a reason for choosing 'no' rather than 'without-password'? For distros at least, I think they'll all have to change that to without-password if there's any chance that people will get the change as part of an upgrade, since anyone that's installed ssh keys will be pretty upset when they stop working. Also, given that on a new install there are not going to be any authorised keys, and one would need to have root access to place anything in root's authorized_keys, I'm wondering what the benefit of having this set to 'no' is supposed to be. The only distinction that I'd expect would be that people are forced to modify it away from 'no' in order to get things working after putting keys in place, which is a needless irritation but more importantly, unless they've been paying attention, they'll not switch it to 'without-password' at that point, they'll switch it to 'yes', with a resulting needless loss of security. I'd suggest that if there's not deemed to be a significant security advantage associated with 'no' that it should be set to 'without-password' if only to educate users to the existence of the option (there are still _many_ ssh users who are surprised that such an option exists) Cheers, Phil. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
