[7.450][BUG][NOTABUG] Shell access passwords not restored from backup

Not a bug; the Root and Loginuser passwords are never stored in the backup file.  ASG systems have worked that way, well, since I've been working with them.  Behaviour is as designed.

Not a bug; the Root and Loginuser passwords are never stored in the backup file.  ASG systems have worked that way, well, since I've been working with them.  Behaviour is as designed.

Not a bug; the Root and Loginuser passwords are never stored in the backup file.  ASG systems have worked that way, well, since I've been working with them.  Behaviour is as designed.

I am confused, and I'm confused a lot, about your comment on the root and loginuser passwords not stored in the backup file.

After my fresh install of 7.450 and without further modifications, other than entering the hostname, organization, country, etc, I went directly into restoring 7.402 backup file. After a few minutes later, I was able to login to 7.450 with root or loginuser using the 7.402 passwords.

Thanks,
jav

Hi Javelin,
the passwords for loginuser and root are are most definitely not stored in the backup files.
Every time I do a build or restore from backup I have to add the to passwords. If you do a fresh install and then do a restore you will find that the console does nt require a password to login
Other passwords are.

Ian M[:)]

Thanks Ian. But I'm still confused. In my fresh install / restore scenario, I never had to add any passwords. We are talking about the same backup file; ie, *.abf right?

I've already done several fresh 7.450 install and 7.402 restore test. And every single one, access to the console was possible only by using my 7.402 password. Same goes with the loginuser or root.

Am I doing something illegal then? [:)]

Javelin, I'm pretty confused too... I have not seen the behavior you describe before.

Te Astaro backup has never included the root / loginuser passwords in the backup file, and for a very good reason:  Let's say you get a job at a company that uses the Astaro solution, but the old admin either changed the passwords on the way out of the door, or the password for Webadmin, root, and loginuser have been lost somehow (I've had calls like this!).  You would most certainly be stuck if the backups restored all 3 (default admin, root and loginuser).

Instead, one can reload the device, from scratch, with a fresh ISO or USB stick, set the loginuser and root passwords via the new, clean webadmin, then restore the configuration.  Then one can SSH (or use the console) in, and run the Webadmin password reset routine from the shell, and voila, you have full access again, with the configuration, without having to redo it all from scratch (some Astaro configurations can be very complex, and would take hours and hours to recreate over time if you had to start all the way over).

Hi Bruce. I agree with your explanation and the security reasons behind it. But that don't explain why I'm able to login with my old password after a restore. Could there be a switch setting from the webadmin I'm not aware of that allows the passwords to be saved?

Given your scenario of a lost password or the old admin changed it, one can simply reboot the server, access GRUB and into rescue, get into the prompt, perform the reset password dance and you're back and running. I don't see resetting the passwords an issue. I've just done it couple of days ago after losing access to the webadmin, ssh or console...if you have 7.450 running, try resetting your password from the webadmin and you'll see what I mean... [[:)]]

Anyway, I apologize for monopolizing this thread. This is my last post for this one... [[:)]]

Normally you can login to the console with an empty password after a restore.
Maybe a real password works too, not sure.

Barry

Hi Folks,
let me offer another reason.
When you login into console you are normally asked for a password, whether one exists or not. Just possibly the password entered is taken as the new password, but doesn't ask for confirmation. Just possibly there is a bug in that process. Food for thought.

Ian

What Ian said is the likely explanation...

I wouldn't have believe it if I didn't see it. The backup file does include administrator passwords. That's why I was always able to login after a restore using my previous credentials.

While going through a restore, again, I was just reading through the documentations and came across this:

In addition, you have the option to encrypt the backup (Triple DES encryption). Once you have selected this option, provide a password (second time for verification). You will be asked for this password when importing the backup (the file extension for encrypted backups is ebf).

Note – A backup does include administrator passwords as well as all RSA keys and X.509 certificates. Since this information is confidential, it is good practice to enable encryption.

Anyway, it's just an fyi ... [:)]

Thanks,
jav