Dear Uri, > Respectfully disagree with your risk-benefit conclusion, and concur with the request to remove this check or > modify it to be informative rather than blocking. I respectfully disagree with you. I am a SSH user (and not an SSH developer) and I find that warning rather useful as it helped me a few times out of a thousand setups when I either forgot something or was using imperfect automation tools. I want SSH to check it, I would patch it back on my own time if it was removed. As a matter of fact, I would like that check to be even stronger and check for ACLs as well... On the other hand, I would support changing the wording from "bad permissions" to "insecure permissions" and "too open" to "most probably insecure" as I feel it is more technical and probably more PC as well. Also, I would support a patch that adds an "ignore-insecure-permissions" option to both the SSH client and the server, so you could set up one-user/one-shot/QaD test (virtual) machines with less hassle. Best wishes: Elmar > > We don't plan to remove this check. Accidental key exposure is still an > > unfortunately common problem and, while this check isn't perfect, I'm > > pretty sure that it avoids enough real-world misconfiguration to > > justify it's continued existence. > > > > You're right that it doesn't withstand a determined administrator > > and that's fine too - it isn't supposed to. > > > > -d > > > >> On Fri, 19 Oct 2018, L A Walsh wrote: > >> > >> Third party programs should not be dictating to users how > >> to manage their systems. Things like: > >> > >> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > >> @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ > >> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > >> Permissions 0660 for '/Users/law.Bliss/.ssh/id_rsa' are too open. > >> It is required that your private key files are NOT accessible by others > >> This private key will be ignored. > >> Load key "/Users/law.Bliss/.ssh/id_rsa": bad permissions > >> > >> 1) how would you know if they are "too open". I assign a group to > >> each user. How would they claim my permissions are "bad". > >> 2) In this specific case, my local-machine and domain login > >> are different UID's, so I put them in the same GID to allow > >> access no matter UID I am logged in with. > >> 3) It may give some users a false sense of "security" if they believe > >> that setting perms to something like 0600 will give them the security of > >> only their 1 login having access. They had better not rely on that. > >> > >> 4) I no longer get the warning -- I can simple change the permission > >> bits to match what is wanted then add my group as an acl -- which > >> gives the group full access but circumvents the irrelevant warning. > >> > >> 5) since my home directory is exported and mountable via samba, anyone > >> in the administrators or Domain Admins group (among others) can read it > >> as well. > >> > >> 6) I.e. the warning message is outdated, inaccurate and not really needed. > >> > >> Thanks much! > >> -linda _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
