Unreliable output from onlykey-agent
I'm having an issue with my onlykey (duo) when using it as a ssh key provider:
(I've redacted what I hope I should to not leak any unwanted information about my device, but I'm willing to send a more complete output privately if needed)
In the picture, the first time I run onlykey-agent, I get the expected public key from the device, and can usually also sign with it for ssh and git operations. However, the next three times I try to run it, the "received=" and "Received Public Key" lines don't output the expected bytes, as you can also see in the final printed public key. This seems to happen more or less at random, and I haven't figured out any better pattern/workaround than to unplug/plug in my onlykey until it works reliably. It seems like once it goes "stable" enough, it works fine without failure until I unplug it again. Writing this now, I'm realizing it might be a hardware issue as well, but I still wanted to ask if there's an obvious issue at play here?
If it's relevant, I'm using the latest version from master, "installed" into a venv by using the following script:
#!/usr/bin/env bash
TZDIR="$HOME/src/tools/trezor-agent"
REPOURL="https://github.com/romanz/trezor-agent"
REPODIR="$TZDIR/repo"
VENVDIR="$TZDIR/venv"
if [[ ! -d $TZDIR ]]; then
echo "Creating $TZDIR"
mkdir -p $TZDIR
fi
if [[ ! -d $REPODIR ]]; then
git clone $REPOURL $REPODIR
fi
if [[ -d $REPODIR ]]; then
(cd $REPODIR && git pull)
fi
if [[ ! -d $VENVDIR ]]; then
python -m venv $VENVDIR
fi
if [[ -d $VENVDIR ]]; then
source $VENVDIR/bin/activate
pip install --upgrade pip
pip install --upgrade Cython hidapi
pip install -e $REPODIR
pip install -e $REPODIR/agents/trezor
pip install -e $REPODIR/agents/onlykey
pip install --upgrade pynvim
else
echo "Something is wrong with the venv dir $VENVDIR"
fi
Probably/maybe not relevant, but I can still use my onlykey as 2-factor login device on github.com through my web browser, while it's in the "state" where onlykey-agent produce invalid public keys.
(Sorry for using this as my personal debugging space...)
I realized that the official documentation points to this package, so I installed that instead:
➜ onlykey-agent -v -e ed25519 [email protected]
2024-12-12 13:50:04,966 INFO identity #0: <ssh://[email protected]|ed25519> [__init__.py:287]
2024-12-12 13:50:04,994 ERROR failed to connect [client.py:279]
Traceback (most recent call last):
File "/external/martin/src/tmpvenv/venv/lib/python3.12/site-packages/onlykey/client.py", line 270, in _connect
self._hid.open_path(self.path)
File "hid.pyx", line 158, in hid.device.open_path
OSError: open failed
2024-12-12 13:50:06,500 ERROR failed to connect [client.py:279]
Traceback (most recent call last):
File "/external/martin/src/tmpvenv/venv/lib/python3.12/site-packages/onlykey/client.py", line 270, in _connect
self._hid.open_path(self.path)
File "hid.pyx", line 158, in hid.device.open_path
OSError: open failed
2024-12-12 13:50:08,005 ERROR failed to connect [client.py:279]
Traceback (most recent call last):
File "/external/martin/src/tmpvenv/venv/lib/python3.12/site-packages/onlykey/client.py", line 270, in _connect
self._hid.open_path(self.path)
File "hid.pyx", line 158, in hid.device.open_path
OSError: open failed
2024-12-12 13:50:09,509 ERROR failed to connect [client.py:279]
Traceback (most recent call last):
File "/external/martin/src/tmpvenv/venv/lib/python3.12/site-packages/onlykey/client.py", line 270, in _connect
self._hid.open_path(self.path)
File "hid.pyx", line 158, in hid.device.open_path
OSError: open failed
2024-12-12 13:50:11,014 ERROR failed to connect [client.py:279]
Traceback (most recent call last):
File "/external/martin/src/tmpvenv/venv/lib/python3.12/site-packages/onlykey/client.py", line 270, in _connect
self._hid.open_path(self.path)
File "hid.pyx", line 158, in hid.device.open_path
OSError: open failed
2024-12-12 13:50:12,515 ERROR Connection error (try unplugging and replugging your device): {} not connected: "{}" [__init__.py:187]
~/src/tmpvenv via tmpvenv took 7.8s …
➜ onlykey-agent -v -e ed25519 [email protected]
2024-12-12 13:50:16,057 INFO identity #0: <ssh://[email protected]|ed25519> [__init__.py:287]
2024-12-12 13:50:16,093 INFO Requesting public key from key slot =132 [onlykey.py:164]
2024-12-12 13:50:16,093 INFO Identity to hash =b'[email protected]' [onlykey.py:178]
2024-12-12 13:50:16,093 INFO Identity hash =... [onlykey.py:182]
2024-12-12 13:50:16,094 INFO curve name= 'ed25519' [onlykey.py:198]
2024-12-12 13:50:16,402 INFO received= [...] [onlykey.py:209]
2024-12-12 13:50:16,402 INFO Received Public Key generated by OnlyKey= '...' [onlykey.py:216]
2024-12-12 13:50:16,402 INFO vk= <nacl.signing.VerifyKey object at 0x...> [onlykey.py:219]
2024-12-12 13:50:16,402 INFO disconnected from OnlyKey [onlykey.py:139]
[Correct key printed]
(Redacted some stuff here as well)
Once I've run the agent once with the repeated "failed to connect" error, I can rerun it, and everything works fine, and after this the agent from this repo also works fine. Judging from the open #303 issue, I'm assuming the onlykey support isn't fully in place yet? If so, I can live just fine with the other version, just having to go through the error before it works.
cc @onlykey , hope that's okay
@mavaa The version of onlykey-agent here just supports derived keys, we haven't had any reports of that not working. The version linked to in our docs also supports stored ECC and RSA keys.
Is onlykey-agent -v -e ed25519 [email protected] and onlykey-agent -v -e ed25519 [email protected] -- git pull not using derived keys?
The error output from my previous message with repeated OSError: open failed happens with your onlykey-agent version.
@onlykey I've been living with this issue for a while now, but haven't had the time to troubleshoot it anymore. But today I tested installing your desktop application, and by starting the app before running onlykey-agent/ssh, the issue disappears. To re-iterate my problem, I have to run onlykey-agent 2-3 times before it starts working, before that it repeatedly fails with:
2025-07-14 11:02:44,114 ERROR failed to connect [client.py:279]
Traceback (most recent call last):
File "onlykey-agent/lib/python3.13/site-packages/onlykey/client.py", line 270, in _connect
self._hid.open_path(self.path)
~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
File "hid.pyx", line 158, in hid.device.open_path
OSError: open failed
This happens again if I reconnect the device or reboot.
If I start the desktop app before running onlykey-agent, the app seems to communicate with the device a bit, and then I can run onlykey-agent flawlessly. Seems like the desktop app might initialize the device in some way that onlykey-agent don't? And/or the first 2-3 times onlykey-agent tries to communicate with the device it probably triggers the same startup sequence/data from the device until it works?
Still running onlykey-agent=1.1.15 lib-agent=1.0.6 from https://pypi.org/project/onlykey-agent/ , and firmware 3.0.4 on an onlykey duo.
@mavaa Thanks for doing some additional troubleshooting, it may be that the app/OnlyKey have gotten out of sync. The way USB works is the USB device sends USB messages to the computer but those aren't actually sent, the computer/app has to poll for them. And if it doesn't then things can get out of sync. Are you able to test using the CLI, that will do the same thing as the desktop app, just run onlykey-cli fwversion or onlykey-cli settime https://docs.onlykey.io/command-line.html#fwversion then after that if you start the SSH agent does the issue go away?
Sorry again for the late reply, but sadly it turns out my onlykey have stopped working. It seems like the USB pins were worn down so much it stopped making contact when plugged into the computer (tried it on multiple ports on multiple computers + the USB-C "sleeve"). A friend of mine tried to help me solder on a bit of tin on the contacts to help it, but now it won't connect at all anymore, so we probably broke something.
Might buy a new one at some point, but until then, it's hard to say whether or not this might've all been due to loose pins, but since I've had variations of this issue since day 1, I'm leaning towards no. Feel free to close the issue in the meantime, since it seems I'm the only one who'se been having this issue.