38,760
edits
Securing your account/en: Difference between revisions
Jump to navigation
Jump to search
Updating to match new version of source page
(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. | ||