Is it possible to not use ssh-agent?

As describe in #1007 pijul record error: "Error: Multiple SSH keys in agent; configure `signing_key` in config:" · Discussions · pijul / pijul, when I first run pijul record or pijul identity new before I set things up, it just throw error Error: Multiple SSH keys in agent; configure signing_key in config:"

Is it necessary to set ssh-agent up before using pijul? Can I bypass it?

If it is necessary, I think the way to set up ssh-agent should be mentioned in Pijul Manual getting started section.

2 Likes

Looking at pijul-identity/src/lib.rs, I currently see no way around ssh-agent. I see quite recent changes to that code, so I guess the documentation will catch up.

I am looking at pijul for a partly non-interactive use-case and having to use ssh-agent complicates the setup.

Yes, I decided to break things a little faster than usual for reasons that I’ll explain in just a few weeks. Also, the best feedback one can receive on a project is by breaking things, isn’t it?

I understand your concern, and I’ve removed a lot of interactivity while introducing this change. If you’re interested in helping to improve the design, please help! Without weakening the default security of course (and if possible even improving it!).

Honestly, it would be faster for me to integrate ssh-agent, than browsing pijul’s code, but I’m doing this as a learning experience. I may even try to use pijul as a library.

From a user experience, though, having to deal with ssh-agent is a bit of stumbling block to just try out pijul and get a feel for its operation. I figure, the new manual will have to involve ssh-add at some point and if the agent is not set up yet,$SSH_AUTH_SOCK may not be set either.

The linked manual page looks like a good flow. I think unencrypted keys are okay for getting started and standard ssh keys should be able to be encrypted later with ssh-keygen.

Some users on nest had troubles, too: #1005 "SSH agent error: Agent protocol error" when recording on a clean working copy · Discussions · pijul / pijul . Looks like the user base can cope with proper documentation, though.

For interactive use, I welcome the use of ssh-agent over some custom credentials loading mechanism. I have been scrolling through change PYELFYSLMEQA3CP4LNAUSQINXPZ3IKYKEIGIHWDCRTYXZWHY5AGQC and it looks like you got rid of a fair amount of code, indeed.

Design-wise, I don’t understand enough about the system yet, but I appreciate the offer. Am I inferring correctly, that the intention now is to use the same keys for signing and for connecting to remotes? What I may attempt as an exercise is to define a key_path for an unencrypted key in identity.toml and try to resurrect some of the ed25519_dalek code. I don’t expect that to be suitable to the project, though, if I manage to do it at all.

1 Like

The intention when doing that was to reduce the attack surface, and the hypothesis was that Pijul users probably already had some keys around. One main issue is key protection: you don’t want cleartext keys on your disk, and some organisations may even want to use hardware to sign patches.