I've followed the procedure to use keybase for ssh auth. https://keybase-ssh-ca-bot.readthedocs.io/en/latest/getting_started.html
It works great! Except that often my colleagues have issues with their AckRequests ending up in the wrong channel.
Our organisation has these channels, the impacted users are members of all
- weatherforce.dev for developers (unrelated to ssh auth), users are writers, certbot is not a member
- weatherforce.ssh.dev for access to dev machines, users are readers, certbot is writer
- weatherforce.ssh.prep for access to preprod machines, users are readers, certbot is writer
In certain cases, the AckRequests end up in weatherforce.dev, not weatherforce.ssh.dev, so the certbot does not see them. If I kick the impacted user out of weatherforce.dev and they retry to provision, the AckRequests go to the correct channel. So it seems that there's a bug in the regex / filtering that kssh uses to determine where to send the AckRequest.
Impacted users are in Linux, with these versions of keybase
keybase version 5.3.1-20200320154633+3e235215b3
keybase version 5.3.0-20200310205642+4f2689009b
One user is not impacted, he is using MacOS:
keybase version 5.3.0-20200310172631+4f2689009b

All users are using the current version of kssh, 1.1.0-5558800
I've followed the procedure to use keybase for ssh auth. https://keybase-ssh-ca-bot.readthedocs.io/en/latest/getting_started.html
It works great! Except that often my colleagues have issues with their AckRequests ending up in the wrong channel.
Our organisation has these channels, the impacted users are members of all
In certain cases, the AckRequests end up in weatherforce.dev, not weatherforce.ssh.dev, so the certbot does not see them. If I kick the impacted user out of weatherforce.dev and they retry to provision, the AckRequests go to the correct channel. So it seems that there's a bug in the regex / filtering that kssh uses to determine where to send the AckRequest.
Impacted users are in Linux, with these versions of keybase
keybase version 5.3.1-20200320154633+3e235215b3
keybase version 5.3.0-20200310205642+4f2689009b
One user is not impacted, he is using MacOS:
keybase version 5.3.0-20200310172631+4f2689009b

All users are using the current version of kssh, 1.1.0-5558800