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

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

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.

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

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?

@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

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.

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

https://pastebin.com/gNxJ4Tpp

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

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.

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…

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.

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.

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

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?)

This is now fixed: Pijul 1.0.0-alpha.16 reads ~/.ssh/config, and understand some of the directives (at least port, hostname, user, proxycommand, and a few others).

Feel free to reopen if it still doesn’t work for you. Thanks!

I did ran with the latest version still the problem still continues. Itdisregards my ~/.ssh/config file

Alright, can you paste the contents of that file here? Thanks.

Here you go

Host nest.pijul.com
    HostName nest.pijul.com
    User arijid79
    IdentityFile ~/.ssh/pijul

Thanks! Can you confirm that you have ~/.ssh/pijul and ~/.ssh/pijul.pub?

If you can, I’d be interested in seeing the output of RUST_LOG="pijul=debug" pijul pull arijid79@nest.pijul.com:pijul/pijul

This is now fixed: Pijul 1.0.0-alpha.16 reads ~/.ssh/config, and understand some of the directives (at least port, hostname, user, proxycommand, and a few others).

@pmeunier did you mean 1.0.0-alpha.15, or 1.0.0-alpha.16-not-yet-released?

I did mean 1.0.0-alpha-16-cargo-publish-failed-as-I-was-writing-the-comment ;-)

D’oh!

[2020-12-05T11:00:24Z DEBUG pijul::repository] “/home/arijit/Desktop/pijul/.pijul” [2020-12-05T11:00:24Z DEBUG pijul::commands::pushpull] Config { current_channel: Some(“main”), default_remote: Some(“arijid79@nest.pijul.com:pijul/pijul”), remotes: {}, hooks: Hooks { record: [] } }

[2020-12-05T11:00:24Z DEBUG pijul::remote::ssh] ssh_remote: Captures({0: Some(“arijid79@nest.pijul.com:pijul/pijul”), 1: None, 2: Some(“arijid79@”), “user”: Some(“arijid79”), 4: Some(“nest.pijul.com”), “host”: Some(“nest.pijul.com”), 6: None, 7: None, 8: Some(“nest.pijul.com”), 9: Some(“:”), 10: None, “port”: None, “path”: Some(“pijul/pijul”)})

[2020-12-05T11:00:24Z DEBUG pijul::remote] unknown_remote, ssh = Remote { addr: “arijid79@nest.pijul.com:pijul/pijul”, host: “nest.pijul.com”, path: “pijul/pijul”, config: Config { user: “arijid79”, host_name: “nest.pijul.com”, port: 22, identity_file: Some(“~/.ssh/pijul”), proxy_command: None, add_keys_to_agent: No } }

Password for arijid79@nest.pijul.com:

Alright, thanks @arijid79, I just fixed this in thrussh-config. The issue was that I wasn’t parsing ~/.

Could you publish 1.0.0-alpha.16 with these patches since it’s not published yet on crates.io

Done, thanks!