Remote SSH: Can not connect to host requiring certificate for authentication (error resolving authority)

[jemus42]

System details:

macOS 15.3 (24D60)

Positron and OS details:

Positron Version: 2025.02.0 (Universal) build 137
Code - OSS Version: 1.96.0
Commit: f4b7966
Date: 2025-01-30T15:14:42.529Z
Electron: 32.2.6
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Darwin arm64 24.3.0

Interpreter details:

R 4.4.2

Describe the issue:

I am trying to connect to a remote host which requires a certificate in addition to an SSH key.
My .ssh/config has an entry like this

Host foobar
  HostName foo.bar.edu
  User myuser
  IdentityFile ~/.ssh/id_ecdsa

And I have an id_ecdsa + id_ecdsa-cert.pub keypair.
I can ssh into the host without issues and VSCode can do its Remote SSH thing as well.

When I try to connect to this host with Positron, I encounter authentication errors akin to when one tries to ssh into a host for which one does not have the correct key installed.
The output window shows ssh connection details including what looks like an attempt to to use my id_ecdsa key

Pardon the 99% superfluous blurring of presumably just public key fingerprints

Since I do not control the host I am unfortunately not sure how I could reproduce this setup in a test environment.

Steps to reproduce the issue:

1. Try to connect to remote host using authentication setup as described?
   (Apologies but I do not now how to reproduce this in an isolate fashion)

Expected or desired behavior:

Positron connecting to and setting up the remote host as it does for other hosts.

Were there any error messages in the UI, Output panel, or Developer Tools console?

See screenshot above. I have failed to find a way to copy the log so far as the modal window blocks the UI.

[jmcphers]

Host foobar
  HostName foo.bar.edu

I notice that the error in the screenshot is error resolving authority which may just indicate a hostname resolution error (vs a cert/auth problem).

• Does it work if you give Positron the full hostname myuser@foo.bar.edu instead of using the short form foobar?
• Are you able to connect to hosts defined this way that do not use cert based auth?

[jemus42]

From what I understand foobar is just the short form alias of the host but connections are made using HostName(specified as a FQDN) in any case? For what it's worth, I can connect to this host just fine with ssh and the HostName resolves using dig just fine as well

• Does it work if you give Positron the full hostname myuser@foo.bar.edu instead of using the short form foobar?

Changing foo to the FQDN foo.bar.edu did not change the behavior, or what do you mean? Since Positron lists the SSH targets from my .ssh/config file I'm not sure where else to supply any further details when connecting via Positron, and since the host config already contains a username and FQDN I'm not sure what to do differently?

• Are you able to connect to hosts defined this way that do not use cert based auth?

Yes, this works via ssh foo in the terminal and via the VSCode Remote SSH extension just normally, both for this host and for various other hosts defined in my .ssh/config file this way.
From what I can gather, it's only Positron that can not connect to this host.

Does Positron's Remote SSH mechanism bundle it's own ssh or do anything in particular around the connection that would interfere with authentication?

[jmcphers]

Try running the command Remote-SSH: Connect to Host from the Palette. You'll see this:

Enter myuser@foo.bar.edu in that prompt. Does that address the issue, or give you a different error?

[jemus42]

Ah, I totally forgot that was even an option, sorry!

Yes, when I try that the behavior is exactly the same.
The only difference of course being the first line

