Help! Cursor Remote-SSH fails with“Error resolving SSH authority This operation was aborted”

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

2026-03-10 17:12:20.543 [info] Resolving ssh remote authority ‘[remote-ip]’ (Unparsed ‘ssh-remote+[remote-ip]’) (attempt #1)
2026-03-10 17:12:20.552 [info] SSH askpass server listening on port 61054
2026-03-10 17:12:20.553 [info] Using configured platform linux for remote host [remote-ip]
2026-03-10 17:12:20.555 [info] Using askpass script: c:\Users[local-username].cursor\extensions\anysphere.remote-ssh-1.0.46\dist\scripts\launchSSHAskpass.bat with javascript file c:\Users[local-username].cursor\extensions\anysphere.remote-ssh-1.0.46\dist\scripts\sshAskClient.js. Askpass handle: 61054
2026-03-10 17:12:20.575 [info] Launching SSH server via shell with command: type “C:\Users[local-username-short]\AppData\Local\Temp\cursor_remote_install_[uuid].sh” | ssh -T -D 61055 [remote-ip] bash --login -c bash
2026-03-10 17:12:20.575 [info] Establishing SSH connection: type “C:\Users[local-username-short]\AppData\Local\Temp\cursor_remote_install_[uuid].sh” | ssh -T -D 61055 [remote-ip] bash --login -c bash
2026-03-10 17:12:20.576 [info] Started installation script. Waiting for it to finish…
2026-03-10 17:12:20.576 [info] Waiting for SSH handshake (timeout: 120s). Install timeout: 30s.
2026-03-10 17:13:31.107 [error] Error installing server: This operation was aborted
2026-03-10 17:13:31.108 [info] Deleting local script C:\Users[local-username-short]\AppData\Local\Temp\cursor_remote_install_[uuid].sh
2026-03-10 17:13:31.108 [error] Error deleting random file C:\Users[local-username-short]\AppData\Local\Temp\cursor_remote_install_[uuid].sh: Error: EBUSY: resource busy or locked, unlink ‘C:\Users[local-username-short]\AppData\Local\Temp\cursor_remote_install_[uuid].sh’
2026-03-10 17:13:31.111 [error] Error resolving SSH authority This operation was aborted

Steps to Reproduce

When I create a new window and select a Linux server to connect to, an error occurs. Moreover, I have deleted the cache of the cursor on the server and extended the waiting time for the connection from 30 seconds to 5 minutes.

Operating System

Windows 10/11

Version Information

Version: 2.6.11 (system setup)
VSCode Version: 1.105.1
Commit: 8c95649f251a168cc4bb34c89531fae7db4bd990
Date: 2026-03-03T18:57:48.001Z
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.22000

Additional Information

No VPN or proxy is being used.

The Remote SSH extension could be used in VS Code.

There is sufficient disk space available on the server.

The latest versions of Cursor, Remote SSH, and all dependencies are installed.

Attempts to reinstall the Remote - SSH extension, clear all caches and temporary files, and reinstall Cursor did not resolve the issue.

The Remote SSH extension can be used on a new computer with a Windows system. The cursor and plugin versions of the two PCs are the same.

he server I’m connected to is CentOS Linux release 7.9.2009 (Core)
Linux version 3.10.0-1160.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the detailed report and logs.

The most likely cause here is a glibc incompatibility. Cursor Server requires glibc >= 2.28, but CentOS 7.9 ships with glibc 2.17, which is below the minimum. The install script tries to set up cursor-server on the remote, but the binary can’t run, so the process hangs until the timeout kicks in and you get “This operation was aborted”.

To confirm, could you SSH into the server manually and run:

ldd --version

If it shows 2.17 (or anything below 2.28), that’s the root cause.

This is a known limitation. Similar reports here: Remote-ssh: This machine does not meet Cursor Server's prerequisites

Unfortunately there’s no simple workaround on the Cursor side for this. Your options are:

  • Upgrade the remote OS to something with glibc >= 2.28 (for example CentOS 8+, Rocky Linux 8+, Ubuntu 20.04+). CentOS 7 reached EOL in June 2024.
  • Check what Cursor version the other working PC is running. It’s possible an older Cursor version shipped a cursor-server binary compatible with glibc 2.17. If that PC is on an older version, that would explain why it works there.

Also, about the timeout setting: you can increase it with remote.SSH.connectTimeout (in seconds, for example 180 or 300) in Cursor settings. But in your case, increasing the timeout alone won’t help if cursor-server can’t start because of glibc.

Let me know what ldd --version shows on the server.

1 Like

Thank you very much for your reply. The version of glibc is exactly 2.17. I will check the cursor version of another computer and then reply to you.Regrettably, I am unable to upgrade the OS to CentOS 8. Therefore, I have tried many IDEs to solve the problem of remote connection development. Although Visual Studio Code can connect, it has some flaws.

1 Like

This is the Cursor and Remote SSH version of my operational computer, which is exactly the same as the previous one.

Version: 2.6.12 (system setup)
VSCode Version: 1.105.1
Commit: 1917e900a0c4b0111dc7975777cfff60853059d0
Date: 2026-03-04T21:41:18.914Z
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200
Remote SSH Version:1.0.46

Glibc 2.17 confirms the issue. Cursor Server requires glibc >= 2.28, and CentOS 7.9 is below that.

About the second PC, the versions are actually slightly different. The broken one is on 2.6.11, and the working one is on 2.6.12. But it’s probably not the client version. More likely, the working PC is using a cached cursor-server on the remote server that was installed earlier with a compatible version.

Can you check this on the remote server:

ls -la ~/.cursor-server/bin/

If you see a cursor-server binary there, that’s a cache from a previous install. When the broken PC connects, it tries to install a new cursor-server that’s no longer compatible with glibc 2.17, and it crashes.

You can try updating the broken PC to 2.6.12 so it matches the working one. But if the cursor-server cache on the remote machine gets overwritten, the issue will likely show up on the working PC too.

Sadly, the real fix is upgrading the OS on the remote server, like Rocky Linux 8+ or Ubuntu 20.04+. CentOS 7 went out of support in June 2024, and newer cursor-server builds aren’t compatible with it anymore.

Let me know what the ls output shows on the server.

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.