Created attachment 2474 [details] AuthorizedKeysCommand-add-an-option-for-alternate-ow.patch Currently the owner of AuthorizedKeysCommand must be root. A setup in which sshd is running as non root, can enjoy a complete and secure environment even if the AuthorizedKeysCommand is owned by a different user. This patch adds AuthorizedKeysCommandOwner option to control the ownership check of the AuthorizedKeysCommand. Default is root, so no change is done without explicit request. --- Discussed without response at[1], I thought I give it a chance here. Looking forward to fix of bug#2081, this and some others to make it possible to run sshd in complete unprivilged mode, while enjoying all benefits provided by the implmentation. Thanks! [1] http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-June/032696.html
I think it would be reasonable to relax the permission check to allow the command to be owned by the user who started sshd as well as root. I don't think another option is warranted or necessary.
(In reply to Damien Miller from comment #1) > I think it would be reasonable to relax the permission check to > allow the command to be owned by the user who started sshd as well > as root. I don't think another option is warranted or necessary. I thought that the original code was designed to block the user that ssh into local to modify the command, I did not want to violate this restriction. Did I understand incorrectly why we limit ownership?
Hello Damien, Can you please reply to comment#2 so I can submit a new patch if required? Thanks!
Rebased on top of master. Can you please reply to question at comment#2? It will simplify the implementation but I think there is potential security cost. (In reply to Alon Bar-Lev from comment #2) > (In reply to Damien Miller from comment #1) > > I think it would be reasonable to relax the permission check to > > allow the command to be owned by the user who started sshd as well > > as root. I don't think another option is warranted or necessary. > > I thought that the original code was designed to block the user that > ssh into local to modify the command, I did not want to violate this > restriction. > > Did I understand incorrectly why we limit ownership?
Created attachment 2558 [details] AuthorizedKeysCommand-add-an-option-for-alternate-ow.patch
(In reply to Alon Bar-Lev from comment #2) > (In reply to Damien Miller from comment #1) > > I think it would be reasonable to relax the permission check to > > allow the command to be owned by the user who started sshd as well > > as root. I don't think another option is warranted or necessary. > > I thought that the original code was designed to block the user that > ssh into local to modify the command, I did not want to violate this > restriction. > > Did I understand incorrectly why we limit ownership? That is indeed the intent, and allowing the user who started sshd in addition to root doesn't violate it.
(In reply to Damien Miller from comment #6) > (In reply to Alon Bar-Lev from comment #2) > > (In reply to Damien Miller from comment #1) > > > I think it would be reasonable to relax the permission check to > > > allow the command to be owned by the user who started sshd as well > > > as root. I don't think another option is warranted or necessary. > > > > I thought that the original code was designed to block the user that > > ssh into local to modify the command, I did not want to violate this > > restriction. > > > > Did I understand incorrectly why we limit ownership? > > That is indeed the intent, and allowing the user who started sshd in > addition to root doesn't violate it. I am very sorry, but must understand that fully. If I start sshd using unprivileged user let's say sshuser, the sshd cannot setuid, so it is left within sshuser context, and be able to modify the authorized keys command as it is the owner. Doesn't it violates the original intention?
The idea is to prevent the _target_ user from modifying AuthorizedUsersCommand, not the user who starts sshd. If the user can start sshd, then they can hardly do more damage by running AuthorizedUsersCommand...
(In reply to Damien Miller from comment #8) > The idea is to prevent the _target_ user from modifying > AuthorizedUsersCommand, not the user who starts sshd. > > If the user can start sshd, then they can hardly do more damage by > running AuthorizedUsersCommand... I understand. But fortunately, sshd can also run under non root account that have no special permissions nor can switch user. This is very useful for git or backup usages in which one wants to completely isolate the remote. In this use case, running sshd under git user, will enable access the machine using git@host, while authenticating based on authorized keys command, this works perfectly. The only missing bit is to enable this command to be owned by different account than root. Owning it by the user started sshd in this case is the same as owning as the _target_ user. This is why I added a configuration option.
Created attachment 2559 [details] AuthorizedKeysCommand-owner-can-be-the-one-that-star.patch This is the alternative of having the owner as user who started sshd.
Created attachment 2560 [details] AuthorizedKeysCommand-add-an-option-for-alternate-ow.patch This is the alternative of having a configuration option. I like it more.