Description of problem: Starting vinagre with RDP it closed the connection Version-Release number of selected component (if applicable): fedora 20 vinagre 3.10.2 How reproducible: start vinagre and an RDP session Additional info: If you start it in a terminal, the gui start and you can see password request but in the terminal and not in the gui.
Here is the full display of what I see when vinagre is started from the command line. This bug is also being tracked by Vinagre's Bugzilla as bug#724133. - Chris [cmeyer@fort1 ~]$ vinagre connected to aa1:3389 Password: [cmeyer@fort1 ~]$ vinagre connected to aa1:3389 Password: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: CERTIFICATE NAME MISMATCH! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The hostname used for this connection (aa1) does not match the name given in the certificate: aa1.cesa10.loc A valid certificate for the wrong name should NOT be trusted! Certificate details: Subject: CN = aa1.cesa10.loc Issuer: CN = aa1.cesa10.loc Thumbprint: 56:5e:23:dd:dc:23:c2:ba:59:b1:37:f9:98:93:98:cf:5b:66:76 The above X.509 certificate could not be verified, possibly because you do not have the CA certificate in your certificate store, or the certificate has expired. Please look at the documentation on how to create local certificate store for a private CA. Do you trust the above certificate? (Y/N) Error: Could not read answer from stdin. SSL_write: Failure in SSL library (protocol error?) Authentication failure, check credentials. If credentials are valid, the NTLMSSP implementation may be to blame. Y connected to aa1.cesa10.loc:3389 Password: Certificate details: Subject: CN = aa1.cesa10.loc Issuer: CN = aa1.cesa10.loc Thumbprint: 56:5e:23:dd:dc:23:c2:ba:59:b1:37:f9:98:93:98:cf:5b:66:76 The above X.509 certificate could not be verified, possibly because you do not have the CA certificate in your certificate store, or the certificate has expired. Please look at the documentation on how to create local certificate store for a private CA. Do you trust the above certificate? (Y/N) Error: Could not read answer from stdin. SSL_write: Failure in SSL library (protocol error?) Authentication failure, check credentials. If credentials are valid, the NTLMSSP implementation may be to blame.
I am experiencing the same issue after upgrading from Fedora 19 to 20. I didn't have any such issues when I was using vinagre on Fedora 19.
I have the same issue as well. Reminna (with the rdp plugin) seems to handle it properly. Seems like I have two issues (I'll file a bug for the password one)... RDP connections that require a password aren't prompted for one (except on the terminal). Once I provide the password it has the above error about the certificate. Remina prompts for the password (and has it in the connection dialogue), then asks if I want to trust the certificate.
Upstream bug... https://bugzilla.gnome.org/show_bug.cgi?id=724135
I can confirm this issue as well. Upstream did a simple 's/rdesktop/xfreerdp/g'[1] without considering the behavioural differences between them (and with the freerdp in rawhide this is even worse[2]). Therefore, I see a few possible solutions: * Revert to using rdesktop by changing the Requires: and adding the following to %prep: sed -i -e 's/xfreerdp/rdesktop/g' plugins/rdp/vinagre-rdp-tab.c po/*.po * Continue using xfreerdp and add the proposed patch in GNOME BZ#724135. I have not tested this patch and it was rejected upstream (although not really for technical reasons per se). * Add a patch with an upstream commit[3] which uses the freerdp API directly instead, which should eventually land in F21. I have tested this on F20, and does solve password handling but not certificate mismatches, so it's not a complete fix. It is also a *very* recent change, so I'm not really ready to suggest it yet. Under the circumstances, I think the best immediate solution is to revert to rdesktop for F20, and make sure that new backend is completely fixed for F21. [1] https://git.gnome.org/browse/vinagre/commit/?id=da9eed5 [2] https://bugzilla.gnome.org/show_bug.cgi?id=724136 [3] https://git.gnome.org/browse/vinagre/commit/?id=7ac600b
(In reply to Yaakov Selkowitz from comment #5) > * Revert to using rdesktop by changing the Requires: and adding the > following to %prep: > > sed -i -e 's/xfreerdp/rdesktop/g' plugins/rdp/vinagre-rdp-tab.c po/*.po Ping for F20? > * Add a patch with an upstream commit[3] which uses the freerdp API directly > instead, which should eventually land in F21. I have tested this on F20, > and does solve password handling but not certificate mismatches, so it's not > a complete fix. It is also a *very* recent change, so I'm not really ready > to suggest it yet. This appears to be implemented upstream (post 3.13.4), so should eventually land in F21.
(In reply to Yaakov Selkowitz from comment #6) > (In reply to Yaakov Selkowitz from comment #5) > > * Revert to using rdesktop by changing the Requires: and adding the > > following to %prep: > > > > sed -i -e 's/xfreerdp/rdesktop/g' plugins/rdp/vinagre-rdp-tab.c po/*.po > > Ping for F20? Packages available here: https://copr.fedoraproject.org/coprs/yselkowitz/f20-misc/ > > * Add a patch with an upstream commit[3] which uses the freerdp API directly > > instead, which should eventually land in F21. I have tested this on F20, > > and does solve password handling but not certificate mismatches, so it's not > > a complete fix. It is also a *very* recent change, so I'm not really ready > > to suggest it yet. > > This appears to be implemented upstream (post 3.13.4), so should eventually > land in F21. 3.14.1-1.fc21 works for me.
I just installed & fully updated RHEL7 Workstation & confirm this is still an issue or is a issue with RHEL7: connected to 192.168.123.218:3389 Password: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: CERTIFICATE NAME MISMATCH! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The hostname used for this connection (192.168.123.218) does not match the name given in the certificate: WIN7-PRO A valid certificate for the wrong name should NOT be trusted! Certificate details: Subject: CN = WIN7-PRO Issuer: CN = WIN7-PRO Thumbprint: b7:44:3a:54:c9:e8:f6:06:91:d6:ad:0c:3a:79:aa:c1:24:fc:3f The above X.509 certificate could not be verified, possibly because you do not have the CA certificate in your certificate store, or the certificate has expired. Please look at the documentation on how to create local certificate store for a private CA. Do you trust the above certificate? (Y/N) Error: Could not read answer from stdin. SSL_write: Failure in SSL library (protocol error?) Authentication failure, check credentials. If credentials are valid, the NTLMSSP implementation may be to blame. ^C I installed remmina.x86_64 and remmina-plugins-rdp.x86_64 That setup works so far...... Whole point of RHEL is stability & things are supposed to work! I hope this gets fixed......
This does work for me on EL 7.1 with rdesktop but not with vinagre, nor with remmina with a custom certificate of the windows 2k8r2 server, when your password must be renewed. hope this gets fixed.
Maybe this error message from the commandline is useful, remmina and vinagre actually generate the same message: "SSL_read: Failure in SSL library (protocol error?) Authentication failure, check credentials. If credentials are valid, the NTLMSSP implementation may be to blame." HTH
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Can this bug please be moved to rhel 7.1 ?