CLI Login and Input Paper Key Without GUI

[rolyatwilson]

I'm working on a project that needs to be able to login to Keybase without using the GUI.

keybase login someUserId
The problem I'm running into with this command is first it prompts for device or paper key. It'd be great if I could specify paper key as an argument in order to avoid the interaction. The next problem is when choosing paper key I then have to interact with the Keybase GUI app.

Is there anyway to input the paper key from the CLI itself?

[bootstraponline]

Why doesn't keybase support automating the login with a paper key? This is super painful when using Keybase in CI.

I expect something like: keybase login --user user --paper-key key

spawn keybase login
expect "passphrase for "
sleep 1; send "$pass\r"

• https://github.com/zegerhoogeboom/keybase-docker-setup/blob/master/keybase-login.sh

[maxtaco]

We have cmd_paperprovision as devel-only, we didn't want to expose it in production.

[bootstraponline]

why aren't we able to automate production for running keybase on CI servers to download encrypted git repos?

• https://github.com/keybase/client/blob/master/go/client/cmd_paperprovision.go

[patrickxb]

If you're using expect you should be able to get it to work on the command line.

keybase login bootstraponline

would be your starting point. Then you will first select the paper key with which to provision, then enter it in.

I just provisioned keybase on a headless server with a paper key on the command line yesterday. Worked fine.

We also use a version of expect in some of our tests...

[bootstraponline]

If you're using expect you should be able to get it to work on the command line.

Expect doesn't work because keybase creates a GUI prompt for the paper key. The index number for pass phrase is also constantly changing. I posted above the expect script I used to explore this approach.

In addition supplying a unique name per device doesn't make sense for Docker.

I just provisioned keybase on a headless server with a paper key on the command line yesterday.

Please post the script you used. The current version of keybase is not possible to automate.

I am using http://bitrise.io/ that runs a fresh docker container for every build. The CI job needs to install keybase and then login automatically at the start of each build for git clone to work successfully. Keybase today doesn't support that use case in a friendly way.

I have even tried manually authenticating and creating a tar file of the home folder, that doesn't work though.

After reading the encrypted git blog post I was quite excited. Setup was painless and we started using keybase at work. Now I have to automate login for git clone and that's not a supported feature so we're blocked.

[patrickxb]

Try keybase --pinentry /dev/null login whatever which should use CLI prompt.

I didn't use a script, I'm just saying it is possible.

As far as your use case, could you add a docker container that has keybase installed and provisioned already?

[rolyatwilson]

Bitrise uses the same Docker image for all Android builds for all of their customers. Baking keybase credentials into the Docker image would expose them to multiple customers.

[bootstraponline]

I didn't use a script, I'm just saying it is possible.

I don't think this solves the 3,000 builds equals 3,000 uniquely named provisioned devices. I want Keybase to be possible in a Docker workflow, I'm not sure that's true today.

Individually naming ephemeral containers is a blocking issue. The weirdness around having to use expect instead of supporting cmd_paperprovision.go in production is an additional contributing factor.

[dabura667]

I have keybase working on Travis CI.

Just login locally, then copy all the files to TravisCI and setup a script to place the files in the right folder, then run_keybase and all keybase commands including git work fine.

I have one device for Travis CI. If I ever feel like it was compromised, I’ll revoke the device with my other device...

The only thing I wish we had was permissions on a per device level.

“This device key cannot revoke other devices or sign in new devices” would be HUGE.

[bootstraponline]

I have keybase working on Travis CI.

Please post the .travis.yml config so I can look at the script. I've tried local login on a linux box and copying over the session.json. That wasn't successful.

I used GitHub advance search and didn't find anyone using encrypted git repos on Travis CI.

[dabura667]

Currently travelling.

This is the docker I found in one of the issues on here a while back.

https://gist.github.com/junderw/2de606d9969c768077308582cd4f7153

Let me know if it helps.

Those four files are all you need.

Config file might contain metadata from
Multiple accounts if you login to multiple accounts with one PC, so you might want to clean it up.

[bootstraponline]

Thank you, I'll research that approach.

@patrickxb Are there any plans to make this a less crazy process? Better supporting encrypted git on Docker would open up entire new use cases for keybase.

This request has been made before with no response:

• Use keybase non-interactively, from a script? #9203
• Keybase GIT with Continuous Integration #9066

[maxtaco]

Just so I understand the requirements better, do you want a solution where keybase can crash and be restarted, or would the docker just be rebooted in that case?

Maybe the right solution here would be to allow some sort of ephemeral instantiation of the paper key, without any actual changes to the user's sigchain when the docker is booted up.

[maxtaco]

I threw together a prototype that I tested to work: #11500. I'm not sure if we'll keep it or not, but it might be useful. The idea is

keybase service &
KEYBASE_USERNAME=foo KEYBASE_PAPERKEY="ball plane foo bar bam boop" keybase oneshot

And then your container should be able to function as a provisioned device as long as the service process doesn't crash. But the device won't show up as a provisioned device on your sigchain, it'll actually be, instead, an instantiation of the "paper key" device.