So, I actually haven't brought it to xCAT secureshell, but the confluent OS deploy capabilities has some changes in how it does ssh: -Rather than doing it in postscript, it actually does it before the installer even partitions a disk. Meaning ssh as root to the installer environment is enabled and known_hosts is already handled as is also ~/.authorized_keys. Node-to-node ssh is not yet setup and no passwords are allowed at this phase -Private keys are generated on the deploying system and are granted a certificate (takes care of known_hosts)
At postinstall phase, some things are changed about the 'about-to-boot OS:' -Installer ssh keys are copied over into installed system (Ubuntu profile has to fight cloud-init a few times, but it prevails with the useful ssh keys in the end) -Host based authentication is enabled for node to node ssh as root and non-root users, removing need for nodes to have access to private user keys -Root's authorized keys are still done with user keys from all collective members (just in case) Note that in xCAT we tended to just have the one root ssh key, in this case each collective member is a totally private CA and distinct user, each node is enabled to trust any of the collective members. Again, toward the end of never ever transferring a private key. The general key algo of choice in these scripts is ed25519. As an aside, at least for RedHat/CentOS, we also support encrypted boot and grub password so that unattended boot can still happen, but a disk walking away would not be able to be decrypted. Currently debating whether/how to make that disk also resistant to rescue boot as an option. Anyway, the stuff is in: https://github.com/lenovo/confluent/tree/master/confluent_osdeploy/el8/profiles/default/scripts There are also things involving a node taken, that is handled in the initrd (actually c programs that are added to initrds). From: Christopher Walker <c.j.wal...@qmul.ac.uk> Sent: Thursday, June 4, 2020 12:09 PM To: xCAT Users Mailing list <xcat-user@lists.sourceforge.net> Subject: Re: [xcat-user] [External] What remoteshell exactly does? remoteshell doesn't currently support ed25519 keys. It looks a relatively simple change to remoteshell to add it (and I think I'll need to add it to credentials.pm too. Before I write a patch, has anyone done this already. It looks like Jarod's secureshell would be a better solution, but we are currently using a somewhat old verision of xCAT so it hasn't yet arrived yet. Chris ________________________________ From: Jarrod Johnson <jjohns...@lenovo.com<mailto:jjohns...@lenovo.com>> Sent: 08 October 2019 21:46 To: xCAT Users Mailing list <xcat-user@lists.sourceforge.net<mailto:xcat-user@lists.sourceforge.net>> Subject: Re: [xcat-user] [External] What remoteshell exactly does? You may remove it from postscripts tabedit postscripts You may remove remoteshell. Our team was actually going to provide a new 'secureshell' postscript as an alternative to supersede with a more sane security strategy, but if you have another strategy that takes care of the authentication, neither would be required. remoteshell tries to avoid perturbing known_hosts by persisting host key across install. Which is a tricky proposition. It also does some potentially undesirable changes to ssh/sshd configuration. For the lazy, it tends to still create a passwordless experience for root with mitigated known_hosts perturbance for all. secureshell is going to replace the key bootstrap with a more hardened mechanism, replace host key persistence with a managed SSH CA, and enable host-based authentication within a cluster if requested to enable non-root ssh enablement without per-user action. It would also allow enabling ssh between nodes as root without user key sharing (using .shosts with host authentication). This is intended as a more modern and manageable 'works regardless of other configuration' ssh bootstrap scheme. Neither should be required if you otherwise enable ssh to your likeing. ________________________________ From: Vinícius Ferrão via xCAT-user <xcat-user@lists.sourceforge.net<mailto:xcat-user@lists.sourceforge.net>> Sent: Tuesday, October 8, 2019 4:19 PM To: xCAT Users Mailing list Cc: Vinícius Ferrão Subject: [External] [xcat-user] What remoteshell exactly does? Hello, I'm trying to add some features to an xCAT HPC Cluster but I'm with some issues with SSH Host Keys. My clients are running ipa-client-install on bootime since I've already deployed an FreeIPA Server on the headnode and I want the nodes to authenticate on it. After some time trying to debug issues I've came across to this file. This file appears to copy some fixed host keys to compute images. But I'm not sure about it. The point is: what this script really do? Is it really necessary since it's added by default by xCAT. Can it be replaced? Thanks, _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net<mailto:xCAT-user@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/xcat-user<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fxcat-user&data=02%7C01%7Cc.j.walker%40qmul.ac.uk%7C971ac0119f244150ff9b08d74c30b8e8%7C569df091b01340e386eebd9cb9e25814%7C0%7C0%7C637061644456923498&sdata=AOYPuVIF%2B4cDj4qZ3Obd3Jtoj8tD2taZZXJaiaFwtj8%3D&reserved=0> xcat-user List Signup and Options<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fxcat-user&data=02%7C01%7Cc.j.walker%40qmul.ac.uk%7C971ac0119f244150ff9b08d74c30b8e8%7C569df091b01340e386eebd9cb9e25814%7C0%7C0%7C637061644456933491&sdata=GPOC44r%2BKt44jsXzqX64DCMnkt1Ij9RUyoVyAq9tqLE%3D&reserved=0> lists.sourceforge.net An extreme cluster/cloud administration toolkit
_______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user
