Note that you may elect to just have a normally generated known_hosts file that you push everywhere if you prefer to skip the CA. Just try to ssh everywhere and take the generated known_hosts there.
For me the CA was appealing as I could manage blessing new keys across reprovisioning without having to update the rest of the nodes. It may be more trouble than it’s worth to do one off, but would pay off in provisioning software. Or I just want to work with it because I have a strange interest in these things. Anyway, the command given, the tr “ “ “,” ends up passing in a trailing comma. At least the version of ssh-keygen I have rejects a trailing comma, as it is expecting another name for the certificate to follow. From: Imam Toufique <[email protected]> Sent: Wednesday, January 22, 2020 4:08 PM To: xCAT Users Mailing list <[email protected]> Subject: Re: [xcat-user] [External] Re: host based authentication HI Jarrod, So, yes, I had a problem with the 'ssh_keys' group, as somehow the private keys in /etc/ssh/ directory was group owned by 'chrony'. I have seen that before, not sure (yet) how it happened. Below is the client side of /etc/ssh/: [root@hpc3-xcat-1 ssh]# ll total 624 -rw-r----- 1 root ssh_keys 1675 Jan 22 11:45 ca -rw-r--r-- 1 root root 404 Jan 22 11:45 ca.pub -rwx------. 1 root root 581843 Aug 8 18:40 moduli -rwx------ 1 root root 64 Jan 22 01:20 shosts.equiv -rwx------ 1 root root 2376 Jan 21 22:27 ssh_config -rwx------ 1 root root 4175 Jan 22 00:02 sshd_config -rw-r----- 1 root ssh_keys 227 Jan 2 22:41 ssh_host_ecdsa_key -rw-r--r-- 1 root root 162 Jan 2 22:41 ssh_host_ecdsa_key.pub -rw-r----- 1 root ssh_keys 387 Jan 2 22:41 ssh_host_ed25519_key -rw-r--r-- 1 root root 82 Jan 2 22:41 ssh_host_ed25519_key.pub -rw-r----- 1 root ssh_keys 1679 Jan 2 22:41 ssh_host_rsa_key -rw-r--r-- 1 root root 382 Jan 2 22:41 ssh_host_rsa_key.pub -rwx------ 1 root root 401 Jan 21 23:04 ssh_known_hosts Below is the server side of /etc/ssh [root@login-i15 ssh]# ll /etc/ssh/ total 624 -rwx------. 1 root root 581843 Aug 8 18:40 moduli -rwx------ 1 root root 64 Jan 22 01:20 shosts.equiv -rwx------ 1 root root 2291 Jan 21 23:03 ssh_config -rwx------ 1 root root 3994 Jan 22 00:01 sshd_config -rwx------. 1 root root 3907 Jan 13 10:31 sshd_config.ORIG -rw-r-----. 1 root ssh_keys 668 Jan 13 10:31 ssh_host_dsa_key -rw-r--r--. 1 root root 589 Jan 13 10:31 ssh_host_dsa_key.pub -rw-r-----. 1 root ssh_keys 227 Jan 13 10:31 ssh_host_ecdsa_key -rw-r--r--. 1 root root 161 Jan 13 10:31 ssh_host_ecdsa_key.pub -rw-r----- 1 root ssh_keys 387 Jan 13 10:49 ssh_host_ed25519_key -rw-r--r-- 1 root root 82 Jan 13 10:49 ssh_host_ed25519_key.pub -rw-r-----. 1 root ssh_keys 1675 Jan 13 10:31 ssh_host_rsa_key -rw-r--r--. 1 root root 381 Jan 13 10:31 ssh_host_rsa_key.pub -rwx------ 1 root root 824 Jan 22 01:13 ssh_known_hosts Below is the client side of ssh-keysign: [root@hpc3-xcat-1 ssh]# ll /usr/libexec/openssh/ssh-keysign ---x--s--x. 1 root ssh_keys 465760 Aug 8 18:40 /usr/libexec/openssh/ssh-keysign Below is the server side of ssh-keysign: [root@login-i15 ssh]# ll /usr/libexec/openssh/ssh-keysign ---x--s--x. 1 root ssh_keys 465760 Aug 8 18:40 /usr/libexec/openssh/ssh-keysign i guess my error now is in my /etc/ssh/ssh_known_hosts section. when I went about creating a ca , i get the following: [root@hpc3-xcat-1 ssh]# ssh-keygen -s /etc/ssh/ca -I "$(hostname --fqdn) host key" -n "$(hostname),$(hostname --fqdn),$(hostname -I|tr ' ' ',')" -V -5m:+3650d -h /etc/ssh/ssh_host_rsa_key.pub /etc/ssh/ssh_host_dsa_key.pub /etc/ssh/ssh_host_ecdsa_key.pub Empty principal name I assumed that I can create a cert and distribute it across all machine, correct? with that, I tried the above and got the error. If I just just create sign the key in my client, I suppose I should be able to use that certificate through my cluster nodes? thanks. On Wed, Jan 22, 2020 at 11:22 AM Jarrod Johnson <[email protected]<mailto:[email protected]>> wrote: Note that the root user ignores /etc/ssh/shosts.equiv, root access is only through ~root/.shosts Depending on how things are and what OS, the other thing I’ve seen is ssh-keysign permissions being off. You’d have to show permissions on the private keys and check the ssh-keysign permissions. Ssh-keysign being setgid to ssh_keys and having the ssh private host key being group readable by ssh_keys group for example. I don’t know if that was the issue, but if you have some info I might recognize. With FreeIPA, I assume you’d do kerberized ssh for user authentication? That’s generally good for node to node within a cluster. One limitation is that for a user coming in from outside, I think they would have to enter their password once on the way in to get a valid keytab. This isn’t too bad, but it’s a bit nicer if I can ssh in with my key and then be able to hop on over to other nodes. Of course, just like I connected CA approach to known_hosts with host based authentication as a strategy, I’m sure you could take FreeIPA host key information and do the same thing instead of an SSH CA. I intend to make SSH CA easier to use, but if you can do FreeIPA with no problem then that should be able to do the same thing. From: Imam Toufique <[email protected]<mailto:[email protected]>> Sent: Wednesday, January 22, 2020 1:50 PM To: xCAT Users Mailing list <[email protected]<mailto:[email protected]>> Subject: Re: [xcat-user] [External] Re: host based authentication thanks Jarrod and Joseph! Jarrod, I am in the process of trying out host-based authentication. I might have made an error somewhere, so it does not work yet for me. I guess I will keep on it. Josef, Since you are already using freeIPA, do you mind summarizing how it can help aid host-based authentication management for local accounts? I am very interested in it. thanks On Wed, Jan 22, 2020 at 5:39 AM Jarrod Johnson <[email protected]<mailto:[email protected]>> wrote: For completion, I'll document what I was discussing. I strangely can't find my notes, but here's some perspective on how my system looks: First is my global known hosts file. This works to not require a user to maintain known_hosts for its normal usage and a prelude for host based authentication: $ cat /etc/ssh/ssh_known_hosts @cert-authority * ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBum8H7Wf8k3vLBI8+mEZtvklpb0UxsLXrswMoXfLfELq70iLcmGqg3gcRSR7eUSyj/HQHxQYrH7l9/2mVrvn6M= root@leonidas With this, the associated set of private ssh keys with that line can use ssh-keygen to sign public keys. It does not allow all keys signed by the CA to authenticate, you will also need an /etc/shosts.equiv, which is just a list of ips and/or names. Unlike rhosts usage, wildcards are not allowed, so the list will have to ultimately have each and every node listed in it. For a client to use ssh client-side host based authentication: Host <entry> HostbasedAuthentication yes EnableSSHKeysign yes The EnableSSHKeysign is what tells ssh-keysign that it's ok to use the host private key on behalf of users. In sshd_config: HostbasedAuthentication yes HostbasedUsesNameFromPacketOnly yes IgnoreRhosts no (to use ~/.shosts) Some material on host based authentication https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication Mix and match with CA to get the above: https://www.lorier.net/docs/ssh-ca.html For reference, my plans are for a new node authentication scheme for provisioning (to enable some tighter security) and plan for it to always enable host based authentication (convenient for local accounts including node to node ssh as root if desired while using a moderately sane strategy for key management) and based on user configuration either nothing more, freeipa, or active directory joining. This would make control over the security behaviors a bit more straightforward and lock in some more hardened options than xCAT currently offers. As an aside, my current thinking in this future strategy is for the default behavior when not specifying a root password to change from 'not able to work' to 'deploy with root password access disabled, root access by key only'. -----Original Message----- From: Josef Dvoracek <[email protected]<mailto:[email protected]>> Sent: Wednesday, January 22, 2020 4:28 AM To: [email protected]<mailto:[email protected]> Subject: [External] Re: [xcat-user] host based authentication > I’m using FreeIPA too so the hostkeys are stored on LDAP, it's integrated. thanks for mentioning this. I was struggling to design simple AND secure hostkey deployment mechanism. Good to know freeIPA can manage this. cheers josef On 21. 01. 20 23:28, Vinícius Ferrão via xCAT-user wrote: ... Josef Dvoracek Institute of Physics | Czech Academy of Sciences cell: +420 608 563 558 | office: +420 266 052 669 | fzu phone nr. : 2669 _______________________________________________ xCAT-user mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/xcat-user _______________________________________________ xCAT-user mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/xcat-user -- Regards, Imam Toufique 213-700-5485 _______________________________________________ xCAT-user mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/xcat-user -- Regards, Imam Toufique 213-700-5485
_______________________________________________ xCAT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xcat-user
