Cannot connect to RDP if host fingerprint changes

[Jim Rorie]

After upgrading to Precise, all my existing connections for RDP are no longer functional. I get the following message:

Unable to connect to RDP server XXXXXX

All connections are in a windows domain. Have tried various O/S's; Win 7, XP, 2008 R2. Same result. Have tried RDP, TLS, NLA and Negoitate. All systems are set to allow all types of RDP traffic. Have verified that the systems are up and function from a Win7 Vbox. Tried creating a new connection, same result.

Anything else that would be of help? Debug info attached. (Hopefully)

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: remmina 1.0.0-1ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-17.27-generic 3.2.6
Uname: Linux 3.2.0-17-generic x86_64
ApportVersion: 1.93-0ubuntu2
Architecture: amd64
Date: Thu Mar 1 09:39:27 2012
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: remmina
UpgradeStatus: Upgraded to precise on 2012-02-29 (0 days ago)

[Jim Rorie (jfrorie)]

Hmm. It connects using IP's only, now. I'm wondering if an external library changed.

[Jim Rorie (jfrorie)]

Remmina now requires a FQDN, even in a local domain.

ie.server.domain.local

This is a change from previous versions.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jim Rorie (jfrorie)]

now it refuses to connect with a FQDN. Im starting to think this is something external changing...

[Christopher Rawlings (rawlinc)]

--- Overview ---
I installed Precise Beta 2 (updated to most current packages as of 4/19/12) and I've been running into the same issue as described in the initial bug report. I was getting the 'Unable to connect to RDP server XXXXXX' error dialog when trying to connect my saved RDP entries. Remmina was also displaying the following messages on the command line:

   SSL_write: Failure in SSL library (protocol error?)
   Authentication failure, check credentials.
   If credentials are valid, the NTLMSSP implementation may be to blame.

Jim R. also reports not being able to connect to RDP using a hostname/FQDN, but from my testing that is a second issue and should be filed in a separate bug report. I'll explain the both problems below.

For reference, Remmina package version I am testing with is: 1.0.0-1ubuntu5.

--- Problem #1 ('Unable to connect to RDP server XXXXXX') ---

For this problem I should note that I transfered my ~/.remmina directory from my previous Ubuntu 11.10 installation to the fresh installation of Precise Beta 2 since I had a lot of RDP entries defined. This caused a problem because Remmina can apparently store passwords for RDP entries in one of two locations: in the same file where the RDP information is stored (~/.remmina/<specific-entry>.remmina) or in the gnome keyring. Apparently in Ubuntu 11.10, the passwords for my RDP entries were being stored in the gnome keyring, but in Precise Beta 2 the package 'remmina-plugin-gnome' which gives remmina the ability to work with the gnome keyring is not installed by default. Therefore, it wasn't able to pull my password out of the keyring and failed to connect to the RDP server.

Problem #1 Workaround: Install 'remmina-plugin-gnome' and/or edit each of your RDP entries and re-enter the password. If 'remmina-plugin-gnome' is not installed, when you re-enter a password, it will get saved in ~/.remmina instead of the gnome keyring.

To the Ubuntu package maintainer: Would it be a good idea to define the 'remmina-plugin-gnome' package as a dependency of either the 'remmina' or 'remmina-plugin-rdp' packages, so that it is installed automatically (I'm not quite sure which package it should be a dependency of since I don't know if other remmina plugins besides the rdp one can use the gnome keyring functionality)?

--- Problem #2 (Unable to connect to RDP session via a hostname or FQDN) ---

I'm not sure if this is the exact same thing Jim R. is seeing, but RDP sessions can connect with an IP address, but there are problems when trying to use a hostname or FQDN on Precise (not sure if this also happens with vnc, nx, etc). When trying to use a hostname or FQDN, I will sometimes see the following dialog box message without any progress for a while:

   Connecting to 'XXXXXX' ...

At first, I thought Remmina would stay on this dialog box and never connect but then I decided to wait a little longer and it eventually connects after about 120-130 seconds and asks me to accept a certificate. For some hosts I see this delay, but for other hosts the RDP session connects immediately and I don't get asked to accept a certificate. After a little troubleshooting, it looks like this is related to ip...

[Jim Rorie (jfrorie)]

I'm going to remove myself from the bug, which is ironic since I filed it. I'm fairly certain that my problem is external from remmina. I think it resides in /etc/nsswitch.conf with a weird problem with avahi and DNS.

The rest of you carry on...

[lots (cairo)]

I'll try to provide some additional informations for this bug:

1) Remmina always fails with following errors:
    a) started from console/terminal (to see some additional info):
