Windows RDP and Remmina: “Unable to connect to RDP server”

If you’ve been using Remmina to RDP to a Windows machine for some time and then all of suddenly find yourself running into the error Unable to connect to RDP server <address>, take a minute to read my experience before you go through some possibly-unnecessary steps.

I occasionally reboot my modem and router, and after doing so tonight, I found I was unable to RDP into a machine running Windows 7 Ultimate on my LAN from Remmina. I immediately checked to see if I could RDP to a Windows Server machine on the same LAN from the same Remmina client and could. So, I ruled out Remmina being the problem – or so I thought.

My next check was at the network. I figured that maybe the machine was either not connected to the network or had been assigned a different IP. So I then connected a monitor the machine and checked via ipconfig to verify that the IP address was the same. I still decided to reboot my router again.

Next, I checked and rechecked the RDP settings on the Windows machine to ensure that RDP was enabled. Everything looked fine on that end, so I moved to the firewall settings. The firewall was set to allow access to RDP on the machine.

Next, I went to the net for support. I searched “unable to RDP into Windows” and naturally found lots of various explanations and solutions. Knowing that I have VirtualBox setup on the computer with network drivers installed, I decided to narrow my search to include that. That’s when I found explanations regarding issues caused by the Host-Only virtual network connection that Windows sees as an “unidentifiable” network connection type. Having had issues with this limiting my network access on a computer in the past due to Windows taking precautions in thinking it is connected to an insecure network, I jumped at several solutions that involved registry edits to tell Windows that the network connection was virtual and host-only – and that it terminated at the machine itself. Re-enabled the driver and found problem was not resolved.

I then decided to boot into Windows on my laptop and see if Windows’ own RDP client could connect to the machine. It did, but the connection seemed sluggish. I then became suspicious that either the network or the machine’s NIC were somehow at fault – which didn’t rule out in my mind that the connection on the machine created by VirtualBox could be to blame as well. I then went into the Network and Sharing settings on the machine and disabled the connection. Rebooted the machine and found myself facing the same problem.

Finally, I wisened up and searched for help: “unable to connecto to Windows RDP using Remmina” and found the solution to my problem. Again, there were several suggested solutions, but I did find the one that worked for me. One solution suggested changing the Advanced > Security value in the connection’s profile in Remmina to RDP. This not only didn’t fix my problem, but caused additional problems with connecting to the machine.

The solution, surprising enough, was as simple as removing an entry in a file. I simply opened .~./freerdp/known_hosts and removed the line that corresponded to the host. I restarted Remmina and tried to connect, getting prompted to accept the host’s key, and was happily connected. Was a little agitated that I spent so much time and work trying to resolve a problem that was so easily fixed, but happy to again have the ability to RDP into my machine.

23 thoughts on “Windows RDP and Remmina: “Unable to connect to RDP server”

  1. Thanks for this. It looks like Windows Server (I’m using 2012) periodically generates a new certificate for RDP connections. If I look in the “LocalMachineRemote Desktop” certificate store, I can see a certificate that was created relatively recently (about 2 weeks ago).

    I can’t see any correlation between that certificate and the value in the known_hosts file, but the new certificate seems to be the cause of the problem.

    I deleted the value from known_hosts, got the “Do you trust this key?” prompt and it’s working again.

    It’s worth noting that I had to set the security mode back to ‘Negotiate’ to get this working.

  2. I deleted the value from known_hosts, got the “Do you trust this key?” prompt and it’s working for me.

    Thank you.

  3. Hi there, this solution doesnt fix the problem.

    Since 3 days I cant access 4 of my servers.
    If I remove or edit the know_hosts the cert will be prompt again but I will still have the issue :s

    • Since you’re getting the prompt to accept the connection, it’s a good sign that the problem isn’t with your network and that the RDP service is running on the machine you’re trying to connect to – though I wouldn’t rule out the issue still possibly being with one of those two, just doesn’t appear that way. The next thing I would check are some configurations in the profile for your RDP session. I assume you have the Protocol set to RDP, but sometimes you might have to also have the Security configuration set to RDP as well – and it’s located under the Advanced tab for the connection profile. If that still doesn’t work and you’re sure you have the server address and login credentials correct, then my advice would be to start verifying the host and client can communicate on the network and go from there. As I pointed out in the post, it usually ends up being something simple – but you rarely find it before going through a bunch of painstaking steps to ensure it’s not something else first.

  4. “The solution, surprising enough, was as simple as removing an entry in a file. I simply opened .~./freerdp/known_hosts and removed the line that corresponded to the host.”

    Novice Linux user here…..what does this mean? Can somebody walk through the steps to “remove an entry in a file”? I do not know what file to open or where to find it. Any help will be much appreciated.

    • In Linux, “~” typically points to your home directory, and so the path “~/” is essentially the same as “/home/brad” for instance, assuming “brad” is your username on your system. It really only matters if you’re navigating to the folder by command line.

      When you open your home directory in the GUI file manager, the files and folders you see are not all that are actually there. Many are hidden and used for configuration and whatnot. The folder I was referring to in this post is in a hidden directory within your home folder. You can show hidden files/folders by the keyboard shortcut CTRL+H when in the file manager. You’ll see “.freerdp” as a folder within your home folder after doing this. Go into that folder and you’ll see the “known_hosts” file that you need to edit. Double-clicking the file will open the default text editor on your system (such as gedit, kate, etc.).

      Once you have that file open, you just need to remove the line with the IP and hash key for the system you’re having the trouble with and save it (CTRL+S just like in Windows for saving an open text document). You should probably make sure Remmina is not running when you do this, just in case it happens to save this information on closing (and overwrite your changes).

      I typically restore the settings to not show hidden files/folders by hitting CTRL+H again, for the sake of avoiding clutter when I don’t need to see it in my file manager, but that’s a matter of preference.

      Hope that helps.

  5. Hi Jerry. I very much appreciate your help!

    I followed your instructions, but there are no files in the .freerdp folder. I suppose this is because I cannot get Remmina to connect to the Windows computer.

    Do I need to change any settings on the remote Windows computer to allow Remmina to connect via RDP? Do you have any other suggestions as to why Remmina is not establishing a connection to the Windows Remote Desktop?

    Brad

    • No files mean you never succeeded to connect on your PC.
      Check “Security” setting on the “Advanced” tab in your connection’s properties in Remmina.

  6. I’ve been using Remina over Ubuntu 15.10 and tried to connect the Windows 10 VM hit the same issue. I only did change the security from negotiate to TLS and VIOLA it worked!
    Goodluck all victims for now on 🙂

  7. Great! Thank you for the solution. I can add that the location of known_hosts on Linux Mint 18.3 is ~/.config/freerdp, not ~/.freerdp

  8. Why nobody comments that the error messages shows up again after you try to reconnect again? So you need to empty the freerdp known_hosts all over again. Does anyone know a script that could automate the deletion or emptying of known hosts on rdp session ned?

Leave a Reply to Jerry Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.