Red Hat Bugzilla – Bug 1075697
rdesktop cannot connect to systems using RDP version 6 or newer
Last modified: 2016-01-12 08:23:23 EST
Description of problem:
rdesktop is unable to connect to systems using RDP version 6 or newer
Version-Release number of selected component (if applicable):
- At will
Steps to Reproduce:
1. Configure Windows 7, 8, server 2008 or server 2012 to allow remote desktop connections, using default settings (or any version of windows that require RDP v6 or newer). This should be the radio button with the following text: "Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure)"
2. Configure users allowed to connect to the system (Administrator should be enabled by default, assuming the Administrator account is not disabled)
3. Attempt to connect to the Windows system using rdesktop
- Receive the following error message:
"ERROR: recv: Connection reset by peer"
-Establish remote graphical console session to the Windows system.
- rdesktop will work if the radio button with the text "Allow connections from computers running any version of Remote Desktop (less secure)." This is because the Windows system is allowing connections from clients using any version of RDP
- This has also been tested using an upstream version of rdesktop acquired from repoforge.org (http://pkgs.repoforge.org/rdesktop/ package: rdesktop-1.8.1-0.1.el6.rfx.x86_64) This package produces the following error:
"Failed to connect, CredSSP required by server."
would be possible to try freerdp (xfreerdp binary) which should be a (better) replacement for rdesktop introduced in rhel6.5?
That alternative has been recommended, however there is no clear notification that rdesktop is being or planning to be deprecated in favour of xfreerdp. AFAIK rdesktop is not available in RHEL 7 BETA, which also has xfreerdp, but I don't want to pass judgement on rdesktop based on this alone.
From what I've looked at in upstream, there's requests for RDPv6.x support, however information on whether or not upstream is going to move forward with it is very unclear.
What's specifically needed is some clarity on the future of rdesktop. If we continue to support it: something definitive that rdesktop will never support RDPv6.x, or add support; if not, something official that it's being deprecated in favour of xfreerdp.
(In reply to Joe Wright from comment #3)
> That alternative has been recommended, however there is no clear
> notification that rdesktop is being or planning to be deprecated in favour
> of xfreerdp. AFAIK rdesktop is not available in RHEL 7 BETA, which also has
> xfreerdp, but I don't want to pass judgement on rdesktop based on this alone.
> From what I've looked at in upstream, there's requests for RDPv6.x support,
> however information on whether or not upstream is going to move forward with
> it is very unclear.
> What's specifically needed is some clarity on the future of rdesktop. If we
> continue to support it: something definitive that rdesktop will never
> support RDPv6.x, or add support; if not, something official that it's being
> deprecated in favour of xfreerdp.
I see your point, lets ask Kevin.
Freerdp was added in RHEL 6.5 exactly from this reason (Bug 951696). Rdesktop lacks support for newer protocol versions and rdesktop upstream is almost dead. Freerdp is a replacement for rdesktop in RHEL 7. Please use freerdp if you need RDP 6 features...
Can someone provide an explanation for why this bug was closed WONTFIX? Comment 3 was seeking clarity on the future of rdesktop. Was it decided to formally deprecate it in favor of xfreerdp? Has upstream stated that it will never support RDP6? Some details here would be helpful.
Additional notes if someone drops by:
Running rdesktop to W2012R2 from Fedora 23 (rdesktop-1.8.3-2.fc23) gives the "Failed to connect, CredSSP required by server." message.
CredSSP == Credential Security Support Provider, a provider for the Windows SSP (basically, its the PAM?)
A short intro on why this thing:
The server requires CredSSP and there are two options were the first option is the easy way,
1) Downgrade security on Windows server to accept SSL/TLSv2
2) Make sure to initialize a kerberos ticket to be able to connect using CredSSP. There are a lot of guides out there how to do configure a linux kerberos client for Windows Active Directory.
I have no idea on how to do (2) but package "freerdp" which provides "xfreerdp" seems to work for me.
Otherworldy Windows command line syntax:
xfreerdp /v:$SERV:$PORT /size:1920x1080 /u:$USER /p:$PASS /compression
Sorry, I made Comment 13 private by mistake. The comment contains explanation why I closed the bug.
Credssp requires libgssglue library which is deprecated upstream and thus it doesn't make sense to port credssp functionality...