If a key supplied by
AuthorizedKeysCommanddoes not successfully authenticate and authorize the user then public key authentication continues using the usualAuthorizedKeysFilefiles.
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.
But maybe not all the Open SSHD has applied the patch?
@lunny This patch has been applied to OpenSSH over 2 years, recent versions of major linux distributions should have come with this support.
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 ?
Maybe we could check for ssh version and work either new way or old depending on it
@lafriks Yes, good idea.
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 there is already two ways anyway. Builtin ssh way and external ssh with rebuilding keys file
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.
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.
In fact, I'm using wheezy running Gitea.
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.)
Since the merge of #5236, Gitea now provides a mechanism for using AuthorizedKeysCommand.
Fixed by #5236
Most helpful comment
Maybe we could check for ssh version and work either new way or old depending on it