Live data from Hacker News

Tips for Getting Started With AWS

jamescarl.us

1–10 of 56 posts

Re: Tips for Getting Started With AWS

#2
> 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.

Re: Tips for Getting Started With AWS

#3
post #2

> 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…

> 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.

Re: Tips for Getting Started With AWS

#4
If you choose to upload .pem to cloud storage, make sure you secure (encrypt) your .pem file, since it allows total access to the boxes! You should also secure remote access via the "security groups" firewall by only allowing known ip addresses (you can edit this via the aws console as needed). Since he mentioned the "The Command Line Crash Course" [1]. I might chime in with a couple into screencasts I've created.

Crash Course on the Filesystem Hierarchy Standard @ http://sysadmincasts.com/episodes/12-crash-course-on-the-fil...

Crash Course on Common Commands @ http://sysadmincasts.com/episodes/13-crash-course-on-common-...

Crash Course on Man Pages @ http://sysadmincasts.com/episodes/19-crash-course-on-man-pag...

[1] http://cli.learncodethehardway.org/book/

Re: Tips for Getting Started With AWS

#5
post #2

> 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…

> 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.

Here's a better idea. Learn to use IAM properly and rotate your keys on a schedule.

Re: Tips for Getting Started With AWS

#6
post #2

> 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…

> 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.

Re: Tips for Getting Started With AWS

#7
post #5

Earlier quoted context omitted.

> 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.

Here's a better idea. Learn to use IAM properly and rotate your keys on a schedule.

IAM rotates ssh keys?

Re: Tips for Getting Started With AWS

#8

If you choose to upload .pem to cloud storage, make sure you secure (encrypt) your .pem file, since it allows total access to the boxes! You should also secure remote access via the "security groups" firewall by only allowing known ip addresses (you can edit this via the aws console as needed). Since he mentioned the "The Command Line Crash Course" [1]. I might chime in with a couple into screencasts I've created. Cr…

I suggest using a TrueCrypt volume with your credentials, stored on Dropbox.

Re: Tips for Getting Started With AWS

#9
post #2

> 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…

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.

Re: Tips for Getting Started With AWS

#10
post #2

> 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…

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?
Post reply on HN