# Is it possible to not use ssh-agent?

**URL:** <https://discourse.pijul.org/t/is-it-possible-to-not-use-ssh-agent/1419>\
**Category:** Uncategorized\
**Created:** [August 19, 2026, 11:32am UTC](https://discourse.pijul.org/t/is-it-possible-to-not-use-ssh-agent/1419 "2026-08-19T11:32:45Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![goodnight](https://avatars.discourse-cdn.com/v4/letter/g/58f4c7/32.png) [@goodnight](https://discourse.pijul.org/u/goodnight)\
**Post date:** [August 19, 2026, 11:32am UTC](https://discourse.pijul.org/t/is-it-possible-to-not-use-ssh-agent/1419/1 "2026-08-19T11:32:45Z")

</div>

As describe in [#1007 pijul record error: "Error: Multiple SSH keys in agent; configure `signing_key` in config:" · Discussions · pijul / pijul](https://nest.pijul.com/pijul/pijul/discussion/1007), 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](https://pijul.org/manual/getting_started).

---

<div class="post-metadata">

**Author:** ![mixis](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/mixis/32/703_2.png) [@mixis](https://discourse.pijul.org/u/mixis)\
**Post date:** [August 29, 2026, 9:26am UTC](https://discourse.pijul.org/t/is-it-possible-to-not-use-ssh-agent/1419/2 "2026-08-29T09:26:57Z")

</div>

Looking at [pijul-identity/src/lib.rs](https://nest.pijul.com/pijul/pijul:main/tree/4KJ45IJLTIE34.BM6QA), 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.

---

<div class="post-metadata">

**Author:** ![pmeunier](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/pmeunier/32/4_2.png) [@pmeunier](https://discourse.pijul.org/u/pmeunier)\
**Post date:** [August 29, 2026, 11:26am UTC](https://discourse.pijul.org/t/is-it-possible-to-not-use-ssh-agent/1419/3 "2026-08-29T11:26:11Z")

</div>

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!).

---

<div class="post-metadata">

**Author:** ![mixis](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/mixis/32/703_2.png) [@mixis](https://discourse.pijul.org/u/mixis)\
**Post date:** [August 29, 2026, 5:30pm UTC](https://discourse.pijul.org/t/is-it-possible-to-not-use-ssh-agent/1419/4 "2026-08-29T17:30:43Z")

</div>

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](https://nest.pijul.com/pijul/pijul/discussion/1005) . 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.

---

<div class="post-metadata">

**Author:** ![pmeunier](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/pmeunier/32/4_2.png) [@pmeunier](https://discourse.pijul.org/u/pmeunier)\
**Post date:** [August 29, 2026, 6:27pm UTC](https://discourse.pijul.org/t/is-it-possible-to-not-use-ssh-agent/1419/5 "2026-08-29T18:27:02Z")

</div>

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.