#79 Running pijul clone via SSH error

Opened by arijid79 on November 16, 2020
arijid79 on November 16, 2020

When I tried to run

pijul clone arijid79@nest.pijul.com:pijul/manual 

Pijul gives different error messages such as Disconnected or Connection reset by peer I tried to run the ssh command and the connection establishes successfully

arijid79 on November 16, 2020

I tried to push some patches using the push subcommand but I get a new weird error

Error: Environment variable not defined

Or something like that

robx on November 16, 2020

I think I worked through the same issues you’re having. Some have been fixed in the meantime, so I suggest running

cargo install pijul --version 1.0.0-alpha.3

to install the latest version. I believe that should fix the “Environment variable” error which happend when ssh-agent isn’t running (or rather, SSH_AUTH_SOCK is unset), and possibly the other connection issues.

arijid79 on November 16, 2020

Ok. I discovered that if I try to SSH with a password validation (by commenting out all lines in ~/.ssh/config), the pull/push/clone works. However when I use a public-private key authentication, the error happens. Although the environment variable issue no longer pop’s up

pmeunier on November 23, 2020

These issues should be fixed now. I fixed a number things related to RSA keys and the absence of an agent. There’s just one thing left, it’s fixed in Thrussh but not yet enforced in Pijul, and that’s host key learning, which can sometimes be printed concurrently with a password prompt. This is not a security concern, since the password was being asked “preventively”, but it’s annoying and confusing.

@arijid79: Can you confirm the latest Pijul works with your favourite setup?

arijid79 on November 23, 2020

@pmeunier. I am really happy for the effort you put it but unfortunately, the issue still continues. There is no verbose flag for the clone command, otherwise I would have posted a log

robx on November 23, 2020

There is no verbose flag for the clone command, otherwise I would have posted a log

@arijid79 Try setting the environment variable RUST_LOG=debug.

arijid79 on November 23, 2020

Thanks. I didn’t knew that. Anyway, here is the log

https://pastebin.com/gNxJ4Tpp

pmeunier on November 23, 2020

Alright, I can now reproduce one potential issue with pijul clone. I’ll let you know if I make progress. Thanks for your patience.

pmeunier on November 23, 2020

Alright, this could be due to the protection against bruteforce attacks on the Nest. The Nest will drop the connection if you fail to authenticate too often. I could raise the threshold a little bit though.

robx on November 23, 2020

Alright, this could be due to the protection against bruteforce attacks on the Nest. The Nest will drop the connection if you fail to authenticate too often. I could raise the threshold a little bit though.

That sounds like a good idea. I ran into this quite a bit, too; something like two failed attempts were enough to lock me out for a while. Also the error message could maybe be clearer, and/or this could be documented as a common error somewhere.

On the other hand, once the kinks in the ssh client are worked out, it might be that none of this is an issue anymore, since folks won’t accidentally fail authentication so frequently…

pmeunier on November 23, 2020

It used to keep you waiting in the former Nest, but when I started operating this new one, it would get stuck sometimes, and one of my hypotheses was that there were two many waiting connections, so I disabled that.

The issue turned out to be that I was negotiating SSL connections on the same Future as the accepting loop, and an easy way to lock things up for everybody for a few seconds was to send a non-HTTPS packet on port 443.

pmeunier on November 23, 2020

Ok, I just published 1.0.0-alpha.6, which solves one bug in the SSH code. If you can, I’d like to know what the errors are now.

@arijid79: I generally use RUST_LOG="pijul=debug,thrussh=debug" to debug SSH issues.

arijid79 on November 24, 2020

I ran withe SSH again, but now it seems to disregard my ~/.ssh/config file and goes for a password prompt

Here are the logs https://pastebin.com/qA6uZqA2

ln on November 25, 2020

Somehow removing my ~/.ssh/known_hosts fixes some issue for me. Sorry, no logs, but maybe it helps someone (maybe there were traces from the old nest?)