Description of problem: It'd make my (hopefully not just my :-)) life easier, if the machines installed via Inventory would be able to accept my ssh key, so that I can login without typing password. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. login at https://inventory.engineering.redhat.com/ 2. "take" a machine 3. provision the machine 4. ssh root@machine Actual results: $ ssh root@machine The authenticity of host 'machine (a.b.c.d)' can't be established. RSA key fingerprint is 81:cb:d2:09:f0:ef:f3:04:13:e3:41:8e:a5:80:63:bb. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'machine' (RSA) to the list of known hosts. root@machine's password: /usr/bin/xauth: creating new authority file /root/.Xauthority [root@machine ~]# Expected results: $ ssh root@machine The authenticity of host 'machine (a.b.c.d)' can't be established. RSA key fingerprint is 81:cb:d2:09:f0:ef:f3:04:13:e3:41:8e:a5:80:63:bb. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'machine' (RSA) to the list of known hosts. /usr/bin/xauth: creating new authority file /root/.Xauthority [root@machine ~]# Additional info: I report against Web UI, because for me, the intuitive first step would be to upload my public key via the Web UI to have it associated with the user account :-)
I'll take a look at this once we have deployed our first release of the beaker scheduler.
*** Bug 735078 has been marked as a duplicate of this bug. ***
Raymond, any news with this?
Jiri, This was actually talked about at the previous stakeholder meeting. Here is some discussion notes: - Default Lab Machine Password Policy Passed - user associated password. file rfe for future work - ER - need to check with infosec if these passwords would have mandatory rotation policy - enable use of .ssh keys rfe for future work - MB - won't work for console but still could be a user option Summary: People think that having a user defined password is more beneficial then having ssh keys available. So that work is going to be completed first. Also looking longer term they have features to add that push the Beaker developers out until mid next year. As requested I will bring this up at the next stakeholders meeting. I will try to get clarification of exactly when this work will be completed. Thanks, Jeff
Works fine on RHEL{4,6} and F{14,15}. Keys can be added/deleted as I wish. Enough for me :-) Thanks. Have I forgotten about something?
Works on RHEL 5 and 6 with both DSA and RSA keys.
works, thanks! [root@dev-kvm-guest-06 ~]# cat .ssh/authorized_keys ssh-dss AAAAB3NzaC1kc3MAAACBAMCGgYsTjKHA9rqLb3vxxyXeBK7ML22EfSt0C/HtedtXCY+pK2IqibBYqv1jod0+h4HgSO1LTRznmnH5inbiisweykk+ZLRmYuwkDjgYEVG9HNEQs9StPCAA87jRGotSLzn//XzDZzVMZIFZI4AwjN3PFWD7kUirYOMzt9juCBbTAAAAFQDORn5hQiAkWev18L1e6zR2MUOl1wAAAIApLa3Uvq4cfb4lgUeQZcvH/sNuS0ex7wkF3mvIA9VuRDSDrVfagzWohjBw6/0i7xW/DEY9JUP6QYCJeq4bvOa5mipKgX0H+AKgzASB6u4yFqsC6zZHtyTenCy+UvL2zUaUoGjTNrOqspjxa9SuWEPltMamJnl3otMtOGGeU8OXcgAAAIEAoEKn/P4ftJuKeQqpDMa/o0HsBmZR9jbRge1NGdUYI2xjwH2O+s3aTH2yZXZQf7UcGEXjVZ6xybUyrnPM0sNnmsT5Wr1dYT0Zjws18q5WMWCpjassNbLKtNaixQUbOT7hwOgGYoiltSPGQPneK5dHeqbbVplNG8kdNU+O0q/fYVo= kavol.brq.redhat.com
Will this also work for stable systems? It IMHO should, but will it?
(In reply to comment #11) > Will this also work for stable systems? It IMHO should, but will it? it depends on who provisions them.
(In reply to comment #11) > Will this also work for stable systems? It IMHO should, but will it? Should it? - stable systems are reinstalled only from time to time - that's their purpose. It's not that difficult to do ssh-copy-id user@ss from time to time... - there are multiple users accessing them. How should it work? IMO the implementation would be some work with little effect. But I see two things which would be more than marginally useful, and could be used for implementing the feature: - add owners public key by default. Owner may need to log into multiple systems. Suggest something like owner@system instead of root, let that be reserved for user. - system's owner should be able to add public keys for a system. So owner could add more keys for users allowed to stable systems.
> - stable systems are reinstalled only from time to time - that's their purpose. > It's not that difficult to do ssh-copy-id user@ss from time to time... Yeah, but it's boring ;-) It would be nice to get everyones (who is interested and has his/her key uploaded to beaker) public key installed on SS by default. > > - there are multiple users accessing them. How should it work? IMO the > implementation would be some work with little effect. > Stable systems are provisioned the same way as any other machines are. So I expect it should need no extra work... But why am I asking: I'd like to improve my errata-tps login script [1] so that it would be as comfortable as possible. At the moment I've got a skeleton of a new version working, but the logon procedure is still waiting for some smart solution. I packaged sshpass for epel for that reason and wanted to use this. But If I could 100% rely to the ssh keys mechanism, then I could use pure ssh, which is straightforward and clean. At the moment the script uses some expect hacks. [1] https://wiki.test.redhat.com/Faq/TipsAndTricks/ErrataTPSLogin
If this has to be configured on a 'per-machine-basis' via the 'web-ui' there is limited value for those managing a large group of machines. For this problem, there's the end-user (who manages their keys) and there are the machine administrators (who manages who has access to the machines). Also this a provision time problem, for machines that are provisioned ever so often, updates to the user/group lists aren't seen until the re-provision. There is a bit to think about. As for Stable Systems using this, it'll be a while.