Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: get rid of the authorized_keys file with AuthorizedKeysCommand #1870

Closed
tsl0922 opened this issue Jun 4, 2017 · 13 comments
Closed
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active.
Milestone

Comments

@tsl0922
Copy link
Contributor

tsl0922 commented Jun 4, 2017

If a key supplied by AuthorizedKeysCommand does not successfully authenticate and authorize the user then public key authentication continues using the usual AuthorizedKeysFile files.

With AuthorizedKeysCommand, public keys can be verified dynamically from database like the embed golang ssh server does.

As of OpenSSH 6.9p1 (released at 2015-07-01), the openssh-for-git patch is not needed anymore (bz#2081), we can use the %f token to pass fingerprint as command line argument to AuthorizedKeysCommand which can be used to recognize the remote user.

@lunny
Copy link
Member

lunny commented Jun 4, 2017

But maybe not all the Open SSHD has applied the patch?

@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Jun 4, 2017
@tsl0922
Copy link
Contributor Author

tsl0922 commented Jun 4, 2017

@lunny This patch has been applied to OpenSSH over 2 years, recent versions of major linux distributions should have come with this support.

@tsl0922 tsl0922 changed the title Get rid of the authorized_keys file Proposal: get rid of the authorized_keys file with AuthorizedKeysCommand Jun 4, 2017
@sapk
Copy link
Member

sapk commented Jun 4, 2017

The only blocking distrib should be debian that is still on 6.7 on stable. But stable will upgrade in the next weeks and version will be 7.4 on debina 9 so this could be implemented and deployed after debian release maybe ?

@lafriks
Copy link
Member

lafriks commented Jun 4, 2017

Maybe we could check for ssh version and work either new way or old depending on it

@lunny
Copy link
Member

lunny commented Jun 5, 2017

@lafriks Yes, good idea.

@bkcsoft
Copy link
Member

bkcsoft commented Jun 11, 2017

I really don't like having 2 paths (since testing becomes hard...) but I also don't like rebuilding authorized_keys all the time, and I don't like dropping support for older versions 😛

@lafriks
Copy link
Member

lafriks commented Jun 11, 2017

@bkcsoft there is already two ways anyway. Builtin ssh way and external ssh with rebuilding keys file

@bkcsoft
Copy link
Member

bkcsoft commented Jun 15, 2017

Well, in any case we should not make assuptions about the SSH-server in use. Not everyone uses OpenSSH. So this would have to be an optional setting.

@TheAssassin
Copy link

Citing https://secure.phabricator.com/book/phabricator/article/diffusion_hosting/#configuring-ssh:

NOTE: The Phabricator sshd service MUST be 6.2 or newer, because Phabricator relies on the AuthorizedKeysCommand option.

This version of OpenSSH has been available for quite a while, Debian oldstable and oldoldstable have it available.

For users of the Docker container, Gitea is in control of the version shipped. Others will most likely use OpenSSH as well, and should be able to upgrade their servers (I mean, if they are not, then their system is probably too outdated for anything else anyway). Dropbear etc. don't support it natively.

Another option is to create an SSH daemon for these purposes with the native ssh package. I could imagine there's projects doing that already.

@lunny
Copy link
Member

lunny commented Sep 3, 2017

In fact, I'm using wheezy running Gitea.

@TheAssassin
Copy link

Which is the last supported version of Debian and for which an appropriate version of OpenSSH is available in the backports.

(Not to mention that everyone running oldoldstable should upgrade ASAP anyway.)

@zeripath
Copy link
Contributor

zeripath commented Nov 1, 2018

Since the merge of #5236, Gitea now provides a mechanism for using AuthorizedKeysCommand.

@lafriks lafriks added type/feature Completely new functionality. Can only be merged if feature freeze is not active. and removed type/proposal The new feature has not been accepted yet but needs to be discussed first. labels Nov 1, 2018
@lafriks lafriks added this to the 1.7.0 milestone Nov 1, 2018
@lafriks
Copy link
Member

lafriks commented Nov 1, 2018

Fixed by #5236

@lafriks lafriks closed this as completed Nov 1, 2018
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active.
Projects
None yet
Development

No branches or pull requests

7 participants