How to set root password without using SSH Key?


The only why to access image imported from MarketPlace in OpenNebula Sunstone is with the Public SSH Key.

So, is there any way to set initial root password for Linux images without using SSH Key ? only with a sample text password like PASSWORD=123456.

This could be a possible solution. Some user posted this a while back. You have to integrate it in your image.


# -------------------------------------------------------------------------- #
# Copyright 2016, Équipe EOLE <>                        #
# Author: Daniel Dehennin <>                      #
#                                                                            #
# License CeCILL:                                                            #
#  * in french:    #
#  * in english    #
# -------------------------------------------------------------------------- #

if ! command -v pwgen > /dev/null
    exit 0

if [ -z "${USERNAME}" ]

if ! getent passwd "${USERNAME}" > /dev/null 2>&1
    exit 0

# Generate password only on first boot
   && expr "${RANDOM_PASSWORD}" : '[tT][rR][uU][eE]' > /dev/null \
   && [ ! -f /etc/ssh/ssh_host_rsa_key ]
    PASSWORD=$(pwgen -c -n -y -B -1 12)

    if chpasswd -c SHA512 <<< "${USERNAME}:${PASSWORD}"
        # Take care to escape backslashed getty commands in password
        cat > /etc/issue <<EOF
$(lsb_release -sd) \l

Default connection:
- Login: ${USERNAME}
- Password: $(echo "${PASSWORD}" | sed -e 's,\\,\\\\,g')

Thomas Stein writes:

This could be a possible solution. Some user posted this a while back. You have to integrate it in your image.

In fact, setting the password is already included in the context
package[1][2], you can find the script loc-20-set-username-password[3].

The RANDOM_PASSWORD generator is not included, if someone think it may
be a good idea, I can submit a patch.


[1] Cleartext:

[2] Crypted:


I just make it working:

  1. import Debian 8.6 - KVM into my OpenNebula
  2. Update the new Debian 8.6 - KVM VM template
  3. Add Custom vars in template Context: PASSWORD = foo
  4. Instantiate the VM
  5. Login with root user and foo password

This is working for me.


1 Like

thank you for your replay, latest version of OpenNebula can set root password by many ways, i’m using the starter script with this one line command : echo -e "123456\n123456" | passwd root

Thank you all

Or update the template using the oneadmin cli:

echo CONTEXT = [ USERNAME = root, PASSWORD = password, NETWORK = YES ] >
onetemplate update testvm -a

You will need to specify the whole context. It would be nice if cli allowed one to update only a part of the context.
Or maybe there is already a way to achieve that with cli?

1 Like

I would also like to add another question to this topic: is there any way do remove PASSWORD variable (or any other ones) after the first (successful) boot? For example, to let VM admin to set temp root passwd, boot VM and then be able to change root password inside of the VM and keep it across reboots? I don’t like setting passwords via context for many reasons but have been asked about this functionality by users.

You could remove one-context service from the startup after the initial contextualization. This could be done via a script executed by the context plugin.
If you do that though you will not get any more updates you might send via onegate and basically onegate on the host will fail as the token and so on might not be there after a cleanup of tmp. That could be ok if the node is fully managed by it’s owner at that point.

1 Like

Removing one-context service will cut too much functionality, so I would prefer to find an another way.

Of course the simplest option is to keep hashed variable value inside of the VM and assume that if it is equal to the hashed value during boot it was already set and do nothing. But this way also leads to some sort of inconvenience, so I would prefer check another solutions first.

As loc-20-set-username-password does not do anything when there is no password you could try to remove the password attribute via onegate. I’m not sure if this is possible via onegate though.

Besides that you could drop the set password script from the installed plugin after the first run. I’d rather patch it than removing the script but you could do that without touching the other context functionality via a script at the end of the first context run. At least that would be last option if everything else fails.