31

Until sometime last night, I had remmina working fine. I could run RDP through an SSH tunnel and all was well.

Then it stopped working. I can get as far as the password dialog for my work machine, but then it just says Cannot connect to RDP server localhost.

I can't even find any logs that look interesting. I've re-installed remmina, cleared my .remmina directory, restarted my machine, and even restarted my gateway.

Just to make it really weird, my laptop (which has the same setup -- latest Ubuntu and Remmina) can make the connection just fine. It is even going through the same router, albeit wirelessly.

Any thoughts?

  • 1
    I face the same issue on ubuntu 18.04 and Its work perfectly once i changed the security option from negotiate to RDP from advance tab. – Paras May 30 '18 at 8:02
49

I have no idea why it worked, but I started changing settings one at a time. When I edited the connection properties, I looked on the "advanced" tab and changed the security from "negotiate" to "TLS", and voila, everything works.

Strangely, "negotiate" still works on the laptop, but at least I'm back in business with my bigger monitor :)

  • After changing from 'negotiate' to 'TLS' I saw the windows log-on screen which prompted me to change the password. So it seems that expired passwords may case the issue. Thx for the solution. – Thorsten Niehues Aug 26 '15 at 7:29
38

This just happened to me, and I found this answer which resolved the issue. Just rm ~/.freerdp/known_hosts and try again.

Apparently this happens when the keys on the tunnel server change. See this bug.

UPDATE

First link now points to a deleted answer, so here's some of the additional info from that link:

  • It seems that the "known_hosts" file contains some routing data for each server, that data becomes outdated sometimes, and when Remmina tries to connect using the outdated data, it fails. Deleting the known_hosts file solves this problem. – Erel Segal-Halevi Dec 13 '12 at 10:06

  • FWIW, my problem had nothing to do with known_hosts (as explained bellow), but everything to do with security settings: see http://www.bauer-power.net/2013/10/unable-to-connect-to-rdp-server-in.html for details. – Tomislav Nakic-Alfirevic Apr 24 '14 at 10:58

  • Totally worked, I was wondering where the certs were being stored. I had same issue for most part, was using Remmina to RDP to a certain machine, then one day it stopped working (nothing on the remote machine changed). Other RDP connections I had saved still worked, except for this one machine. It did happen to use NLA auth, which seems to be part of the problem with the newest Remmina not saving certs. – Nicholi Apr 26 '13 at 20:26

  • thanks , it used to connect perfectly then i reformatted the server and it stopped working , deleting the line for this host worked . – Bor691 Jan 15 '14 at 8:50

  • I need to use two services on same address but different ports and using this repeatedly is the only way I could connect to both. – Gringo Suave Oct 13 '14 at 18:55

  • It was sugested to add sudo in front of the rm command. As far as I see, the user removes his own file, so sudo just ads risk. Am I missing something? – Volker Siegel Jun 24 '15 at 7:24
  • I understand this is an old question and answer. One of the reason I never ever post an external link as answer or in a question is because after something that link could be DEAD like in this case. When that happens, answer could become useless. I am just pointing out the obvious or Stackoverflow should prevent users of this website posting external links. – ThN May 3 '16 at 1:16
  • 3
    FYI, the file in question appears to now be at ~/.config/freerdp/known_hosts - at least it is on my system (Linux Mint 18.1). There is also a ~/.config/freerdp/known_hosts2 which had additional information in it that might be more up-to-date. Remmina 1.20. – Chris Hillery Apr 28 '17 at 21:24
  • Or the location might be at ~/snap/remmina/current/.config/freerdp (known_hosts2 only). You need to restart Remmina for deletion to take effect. – velis Jan 28 at 8:14
4

This happened to me when I copied my remmina configuration (under ~/.remmina) from one machine to another. Perhaps the remmina versions were different; changing security did not help but deleting and recreating the connection did.

2

It worked for me by changing security to NLA for some unknown reason.

  • 2
    Welcome to Ask Ubuntu! I recommend to edit this answer to expand it with specific details about how to do this. (See also How do I write a good answer? for general advice about what sorts of answers are considered most valuable on AskUbuntu.) – David Foerster May 3 '17 at 10:27
  • 1
    Separate answers that you can upvote and downvote seems useful to me. Editing other peoples answers to insert "well, what about X", seems the opposite of useful. It's one thing to correct mistakes, go ahead and edit. But to tell a new person to go about editing instead of saying what worked for them seems the opposite of good. – Warren P Jun 13 '18 at 18:26
  • NLA didn't work for me but following a Windows update (I'll blame that) I had to change security settings from "Negotiate" to "RDP". – Richard Wiseman Jan 16 at 16:01
1

The problem is with the viewmode=1 setting in the saved conf file. If you resize the window it should refresh and start showing the session. Changing this boolean to 0 will force the window to defaults and it'll refresh on load. The problem is if you resize the window after the session has started, remmina will change this setting back.

A work around would be to set the window_maximize=0 to true and then just click/press the maximize button/shortcut to bring it back to your settings. 
window_maximize=1 
window_height=960 
viewmode=1 
Window_width=1440
0

Probably stupid answer, but the problem for me was that I tried connecting through an open Wi-Fi network (unencrypted) and remmina wouldn't allow that. Once I connected to a secure network everything worked as planned again.

  • 3
    Wouldn't it be nice if Remmina actually showed useful error messages instead of just failing? – Warren P Jun 13 '18 at 18:27
0

It could also be an issue with the certificate verification, To test if this is the problem go to:

Advanced -> check "Ignore certificate"

Be careful, with this check disabled, you may be open to man in the middle attacks. But should be fine connecting on internal networks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.