Resolving ssh remote authority 'ssh-remote+myuser@foo.bar.edu' (attemp #1)

Instead of

Resolving ssh remote authority 'ssh-remote+foobar' (attemp #1)

I can also see that it's trying the ed25519 key, but shouldn't my .ssh/config ensure that only the ecdsa key is being used? Presumably that doesn't affect the resolution issue but I'm wondering if (parts of) the config are ignore or misinterpreted?

[jmcphers]

Okay, thanks, that's helpful!

I think what you're seeing is an issue with the Open Remote SSH extension we're using, which is also responsible for lots of reports of this issue in Cursor. See here for lots more details: cursor/cursor#1027.

Do any of the workarounds in that issue help?

[jemus42]

Ah too bad, but oh well, will watch that other issue as well just in case, thanks!

There were two workarounds stated in cursor/cursor#1027 (comment), so for anyone else running into this here:

1. (macOS): Give Full Disk Access permission to Cursor (->Positron)
   -> Tried it, didn't work.
2. Delete ~/.cursor_server on the remote host
   -> There's no .positron_server on the remote host or anything as I never connected to it (with Positron) yet, only ~/.vscode_server which of course I assume to be unrelated
   -> Not applicable

The linked issue notes the error message Error: All configured authentication methods failed though which is kind of related but different from what I'm seeing though 🤷‍♂

[juliasilge]

I'm not sure if you have the bandwidth for this, but if you are able to test out connecting to a session with VSCodium and the open-remote-ssh extension, we are wondering if you see the same error.

[jemus42]

Sure! This issue is the only thing blocking me from going all-in on Positron for my R projects, so I'm happy to do all the debugging things you can think of if it helps 😁

Here's what I get in VSCodium with open-remote-ssh v0.0.48:

[Info  - 12:30:54.765] Resolving ssh remote authority 'ssh-remote+foo' (attemp #1)
[Trace  - 12:30:54.780] Identity keys:
Lukas@dufte ssh-ed25519 SHA256:m3CfNF/UTtpkO/srgC4RmPGd9qQ0923v+bqYeQogN6c=
/Users/Lukas/.ssh/id_ecdsa ecdsa-sha2-nistp256 SHA256:W6FX9Wdw2XhSyoV5yMHLxPKjAyY8DRKcLu3GCG94nkc=
[Info  - 12:30:56.121] Trying no-auth authentication
[Info  - 12:30:56.451] Trying publickey authentication: Lukas@dufte ssh-ed25519 SHA256:m3CfNF/UTtpkO/srgC4RmPGd9qQ0923v+bqYeQogN6c=
[Info  - 12:30:56.875] Trying publickey authentication: /Users/Lukas/.ssh/id_ecdsa ecdsa-sha2-nistp256 SHA256:W6FX9Wdw2XhSyoV5yMHLxPKjAyY8DRKcLu3GCG94nkc=
[Error  - 12:30:57.309] Error resolving authority
Error: All configured authentication methods failed
	at me (/Users/Lukas/.vscode-oss/extensions/jeanp413.open-remote-ssh-0.0.48-universal/out/extension.js:1:155776)
	at /Users/Lukas/.vscode-oss/extensions/jeanp413.open-remote-ssh-0.0.48-universal/out/extension.js:1:409435
	at authHandler (/Users/Lukas/.vscode-oss/extensions/jeanp413.open-remote-ssh-0.0.48-universal/out/extension.js:1:404812)
	at Se (/Users/Lukas/.vscode-oss/extensions/jeanp413.open-remote-ssh-0.0.48-universal/out/extension.js:1:158994)
	at USERAUTH_FAILURE (/Users/Lukas/.vscode-oss/extensions/jeanp413.open-remote-ssh-0.0.48-universal/out/extension.js:1:147797)
	at 51 (/Users/Lukas/.vscode-oss/extensions/jeanp413.open-remote-ssh-0.0.48-universal/out/extension.js:1:311810)
	at e.exports.M (/Users/Lukas/.vscode-oss/extensions/jeanp413.open-remote-ssh-0.0.48-universal/out/extension.js:1:178339)
	at H.decrypt (/Users/Lukas/.vscode-oss/extensions/jeanp413.open-remote-ssh-0.0.48-universal/out/extension.js:1:274675)
	at e.exports.F [as _parse] (/Users/Lukas/.vscode-oss/extensions/jeanp413.open-remote-ssh-0.0.48-universal/out/extension.js:1:177863)
	at e.exports.parse (/Users/Lukas/.vscode-oss/extensions/jeanp413.open-remote-ssh-0.0.48-universal/out/extension.js:1:182250)
	at Socket.<anonymous> (/Users/Lukas/.vscode-oss/extensions/jeanp413.open-remote-ssh-0.0.48-universal/out/extension.js:1:154516)
	at Socket.emit (node:events:518:28)
	at Socket.emit (node:domain:489:12)
	at addChunk (node:internal/streams/readable:561:12)
	at readableAddChunkPushByteMode (node:internal/streams/readable:512:3)
	at Readable.push (node:internal/streams/readable:392:5)
	at TCP.onStreamRead (node:internal/stream_base_commons:191:23)

And here's Positron (2025.02.0 (Universal) build 137 Code - OSS Version: 1.96.0) again for comparison:

[Info  - 12:33:36.642] Resolving ssh remote authority 'ssh-remote+foo' (attemp #1)
[Trace  - 12:33:36.667] Identity keys:
Lukas@dufte ssh-ed25519 SHA256:m3CfNF/UTtpkO/srgC4RmPGd9qQ0923v+bqYeQogN6c=
/Users/Lukas/.ssh/id_ecdsa ecdsa-sha2-nistp256 SHA256:W6FX9Wdw2XhSyoV5yMHLxPKjAyY8DRKcLu3GCG94nkc=
[Info  - 12:33:37.593] Trying no-auth authentication
[Info  - 12:33:37.912] Trying publickey authentication: Lukas@dufte ssh-ed25519 SHA256:m3CfNF/UTtpkO/srgC4RmPGd9qQ0923v+bqYeQogN6c=
[Info  - 12:33:38.255] Trying publickey authentication: /Users/Lukas/.ssh/id_ecdsa ecdsa-sha2-nistp256 SHA256:W6FX9Wdw2XhSyoV5yMHLxPKjAyY8DRKcLu3GCG94nkc=
[Error  - 12:33:38.731] Error resolving authority
Error: All configured authentication methods failed
	at mt (/Applications/Positron.app/Contents/Resources/app/extensions/open-remote-ssh/dist/extension.js:1:160854)
	at /Applications/Positron.app/Contents/Resources/app/extensions/open-remote-ssh/dist/extension.js:1:407773
	at authHandler (/Applications/Positron.app/Contents/Resources/app/extensions/open-remote-ssh/dist/extension.js:1:403150)
	at St (/Applications/Positron.app/Contents/Resources/app/extensions/open-remote-ssh/dist/extension.js:1:164072)
	at USERAUTH_FAILURE (/Applications/Positron.app/Contents/Resources/app/extensions/open-remote-ssh/dist/extension.js:1:152875)
	at 51 (/Applications/Positron.app/Contents/Resources/app/extensions/open-remote-ssh/dist/extension.js:1:309500)
	at t.exports.M (/Applications/Positron.app/Contents/Resources/app/extensions/open-remote-ssh/dist/extension.js:1:183417)
	at R.decrypt (/Applications/Positron.app/Contents/Resources/app/extensions/open-remote-ssh/dist/extension.js:1:276148)
	at t.exports.F [as _parse] (/Applications/Positron.app/Contents/Resources/app/extensions/open-remote-ssh/dist/extension.js:1:182941)
	at t.exports.parse (/Applications/Positron.app/Contents/Resources/app/extensions/open-remote-ssh/dist/extension.js:1:187433)
	at Socket.<anonymous> (/Applications/Positron.app/Contents/Resources/app/extensions/open-remote-ssh/dist/extension.js:1:159594)
	at Socket.emit (node:events:518:28)
	at Socket.emit (node:domain:489:12)
	at addChunk (node:internal/streams/readable:561:12)
	at readableAddChunkPushByteMode (node:internal/streams/readable:512:3)
	at Readable.push (node:internal/streams/readable:392:5)
	at TCP.onStreamRead (node:internal/stream_base_commons:191:23)

[juliasilge]

Yep, that definitely looks like the same error, which is sort of a good news / bad news situation, I guess! We will make plans to prioritize working on this problem.

[apcamargo]

I've been experiencing the same bug here for some time now. Let me know if there's any information I can provide to help with this.