On 2021-08-11 at 13:50:55, Konstantin Ryabitsev wrote:
> 2-factor authentication does not make sense in the first three cases (you
> already have access to all the objects with 1 and 2, and the git:// protocol
> is public and anonymous by design). For the ssh/https scheme, 2fa is already
> supported by the underlying protocol, so it does not make sense for git to
> implement it again on the application level.

To expand on this a little bit, you can absolutely set up a Git server
with OpenSSH and require 2FA with OpenSSH.  That should work just fine.
You could also leverage a custom credential helper for HTTPS to require
a 2FA code, send it to a server, which would issue a one-time token for
Basic auth.  All of this is achievable with existing tooling that we
have today or tooling that can be easily built.

One note here is that as a practical matter, many people require
automated cloning of repositories, such as to use their CI systems.
Those systems generally cannot practically use 2FA and the security
would not be improved if they did, so some solution that allows for that
to work is going to be required.

Also, in workflows that require many repositories to be cloned, it can
be kind of a hassle to wait for one clone to complete, enter the 2FA
code (or touch the YubiKey) for the second clone, wait for it to
complete, do 2FA for the third clone, and so on.  So while you can do
this, it's important to keep in mind that there are some user experience
tradeoffs here that need to be considered as well.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA