Feature request: Configure priority/Make Kryptonite method of last resort

[henryk]

OS: Ubuntu 16.04.3 LTS SSH: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016 kr version 2.2.7

My primary SSH key store is a Yubikey Nano with touch-to-sign. It's configured into SSH through the agent, via PKCS#11, as a Smartcard with OpenSC: ssh-add -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

For some hosts I have configured both the Yubikey public key and the Kryptonite key. (In order to access these hosts from f.e. a Windows Ubuntu session, where no Smartcard support is present.) In general, I want Kryptonite to be the method of last resort: It's easier to touch the yubikey next to my keyboard than the authorize the action on my phone. This doesn't happen: I'm asked to authorize through Kryptonite, and even if I reject, the Yubikey isn't tried.

The same behaviour is present when loading keys into the agent normally, without any Smartcard related stuff.

I'd like to be able to configure Kryptonite to first try the keys that the regular SSH agent offers, and only then use the phone app.

Steps to reproduce:

1. Add a key to the ssh agent: ssh-add .ssh/id_ed25519
2. Start/set up Kryptonite
3. Add both the Kryptonite key and the normal id_ed25519 key to the authorized_keys on a host
4. SSH into that host

Actual results:

• Kryptonite asks for authorization on the phone, even though the agent would be able to provide a key without interaction.

Expected results:

• Should try the normal ssh-agent keys first, then fall back to Kryptonite.

[kcking]

Thanks for the detailed request! We will indeed make this configurable

[balupton]

Turns out the installation of krypton accomplished this automatically for me, as I was already using server configurations in my .ssh/config, which is as follows (modified for brevity):

# Added manually
Host some.server.com
	IdentityFile ~/.ssh/some-ssh-key
AddKeysToAgent yes

# Added by Krypton
Host *
	PKCS11Provider /usr/local/lib/kr-pkcs11.so
	ProxyCommand /usr/local/bin/krssh %h %p
	IdentityFile ~/.ssh/id_krypton
	IdentityFile ~/.ssh/id_ed25519
	IdentityFile ~/.ssh/id_rsa
	IdentityFile ~/.ssh/id_ecdsa
	IdentityFile ~/.ssh/id_dsa

So when I went to ssh into the some.server.com server, it used the key specified rather than krypton. Seems this accomplishes the requested goal here.