SSH Remote Login (still) Not Working

Hi. Friendly reminder: The SSH Remote Login (still) does not work. Works fine in VSCode. From October of '23, this seems to be an outstanding issue, Can you give me/others a status on a fix?

1 Like

Hi Graham.

We already pushed out a fix for ssh about a month ago. I also just checked on my side and SSH was working.

Seems to me this is a different SSH bug than the one from October.

Are you on Windows or Mac? And which operating system are you SSHing into?

I’m on a macbook ssh’ing into a Windows 10 Machine…
The below works in VSCode

Host Windows
User user_name
IdentityFile ~/.ssh/id_ed25519
RemoteCommand cmd.exe

Host Ubuntu
User user_name
IdentityFile ~/.ssh/id_ed25519
RemoteCommand wsl

I see, we don’t support SSH onto non-linux machines (i.e. we can do windows/linux/mac → linux)

As VSCode already does this, do you plan to support logging into a Windows 10 WSL 2 machine? It’s a crucial part of my own workflow, perhaps to others as well


I am working on MacOS, trying to ssh into Linux via “Connect to Host”. Am I understanding correctly, that you think this should be working right now in Cursor?

Because for me at least it’s definitely not. It does in vscode, though.

[Info  - 09:58:00.472] Resolving ssh remote authority 'ssh-remote+[REDACTED]' (attempt #1)
[Trace  - 09:58:00.493] Identity keys:
[Info  - 09:58:00.665] Trying no-auth authentication
[Info  - 09:58:00.697] Trying publickey authentication: [REDACTED] ssh-rsa [REDACTED]
[Info  - 09:58:00.699] Trying password authentication
[Error  - 09:58:20.899] Error resolving authority
Error: All configured authentication methods failed
	at _e (/Applications/
	at /Applications/
	at authHandler (/Applications/
	at Ee (/Applications/
	at USERAUTH_FAILURE (/Applications/
	at 51 (/Applications/
	at e.exports.U (/Applications/
	at U.decrypt (/Applications/
	at e.exports.J [as _parse] (/Applications/
	at e.exports.parse (/Applications/
	at Socket.<anonymous> (/Applications/
	at Socket.emit (node:events:513:28)
	at Socket.emit (node:domain:489:12)
	at addChunk (node:internal/streams/readable:324:12)
	at readableAddChunk (node:internal/streams/readable:297:9)
	at Readable.push (node:internal/streams/readable:234:10)
	at TCP.onStreamRead (node:internal/stream_base_commons:190:23)

I wanted to give a ping for this WSL SSH Remote issue. Today, I checked Cursor again to see if it’s ssh remote into WSL works yet, which (sadly) it doesn’t.
I’ll continue with VSCode and check back every now and then. Or, maybe this bug is on the radar/queue for Cursor to support/fix. It’s a deal killer for me as I ssh into WSL on a daily basis. No worries. Not everyone needs this.

Is there no plan to support it in the future? Is there a workaround to SSH into a windows machine from a mac? I love Cursor man, that could e super useful if added, or even a workaround maybe


I can’t say for certain what fixed it, but I was able to fix a broken devcontainer, because I fortunately had a similar working one to compare it to.

If I narrow the cause further I will update. This is what was different:

  1. connected to docker container (outside vscode) and deleted .cursor_server
  2. Disabled all cursor features in vscode settings
  3. AND these changes in .devcontainer:

diff --git a/.devcontainer/localstack/devcontainer.json b/.devcontainer/localstack/devcontainer.json
index 886575d..ea72f91 100644
--- a/.devcontainer/localstack/devcontainer.json
+++ b/.devcontainer/localstack/devcontainer.json
@@ -14,14 +14,14 @@
         "vim.useSystemClipboard": true,
         "vim.useCtrlKeys": true,
         "vim.hlsearch": true,
-        "keyboard.dispatch": "keyCode",
+        // "keyboard.dispatch": "keyCode",
         "vim.insertModeKeyBindings": [
             "before": ["j", "j"],
             "after": ["<Esc>"]
-        "vim.leader": "<space>",
+        // "vim.leader": "<space>",
         "vim.handleKeys": {
           "<C-a>": false,
           "<C-f>": false
@@ -50,11 +50,11 @@
       "extensions": [
+        "vscodevim.vim",
-        "mtunique.vim-fcitx-remote",
@@ -77,7 +77,8 @@
         "version": "latest",
         "dockerDashComposeVersion": "v2"
-    "": {},
+    "": {}
+    // "": {},

Edit: Should laso mention that I noticed my .github folder was repetitively nested like 12 deep, and errors stopped when a “git submodule update --init --recursive” resolved

1 Like