Hacker News new | ask | show | jobs
by ceejayoz 4559 days ago
> For the love of all that is good, save your .pem file to some kind of cloud storage so you’ll never be without it.

For the love of all that is good, don't do this for anything beyond random hobbyist screwing around. A Dropbox compromise shouldn't risk your entire company's server infrastructure.

> If you only have need for one free tier instance leave it running.

No, because the 750 hours/month can be used by more than one instance. You could, for example, try out database clustering by running two t1.micro instances for two weeks.

> Finally resist the urge to use your GUI when working with your project even when your working with your project on a local machine you’ll find that as you move along with your project you’ll be in better control of the project when it’s on the remote server.

The AWS Console is perfectly usable for 99% of what you'll need to do. Most users won't need anything beyond it.

4 comments

A few things you can do back up your private key safely (correct me if I'm wrong here.)

- Encrypt the pem file with a gpg passphrase you can memorize or put in a password manager

or

- Create a new IAM AWS account with a strong password, turn on 2-factor authentication, and grant access to the keys bucket for just that account. Make sure you turn on S3-side AES256 bit at-rest encryption for the file.

The latter still has the risk of a complete AWS breach and S3 encryption key compromise, or someone hacking into your admin account somehow (in which case you have bigger problems), but that seems much less likely than say someone just snagging your laptop and getting the key off of it.

In practice I have a single jump node in a VPC facing the internet in a security group with my IP whitelisted that has 2-factor authentication with a PAM module for google authenticator and a strong password, so they would need my phone, the password, my IP, and the backend nodes' private key to get to any machine.

> For the love of all that is good, don't do this ...

I, too, was astounded that anybody would be recommending keeping your keys 'public' like this. By all means, keep it on a few USB sticks that are nicely secure - and have a good plan in place in case you lose one.

By all means, have a separate, passphrase-protected key for each separate device (desktop, laptop, tablet) and push them to your machines using something like chef and the 'users' and 'sudo' community cookbooks, at a minimum, and destroy the .pem after you initially set up the host.

There is a reason that Amazon only configures one user with only one key, and it's not because that's how sane people access their machine.

Here's a better idea. Learn to use IAM properly and rotate your keys on a schedule.
You're thinking of AWS access keys. Not the same thing.
Oh, I thought this article was about AWS not SSH. My bad. Yeah, don't rotate your SSH keys either.
IAM rotates ssh keys?
>The AWS Console is perfectly usable for 99% of what you'll need to do. Most users won't need anything beyond it.

I believe the author was referring to navigating the filesystem and running commands via CLI (e.g. `cd` and `ls`, not `ec2-describe-instances`).

If that's the case, it's kinda pointless advice - none of the commonly used Linux AMIs have GUIs installed, and someone who can install X on one probably knows the CLI already.
a lot of the 'development server in a box' type AMIs (like from the AWS marketplace) have cpanel/webmin-type crap.
What about encrypting your pem file with AES (using 7zip on a Windows or OpenSSL on *nix) and then backing it up to the cloud?
If you keep one key per device, you can revoke it if/when that device is compromised, stolen, etc..

That key is for initial access to provision your machine, after which you should have a more sophisticated means of managing users, as certainly, if you are doing anything of much importance, you will eventually need at least 2.

And your IV and key for the AES encryption ... are you going to back that up to the cloud too? :-)