I use a smartcard to do SSH authentication today, which works fine with OpenSSH. Is there any support for agent-style public-key authentication in lsh? Any plans? The agent protocol appears stable, and is used by several projects already (ssh, gpg-agent, libssh2, maybe others).
/Simon
Simon Josefsson simon@josefsson.org writes:
Is there any support for agent-style public-key authentication in lsh?
No.
Any plans?
It would definitely be good to have. Patches welcome. I haven't gotten around to implementing it myself.
On the lsh-side, I imagine one needs code to talk to the agent and return an instance of (a subclass of) the class signer. Interfaces in src/crypto.h. I don't think it should be very difficult.
And then I imagine one would also want to support agent forwarding. With the split into lsh and lsh-transport, it's not entirely obvious where agent forwarding belongs. It seems natural that it is lsh-transport which holds the connection to the agent (since this program does all cryptographic operations), but for forwarding, it probably needs to coordinate a bit with the lsh process, which keeps track of ssh channels and the like. Or maybe it's simplest to let each program have its own independent connection to the agent, where lsh-transport makes use of the agent, while lsh will just forward data to and from the agent?
I don't know if there's any need for a new lsh-agent program, or if one can just reuse gpg-agent.
A related (but independent) misfeature is that lsh asks for passphrases for all keys up front. It would be preferable to just read the public keys at startup, and unlock the needed private key only when it is about to be used.
Regards, /Niels
On Wed, 4 Apr 2012 14:16, nisse@lysator.liu.se said:
I don't know if there's any need for a new lsh-agent program, or if one can just reuse gpg-agent.
You only need to speak the agent protocol and setup the corresponding environment variables. Bonus points for starting an agent on demand and thus get rid of the need for environment variables. Code for the latter is in gnupg/common/ - or ask me to send a patch.
Salam-Shalom,
Werner
nisse@lysator.liu.se (Niels Möller) writes:
Simon Josefsson simon@josefsson.org writes:
Is there any support for agent-style public-key authentication in lsh?
No.
Any plans?
It would definitely be good to have. Patches welcome. I haven't gotten around to implementing it myself.
Ok. Daiki Ueno wrote agent support for libssh2, under a BSD license, maybe some of that could be re-used to simplify the implementation.
And then I imagine one would also want to support agent forwarding. With the split into lsh and lsh-transport, it's not entirely obvious where agent forwarding belongs. It seems natural that it is lsh-transport which holds the connection to the agent (since this program does all cryptographic operations), but for forwarding, it probably needs to coordinate a bit with the lsh process, which keeps track of ssh channels and the like. Or maybe it's simplest to let each program have its own independent connection to the agent, where lsh-transport makes use of the agent, while lsh will just forward data to and from the agent?
That sounds simpler, and I don't see any reason why having two connections would cause problems, but there could be some potential problem.
Agent forwarding isn't that important to me, though. Basic agent support is what is preventing me from using lsh at all, since my private keys are stored on a smartcard.
I don't know if there's any need for a new lsh-agent program, or if one can just reuse gpg-agent.
I don't think that is important.
A related (but independent) misfeature is that lsh asks for passphrases for all keys up front. It would be preferable to just read the public keys at startup, and unlock the needed private key only when it is about to be used.
Oh. I'm not sure if that works though. You can defer the passphrase prompt until lsh wants to use the private keys, but if I recall correctly, with SSH you don't know which private key to use anyway, so you have to decrypt them all and try them in order. However, lsh could try to use the agent first, and only if that doesn't work out, start to decrypt private keys, which would be a slight improvement.
On the other hand, if the user doesn't have any encrypted private keys on the machine (like for me), there wouldn't be any prompts anyway, and the agent would work.
/Simon
Simon Josefsson simon@josefsson.org writes:
Agent forwarding isn't that important to me, though. Basic agent support is what is preventing me from using lsh at all, since my private keys are stored on a smartcard.
Point taken. Basic agent support is more important.
Oh. I'm not sure if that works though. You can defer the passphrase prompt until lsh wants to use the private keys, but if I recall correctly, with SSH you don't know which private key to use anyway, so you have to decrypt them all and try them in order.
You're not recalling all the details ;-)
The ssh userauth protocol allows you to send a publickey, *without* any signature, and the server will tell you if the key + signature would be accepted. The way lsh uses that, it sends such requests for all known keys (and one can send the requests back-to-back, without having to wait a network roundtrip per key), and then it creates and sends a signature for the first key which the server says it will accept.
It's just a question of getting the public key first, without decrypting the corresponding private key upfront.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
Oh. I'm not sure if that works though. You can defer the passphrase prompt until lsh wants to use the private keys, but if I recall correctly, with SSH you don't know which private key to use anyway, so you have to decrypt them all and try them in order.
You're not recalling all the details ;-)
The ssh userauth protocol allows you to send a publickey, *without* any signature, and the server will tell you if the key + signature would be accepted. The way lsh uses that, it sends such requests for all known keys (and one can send the requests back-to-back, without having to wait a network roundtrip per key), and then it creates and sends a signature for the first key which the server says it will accept.
It's just a question of getting the public key first, without decrypting the corresponding private key upfront.
Ah, nice. I don't think libssh2 implements this idea, so that's why I missed it. Not even sure OpenSSH does, I recall having to unlock my smartcard even though I had a private key on disk that would have worked (although in that case, the smartcard key would also work, so maybe when faced with multiple working keys, OpenSSH prefered my smartcard key).
/Simon
-
nisse＠lysator.liu.se -
Simon Josefsson -
Werner Koch