@sir'nt does this approach of accepting any ssh key break when the user offers multiple keys during a single session, and the second key offered is in sr.ht, but the first one isn't?

@Wolf480pl no, you just print a list of authorized keys (the ones known to sr.ht, or in the case of builds.sr.ht, the first key offered, which always works) and openssh compares them against all of the keys offered.

@Wolf480pl actually, thinking about it more, you might be right

@Wolf480pl but only for the git.sr.ht/hg.sr.ht case, not the builds.sr.ht case

@sir but aren't you then checking the first key offered against meta.sr.ht ?

r = requests.get(f"{meta_origin}/api/ssh-key/{b64key}")

@Wolf480pl this is a fallback in the git.sr.ht/hg.sr.ht case. Usually all of your keys are available in redis

@sir @Wolf480pl AuthorizedKeysCommand is invoked for every offered key until one is accepted (I tried)

@minus cool... I always thought I have to output a list of all authorized keys with username passed as an argument in command="", but if AuthhorizedKeysCommand is invoked for every key, @sir 's method is another interesting possibility

@Wolf480pl @sir Also note that AuthorizedKeysCommand is used *in addition to* authorized_keys files

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!