Convert Old Weakly Encrypted SSH Private Keys to the Newer PKCS8 Format
The default password-based encryption for openSSH RSA private keys (generated with ssh-keygen -t rsa) has inadequate protection against brute forcing due to a weak Password-Based Key Derivation Function (PBKDF) because it used OpenSSL's key derivation with just one round of MD5.
TL;DR: Rather generate new keys with ssh-keygen -t ed25519 which by default should use the more secure PBKDF with the PKCS8 format. RSA key generation defaults to the weak PBKDF stored in the PEM format.
However, if you still need RSA to work with older Unix systems, network devices, and other systems' SSH servers are not yet upgraded with Ed25519 support, this provides info to avoid the less secure default of saving private keys in the legacy PEM format when generating RSA keys. Backward compatibility is not that much of a concern since only the SSH client needs a reasonably modern version of SSH.
This is useful for trying to recover from an unresponsive system. However, by default, Ubuntu disables the key to gain raw keyboard access.\
Sometimes part of the issue is that X/Wayland display servers have crashed due to bad graphics drivers and keyboard input isn't processed anymore, whereby changing to another console, e.g. ctrl + alt + F1 doesn't work. Since the default disables keyboard control, alt + sysrq + r, can't help salvage the situation. Hence the suggestion to at least enable system request raw keyboard control when trying to recover a system.
Ubuntu doesn't enable control of keyboard by default
Boot failure was caused by installing spice-guest-tools which, if you read details about it, also includes the QXL driver and the install broke my Windows 10 build 17134 guest somehow. This occured on Ubuntu 16.04 LTS with QEMU emulator version 2.5.0.
BSOD with "page fault in nonpaged area" occurs after installing spice-guest-tools-latest.exe. It possibly clobbers other stable/good versions of drivers.
Automatic boot repair fails. After going through advanced options and getting to a command prompt, inspect the boot repair logs:
Enable persistent storage for the systemd journal log
The assumed default setting in /etc/systemd/journald.conf is Storage=auto which implies that systemd journaling will only persist the journal if the expected storage location is available. Otherwise, the journal data is stored in memory and lost between reboots. On Ubuntu 16.04, /var/log/journal does not exist by default. Create it to keep and query events from previous boots.
Syslog still provides the persistant log records for Ubuntu 16.04, so enabling persistant systemd journal logging does cause a level of duplicaiton.