How to log into your freshly fired-up instances and how to secure ssh access
(works under Linux and Mac OS, under Windows with Cygwin)
First time you want to log into a newly started instance you appear to have the chicken-and-egg problem: how to log in when you do not know the root password? Luckily Amazon devised a comfortable way to circumvent this: your Key Pairs. these are not to be confused with the „Access Key IDs“ on the Access Identifier web page and they are neither the X509 certificates. These Key pairs are automatically generated the first time you log into the web console and you can only download its private part. Store it in your ~/.ssh directory. In case you missed the download or don't know where you've put it AND you don't have any instances running, just generate and download a new one.
Beware: already running instances are bound to this key and if you didn't change the sshd config like described below, you won't be able to log in anymore! A new SSH key can be generated both on the AWS web console and ElasticFox under „Key Pairs“.
For the sake of simplicity we assume that there's no instances running and you either have your key already placed in ~/.ssh or created and download a new one.
Beware again: everyone who gains access to this key can log into the respective instances as root! So make sure it is readable only by you.
You can even have several Key pairs, may be if several people are supposed to manage a sub-set of instances while each one isn't allowed to log into the instances managed by others. Whether this concept is recommendable or not, it is possible. So for the first-time login to a new instance, use this:
ssh -i .ssh/mykey.pem root@[AWS_public_hostname]
As soon as you created users on your web server instances and provided passwords for the accounts, you want your web developers be able to log in -- without having root access of course. And (at least for some/many public images) password logins are denied per default and you really don't want to give your key to anyone who must not have root access. What to do?
Activating Password Access
Easy: either activate password logins or use ssh keys. For passwort logins edit /etc/ssh/sshd_config and set „PasswordAuthentication“ to „yes“,issue a „/etc/init.d/ssh reload“ for the new config to become active. But a much better solution is to use ssh keys.
SSH keys as a password replacement
SSH uses public key cryptography, hence its keys consist of a public ("id_dsa.pub") and a private part ("id_dsa"). These keyspairs are both user- and machine-dependent. Thus you have to generate them once for every user on every machine from which you connect to the servers (not for every server!). And don't just copy them over!
The private part of a user's key has to remain in ~/.ssh/ and this directory must be not readable by other users. The public part instead doesn't have to be hidden from other's views, that's why it is called "public". At first look into your user accounts ~/.ssh/ on your local machine, whether there might already be the files "id_dsa" and "id_dsa.pub". If they exist, don't make new ones and proceed to the copy process instead. If the files don't yet exist, create them:
ssh-keygen -b 1024 -t dsa
You will be asked for your passphrase twice. Input your desired passphrase and try not to forget it. Now you have two files in "~/.ssh/": "id_dsa" und "id_dsa.pub". Copy the public part to your instance and append it to the user's "~/.ssh/authorized_keys" file. Make sure the user rights are correct: the "~/.ssh" directory and everything in it should be owned by the respective user, "authorized_keys“ should have 600 and "~/.ssh 700". Next time you log in you won't be asked for a password anymore and you don't have to give your AWS Key while logging in. Do this for every user who is supposed to log into your instance, test that it works and then de-activate "PasswordAuthentication" in the sshd config, if you activated it before.
In case your local machine is running under Windows and you don't use the
Cygwin environment but
Putty instead, please read here: http://tartarus.org/~simon/putty-snapshots/htmldoc/Chapter8.html#pubkey
Remember: Your chosen passphrase while creating the ssh keys protects access to the private part of your key. This passphrase doesn't have anything to do with login passwords. You can also just press RETURN once asked for a passphrase, but then everyone who gains access to your private key file is able to log into the servers where the public part is installed.
Disabling remote root login
Once user logins are working, you want to deactivate direct login as root via network. This is generally a good idea as it makes it even harder for anyone to really exploit some possible vulnerabilites in the ssh daemon. While your instance is already quite secure with no password login and ssh keys, it is always better to be safe than sorry. First you have to give a password for the root account, if your Linux doesn't use the sudo mechanism, as Ubuntu does. In this case you don't have to give root a password. Just log into your user account and try "sudo -s". It asks for your password and then you should be root. For Linuxes which doesn't use sudo, like SuSE, give root a password, log in as user and try "su -" with root's password. If either su or sudo works, you can de-activate remote root access in /etc/ssh/sshd_config with setting "PermitRootLogin" to "no". Of course there's other means to secure your server even more -- which would go too far for this instalment, like preventing most users to gain root rights at all.
Further securing access to your instances
If you're running a production environment, you want to secure it as much as you can. Even if you installed ssh key authentication and forbid passwords, you can tie access further down with restricting access via ssh to only some IP addresses like the public one of your office's internet connection. This is especially useful if there's several web designers working on your servers and you aren't sure they know how to handle passwords and stuff. They might carry unsecured notebooks around, they might mail their user keys around and everything.
So in case your office's internet connection has a fixed IP address, you can restrict ssh access to only this address. While -- as far as I know -- it is quite common in the US to have an internet connection with a quasi-fixed IP address (bound to your DSL modem's MAC address), there's countries like Germany where the usual DSL line has dynamic IP addresses, which actually change every 24 hours. In this case restricting access to IP addresses is of course out of the question. So either stick with the ssh keys or change your DSL line into one with a fixed address -- which has other benefits as well, like a more stable VPN access (yes, I know, dyndns works -- mostly).
Anyway, to tie down ssh access you have to manipulate the Security Groups assigned to your instances. Remove the rule where ssh access is allowed from everywhere and instead create a new one which allows access only from your office's IP address. And you might think about a second rule with another IP address you can login from -- in case your office's DSL line is down. Don't worry, if you misplace some rules, you cannot lock yourself out. You can alway use
ElasticFox or the AWS web console to change the rules back to „access from everywhere“.
