> Until we figure out the ultimate flexible solution, I'd like to be able
> to log in while the user-data script is running so I can monitor
> progress and debug.
I think that is reasonable.
> A security bug in ssh should be considered a good motivating reason to
> publish updated AMIs.
I had thought about this when i posted. The basic point, though, is that
the later the user gets a hook in, the less they can fix or modify (at
least without a reboot).
I don't personally like the hassle/delay of ec2-get-console-output to
verify the ssh fingerprint. I'd much rather generate the new keys on the
system that launches the instance and pass them in the user-data. If
user-data doesn't run till after ssh starts, i have to restart sshd.
Again, not a major not ideal.
In the mean time, I think I agree to running user data after sshd per the
de-facto standard in place.
> Until we figure out the ultimate flexible solution, I'd like to be able
> to log in while the user-data script is running so I can monitor
> progress and debug.
I think that is reasonable.
> A security bug in ssh should be considered a good motivating reason to
> publish updated AMIs.
I had thought about this when i posted. The basic point, though, is that
the later the user gets a hook in, the less they can fix or modify (at
least without a reboot).
I don't personally like the hassle/delay of ec2-get- console- output to
verify the ssh fingerprint. I'd much rather generate the new keys on the
system that launches the instance and pass them in the user-data. If
user-data doesn't run till after ssh starts, i have to restart sshd.
Again, not a major not ideal.
In the mean time, I think I agree to running user data after sshd per the
de-facto standard in place.