Mailing List Archive

please remove permission check that disallows private-group access.
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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: please remove permission check that disallows private-group access. [ In reply to ]
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

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@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: please remove permission check that disallows private-group access. [ In reply to ]
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

> On Oct 21, 2018, at 20:23, Damien Miller <djm@mindrot.org> wrote:
>
> 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
>
>> 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@mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: please remove permission check that disallows private-group access. [ In reply to ]
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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: please remove permission check that disallows private-group access. [ In reply to ]
Damien Miller <djm@mindrot.org> writes:
> 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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: please remove permission check that disallows private-group access. [ In reply to ]
Damien Miller <djm@mindrot.org> writes:
> 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.

> 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?
Re: please remove permission check that disallows private-group access. [ In reply to ]
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
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: please remove permission check that disallows private-group access. [ In reply to ]
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

On Mon, Oct 22, 2018 at 2:20 PM Charlie Smurthwaite <charlie@atech.media> wrote:
>
> 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
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: please remove permission check that disallows private-group access. [ In reply to ]
On 10/22/18, 5:42 PM, "openssh-unix-dev on behalf of Peter Moody" <openssh-unix-dev-bounces+uri=ll.mit.edu@mindrot.org on behalf of mindrot@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.


On Mon, Oct 22, 2018 at 2:20 PM Charlie Smurthwaite <charlie@atech.media> wrote:
>
> 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
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: please remove permission check that disallows private-group access. [ In reply to ]
On 23/10/18 7:28 am, Wolfgang S. Rupprecht wrote:
> Damien Miller <djm@mindrot.org> writes:
>> 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.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: please remove permission check that disallows private-group access. [ In reply to ]
On Mon, 22 Oct 2018, Charlie Smurthwaite wrote:

> 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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Re: please remove permission check that disallows private-group access. [ In reply to ]
On 10/22/2018 11:55 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> 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:
localuser@centralhost, networkuser@centralhost and
networkuser@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.

> 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,
--
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect