pijul_org / pijul

#13 Error message is misleading when pushing without a correct ssh key

Opened by FlorentBecker, on March 21, 2017
Closed
FlorentBecker commented on March 21, 2017

When doing pijul push FlorentBecker@nest.pijul.com:pijul, if the ssh key for FlorentBecker@nest.pijul.com is not present, or the remote host is not in .ssh/known_hosts, the error message is:

thread 'main' panicked at 'called Result::unwrap() on an Err value: IO(Error { repr: Os { code: 2, message: "No such file or directory" } })', src/libcore/result.rs:837

It should be more specific ("failed to connect to FlorentBecker@nest.pijul.com, ssh error: bla")

FlorentBecker commented on March 21, 2017

Actually, the problem is that pijul does not know how to use ssh-agent and tries to load the ssh key from ~/.ssh/id_ed12345 while the key is actually in my gpg keyring and accessible through gpg-agent running as ssh-agent

pmeunier commented on March 21, 2017

Yes, @Keruspe reported the same on twitter, and said he might be interested in writing "thrussh-agent". I'm pretty sure this could be done outside of Thrussh.

On the same topic, several people contacted me because they wanted support for older algorithms (RSA/DSA, cipher-independent MAC, or AES) in Thrussh.

FlorentBecker commented on March 22, 2017

given that ssh-agent is only used on the client side, libssh2 can also fill the gap of getting the key from the agent for now.

pmeunier commented on March 22, 2017

Well, given the amount of nest users who registered an RSA key (despite the relatively explicit, but maybe too technical, warning), my priority for Thrussh is to get RSA authentication to work.

Also, in order to use keys from different sources, the key loading mechanisms in Thrussh would need to be cleaned up a little. A clean trait (in Thrussh) would allow others to write new ways of getting keys).

ocharles commented on March 22, 2017

So what are we meant to do in the meantime? I'm getting the same panic

FlorentBecker commented on March 23, 2017

ocharles: I ended up creating an ed22XYZ ssh-key specially for pijul and have it live in ~/.ssh/id_ed25519 . It's only a stopgap, but it works

lthms commented on March 23, 2017

Indeed, the .ssh/id_ed22519 path is hardcoded into the crate. FYI, encrypted keys (with bcrypt) are not supported either.

ocharles commented on March 29, 2017
pmeunier commented on March 29, 2017

It actually is an option if you don't encrypt your key, i.e. if you don't use a password.

ocharles commented on March 29, 2017

Oh, I hadn't thought of that! Thanks

lthms commented on June 5, 2017

What is the status of that issue?

FlorentBecker commented on June 6, 2017

as far as I can tell, encrypted ed25519 and RSA keys can now be used. I don't think things have changed on the following:

  • misleading error message
  • other algorithms (this would have to be done in thrussh-keys)
  • interfacing with ssh-agent (likewise, thrussh-keys)
FlorentBecker commented on June 6, 2017

The error message is now better, but issue #108 still exists.

pmeunier commented on October 24, 2017

So, #108 is closed, and I have an agent (I'm waiting on https://github.com/briansmith/ring/pull/582 to release it).