Bug 569909
| Summary: | RFE: please add possibility to use ssh keys | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Karel Volný <kvolny> |
| Component: | web UI | Assignee: | Steven Lawrance <stl> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 0.5 | CC: | abourne, azelinka, bpeck, dcallagh, jburke, jlustick, jpirko, kbaker, mcermak, mcsontos, rmancy, stl |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-10-20 06:19:04 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 593663 | ||
|
Description
Karel Volný
2010-03-02 16:51:17 UTC
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. |