By: Sadequl Hussain | Comments (1) | Related: More > Database Administration
Problem
I am a system administrator / DBA using a Windows laptop. I can remotely connect to our Windows servers from my laptop. Some of my colleagues are using non-Windows systems like Mac or Linux. Sometimes they also need to access these boxes. How can they connect?
Solution
System administrators or DBAs often need to access Windows servers remotely. This can be for various reasons like:
- Troubleshooting low disk space
- Running Performance Monitor or Profiler
- Monitoring Windows Event Viewer
- Applying service packs
- Creating and troubleshooting scheduled Windows jobs
- Installing software like SQL Server
- Connecting to another instance from a “jump host”
- Administering Active Directory
- Etc.
Windows ships with a tool called the “Remote Desktop Client” to help connect to another Windows machine. However, there are users who do not use a Windows workstation. Particularly with the spread of open source databases, cloud technologies and the need for accessing Linux servers, a lot of engineers now use an Apple MacBook or Linux distributions like Fedora or Ubuntu.
Some of these engineers and administrators may need to access Windows hosts. It would make their job much simpler if they had tools similar to the RDP client.
In this tip we will talk about a few remote desktop clients available for Mac and Linux. We will talk about their ease of use, features, etc. In a future post, we will talk about Mac and Linux-based database client tools.
Disclaimer
Please be careful when accessing production servers remotely. In most cases, organizations have strict security principles about who can access their servers, so readers need to follow those guidelines. Also, you should not run any commands, queries, or configurations from this tutorial on a production server. In the case when you are required to access remote servers and run commands, make sure you are connected to the right server.
Although we list a number of remote clients from various vendors, this is by no means an exhaustive list. Nor do we endorse any of the products or have any affiliation with their vendors. The observations made here are purely those of the author.
Also, this tip is not about how to install and configure remote desktop clients. Each software installer package will have its own requirements and dependencies for different operating systems; it’s not possible to address every issue where the package may be failing to install or the client failing to connect to a remote server. This is more of an overview of the tools available.
Remote Desktop Clients
Before going into details, let’s talk about the features we want in a remote desktop client. We wanted tools which:
- Are free / open source or at least have a community edition available
- Have active development or product support
- Can map local resources like disk drives or folders to the remote machine
- Allow saving remote desktop sessions for easy future connection
- Allow different screen resolutions
- Enables clipboard sharing between local and remote machines
With these features in mind, let’s first see what’s available for Mac users.
Mac Clients
Microsoft Remote Desktop
For Mac users, Microsoft has released the Microsoft Remote Desktop app, downloadable from the Mac App store. The application features connection saving, easy searching of saved connections, connectivity to Azure RemoteApp and remote resources:
Creating a new connection is fairly simple and intuitive:
Standard features like mapping local directories to remote machine, sound and printer forwarding are also present:
CoRD
Out next option for the Mac platform is CoRD, downloadable from its source forge site. CoRD is also easy to use and offers most features found in other remote desktop tools.
The image below shows a local folder in a Mac system mapped to a remote Windows machine.
Royal TSX
Royal TSX is yet another tool available for Mac from Royal Applications. The latest version requires at least the Mac OS Yosemite operating system.
What sets RoyalTSX apart is its ability to use plugins for different types of connectivity. These plugins are available from Royal Software as well. The remote desktop client plugin is installed by default. Similarly, other connection types like VNC, SSH, HTTP or FTP can be installed with plugins, making it almost a universal connectivity tool.
Royal TSX allows repetitive command tasks or key sequences to be run automatically before, after or when a connection is made. The images below show this:
Some plugins allow Windows processes, services or events to be accessed remotely. However, this requires the RoyalTSX server component:
As the image below shows, connecting to a Windows server is fairly simple and standard. The credentials for the connections need to be created first:
The free version of Royal TSX allows up to 10 remote connections. If you are not managing dozens of Windows servers, the free version can be a good choice.
Linux Clients
Like Mac, there are remote desktop tools available for different flavors of Linux. To use these tools, needless to say, the Linux computer needs to be running in graphical mode. Here are few of the tools to consider.
KRDC
KRDC or KDE Remote Desktop Client is available for Linux distros running K Desktop, like Fedora. The package is available from KDE repo, so it can be easily installed with the following command:
sudo dnf install krdc -y
KRDC has a simple interface. However, in our opinion, it lacks a basic feature expected from any RDP client.
For example, once a connection is created, KRDC can “remember” the remote server’s username and password, provided it’s saved in the KDE Wallet Manager application.
This obviously means installing another KDE application in your workstation. The default wallet it looks for is called “kdewallet” and in a vanilla installation of KDE Wallet, users don’t know the password for that wallet, nor can they change it (at least we could not).
This means when connecting from the KRDC tool, users will be prompted for the wallet’s password if the “Remember password (KWallet)” option was chosen. Since users would not know the password, they have to bypass this by pressing the “Cancel” button:
Bypassing the wallet password prompt will result in the tool asking for the remote user’s password. Not a show-stopper perhaps, but to most regular users this can be a time-consuming affair.
Remmina
In our opinion, this is one of the best tools available for debian-based Linux distros, and can be downloaded from the Remmina GitHub repo of FreeRDP. Unfortunately the installation page does not list any RedHat-based distros except Fedora. If you are using something like Ubuntu, Gentoo, Fedora or ArchLinux, this tool should be yours.
The two images below show a remote Windows desktop displayed in Remmina running in Ubuntu 16.10:
Other than RDP, this tool also supports NX, VNC and SSH protocols:
Some of the advanced features of Remmina connection properties are shown below:
Like RoyalTSX for Mac, this tool also allows for startup programs to run when a connection is made.
FreeRDP
Another tool from the same repo owner is FreeRDP, a command line tool to start remote desktop sessions. This is available from the GitHub page of the product. FreeRDP is available for Ubuntu, Debian, Fedora, and OpenSuSE in Linux distributions and for Mac and even Windows. As said, this is a command line tool, but has a large number of options available as switches.
We installed the tool in a Fedora 26 machine and were able to connect to a Windows Server. The actual command is xfreerdp and it’s located in the /usr/bin directory. The following code snippet shows a basic form of the command and its output. In this case, we can safely ignore the warning:
$ xfreerdp /v:<sever ip address or dns name> /u:Administrator /p:<password> /d:WindowsServer1 /port:3389 [06:27:07:169] [9101:9102] [ERROR][com.freerdp.core] - failed to connect to 34.233.36.60 [06:27:07:169] [9101:9102] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure [06:27:07:169] [9101:9102] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C] [06:27:07:169] [9101:9102] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure [06:27:07:169] [9101:9102] [ERROR][com.freerdp.client.x11] - Freerdp connect error exit status 1 [osboxes@osboxes ~]$ xfreerdp /v:34.233.36.60 /u:Administrator /p:bL@ckbelt21 /d:WindowsServer1 /port:3389 [06:27:33:278] [9109:9110] [ERROR][com.freerdp.crypto] - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ [06:27:33:278] [9109:9110] [ERROR][com.freerdp.crypto] - @ WARNING: CERTIFICATE NAME MISMATCH! @ [06:27:33:278] [9109:9110] [ERROR][com.freerdp.crypto] - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ [06:27:33:278] [9109:9110] [ERROR][com.freerdp.crypto] - The hostname used for this connection (34.233.36.60:3389) [06:27:33:278] [9109:9110] [ERROR][com.freerdp.crypto] - does not match the name given in the certificate: [06:27:33:278] [9109:9110] [ERROR][com.freerdp.crypto] - Common Name (CN): [06:27:33:278] [9109:9110] [ERROR][com.freerdp.crypto] - WindowsServer1 [06:27:33:278] [9109:9110] [ERROR][com.freerdp.crypto] - A valid certificate for the wrong name should NOT be trusted! Certificate details: Subject: CN = WindowsServer1 Issuer: CN = WindowsServer1 Thumbprint: 9a:56:7d:e0:10:7a:66:b5:5a:08:9c:75:c9:40:99:c0:16:f0:e4:b4 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/T/N) y [06:27:44:185] [9109:9110] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_BGRX32 [06:27:44:185] [9109:9110] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_RGB16 [06:27:44:314] [9109:9110] [INFO][com.winpr.clipboard] - initialized POSIX local file subsystem
Other Remote Desktop Sharing Protocols
So far, the tools we have talked about all use the remote desktop protocol. This is a proprietary protocol developed by Microsoft and ships with any Windows machine. It runs on port 3389 by default. However, this is not the only protocol available for remote connections. We will talk about two other protocols:
- VNC
- NX
VNC
VNC or Virtual Network Computing is a desktop sharing system using the Remote Frame Buffer (RFB) protocol. Computers running a VNC server can be remotely connected from other computers running a VNC client. This is a platform independent protocol, which means there are servers and clients available for Mac, Linux and Windows. This also means the same VNC client can connect to a remote Windows server or a Linux server, each of which could be running VNC as a service. In fact some of the RDP tools we have discussed so far like Remmina, KRDC or RoyalTSX - all feature a VNC client. The default port for VNC communication is 5900. For Java-based VNC client, this is 5800.
Although VNC can be an alternative to remote desktop protocol, it means installation of additional software on the Windows server and configuring any firewall to allow traffic on the VNC port.
There are various VNC client and server packages available for free, some of these are:
- TightVNC
- TigerVNC
- RealVNC Home Edition
- UltraVNC
The image below shows the UltraVNC service running in a Windows Server 2016 machine. We downloaded it from UltraVNC’s official site.
And here are some of the UltraVNC service configurations:
The image below shows how we are using a TigerVNC Viewer client from a CentOS 7.16 machine to connect to the Windows server running UltraVNC.
NX
NX is another remote desktop sharing protocol developed by a company called NoMachine (there are also open source variants like OpenNX and FreeNX). The tool, also called NoMachine, allows some cool features like recording the remote desktop sessions or streaming remote multimedia. Unlike VNC or RDP, NoMachine does not have separate software installers for client and server: a NoMachine install creates both the components. Once NoMachine is installed in a Windows server, make sure the service is running and the firewall is allowing traffic through the default port of 4000.
In the image below, we can see the nxservice (NoMachine server) running as a Windows service:
The following series of images show a NoMachine client running in Fedora setting up a remote Windows server connection:
Once the connection is set up, subsequent connections are easy: just select the connection icon and click on the “Connect” button:
Once the credentials are provided (here we are using password authentication), there are a number of options to choose from for logon, display, resolution, sound, multimedia, etc.:
As you can see, NoMachine provides lot of options to configure how you interact with the remote computer. Once you click through the options, the remote desktop is shown as a locked screen:
You can now press Ctl+Alt+0 to bring out the NoMachine menu, click on the little icon in the lower right corner and choose Ctl+Alt+Delete from the pop-up menu, then click on the “Done” button:
This will bring up the Windows logon screen where you can put the remote server’s access credentials.
Conclusion
One thing to remember when troubleshooting remote desktop session issues is the networking layer. For any remote desktop connection to succeed:
- The service component needs to be running in the remote machine, whether it is remote desktop service, VNC or NX.
- The remote server needs to have a network path from the client: for example, we cannot remote desktop into a server if it’s only accessible from a bastion host.
- The server’s firewall or other network protection layer has to allow remote desktop traffic coming from the client’s network. This is particularly true if the machine is running VNC or NX.
- When running the Windows remote desktop protocol and client, the user needs to be a member of the remote desktop users local Windows group other groups with higher privileges.
- The network bandwidth needs to be good, particularly if there is a large geographical distance between client and server.
We hope this tip has given you some ideas about choosing the right RDP tool. We leave it up to the reader to make their own choice. Feel free to comment about other non-Windows RDP clients you might be using in the comments section below.
Next Steps
If you are using a non-Windows workstation, consider the following:
- Download and install the RDP clients we talked about
- Test the limitations of the “free” editions; for example:
- How many remote sessions you can keep open or
- How many sessions you can save
About the author
Sadequl Hussain has been working with SQL Server since version 6.5 and his life as a DBA has seen him managing mission critical systems.This author pledges the content of this article is based on professional experience and not AI generated.
View all my tips
