/.ssh/known_hosts — у меня нестандартное имя файла ключа (для разных машин разные ключи).
Подключение с явным указанием файла ключа проходит, но, видимо, не добавляет запись в
/.ssh/known_hosts — повторная попытка соединиться без указания файла приводит к той же ошибке.
Ясности не добавляет то, что файл
/.ssh/known_hosts хэширован — IP удаленных машин не видны.
Как можно сделать так, чтобы клиент SSH запомнил, что есть 1 и тот же ключ для 2 разных IP удаленных машин?
Simple IT Library for the rest of us
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
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….
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
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
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
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.
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
Why do I get this error? I have change permissions for all directories and files to 755.
[Mon May 12 14:34:25 2008] [error] [client 24.89.216.3] (13)Permission denied: access to / denied
[Mon May 12 14:34:55 2008] [error] [client 69.25.142.59] (13)Permission denied: access to / denied
Premium Content
Premium Content
- https://www.experts-exchange.com/questions/23395709/Apache-Error-Permission-denied.html copy
Yipes, you have everything set to 777? They should be set to no more that 775. Assuming that you changed that after you started having the trouble though, that shouldn’t be the issue. How about the directories above that? Is /home/default and /home at least 755?
Do you get any other messages in your error or access logs that might indicate why it’s being denied? Try stopping apache, clearing the logs, then starting it again, and look at the log files for anything that shouldn’t be there. Feel free to attach those files here. Also, do you get any warnings when starting up apache? And finally, are any clients able to successfully connect and view the web page?
I did this and it works:
chmod -R 755 /home
IT issues often require a personalized solution. With Ask the Experts™ , submit your questions to our certified professionals and receive unlimited, customized solutions that work for you.