myUsername@myhost:~$ remmina
Remmina plugin VNC (type=Protocol) registered.
Remmina plugin VNCI (type=Protocol) registered.
Remmina plugin RDP (type=Protocol) registered.
Remmina plugin RDPF (type=File) registered.
Remmina plugin RDPS (type=Preference) registered.
Remmina plugin SFTP (type=Protocol) registered.
Remmina plugin SSH (type=Protocol) registered.
unable to connect to (null):3389
Error: protocol security negotiation failure

    b) shows error window:
"Unable to connect to RDP server dc-1.myDomain.cz"

which corresponds to last two lines from a)
"
unable to connect to (null):3389
Error: protocol security negotiation failure
"

2) Version and configuration settings:

   a) Ubuntu versions (it doesn't matter):
        - 11.10
        - 12.04

   b) Remmina/FreeRDP:
        - Remmina 1.x
        - FreeRDP 1.x

   b) Remmina RDP settings:
        - Server (Tab/Basic):
        dc-1.myDomain.cz
        - Security (Tab/Advanced):
        Negotiate (Default)

Note:
It doesn't matter what I choose in Security - Remmina defaults (Negotiate) or NLA, TLS or RDP - Remmina always fails/refuse connection.

[lots (cairo)]

see screenshot attached

[lots (cairo)]

see second screenshot attached

[lots (cairo)]

After several weeks and from time to time unsuccessful operations, eg.:
- revert back to previous version,
- install latest version,

I've decided to clean everything from my system - everything which touch RDP:
- Remmina,
- RDP plugin,
- xFreeRDP,
- libFreeRDP,
...

problem disappeared, I don't care if it was two versions of libFreeRDP (.0 and .1 I thing).

Now I think several reasons exists/leads to these "symptoms":
- multiple versions of libFreeRDP,
- ...

Sorry for my mystake, but there are also uncomfortable troubleshooting:
- only running Remmina from console shows little bit more informations,
- on lucky by using xFreeRDP from console for troubleshooting I've found the reason of one common "Unable to connect" notification (it was changed fingerPrint of server)
- debug windows doesn't function,
...

So, If you see above, you can find out several ways to troubleshoot the reasons - why the Remmina doesn't connect to your servers.

[Daniel Di Sarli (danieleds0)]

Can you try deleting the file ~/.freerdp/known_hosts ?

[Todd Reed (toddnamy)]

I can confirm that deleting "~/.freerdp/known_hosts" does indeed fix the problem for me.

[Miku Laitinen (miku-laitinen-gmail)]

I had two RDP connections in Remmina and the other one stopped working all of a sudden. I didn't remove ~/.freerdp/known_hosts, but I did remove the fingerprint line of the defunct connection. It fixed the problem.

[Mark Foster (blakjak)]

I've been having no end of problems with Remmina - intermittantly - though I did notice that changing to an FQDN worked well (thanks for that one). I see this as a regression - what about home LAN's that don't have FQDN for hostnames? I've been forced to install xtightvncviewer and grdesktop as alternates despite having grown quite fond of Remmina since being introduced to it with 12.04.

[Paul (treepata)]

Hi all,

I was just confronted with this problem as well, even although it was not related to my Precise Upgrade (which was done earlier). It might be related to a regular update using the Update manager last week.

In any case, Remmina refused to make the connection, giving the same error message the OP noted. Using rdesktop from the concole did not give any problems, so I soon found out Remmina was causing problems.

Removing the ~/.freerdp/known_hosts file solved my troubles however, so happy that you guys provided that solution here.

[Nicolas Briche (nbriche)]

Just got bit by this bug after upgrading to Raring. Deleting ~/.freerdp/known_hosts also corrects the problem, although it seems Remmina doesn't print anything to the console anymore.

[sneakypete (sneakypete81)]

Looking through the recent comments, it seems that deleting ~/.freedp/known_hosts (or using FQDN) solves the problem.

This is fixed upstream: https://github.com/FreeRDP/Remmina/issues/68

[Aaron Roydhouse (aaron-roydhouse)]

I just got hit by this on 13.04 / Raring after a update pushed yesterday. Suddenly Reminna decided not to connect to any of my hosts just saying connection failed. After moving aside ~/.freerdp/known_hosts file I could connect again.

Comparing the before/after known_host files, freerdp appears to have suddenly decided that all the fingerprints for all the hosts I connect to have simultaneous changed. Every computer I connect to now is displaying and storing a new an different fingerprint value in known_hosts from the previous file. I assume this is because I shifted to a parallel universe in my sleep?

[enekux (enekux)]

Thanks for the solution! I also confirm that deleting "~/.freerdp/known_hosts" does fix the problem.

[Yajo (yajo)]

