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

New Issue

GiteaMirror · 2025-11-02T03:35:47-06:00

GiteaMirror commented

2025-11-02 03:35:47 -06:00

Originally created by @tsl0922 on GitHub (Jun 4, 2017).

Idea: https://github.com/tsl0922/openssh-for-git
Ref: http://man.openbsd.org/sshd_config#AuthorizedKeysCommand

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.

Originally created by @tsl0922 on GitHub (Jun 4, 2017). - **Idea:** https://github.com/tsl0922/openssh-for-git - **Ref:** http://man.openbsd.org/sshd_config#AuthorizedKeysCommand > 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](https://bugzilla.mindrot.org/show_bug.cgi?id=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.

GiteaMirror added the type/feature label 2025-11-02 03:35:47 -06:00

GiteaMirror closed this issue

2025-11-02 03:35:47 -06:00

GiteaMirror commented

2025-11-02 03:35:48 -06:00

@lunny commented on GitHub (Jun 4, 2017):

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

@lunny commented on GitHub (Jun 4, 2017): But maybe not all the Open SSHD has applied the patch?

GiteaMirror commented

2025-11-02 03:35:48 -06:00

@tsl0922 commented on GitHub (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 commented on GitHub (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.

GiteaMirror commented

2025-11-02 03:35:48 -06:00

@sapk commented on GitHub (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 ?

@sapk commented on GitHub (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 ?

GiteaMirror commented

2025-11-02 03:35:48 -06:00

@lafriks commented on GitHub (Jun 4, 2017):

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

@lafriks commented on GitHub (Jun 4, 2017): Maybe we could check for ssh version and work either new way or old depending on it

GiteaMirror commented

2025-11-02 03:35:48 -06:00

@lunny commented on GitHub (Jun 5, 2017):

@lafriks Yes, good idea.

@lunny commented on GitHub (Jun 5, 2017): @lafriks Yes, good idea.

GiteaMirror commented

2025-11-02 03:35:48 -06:00

@bkcsoft commented on GitHub (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 😛

@bkcsoft commented on GitHub (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 😛

GiteaMirror commented

2025-11-02 03:35:49 -06:00

@lafriks commented on GitHub (Jun 11, 2017):

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

@lafriks commented on GitHub (Jun 11, 2017): @bkcsoft there is already two ways anyway. Builtin ssh way and external ssh with rebuilding keys file

GiteaMirror commented

2025-11-02 03:35:49 -06:00

@bkcsoft commented on GitHub (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.

@bkcsoft commented on GitHub (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.

GiteaMirror commented

2025-11-02 03:35:49 -06:00

@TheAssassin commented on GitHub (Sep 2, 2017):

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.

@TheAssassin commented on GitHub (Sep 2, 2017): 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](https://packages.debian.org/de/jessie/openssh-server) and [oldoldstable](https://packages.debian.org/de/wheezy-backports/openssh-server) 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](https://godoc.org/golang.org/x/crypto/ssh) package. I could imagine there's projects doing that already.

GiteaMirror commented

2025-11-02 03:35:49 -06:00

@lunny commented on GitHub (Sep 3, 2017):

In fact, I'm using wheezy running Gitea.

@lunny commented on GitHub (Sep 3, 2017): In fact, I'm using wheezy running Gitea.

GiteaMirror commented

2025-11-02 03:35:50 -06:00

@TheAssassin commented on GitHub (Sep 3, 2017):

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.)

@TheAssassin commented on GitHub (Sep 3, 2017): 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.)

GiteaMirror commented

2025-11-02 03:35:50 -06:00

@zeripath commented on GitHub (Nov 1, 2018):

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

@zeripath commented on GitHub (Nov 1, 2018): Since the merge of #5236, Gitea now provides a mechanism for using AuthorizedKeysCommand.

GiteaMirror commented

2025-11-02 03:35:50 -06:00

@lafriks commented on GitHub (Nov 1, 2018):

Fixed by #5236

@lafriks commented on GitHub (Nov 1, 2018): Fixed by #5236

GiteaMirror referenced this issue

2025-11-02 11:49:57 -06:00