FATA[0000] ssh dial error: ssh: handshake failed: ssh: unable to authenticate

[vd2org]

Unable to start a session using either public or local servers.

FATA[0000] ssh dial error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

OS:

Darwin host.name 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:16 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6000 arm64

The command are used for public server:

upterm host

The command are used for start an own server:

docker run --rm -p 2222:2222 ghcr.io/owenthereal/upterm/uptermd --ssh-addr 0.0.0.0:2222 --debug

The command are used for own server:

upterm host --server ssh://localhost:2222

Server's log:

time="2025-02-26T14:00:03Z" level=info msg="starting server" app=uptermd network=mem network-opt="[]" node-addr="[::]:2222" ssh-addr="[::]:2222"
time="2025-02-26T14:00:43Z" level=debug msg="connection establishing failed" addr="192.168.65.1:54084" app=uptermd com=ssh-proxy error="[ssh: no auth passed yet, ssh: authenticated with partial success]" network=mem network-opt="[]" node-addr="[::]:2222" ssh-addr="[::]:2222"
time="2025-02-26T14:00:46Z" level=debug msg="connection establishing failed" addr="192.168.65.1:37581" app=uptermd com=ssh-proxy error="[ssh: no auth passed yet, ssh: authenticated with partial success]" network=mem network-opt="[]" node-addr="[::]:2222" ssh-addr="[::]:2222"

[counterbeing]

This might have to do with the ssh agent on your machine not running. At least that's what it was for a coworker.

[oscarmlage]

Same problem here:

$ upterm host
Error: ssh dial error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

OS:

Darwin host 24.1.0 Darwin Kernel Version 24.1.0: Thu Oct 10 21:02:27 PDT 2024; root:xnu-11215.41.3~2/RELEASE_X86_64 x86_64

[oscarmlage]

I think I've found an explanation for this issue. If we inspect the key type required by the uptermd.upterm.dev host, we can see that it expects an ssh-ed25519 key:

$ ssh-keyscan uptermd.upterm.dev
[...]
uptermd.upterm.dev ssh-ed25519 AAAAC3N...
[...]

And probably, the ssh-agent doesn't have any ed25519 key available for authentication during the SSH handshake. If you don't already have a key of this type, you can generate a new one with:

$ ssh-keygen -t ed25519 -b 4096 -f ~/.ssh/id_upterm -C "your@email"

By default, upterm seems to pick up the key named ~/.ssh/id_ed25519 (and its .pub pair) automatically, but if your key has a different name, for example id_upterm (id_upterm.pub), it won't be used unless you add it manually to the SSH agent:

$ ssh-add -l
The agent has no identities.

$ ssh-add ~/.ssh/id_upterm
Identity added: ~/.ssh/id_upterm (your@email)

$ ssh-add -l
4096 SHA256:xxXX your@email (RSA)

Once the key is added to the ssh-agent (or if you already have a default ~/.ssh/id_ed25519 key), the authentication and handshake process should work correctly.