Trying to figure out what a certain authorized_key record is all about

Latest response

Hello -

I have a RHEV-M server and 2 data centers. Each datacenter has 6 RHEV/RHEL hosts. Full-blown RHEL, not RHEV-H appliances. I am running RHEV 3.2. All clusters and data centers are at the 3.2 compatability level. All were built with 3.1 and upgraded this week from 3.1 to 3.2.

Looking at /root/.ssh/authorized_keys on my RHEV-M server, I see an entry that looks like this:

ssh-rsa AAAAB3nZa...Lots_of_digits...PIO7j ovirt-engine

I see the same entry in all my RHEL/RHEV hosts.

Wonderful - if I understand this, the authorized_keys file is a list of public keys such that systems sending over the corresponding private keys can log on as root without sending a password.

According to "man sshd", each record/line in this file is a space separated list formatted like this:

Options KeyType Key Comments

The Options field is optional and starts with a number if present. In my case, I don't have any options, it's an ssh-rsa key, it has lots of digits, and the comment is "ovirt-engine".

This site needs to comply with some strict security requirements and I need to find out what this key belongs to. In some of the other records in authorized_keys, the comment field takes the form, root@hostname, so I can reasonably infer where those records come from.

But there is no user account named ovirt-engine on either the hosts or the RHEV-M server here, so the "ovirt-engine" comment gives no clue where that key comes from.

The closest I can find is an ovirt username on the RHEV-M server:
[root@rhevm .ssh]# grep engine /etc/passwd
ovirt:x:108:108:oVirt Manager:/var/lib/ovirt-engine:/sbin/nologin

If I am unable to find out where this key comes from, the site will get rid of it and then I'll many late nights dealing with a deep dark failure somewhere.

Any ideas how to chase down this key? That key depends on both the user and system, right? So every user on every system would have a unique public/private key pair - right?


  • Greg Scott


Hey Greg - excellent question.  There are a number of "local" users on the system that RHEV is dependent on.  ovirt, vdsm, qemu, sanlock, etc...

To answer your question:

You can find the matching "public" key in:


The .txt file should be the public key that you will find on your Hypervisors authorized_keys file.


This is one of the challenges of using a "shop build" of RHEL for a Hypervisor, as opposed to using RHEV-Hypervisor or a vanilla RHEL installation.  Once you start to harden the system or apply and shop specific tweaks, it may impact your RHEV environment.  For example, disabling the ability for a user to connect as root remotely.  Or as we found out, updating sudoers to require an actual TTY.  What we have concluded is that we need a separate management channel for our RHEV environment and then we have to justify why those boxes do not conform to the Enterprise standard we have adopted.

Sure enough - there it is. Well, sort of.

[root@rhevm keys]# more engine.ssh.key.txt
ssh-rsa AAAAB3...LotsOfDigits...07J engine

(I dummied up that key, of course.)

Except the comment at the end - "engine" in the .txt file here, versus "ovirt-engine" in authorized_keys. But the comment is probably from a setup process somewhere that just fudges it in.

And there's no user named "engine" on the RHEVM server, but there is a user named "ovirt".

[root@rhevm keys]# grep engine /etc/passwd
ovirt:x:108:108:oVirt Manager:/var/lib/ovirt-engine:/sbin/nologin

So this public key probably belongs to user ovirt on the RHEV-M server - but how do I prove it?

  • Greg

I'm not sure how you could "prove it".  The source of the key.  In most cases, the username@hostname entry at the end of the key is completely harmless - you can change it to whatever you want (I assume there is someway to lock that part down so that it matches on both ends, but I have not ever seen that implemented).


You can validate the public key matches the private key by running ssh-keygen.  I would copy the keys to somewhere else to test.

# ssh-keygen -y -f engine_id_rsa

will produce the same value in your engine.ssh.key.txt file.

Yes - that ssh-keygen idea should do the trick, thanks. 

- Greg