[ovirt-users] How to extract root ssh

Yedidyah Bar David didi at redhat.com
Thu Aug 10 05:51:16 UTC 2017


On Wed, Aug 9, 2017 at 5:27 PM, Fabrice Bacchella
<fabrice.bacchella at orange.fr> wrote:
>
>> Le 9 août 2017 à 16:03, Yedidyah Bar David <didi at redhat.com> a écrit :
>>
>> On Wed, Aug 9, 2017 at 4:35 PM, Fabrice Bacchella
>> <fabrice.bacchella at orange.fr> wrote:
>>> oVirt own a private ssh keys that it can use to do remote installation on
>>> host, instead of using a password. But I didn't found at
>>> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/rest_api_guide/
>>> how to find it's public key. Where can I found it ?
>>
>> For the public key, see:
>>
>> http://www.ovirt.org/develop/release-management/features/infra/pki/#services
>>
>> Not sure if it's part of the API, or if it should be - adding Juan.
>
> I'm writing code to create automatically datacenter/cluster/host, without storing the root password in scripts.

How do you provision your hosts? If using pxe or cloud-init or
something like that, you can arrange to add a public key to the
authorized keys during installation, and then you can use the matching
private key later on for management, with no relation to oVirt.

> Having a way to have the sdk automatically get it would be nice. Having a known URL is good enough, but it it's not obvious to find it.

Doc patches/Blog posts/etc. are welcome :-)

>
> The resource is missing content-disposition, and the date is not optimal:
>
> $ curl -JORLkv 'https://XXXX/ovirt-engine/services/pki-resource?format=OPENSSH-PUBKEY&resource=engine-certificate'
> < HTTP/1.1 200 OK
> < Date: Wed, 09 Aug 2017 14:22:49 GMT
> < Server: Apache
> < Set-Cookie: locale=en_US; path=/; HttpOnly; Max-Age=2147483647; Expires=Mon, 27-Aug-2085 17:36:56 GMT
> < Content-Type: text/plain; charset=ISO-8859-1
> < Content-Length: 394
>
> $ls
> ...
> pki-resource\?format\=OPENSSH-PUBKEY\&resource\=engine-certificate
>
> See curl(1)
>
>        -J, --remote-header-name
>               (HTTP)  This  option tells the -O, --remote-name option to use the server-specified Content-Disposition filename instead of extracting a
>               filename from the URL.
>
>               If the server specifies a file name and a file with that name already exists in the current working directory it will not be overwritten
>               and an error will occur. If the server doesn't specify a file name then this option has no effect.
>
>               There's  no  attempt  to  decode %-sequences (yet) in the provided file name, so this option may provide you with rather unexpected file
>               names.
>
>               WARNING: Exercise judicious use of this option, especially on Windows. A rogue server could send you the name of a  DLL  or  other  file
>               that could possibly be loaded automatically by Windows or some third party software.
>



-- 
Didi


More information about the Users mailing list