That workaround worked also for me.

[JuanJo Ciarlante (jjo)]

See http://paste.ubuntu.com/7261713/ for a ~5lines script that will workaround this without removing ~/.freerdp/known_hosts in case you value what's there already (it won't update it either, tho).

[Mossroy (mossroy)]

Same issue. The workaround worked for me too.

[tallien (tallien)]

I had this problem in Remmina after upgrading to 14.04 LTS. Was working fine on 13.10 before that. I tried two fixes:

- renamed the ~/.freerdp/known_hosts file

- changed the Security setting for the problem profile in Remmina from Negotiable to TLS (found that fix in this post http://www.bauer-power.net/2013/10/unable-to-connect-to-rdp-server-in.html#.U1jtCo86MgR )

Either one or both of the fixes must have worked, as I am now able to connect with no problems.

[Tristan (tristantonks-b)]

I have resolved this a number of times on my machine but each time the solution has been different (Alway one of the above). I'm not a programmer so this is pretty arduous to be honest. If there was something I could do to help identify I would be pleased to assist.
It is a very random issue and it can go for months without a problem but when it does crop up its a real pain in the ***.

[theghost (theghost)]

Also confirmed for 14.10

[Mossroy (mossroy)]

I faced this issue one more time, and I had forgotten the workaround in between...

At least Remmina should display a meaningfull error message, sot that the user does not suspect something completely different (like the remote server being down)

[Jamie Lokier (jamie-shareable)]

I had the same experience *without* any upgrade to Ubuntu.

The Remmina client simply stopped working one day.

Today I spent several hours on a Windows 7 box trying to work out why "Unable to connect to RDP server". Was it the Windows firewall? Was it McAfee being expired? What does the Windows event log tell us? (It tells us there's a connection, a session is started, and then it's disconnected. Nothing useful.) Was there an authentication problem? How about connecting with no user/password? Was it some obscure need-to-login-at-the-console-first session problem (as happens with SSH sometimes).

No, in the end the forums gave the answer: It's Remmina, not Windows. Delete ~/.freerdp/known_hosts and it'll work.

I just removed one line from that file, and all my problems were solved. Meanwhile the changes to Windows to try and find the problem were a waste of time and maybe not such a good idea :-)

I don't know what went wrong with the signature in ~/.freerdp/known_hosts - as I didn't upgrade the Ubuntu client, and I didn't do anything on the Windows box either (it's been running for years).

The only thing I'm aware of is Windows 7 rebooted itself after an automatic update somewhere between Remmina working and not working. But even reboots don't normally cause this problem.

I think this might have happened for me once before. Like #27, the workaround is hard to remember because the error message doesn't say anything useful.

This is on Ubuntu 13.04, remmina-1.0.0-4ubuntu2, libfreerdp-1.0.1-2ubuntu1.

Thanks.

[Mossroy (mossroy)]

I also confirm that I had this issue without any Ubuntu upgrade, on Ubuntu 14.04 (with latest updates).
Maybe the cause might be an update of Windows itself, that would have modified the OS signature?

[cmcanulty (cmcanulty)]

I also have this problem in xubuntu 14.04 the above patch did nothing for me. I have to remove known_hosts before every rdp windows connection (not for remote xubuntu) then it asks for a certificate OK every time. Very irritating as I manage 17 remote computers, but worse is how long it took to even find the known_hosts tweak. One windows 7 I can never connect to even after triple checking every possible cause. Please fix this soon.

[cmcanulty (cmcanulty)]

this manpage seems to offer the options needed for a fix but how to permanently install them is beyond me

http://manpages.ubuntu.com/manpages/precise/man1/xfreerdp.1.html

[Chris Carlin (crcarlin)]

Note that a restart of remmina was required after deleting that file.

[Hawk (beehock)]

Happening for 14.04 as well. removing known_hosts works

[Brian Slezak (br7an)]

Throwing my voice in to say this affects me as well on 14.04. Removing the associated fingerprint from ~/.freerdp/known_hosts and reconnecting works.

[cmcanulty (cmcanulty)]

Good news, the problem disappeared after upgrade to 16.04 (lots of other system bugs appeared however). Now I can reliably connect via remmina with vnc and xrdp with no tweaks at all. However it does pop up with an irritating message with every connection saying the certificate has changed and I have to click OK. But I can live with that now that everything else works on remmina.

[Michael (m-gruys)]

Problem is back. Removing the associated fingerprint from ~/.freerdp/known_hosts and reconnecting does not work anymore.
version:
3.22.0

[Michael (m-gruys)]

Duplicate of : https://bugzilla.redhat.com/show_bug.cgi?id=1404771