ssh keys permissions changed on logon

[Jakub_H]

Hi.

I recently started using the devcloud (https://console.cloud.intel.com). I am launching the JupyterLab from the training tab and then connecting with VS Code.

Every time I start the JupyterLab, the permissions of the directory ~/.ssh and all files inside are changed. All files receive the permissions rwx---r-x (705), including the private key I have there. I change it to 600, but after the next login (jupyterlab start), the permissions are again 705.

This seems very bad. Apart from the security, everytime I try to access the ssh key, an error appears that the key cannot be used due to bad access rights, which is also annoying.

Permissions of all other files and directories remains the same, the permission are modified only for the .ssh directory and all its contents.

Is this expected? Can this please be fixed?

Thanks,

Jakub

PS: on the first login, I deleted the .ssh directory and recreated it again, this might be relevant.

[Jakub_H]

I put

chmod 600 ${HOME}/.ssh/*

into my .bashrc, which removed the annoyance of changing the permissions manually every time.

But why did I even have to do that?

[Thivagar_Intel]

Hi Jakub_H,

Thank you for reaching out to us.

Sorry for the late reply. The ~/.ssh directory contains the authorized_keys file, which holds your SSH public key. By default, the owner of the directory is set to root. However, in order for the user to view the contents of the authorized_keys file, the directory's permissions are set to 705. Changing the permissions to 600 will prevent user from being able to view the contents of the ~/.ssh directory. Please provide a screenshot of the permissions for all files in your home directory using the command 'ls -la' and please specify the reason for changing the .ssh directory’s permissions from 705 to 600.

Additionally, I attempted to change the file permissions to 600 but was unable to do so without root privileges, which require 'sudo' access. Unfortunately, using 'sudo' commands on Intel® Developer Cloud batch instances (JupyterLab) is not permitted due to security restrictions. Please specify the command you used to change the permissions of the ~/.ssh directory.

Regarding the error encountered when accessing the SSH public key, please provide a screenshot of the error. Additionally, please specify whether the error occurred before or after changing the permissions of the ~/.ssh directory, as I am unable to replicate the issue.

Regards,

Thivagar

[Jakub_H]

Hi.

> The ~/.ssh directory contains the authorized_keys file, which holds your SSH public key.

I remember that the .ssh directory was empty when I first logged in.

> By default, the owner of the directory is set to root. However, in order for the user to view the contents of the authorized_keys file, the directory's permissions are set to 705.

For some reason I did not like that, so I deleted the .ssh directory and created a new one.

> Please provide a screenshot of the permissions for all files in your home directory using the command 'ls -la'

I don't want to publicly share my username, but all the content is owned by me (user starting with u)

I also attach the screenshot of permissions inside the .ssh directory after login, they are all 705:

> and please specify the reason for changing the .ssh directory’s permissions from 705 to 600

I didn't really do anything to the permissions of the .ssh directory itself. I just deleted it when it was owned by root, and recreated it myself. It has 705 now. But I keep changing the permissions for the files inside the directory. Mainly so that others cannot read my private key file, and also so that I am able to use the key to ssh out.

> Please specify the command you used to change the permissions of the ~/.ssh directory.

rm -r .ssh

mkdir .ssh

> Regarding the error encountered when accessing the SSH public key, please provide a screenshot of the error.

same with cloning, pulling, pushing in git via ssh. If I change the permissions to 600, this error disappears and it works fine.

> Additionally, please specify whether the error occurred before or after changing the permissions of the ~/.ssh directory

I did not even try using the .ssh directory when it was owned by root. I do not change the permissions of the directory itself. Just the files in ~/.ssh. Before I change the permissions, I get the above error. After I change the permissions to 600, ssh works just as expected. And, even though I change the permissions of the files inside ~/.ssh to 600, after the next login, the permissions are back to 705, which is the issue I am reporting. I don't want my private keys accessible by others.

[Thivagar_Intel]

Hi Jakub_H,

Sorry for the late reply. I was able to replicate the error. As you mentioned before, the ~/.ssh directory’s permissions were reset to 705 after restarting the instance. This behavior is due to startup scripts in the ~/etc directory, which cannot be edited due to security restrictions.

The error "Load key '~/.ssh/id_local': bad permissions" occurred because your SSH client does not allow the use of private keys in the id_local file when they are accessible by others. This can be resolved by restricting the permissions of the SSH private key file, as you have done previously, by changing the permissions from 705 to 600 using the command "chmod 600 ${HOME}/.ssh/*".

From the screenshot you provided, it seems that you are using JupyterLab to launch your instance.

Launching the instance in JupyterLab can cause the error "Load key '~/.ssh/id_local': bad permissions" because the ~/.ssh directory is reset to default permissions whenever JupyterLab is restarted. To further troubleshoot this issue, please provide the following details:

1. Please specify the reason for using the JupyterLab to launch your IDC instance.
2. Please provide your instance details:
   1. Instance Type:
   2. Instance ID/Resource ID:
   3. Region: us-region-1/us-region-2
   4. IP Address:
   5. Reservation details:
      1. start date:
      2. end date:
3. Cloud Account ID:
4. Customer Time Zone: 
5. Is there any important data stored on the instance?
6. Can the IDC support team access the instance and perform the required operations to validate or fix an issue if needed?

Regards,

Thivagar

[Jakub_H]

Hi, yes, this is exactly what is happening.

> "the ~/.ssh directory is reset to default permissions whenever JupyterLab is restarted"

This seems like this is exactly what is happening. Why is it happening? Why are default permissions for .ssh/* 705?

Here are the detaile requested:

1. Please specify the reason for using the JupyterLab to launch your IDC instance.
   • I attended an Intel-organized devcloud workshop on May 16, and we were told that JupyterLab is the only way to access the training servers. Allegedly, direct ssh access is not possible because of security reasons. The training nodes are free, and a great place for code development and debugging, since I don't yet need the full power of Intel GPUs, just need to make my software compile and run without errors. The benchmarking and proper performance tests of my code will come later where I will probably use a preview instance (currently in waitlist).
2. Please provide your instance details:
   1. Instance Type:
      • I don't have any standalone instance, I am using the shared training nodes
   2. Instance ID/Resource ID: ---
   3. Region: us-region-1/us-region-2
      • us-region-1
   4. IP Address: ---
   5. Reservation details: ---
      1. start date: ---
      2. end date: ---
3. Cloud Account ID:
   • 309713633000
4. Customer Time Zone: 
   • CEST, UTC+2 right now in summer
5. Is there any important data stored on the instance?
   • I am trying to regularly git-commit and git-push my changes, so not really.
6. Can the IDC support team access the instance and perform the required operations to validate or fix an issue if needed?
   • sure

Hope this helps. Thanks,

Jakub

[Thivagar_Intel]

Hi Jakub_H,

Thank you for responding. We have escalated this issue to the appropriate team for further investigation and will keep you updated. We greatly appreciate your patience.

Regards,

Thivagar

[Thivagar_Intel · Accepted solution]

Hi Jakub_H,

Thank you for your patience. The default permission for the ~/.ssh directory is set to 705, and this permission is reset to default as part of the design. This setup is intentional to prevent SSH access to nodes in the ITDC Training cluster (JupyterLab). SSH access is prohibited in the ITDC Training cluster (JupyterLab).

However, SSH access is available on Bare Metal and Virtual Machines, which can be reserved through the Intel® Tiber™ Developer Cloud (ITDC). We hope this information helps.

Regards,

Thivagar

[Jakub_H]

Hi,

I don't really understand how setting the permission should prevent ssh access, when I am able to change the permissions, but alright, whatever. I will just keep the chmod command in my .bashrc.

Also, I am not trying to access the ITDC training nodes via ssh, I am not trying to ssh TO itdc training nodes. I am trying to ssh OUT of them to other machines (cluster at our institution, git repositories, ...) using ssh keys. And that should not be such a problem in my opinion.

[Thivagar_Intel]

Hi Jakub_H,

Regarding the inquiry about accessing other machines through SSH connections from the ITDC Training nodes(JupyterLab), we have escalated the issue to the appropriate team for further investigation and will keep you updated. We greatly appreciate your patience.

Regards,

Thivagar

[Thivagar_Intel]

Hi Jakub_H,

This thread will no longer be monitored since this issue has been resolved. If you need any additional information from Intel, please submit a new question.

Regards,

Thivagar