Can't get remote debugging to work with JetBrains Rider

Okteto CLI is working great, except I cannot get the remote debugging to work.

I am able to set everything up, and test the SSH connection from within the Rider UI, however, when I try to attach to a remote process, no processes get ever listed. There is just a message at the bottom of the IDE saying Rider is checking for the remote debugging tools. It typically installs those if they are missing.

So I tried using VSCode. With VSCode I can see the remote process (the one I started in the Okteto container using dotnet watch run -c debug), however, when I try to attach to it I get a message about insufficient permissions for vsdbg. From what I found it’s because the okteto container is running as root and I am running a different user in my Linux distro (openSUSE Tumbleweed).

I am not very proficient with Linux, so I couldn’t get this to work. But I am wondering if it’s the same issue of root vs non-root user when trying to debug in Rider.

Has anyone ran into this issue or does anyone have Okteto and remote debugging working with JetBrains Rider on Linux?

Thank you!

Hey Maxt! Would you mind sharing your okteto.yaml file, and the error message you’re getting from VSCode? I don’t think the root vs non-root is the issue, although it’s hard to discard.

Could this be the issue you are running into?

Hello Ramiro,
Thank you for replying so quickly! I watched some of your webinars about Okteto, so I am honored you are the one answering my post. :beers:

Okteto yaml looks like this:

    command: bash
    remote: 8888

The error is:

And I am trying to attach to this process:

Nice meeting you online! Excited to ‘hear’ that you’ve seen some of our webinars. I hope they were helpful!

Can you share your launch.json configuration? Or how are you configuring the remote debugging? I’m assuming the error you mention happens when you try to connect the debugger; is that correct?

1 Like

I haven’t configured the debugger in VSCode, I didn’t see that part mentioned in the ASP.NET Core tutorial, since it assumes the example repo is being cloned.

This gives me the next step in troubleshooting. I’ll let you know if I get it working. :smiley:

Thank you for pointing me in the right direction. I’ll get back to you with the results and with the Rider piece of the puzzle. :beers:

I was able to get VSCode to work by installing vsdbg in the okteto container and using a slightly modified launch.json from the core example repo.

I am guessing Rider needs to have the remote debugging tools installed in the Okteto container as well.
I’ll work on figuring out how to do that.

Thank you and sorry for the false alarm! :smiley: :beers:

1 Like

I was able to get Rider to install the remote debug tools, but they are coming up with a Rider specific error (ENUMERATOR_PARENT_PROCESS_PID is not defined) which has nothing to do with Okteto. I’ll have to open a ticket with JetBrains. :frowning:

1 Like

Interesting! Would you mind sharing the link to the rider ticket? (and also to the configuration that worked for

Here is the link to the bug report.

They haven’t replied yet. I’ll post the config tomorrow. I’m rebuilding my Linux distro today :smiley:

Here is the config in Rider (with a successful connection test):

Here is the error:

Here is the path where Rider installs the remote debug tools on the replacement (Okteto) container:

Instructions for installing the tools here

sorry for the message spam but it won’t let me post more than one screenshot per message. :smiley:

So far no response from JetBrains.

Does anyone have okteto remote debugging working with Rider on Linux with a local cluster (kind, minikube, krd, etc.) with the standard .net7 or .net8 SDK image?


I spent quite a bit of time today digging into this and it looks like whatever SSH server comes with Okteto doesn’t work wirh JetBrains Rider remote debugging. Or the way it’s configured is not supported.

I had the same exact issue with tool.

So I scripted out installation of either JetBrains SSH Server or OpenSSH (per their documentation) inside the “replacement” container, and using eithrer one, I was able to connect, list the processes, and attach the debugger (after forwarding the SSH port manually with kubectl).

Maybe I was doing something wrong, but that was my experience with Rider and Okteto/

Thank you again for looking into it! :beers:

1 Like

Thanks @maxt ! We wrote a minimalistic SSH server for Okteto. I wonder if we need to support any specific protocols that Rider needs.

I’ll do some testing this week. I wasn’t able to replicate this with IntelliJ or Pycharm. Not sure what’s different about Rider.

@maxt I spent some time tonight, and I think I was able to get it to work. I put the steps I followed on this repository. It’s not super solid, but I was able to launch the container, install the debug tools, and attach the debugger, and hit a breakpoint.

Take a look and let me know what you think?

@ramiro had the same issue (so whatever SSH server they use, doesn’t work with Rider either). I didn’t realize you wrote your own SSH server and weren’t using some eixsting product like OpenSSH.

But yeah, my experience ended up being same as yours, I had to automate the installation of the JetBrains SSH Server or OpenSSH server and I got both to work.

Maybe you can reach out to JetBrains to see what’s so special about Rider compared to PyCharm? I am surprised none of the other Okteto users reported this before. Maybe nobody codes in .net? Or maybe nobody debugs their code? :laughing:

1 Like

We have community members that use IntelliJ, RubyMines, Goland, and PyCharm. You are the first that mentions Rider :stuck_out_tongue: . All the dotnet + okteto developers I know use Visual Studio Code.

I have a contact at JetBrains, I’ll try to get more info on this. Thanks for the extended details, glad you have a working setup!

1 Like