Securing your account/en: Difference between revisions
(Updating to match new version of source page) |
(Updating to match new version of source page) |
||
Line 19: | Line 19: | ||
For technical details on implementing SSH keys for your account, please see [[SSH_Keys|this page]]. | For technical details on implementing SSH keys for your account, please see [[SSH_Keys|this page]]. | ||
= Multifactor authentication = | |||
Multifactor authentication (MFA) allows you to protect your account with more than a password or SSH key. Once your account is configured to use this feature, you will need to enter your username and password or SSH key as usual, and then perform a second action (the second factor) to access most of our services. It is highly recommended to activate it on your account. Please cette the [[Multifactor authentication]] page for more details. | |||
= General best practices = | = General best practices = | ||
Line 34: | Line 37: | ||
* On clients that use OpenSSH (Linux, Mac and as an option under Windows), you can configure SSH behavior using ~/.ssh/config. In particular, you can define system and even username-specific behavior, such as selecting specific keys to use, or automatically selecting advanced features such as X/port forwarding, and even ProxyJump. | * On clients that use OpenSSH (Linux, Mac and as an option under Windows), you can configure SSH behavior using ~/.ssh/config. In particular, you can define system and even username-specific behavior, such as selecting specific keys to use, or automatically selecting advanced features such as X/port forwarding, and even ProxyJump. | ||
== For the system you log in to == | == For the system you log in to == | ||
One important advantage of using ssh keys is that the remote system only needs your public key. This value is not sensitive, so there is no risk of disclosure. If someone gets your public key, all they can do is give you additional access. | One important advantage of using ssh keys is that the remote system only needs your public key. This value is not sensitive, so there is no risk of disclosure. If someone gets your public key, all they can do is give you additional access. | ||
* Avoid placing any private keys on remote machines, even encrypted ones. An unencrypted key is equivalent to a password, and may be stolen or exposed inadvertantly. An encrypted key is, by itself, not sensitive - except if you ever use it on that machine (at which point you are effectively trusting the machine.) | * Avoid placing any private keys on remote machines, even encrypted ones. An unencrypted key is equivalent to a password, and may be stolen or exposed inadvertantly. An encrypted key is, by itself, not sensitive - except if you ever use it on that machine (at which point you are effectively trusting the machine.) | ||
* If you use ssh-agent, avoid forwarding it to remote machines. ComputeCanada clusters use hostbased trust within the cluster, so you do not need to re-authenticate if you connect to an internal node. | * If you use ssh-agent, avoid forwarding it to remote machines. ComputeCanada clusters use hostbased trust within the cluster, so you do not need to re-authenticate if you connect to an internal node. |
Revision as of 17:50, 4 October 2023
Authentication
There are two primary authentication mechanisms that are used to connect to a cluster: passwords and SSH keys. Below are some best practices for both methods.
Password best practices
- Users are strongly encouraged to use unique passwords, and to never reuse them.
- Passwords are sensitive confidential information and users must never share or disclose them by any means. Users should also refrain from disclosing tips that could help identify their passwords.
- Users are encouraged to never write down a password. In the situation where a user needs to write or store his password on a given media, it is acceptable to do so given that the appropriate security measures to prevent unauthorized access are in place (encryption, strong password protection, etc.). A user should never store or write a password to facilitate access or transfer between information systems.
- Users are encouraged to not use the "remember your password" feature of browser or operating systems.
Resetting your password
If you think that your password may have been compromised, you can reset it through this page.
SSH keys best practices
SSH keys can be a good way to authenticate to your account without typing your password every time. However, to be secure, it is imperative that SSH keys use a strong passphrase that is treated like a password.
Treat the private key as a security token, even when encrypted with a passphrase. Avoid putting a private key on any shared machine. Placing an unencrypted private key on the clusters is a huge security hole.
For technical details on implementing SSH keys for your account, please see this page.
Multifactor authentication
Multifactor authentication (MFA) allows you to protect your account with more than a password or SSH key. Once your account is configured to use this feature, you will need to enter your username and password or SSH key as usual, and then perform a second action (the second factor) to access most of our services. It is highly recommended to activate it on your account. Please cette the Multifactor authentication page for more details.
General best practices
Sharing data
When sharing data among collaborators, it may seem convenient to change filesystem permissions to allow everyone to read or write some files. This can compromise your account if not done properly. Please see our Sharing data page.
For the system you log in from
Security issues often start on the outside, by a third party getting access to a user's password or (passwordless) ssh key. To help prevent this, please:
- Log in from trusted computers only;
- On Windows computers, make sure to regularly run a virus scanner and malware scanner;
- Regardless of what Operating System you have, keep up to date with security updates for all software;
- Do not leave your computer or laptop unattended.
- On clients that use OpenSSH (Linux, Mac and as an option under Windows), you can configure SSH behavior using ~/.ssh/config. In particular, you can define system and even username-specific behavior, such as selecting specific keys to use, or automatically selecting advanced features such as X/port forwarding, and even ProxyJump.
For the system you log in to
One important advantage of using ssh keys is that the remote system only needs your public key. This value is not sensitive, so there is no risk of disclosure. If someone gets your public key, all they can do is give you additional access.
- Avoid placing any private keys on remote machines, even encrypted ones. An unencrypted key is equivalent to a password, and may be stolen or exposed inadvertantly. An encrypted key is, by itself, not sensitive - except if you ever use it on that machine (at which point you are effectively trusting the machine.)
- If you use ssh-agent, avoid forwarding it to remote machines. ComputeCanada clusters use hostbased trust within the cluster, so you do not need to re-authenticate if you connect to an internal node.