I've been tweaking a post on building a solid LEMP stack, that I hope to publish soon that covers your last three points. While security through obscurity isn't a solution, it does help thwart a large portion of the attacks, although it causes more headache than benefits in some cases (heavily restricted work networks for instance). When it comes to webservers, you don't encounter issues like that, and the less information you provide, the better.
I haven't enabled IPv6 on any of my servers yet, as I can say with 99.9% certainty that my visitors do not know what it is, let alone have it enabled. Additionally, this is intended as a quickstart or beginners guide, and obviously leaves quite a bit out. That being said, it is definitely something you want to consider, and I've added a followup to the post mentioning that.
This isn't intended as a be-all-end-all guide to security, like the NSA aims for. Instead, view it as a quickstart guide for those first five minutes on a new server, or as a starting point for beginners that have no idea where to even look.
I do the same, and have found it works beautifully. You need my master password, SSH Key, and my SSH Key's password before you can log into my server. And if you somehow manage to get all of that, you need my account password in order to modify any non-user files.
Both limit and spindritf's suggestion will mitigate the attack, but they won't notify you about it. In most circumstances, I'd prefer to skip on the thousands of notifications per day, however I sometimes like to know about every detail on a server, and Fail2ban gives me that level of control, without the need to tail a log file.
I prefer to be actively administrating my server, so that I know if something does go awry. If I'm asleep, it may be a few hours before I realize that an update broke something. On top of that, I clone my servers and test upgrades in a development environment as much as possible, before allowing an update to go live. As long as you're on top of the updates, a few days between automatic and manual shouldn't have much effect.
Don't manually file them in that case. Install Fail2ban and automatically ban anyone with x failed attempts, and have it email [email protected]. Their system will look up the correct abuse department, and forward it along on your behalf, along with thousands of others that report it. A large portion of them probably go ignored, but if you can get a fraction of them taken offline, then why not spend the five minutes to set it up?
If you're coming from an HTTPS page (which I think HN forces) to an HTTP page, the referer is not sent. It is only sent for HTTP->HTTP and HTTPS->HTTPS (even cross-domain, despite the info that leaks out)
I'm not sure I'd even go that far. A set of commands showing how to lock down account permissions would work just as well, while allowing me to remain in control. That is a good point though, as Bastio would be able to create unrestricted administrative users anyway.
Where are your encryption keys stored in relation to our connection data?
I was thinking the same. Perhaps if the setup procedure included a limited-access account that could only run useradd/userdel, I'd consider trying it, but definitely not while root.
Vim should be able to do everything that GVim can do, if you add a few lines to your configs. I'm not sure what specifically though.
I bring my entire development setup with me when using a server, and preparing it is as simple as cloning Homeshick (or Homesick if you have Ruby), cloning your dotfiles repository, and installing any applications that you want to use.