# rdesktop: RDP 4 and 5 Client Setup, Limits, and Maintenance > rdesktop is a C client for Microsoft's RDP protocol, with documented support for RDP versions 4 and 5 and a GNU-style source build. Its README states that the project is no longer maintained and warns of unreviewed security vulnerabilities. **rdesktop/rdesktop** — 🚨 rdesktop is in need of a new maintainter. Please see the home page for more details. 🚨 - Repository: https://github.com/rdesktop/rdesktop - Website: http://www.rdesktop.org - Stars: 1,356 · Forks: 386 - Language: C - License: GPL-3.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/rdesktop-rdesktop ## Why rdesktop Exists and Which RDP Servers It Targets rdesktop solves the problem of connecting a Unix-like client to a machine that exposes Microsoft's Remote Desktop Protocol. It is aimed at administrators, developers, and users who need command-line access to a compatible Windows Terminal Services or RDS system. The README says the client is known to work with Windows versions ranging from NT 4 Terminal Server through Windows 2012 R2 RDS. That is a historical compatibility statement rather than evidence of current server support. The documented protocol scope is a major constraint. rdesktop has implemented RDP versions 4 and 5. The source tree reinforces that split through separate files such as `rdp.c` and `rdp5.c`. It does not document RDP version 6, later negotiation behavior, or compatibility with current protocol extensions. The README also does not claim support for RemoteFX, modern graphics pipelines, current credential flows, or recent Windows releases. The immediate warning matters more than the age of the release list. The README labels rdesktop as no longer maintained, says it had not received a patch in many years, and reports security vulnerabilities that have not been reviewed. The repository is not marked as archived, and its last push was on 2026-05-16. Those repository facts do not override the explicit maintenance warning in the README. They mean that recent source activity alone should not be treated as a guarantee of supported security maintenance. ## rdesktop's Protocol Implementation and Source Layout The documented mechanism is a command-line RDP client. The user supplies a server name, and rdesktop attempts to connect using its implemented RDP 4 or 5 behavior. The README specifically identifies "Connection refused" as a likely indication that Terminal Services is disabled on the server or blocked by a firewall. It does not provide a packet-level protocol walkthrough, so claims about a particular negotiation sequence cannot be confirmed from the project documentation. Based on the repository layout, protocol handling is divided into recognizable C modules. `rdp.c` and `rdp5.c` correspond to the documented protocol generations. Other files cover areas such as bitmap handling (`bitmap.c`), channels (`channels.c`), clipboard redirection (`cliprdr.c`), certificate and PKIX data (`pkix.asn1_tab.c`), audio (`rdpsnd.c`), printer redirection (`printer.c` and `printercache.c`), and device redirection (`dvc.c` and `rdpdr.c`). These names show the intended implementation boundaries, but the README does not describe their internal data flow. Several files also reflect platform or sound-system variants, including `rdpsnd_alsa.c`, `rdpsnd_libao.c`, `rdpsnd_oss.c`, `rdpsnd_pulse.c`, `rdpsnd_sgi.c`, and `rdpsnd_sun.c`. That suggests the audio implementation is conditional across environments. The repository also contains `cache.c`, `pstcache.c`, `mcs.c`, `iso.c`, and `mppc.c`, but the README does not describe their responsibilities in enough detail to document caching or connection negotiation precisely. For engineers, the practical distinction is between protocol generation and product recency. Supporting RDP 4 and 5 is an explicit fact. Whether a particular server accepts those versions, negotiates a compatible session, exposes redirected devices, or enforces a security policy is controlled by the remote endpoint and cannot be inferred from the client source names. ## Building rdesktop from a Release or Source Snapshot Release versions use the documented GNU-style build procedure. The default installation prefix is `/usr/local`, while `--prefix=` changes it. Run the commands in an account with sufficient permission for the selected prefix. ```bash ./configure make make install ``` For a source snapshot rather than a release archive, the README says `./bootstrap` must first generate the build infrastructure. It explicitly says this bootstrap step is not necessary for release versions. ```bash ./bootstrap ``` After bootstrapping a snapshot, the normal configuration and installation sequence applies. The README does not provide an exact combined bootstrap command, so it is clearer to run the documented steps separately. If redirected smart-card access is required, configuration needs the PCSC-lite dependency and the `--enable-smartcard` option. The README specifies PCSC-lite 1.2.9 or later. That command enables the module but does not install PCSC-lite itself. The README gives no package-manager commands, supported distribution list, dependency names beyond PCSC-lite, or troubleshooting procedure. A source build also requires a working local toolchain and whatever prerequisites its `configure` checks. Those details are not documented in the README, so they should be checked from the build output rather than assumed. A custom prefix can be supplied during configuration. The placeholder in `--prefix=` is presented exactly as the documented option shape rather than as a literal installation path. ## Making the First rdesktop Connection The shortest documented use is to pass the Terminal Services machine name to the installed client. Replace the README's illustrative `server` name with the actual host name or address supported by that environment. ```bash rdesktop server ``` A successful connection cannot be described further from the README because it does not document startup output, authentication prompts, the graphical session, or exit behavior. The manual page is identified as the reference for command-line options, but no individual options are reproduced here. ```bash man rdesktop ``` If the client reports `Connection refused`, the README gives two likely explanations: Terminal Services is not enabled on the server, or a firewall is blocking access. This message should not be interpreted as proof of either cause. DNS failure, routing, server availability, or policy could also matter, although the project documentation does not define diagnostics for those cases. The first connection should be attempted from a controlled administrative path because the README explicitly advises caution and says reported security vulnerabilities have not been reviewed. It does not prescribe network isolation, protocol-version selection, or a security review checklist. Consequently, the documented command establishes how to start the client, not whether a deployment is acceptable for sensitive systems. ## Maintenance, Licensing, and Upgrade Burdens The README's status statement is explicit: rdesktop is no longer maintained. It also says the project had not received a patch in many years and that reported vulnerabilities remain unreviewed. The repository itself is not archived, and the last push was on 2026-05-16, but there is no basis in the README or repository metadata for describing that activity as ongoing maintenance. The listed releases end at `v1.9.0`, released on 2019-10-11, with `v1.8.6` on 2019-05-21 and a beta release on 2019-09-20. This status changes the adoption decision. An organization using rdesktop may need to inspect unreviewed vulnerability reports, compile fixes locally, track operating system changes, and verify compatibility with each remote server. The README does not promise patches, security review, or a supported upgrade path. It also does not document a rollback procedure. The repository identifies the project as licensed under `GPL-3.0` and includes a `COPYING` file. Anyone redistributing the software or preparing a modified build should review that license text and its source-offer obligations for the intended distribution. This is a repository-specific compliance checkpoint, not legal advice. Smart-card support adds another maintenance surface because it depends on PCSC-lite 1.2.9 or later and activates through an optional configure flag. The README does not describe how that module behaves on modern smart-card stacks, so enabling it requires direct compatibility verification. ## Where rdesktop Is the Wrong Choice rdesktop is the wrong choice when the target requires an RDP generation newer than 5, because the README documents only RDP 4 and 5. It is also a poor fit for a new production deployment where unreviewed security reports and the project's no-longer-maintained status would need to become the operator's responsibility. A real alternative is to use a maintained client that supports the RDP features and server versions required by the environment. The architectural difference is not cosmetic: such a client can negotiate protocol generations beyond rdesktop's documented RDP 4 and 5 scope and may track current transport, authentication, graphics, and redirection behavior. The README does not name a specific maintained alternative, version, package, command, or license, so naming one with an assumed feature set would go beyond the available evidence. For legacy environments, rdesktop may still have value because the README records compatibility from Windows NT 4 Terminal Server through Windows 2012 R2 RDS. That support can matter when a controlled client is the only practical path to an isolated legacy system. It should not be extrapolated to newer Windows releases. The client is also a poor fit when smart-card integration is mandatory but PCSC-lite and the remote smart-card redirection path have not been checked. The option exists, but the README does not document driver behavior, tested token vendors, session limitations, or failure handling. ## Conclusion Adoption is reasonable only for engineers maintaining an existing, isolated use of rdesktop against a compatible RDP 4 or 5 service. Do not choose it for a new internet-facing deployment or for environments that require current protocol support and reviewed security fixes. Verify the server implementation, any local patches, PCSC-lite requirements if smart-card support is needed, and the consequences of using code declared unmaintained before installation. ## FAQ ### Does rdesktop still support remote connections? The README documents connecting to a Terminal Services server with `rdesktop server`, but it also states that the project is no longer maintained and advises caution. The documented protocol implementations are RDP 4 and 5. ### How do I build and install rdesktop from source? A release uses `./configure`, `make`, and `make install`, normally under `/usr/local`. A source snapshot first requires `./bootstrap` to generate its build infrastructure. ### Can rdesktop connect to modern RDP servers? The README only confirms support for RDP versions 4 and 5 and names Windows NT 4 Terminal Server through Windows 2012 R2 RDS as known targets. It does not claim compatibility with newer protocol versions or current Windows releases. ### How do I enable smart-card support in rdesktop? Configure the build with `--enable-smartcard` and use PCSC-lite 1.2.9 or later. The README does not document token testing or troubleshooting. ## Sources - [License: GPL-3.0](https://github.com/rdesktop/rdesktop/blob/master/LICENSE) - [Project website](http://www.rdesktop.org) - [rdesktop/rdesktop on GitHub](https://github.com/rdesktop/rdesktop) - [README](https://github.com/rdesktop/rdesktop/blob/master/README.md) - [Releases](https://github.com/rdesktop/rdesktop/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rdesktop-rdesktop