GrahamDumpleton
commented
9 months ago The alternative you considered is already possible and was the compromise solution for now at least.
With a workshop session there is an environment variable CONFIG_PASSWORD. This is also available as data variable for interpolation in workshop instructions using config_password.
$ env | grep CONFIG_PASSWORD
CONFIG_PASSWORD=eHSWjbczrE17BFLC4iomyT6J0IVvlptMThat password can be used with special URL against a workshop session instance to get configuration related to the session.
Some details are found in:
The special URL prefix is the equivalent of $SESSION_URL/workshop/config/ where in a workshop session you can construct that from SESSION_URL environment variable or session_url data variable in workshop instructions.
For example:
$SESSION_URL/workshop/config/id_rsa?token=$CONFIG_PASSWORDThe configuration one can download using this includes the kubeconfig as well as SSH keys.
The idea thus was until work out a better solution, that any custom tunnel client for SSH access could be given the session URL and the config password. That client could then download the SSH key, saving it somewhere it can then use it when it actually runs SSH to access the session.
Nothing more has been done at this point and as sort of mentioned in SSH access docs the idea is to come up with a purpose built CLI, or as part of VS Code extension, for doing tunnelling, with samples for what is required provided for Python and Go. See tunnel.go and tunnel.py in:
So idea was to see first how people may want to use this before work out whether anything else should be done as part of Educates to make it easier.
As to having SSH directly accept a password, the challenge there was no readily available PAM module for a password file distinct from /etc/shadow. One can get an old package for Debian, but not Fedora.
Updating /etc/shadow to add a password is problematic as nothing runs as root in the workshop container. The only way around it is to use an init container running as root to update the file in that container and then using some volume mount tricks to inject the modified file into the main workshop container. Even then though that is not enough as /etc/shadow will not be readable by the workshop user (which sshd also runs as), so it couldn't authenticate the user against it anyway.
So short of find an existing PAM plugin module which allows use of a separate htpasswd, or maintaining our own such PAM plugin module, there is no ideal solution for having SSH access use a password, thus why SSH keys we used so far.
We can have a separate discussion about what you are trying to use SSH access for so can see where we go.
Is your feature request related to a problem? Please describe.
Educates has the documented Enabling Remote SSH Access feature. However this requires the use of SSH key pairs and the learner to have to copy the file or key. This is cumbersome.
Being able to set a common or simple generated password and the learner do password authentication from a client on their machine would be an easier/simpler experience.
Describe the solution you'd like
Being able to set a common or simple generated password and the learner do password authentication from a client on their machine would be an easier/simpler experience.
Describe alternatives you've considered
Hosting the key in a webserver and having a generated script people could run that would download the key, chmod the permissions, etc.
Additional information
https://docs.educates.dev/custom-resources/workshop-definition.html?highlight=ssh#enabling-remote-ssh-access