21–30 of 121 posts
This is super useful if you are in the game of building images, or highly tweeking init systems and/or the kernel. For general consumers, not much value IMHO.
Earlier quoted context omitted.
They could not accept downtime. They were also using a database that had it's consistency guarantees scaled back for "web scale" reasons and were terrified of what a hard reset would do. Yes, the VM could just disappear randomly anyway, which made doing that a very poor choice. There were a whole lot of questionable prior decisions that had been made that did not help. You learn a lot in situations like this about be…
To use something like this you’d still need an SSH root password setup in advance. So not much different than not losing your SSH keys or creating fallback ones. One other option is to exploit a bug in managed software to escape to a shell. One man’s CVE or backdoor, is another support engineers magic sword to save the day.
Other implementations I've seen drop you right into a root shell, relying on equivalents to IAM to govern access to the other side of the virtual serial port rather than machine local permissions.
Earlier quoted context omitted.
To use something like this you’d still need an SSH root password setup in advance. So not much different than not losing your SSH keys or creating fallback ones. One other option is to exploit a bug in managed software to escape to a shell. One man’s CVE or backdoor, is another support engineers magic sword to save the day.
Is that strictly true? Other implementations I've seen drop you right into a root shell, relying on equivalents to IAM to govern access to the other side of the virtual serial port rather than machine local permissions.
I remember having an EC2 terminal in the browser years ago and recently I went back and it seemed far more locked down.
I wonder if this is implemented at the hypervisor level (gives you access to the "console") or if this is actually implemented as a serial port.
What would be the difference exactly? The console of a Linux VM is either the emulated serial port or the emulated VGA device + emulated keyboard. I once implemented a tool called virt-dmesg which read out the log_buf from a running Linux kernel (surprisingly useful for those tricky crashes, but difficult from a maintenance point view so the tool is now abandoned). I suppose that's the closest you could get to a "rea…
Based on a quick SSH it looks like it's a serial thing:
root 1221 /sbin/agetty -o -p -- \u --keep-baud 115200,38400,9600 ttyS0 vt220
root 1229 /sbin/agetty -o -p -- \u --noclear tty1 linuxOh thank god. I had a customer once that erased their SSH keys, and had a running database cluster on EC2 that they couldn't get access too anymore. That was... fun. This is a long time coming.
I wonder if this is implemented at the hypervisor level (gives you access to the "console") or if this is actually implemented as a serial port.
What would be the difference exactly? The console of a Linux VM is either the emulated serial port or the emulated VGA device + emulated keyboard. I once implemented a tool called virt-dmesg which read out the log_buf from a running Linux kernel (surprisingly useful for those tricky crashes, but difficult from a maintenance point view so the tool is now abandoned). I suppose that's the closest you could get to a "rea…
Earlier quoted context omitted.
Is that strictly true? Other implementations I've seen drop you right into a root shell, relying on equivalents to IAM to govern access to the other side of the virtual serial port rather than machine local permissions.
Depends on how getty (or other local TTY manager) is setup. Most (if not all) Linux and BSD distributions attach login(1) to console and serial TTYs by default, and login(1) will normally require password authentication. Though, whether login prompts for a password is (I think) also a function of flags in /etc/passwd (or /etc/shadow or equivalent), so you may be able to login as `root` or `$USER` without entering a p…
Earlier quoted context omitted.
Depends on how getty (or other local TTY manager) is setup. Most (if not all) Linux and BSD distributions attach login(1) to console and serial TTYs by default, and login(1) will normally require password authentication. Though, whether login prompts for a password is (I think) also a function of flags in /etc/passwd (or /etc/shadow or equivalent), so you may be able to login as `root` or `$USER` without entering a p…
if you have serial console access, can't you key-combo it to boot into single user mode?
And adding to the fun, watching it on an initial instance bootup seems to block the process AWS uses to grab the encrypted password out of the log. So, it's not useful, and makes the instance a bit hard to remote into.