[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