Hello World, 

We are again back and ready to discuss a really minor issue/annoyance that some people have noticed when performing there remote connection using xRDP software.  For some weeks now (see our previous posts),  a lot of work has been done to analyse how Ubuntu 19.04 would affect the xRDP installation process and we have included our findings in the latest version of our scripts.  The changes are not major but still needed to be tackle to offer an easy way to perform xRDP installation and provide the best user experience. 

If you are interested in our findings, you can have a look at the following posts 

• xRDP – Manual Installation on Ubuntu 19.04
• xRDP – Fixing Look n’ Feel Settings in Ubuntu 19.04 Remote Session
• xRDP – New “Authentication Required…” Popup showing up in Ubuntu 19.04
• xRDP – Missing packages for Sound Redirection in Ubuntu 19.04

The post of today will explain why xRDP logs an SSL error in its log and how this can be solved.  Please not that this error is not preventing the connection and you could simply ignore the steps described in this post.  However, if you are a picky user and want to get rid of this error message, you can proceed…. 

So, let’s go ! 

Issue Description

As mentioned earlier, if you have used the manual installation approach or if you have used one of our scripts (Std installation vs Custom installation), you should be able to perform your remote connection and access your beautiful Ubuntu Desktop interface.  No popups should be displayed and you should be able to start working almost immediately.  However, some advanced users/sysadmins have noticed that an error is thrown in the /var/log/xrdp.log file.   The screenshot below shows the error that will be generated each time a user perform a remote connection (if you have not perform any additional actions) 

Click on picture for better resolution

So, to understand why this error is generated, we need to have a look at the permissions on this specific file.  If you open nautilus and your browse to the following location 

/etc/xrdp

You will see that the folder contains indeed the *.pem files (cert.pem and key.pem) 

Click on picture for better resolution

Looking at the permissions for the the file /etc/xrdp/cert.pem, any user can have a read access on it.  This is inline with what the /var/log/xrdp.log is telling us.  xRDP can read the cert.pem file but gets an access denied on /etc/xrdp/key.pem

Click on picture for better resolution

So, looking at the permissions on the file /etc/xrdp/key.pem, we can see that again, in theory, everybody should have a read access to it

Click on picture for better resolution

If we try to open this file, we get the following error message. 

Click on picture for better resolution

So, this provide us a clue on the real location of the file.  Indeed, checking at the properties of the file, the real location of the file is under /etc/ssl/private/ssl-cert-snakeoil.key

Click on picture for better resolution

Browsing to the location /etc/ssl/, we can see that the red cross (in the screenshot) on the private folder indicate a no access for normal users. This can be confirmed by checking the permissions on the folder and indeed, others group has access set to None (i.e. Access Denied)

Click on picture for better resolution

 

Solution 

Since the issue has been identified (i.e. file permission issues), it’s time to come with some solution to this really minor issue.  There are two way to approach the problem.  We can either relax security and grant access to the group Others.  The other option would be to add the most appropriate user account into the ssl-cert group.  As you can see on the previous screenshot above, this group has some rights and should be able to access the requested file.  Let’s investigate these options 

Option 1 – Change Permissions (Not the best option)

I mention this option because I have seen a lot of people using it.  This was basically the easiest way to fix their issue at that moment.  Based on our analysis, the Others group has no access to the folders and file needed by xRDP.  So, by changing this and providing read only access to the resources should fix our issue.   As shown in the following two screenshots, from nautilus (started as admin), we have changed the permissions on the folder and file located at /etc/ssl/private

Click on picture for better resolution

Click on picture for better resolution

After that, try your xRDP connection and check again the /vart/log/xrdp.log file and you should see that the warning/error is gone. 

Click on picture for better resolution

Option 2 – add user xrdp into ssl-cert group

This would be the recommended approach.  Updating the group membership for the ssl-cert group with the appropriate user account should fix the issue.   The information is not new as Martin Thiago (see this post) shared it already.  To fix this minor issue without changing file system permission, you would simply need to add the user account called xrdp into the group called ssl-cert.  you can achieve this by executing the following command 

sudo adduser xrdp ssl-cert  

With no more actions, if you try to perform an xRDP login again, you will notice that the error is still generated and logged in the /var/log/xrdp.log.  To ensure that the change fixes the issue, you also need to restart the xrdp services or simply reboot the machine ensuring that the group memberhsip is updated and the correct information is read by the system.  

Final Notes 

This is it for this post !  Again, the fact that xRDP cannot read some of the certificate files does not seems to break the remote desktop functionality.  Users should be able to connect even if the certificate file cannot be read.  Because our goal is to provide the best user experience, this minor issue should be fixed and as you have seen the fix is really easy to implement.  Actually, it’s so easy to implement it that it will be included in the next version of our famous scripts (Standard and custom installation scripts).

We are almost ready to release these scripts and we are already working on the next version that might introduce again some really interesting changes 

Till next time 

See ya