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
Hello,
I’ve been copying the snake-oil certs to /etc/xrdp in replace of the sym links, and changing group of key.pem to chown root:xrdp key,pem, and I’ve been doing that for ages,
Anything wrong with that method?
But now I know your method, I agree it’s simpler!
Cheers
John
@JohnR,
They are multiple ways to achieve the same way….So, if the copy files and replacing permissions works for you, that’s fine with us…
However, as you mentioned, there is a simpler and more efficient way to achieve the same results…It’s probably best to try to use simplest method
but again up to you
Thanks for the visits and sharing your comments
Till next time
See ya
Option 2 doesn’t work on 20.04 (Linux version 5.4.0-53-generic) anymore.
User xrdp is a member of ssl-cert, the error message still appears in the logs.
hello there,
I have done all the steps as instructed. When I try to connect I got a black-screen.
when I check the logs I get the followings,
Apr 22 16:05:01 template xrdp[109030]: (109030)(140123311941440)[INFO ] starting xrdp with pid 109030
Apr 22 16:05:01 template xrdp[109030]: (109030)(140123311941440)[INFO ] listening to port 3389 on 0.0.0.0
Apr 22 16:11:27 template xrdp[109030]: (109030)(140123311941440)[INFO ] Socket 12: AF_INET6 connection received from ::ffff:95.70.145.34 p
Apr 22 16:11:27 template xrdp[109030]: (109030)(140123311941440)[DEBUG] Closed socket 12 (AF_INET6 ::ffff:90.159.46.77 port 3389)
Apr 22 16:11:27 template xrdp[110306]: (110306)(140123311941440)[DEBUG] Closed socket 11 (AF_INET6 :: port 3389)
Apr 22 16:11:27 template xrdp[110306]: (110306)(140123311941440)[INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
Apr 22 16:11:27 template xrdp[110306]: (110306)(140123311941440)[INFO ] Using default X.509 key file: /etc/xrdp/key.pem
Apr 22 16:11:27 template xrdp[110306]: (110306)(140123311941440)[ERROR] Cannot read private key file /etc/xrdp/key.pem: Permission denied
when I try to add xrdp user again,
sudo adduser xrdp ssl-cert
The user `xrdp’ is already a member of `ssl-cert’.
my server spec
Distributor ID: Ubuntu
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Codename: bionic
So I m not sure what kind of extra permission I should provide?
still I get a black screen and then it disconnects. could you please guide me?
any help appriciated. many thanks
@Tunc,
Have you installed a Desktop interface on your Ubuntu Server ? ARe you using Ubuntu Desktop edition or UBuntu Server edition ? If you have the Server edition, there is no Desktop interface by default and you have to install one
If yo have the Desktop interface on SErver or if you are using the DEsktop Edition and you still have the Black screen issue, please review the following two posts
xRDP – xRDP shows only black screen after authentication windows – HowTo Fix !
xRDP – Allow multiple sessions (local and remote) for the same user – HowTo
Hope this help
Till next time
See ya
My previous user was disabled when I entered the sudo adduser xrdp ssl-cert command
What should I do now?
please help ? ? ?
@Yamahdi,
Thank you for visiting our blog and providing feedback…. Not sure we understand your question… the user account that run the command sudo adduser xrdp ssl-cert needs to have admin rights or needs to be part of the sudoers group… If you are managing your system, you should have at least an account that has admin right
Hope this help
Till next time
See ya
Thank you! Option 2 solved my issue.
@Nikita,
Thank you for visiting our blog and providing feedback. We are happy to see that the information provided through this blog can be useful
Till next time
See ya
I encountered the same issue as yamahdi. Initially, I was able to log in to the remote desktop using the root account, but other users couldn’t. Later, I added a user to the ssl-cert group, and that user was then able to log in. However, after that, the root account could no longer access the remote desktop—until I removed the newly added user from the ssl-cert group.
Could you help me with this? I hope all users are able to log in to remote desktop.
@Alan,
Thank you for reaching out and visiting our blog. So, we are not sure we understand the issue here. so, we have done a basic test on Ubuntu 25.04 (since we are working on updated version of the xrdp-installer script). So, what we have done
1. install xrdp using the script
2. enable root user on Ubuntu
3. Performed a remote desktop session from a standard user
4. at the same time, performed a remote desktop session using root account
5. we do not perform any change in the ssl-cert group membership
=> results, both users were able to remote in and access their desktop
So, either we cannot reproduce your issue or you are doing something different
Hope this help
Till next time
See ya
Hi,
Thank you for your help.
I did the exact what you did. The only difference is my Ubuntu version is 20.04.
However, either the root user can’t log in by the xrpd, or the standard user can’t log in by the xrpd.
Luckly they all can log in by SSH.
I will keep reserch till I find the reason.
Thank you again!
Alan
@Alan,
Thank you for providing feedback… We can have check the same config on Ubuntu 20.04 to see if there is a change in behavior. The question is why do you need to login with root account (highly not recommended). Additionally, you are telling me that you have enabled the root account. Can the root account login locally on your ubuntu session or not ? After enabling the root account, have you performed any additional actions for the root account to login into your system ?
Till next time
See ya
Hi Griffon,
My Linux computer is a rented remote machine, so I don’t have the ability to perform local testing. After I rented it, the provider gave me a root account, so I used it to install XFCE4 and xrdp, and performed a login test. As you mentioned, it’s not safe to use the root account for daily work, so I created a regular user account to try logging in via xrdp. However, unexpectedly, it failed — it seems only one of the two accounts (root or the regular user) can log in at a time.
Yes, I can start using the regular user account for xrdp from now on and stop logging in as root, which is totally fine for my work. But I still want to solve this issue. I believe there must be a way to allow both accounts to use xrdp at the same time.
Thank you so much for your response!
@Alan Smith,
Thank you for your feedback and for providing additional information about your setup. So, normally by default, xrdp allows multiple users to login including root account (if the account has been enabled and authorized to login to the GUI.
We would need to have access to the logs to see what can be the issue…. (/var/log/xrdp.log and /var/log/xrdp-sesman.log). Did you perform a standard installation or custom installation with the script ? (in order words, have you used the -c switch ?)
in xrdp, there is an option to control who can perform remote session (see https://c-nergy.be/blog/?p=18536) but I do not think this is your problem since this option is turned off by default.
There are also some changes coming in the xrdp code that we will integrate soon in a new version of the script
Hope this help
Till next time
See ya