please remove permission check that disallows private-group access.

[L A Walsh]

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

[Damien Miller]

Hi,

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

Post by L A Walsh
Third party programs should not be dictating to users how
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Blumenthal, Uri - 0553 - MITLL]

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.

Regards,
Uri

Sent from my iPhone

Post by Damien Miller
Hi,
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

Post by L A Walsh
Third party programs should not be dictating to users how
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Dr. Nagy Elemér Kár oly]

Dear Uri,

Post by Blumenthal, Uri - 0553 - MITLL
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

Post by Blumenthal, Uri - 0553 - MITLL

Post by Damien Miller
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

Post by L A Walsh
Third party programs should not be dictating to users how
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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

[Wolfgang S. Rupprecht]

Post by Damien Miller
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.

Maybe the check could have a configuration option to disable it? That
ways newbies would still be protected but folks that need to use the
group permissions to sort out NFS / UID issues could still use ssh
without going to great lengths to circumvent the check?

-wolfgang

[Blumenthal, Uri - 0553 - MITLL]

Post by Damien Miller
We don't plan to remove this check. Accidental key exposure is still an
unfortunately common problem and,

Could you please explain where you got this data from? I'd like a reference, please.

Post by Damien Miller
while this check isn't perfect, I'm
pretty sure that it avoids enough real-world misconfiguration to
justify it's continued existence.

If this check "while not perfect ... avoids real-world misconfiguration", why is there "accidental key exposure"?

Is there a contradiction?

[Charlie Smurthwaite]

I'm new here, but I feel like chiming in, I hope my opinions are
welcome. At first glance at this thread it seems unnecessary to argue
about the necessity of these checks when when the option exists to give
users the choice.

Adding configuration option(s) for users who wish to bypass these checks
could allow experienced users to do what they need to, and less
experienced users could still benefit form the protection by default.

Generally, giving users the choice should not be controversial, but I
will note that there is the mild fear of a user googling the error and
finding misguided advice to simply disable the check.

Charlie

[Peter Moody]

the determined sysadmin can just copy the keys where they want them to
be and run chmod. problem solved. no need for a new client side config
option, which carries a non-zero cost of ongoing maintenance.

Cheers,
peter

Post by Charlie Smurthwaite
I'm new here, but I feel like chiming in, I hope my opinions are
welcome. At first glance at this thread it seems unnecessary to argue
about the necessity of these checks when when the option exists to give
users the choice.
Adding configuration option(s) for users who wish to bypass these checks
could allow experienced users to do what they need to, and less
experienced users could still benefit form the protection by default.
Generally, giving users the choice should not be controversial, but I
will note that there is the mild fear of a user googling the error and
finding misguided advice to simply disable the check.
Charlie
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Blumenthal, Uri - 0553 - MITLL]

On 10/22/18, 5:42 PM, "openssh-unix-dev on behalf of Peter Moody" <openssh-unix-dev-bounces+uri=***@mindrot.org on behalf of ***@hda3.com> wrote:

the determined sysadmin can just copy the keys where they want them to
be and run chmod. problem solved.

Not so fast. If a home directory is on an NFS or AFS filesystem, where would that "determined sysadmin" copy the keys to? Not to mention the question of what business that "determined sysadmin" has touching my keys?

no need for a new client side config option, which carries a non-zero
cost of ongoing maintenance.

The cost of ongoing maintenance does not exceed the cost of dealing with this problem.

Post by Charlie Smurthwaite
I'm new here, but I feel like chiming in, I hope my opinions are
welcome. At first glance at this thread it seems unnecessary to argue
about the necessity of these checks when when the option exists to give
users the choice.
Adding configuration option(s) for users who wish to bypass these checks
could allow experienced users to do what they need to, and less
experienced users could still benefit form the protection by default.
Generally, giving users the choice should not be controversial, but I
will note that there is the mild fear of a user googling the error and
finding misguided advice to simply disable the check.
Charlie
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-***@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Jochen Bern]

Post by Blumenthal, Uri - 0553 - MITLL
Not so fast. If a home directory is on an NFS or AFS filesystem, where would
that "determined sysadmin" copy the keys to?

If there's not only a shared $HOME between two userids but also remote
mounts, you have THREE security contexts to keep track of:
***@centralhost, ***@centralhost and
***@whereverelsetheHOMEismountedto. Since all *other* machines
would need to be expected to use the standard $HOME/.ssh to find stuff
in, I would give serious thoughts to compiling OpenSSH on centralhost to
default to $HOME/.ssh-%u or somesuch instead. It takes but *one* user
who'ld like to keep his configs *separate* to make the point of such a
setup.

Post by Blumenthal, Uri - 0553 - MITLL
Not to mention the question of what business that "determined sysadmin" has
touching my keys?

Oh, I *would* prefer not to. And then I look at how many of our users
actually stick to established security procedures ("I've put your
[security relevant data including personal keypair] *there*, please
*delete* it off that server once you've downloaded it") and ...

Regards,

[Damien Miller]

Generally, giving users the choice should not be controversial, but I will
note that there is the mild fear of a user googling the error and finding
misguided advice to simply disable the check.

That's exactly what I believe will happen if we include an option.
Then we're stuck having to maintain a useless option in perpetuity.

[David Newall]

Post by Wolfgang S. Rupprecht

Post by Damien Miller
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.

Maybe the check could have a configuration option to disable it?

+1.  It's rude of SSH to refuse to use the key it was told to use.  A
warning is acceptable, as is an option to avoid any kerfuffle.