Massive rewrite of SSH section for 2025's authentication changes #266
Conversation
obilaniu
force-pushed
the
ssh-keys
branch
4 times, most recently
from
72d7516 to
d3f6b5a
Compare
docs/Userguide_login.rst
Outdated
| The login nodes support the following authentication mechanisms: | ||
| ``publickey,keyboard-interactive``. If you would like to set an entry in your | ||
| ``.ssh/config`` file, please use the following recommendation: | ||
| Logging in with SSH |
There was a problem hiding this comment.
Please move this section before "mila init". Plain old SSH is the easiest and fastest way to connect to the cluster.
There was a problem hiding this comment.
Ok... that slightly contradicts my description of mila init as doing everything for you. And this SSH config block does look slightly intimidating, and doesn't include the mila-cpu entry that mila init generates and that gets mentioned a lot elsewhere. @lebrice?
There was a problem hiding this comment.
Hmm. With these changes, it's still unclear to me to what extent the "role" of mila init should be affected.
Here's exactly what running mila init does at the moment:
- Asks the user for their Mila / DRAC usernames
- Populates the SSH configuration file
- Generates an ssh keypair if not present
- Runs
ssh-copy-id milaand optionally does the same for DRAC - Generates an ssh keypair without passphrase on the login nodes, and adds it to authorized keys (to allow connecting to the compute nodes from the login node)
- When launched from WSL, also attempts to configure the Windows SSH configuration and keypair.
- Adds useful default settings for connecting to the cluster with Visual Studio code in the users's
settings.jsonfile.
I guess following these changes, we can either try to send the form programmatically (which might be difficult given Google Auth + 2FA) or just print a link to the form, and display the info that the user would then have to copy-paste into the form.
What do you think @breuleux @obilaniu @btravouillon ?
There was a problem hiding this comment.
Even if mila init can do everything for you, the simplest command to access the cluster once the access is granted is plain old SSH. First, we must document how to access the cluster with a simple SSH command. This is how the documentation is written today. Just move the mila init section below. It does not dismiss any additional information on how to configure the ssh client (~/.ssh/config) nor how to use mila init. But I prefer to get the simplest command first.
There was a problem hiding this comment.
Reordered to put manual SSH configuration first.
There was a problem hiding this comment.
Can you double check? I'm reviewing right now and the "Logging in with SSH" is still after "mila init"/
docs/Userguide_login.rst
Outdated
| The login nodes support the following authentication mechanisms: | ||
| ``publickey,keyboard-interactive``. If you would like to set an entry in your | ||
| ``.ssh/config`` file, please use the following recommendation: | ||
| Logging in with SSH |
There was a problem hiding this comment.
Hmm. With these changes, it's still unclear to me to what extent the "role" of mila init should be affected.
Here's exactly what running mila init does at the moment:
- Asks the user for their Mila / DRAC usernames
- Populates the SSH configuration file
- Generates an ssh keypair if not present
- Runs
ssh-copy-id milaand optionally does the same for DRAC - Generates an ssh keypair without passphrase on the login nodes, and adds it to authorized keys (to allow connecting to the compute nodes from the login node)
- When launched from WSL, also attempts to configure the Windows SSH configuration and keypair.
- Adds useful default settings for connecting to the cluster with Visual Studio code in the users's
settings.jsonfile.
I guess following these changes, we can either try to send the form programmatically (which might be difficult given Google Auth + 2FA) or just print a link to the form, and display the info that the user would then have to copy-paste into the form.
What do you think @breuleux @obilaniu @btravouillon ?
obilaniu
force-pushed
the
ssh-keys
branch
3 times, most recently
from
b31bf14 to
a9fbde5
Compare
No description provided.