Thursday, February 25, 2010

Join us for Part 1 of the MySQL in the Cloud webinar series with Jimmy Guerrero and Mike Frank of the MySQL group at Sun Microsystems. In this presentation we will explore the benefits and some specifics related to deploying and managing MySQL in a “cloud” environment. We will discus several cloud computing platforms suitable for hosting MySQL, including the Joyent Public Cloud, Amazon EC2 and Windows Azure. Included will be a discussion of cloud enabling technologies like VMWare and Xen. If you are interested in learning how to leverage cloud computing with MySQL, this webinar is for you.

WHO:

• Jimmy Guerrero, Sr Product Marketing Manager – Sun Microsystems
• Mike Frank, Sr Product Marketing Manager – Sun Microsystems

WHAT:

MySQL in the Cloud – Part 1: Introduction to Deploying MySQL in the Cloud web presentation.

WHEN:

Thursday, February 25, 2010: 10:00 Pacific time (America)

The presentation will be approximately 45 minutes long followed by Q&A.

1) First login to your Plesk control panel.

2) Then select the domain on which you wish to install the SSL certificate.

3) Then select the “certificates” icon.

4) Then select the icon “Add New Certificate”.

5) Give the certificate a name. This is for your reference only.

6) Then generate a certificate request which you will submit to the Certified Authority (CA).

7) Once you are done with it, come back to the previous page.

Then select the certificate 1 which is given below the page.

9) Copy the CSR (Certificate Signing Request) and the Private key. You will need to submit these in your application to the Certified Authority (CA).

10) Once you have done that and submitted the CA your SSL certificate will be installed on the domain you have selected.

If you do not wish to get into all this, your web hosting provider can provide you with the SSL certificate on the domain you wish to. You will have to pay some charges to your web hosting provider for the SSL certificate. It might be possible that your web hosting provider does not provide SSL certicates and if this is the case, then you will have to do it on your own with the above given steps.

Note : You will have to purchase a Dedicated IP for the domain you wish to have the SSL certicate on both Windows as well as Linux Dedicated Servers. You cannot install the SSL certificate on the domain if the domain does not have a Dedicated IP.

Login to your server. You should be in your home directory, if not go there with ‘cd ~’
vi (or pico, vim, etc.) .bash_profile

At the end add this:

# User specific environment and startup programs

# Email admin when user logs in as root
rootalert() {
  echo ‘ALERT – Root Shell Login’
  echo
  echo ‘Server: ‘`hostname`
  echo ‘Time: ‘`date`
  echo ‘User: ‘`who | awk ‘{ print $1 }’`
  echo ‘TTY: ‘`who | awk ‘{ print $2 }’`
  echo ‘Source: ‘`who | awk ‘{ print $5 }’`
  echo
  echo
  echo ‘This email is an alert automatically created by your server telling you that someone, even if it is you, logged into SSH as the root user.  If you or someone you know and trust logged in as root, disregard this email.  If you or someone you know and trust did not login to the server as root, then you may have a hack attempt in progress on your server.’
}
rootalert | mail -s “Alert: `who | awk ‘{ print $1 }’` Login [`hostname`]” (your OFFSITE email address)

By the way those wierd looking single quotes are the one on the key to the left of the 1 key on the top row of the keyboard. They tell the shell to execute the command between taking their output for the line it’s on. In this case, printing out pieces of login information. So go ahead and save and close the file.  Before logging out  type ‘sh .bash_profile’   and check that it execute cleanly, and emails you like it should.

So now if someone logs into your account, you will get an email. If it happens when you weren’t expecting it (as when you didn’t login yourself), you will know about it… Plus you’ll have the ip address they were on when they did… well, you’ll have the ip address of the last machine before they reached you as they will often go from one machine to the next. But it’s more than you had. And if you didn’t know, who knows how long they could hide out there and what damage they could cause.

I find this provides dual benefits… One, passwords are too easy to crack sometimes (or too easy to forget if you actually are one who makes them difficult to crack). And two, it actually makes ssh’ing into the server easier. What we’re going to do is generate key pairs for the server and your client, and then use that to authenticate to the server.

1. First get a SSH session going. And like yesterday, don’t close it until I tell you.
2. Generate the user’s keypair on the server with “keygen -t rsa”.  This will go into .ssh directory off the user’s home directory – you’ll need these to ssh to other boxes and it creates the .ssh directory for you.
3. cd ~/.ssh
4. Next create a keypair on the client. For putty this is done with PuTTYgen. If you use something else you’ll need to lookup how for that client.  This will create a couple of files for you… id_rsa.pub is the public key file and id_rsa.ppk is the private key.
5. Transfer the public key to the server in user’s home/.ssh directory with a NEW NAME. Don’t overwrite anything!
6. If a authorized_keys2 already exists you will need to cat the file onto the end with ‘cat (filename) >> authorized_keys2′   NOTE the double greater than. That means append it to the end.  If you mess this up other keys will be lost.
7. I also recommend that if you are going to have multiple keys for the user, you edit the comment at the end of the line you just added to authorized_keys2. The comment is the portion at the end after the second space. The line’s format is (ke type)(space)(key)(space)(comment) So you’ll see something like “ssh-rsa (lots of letters and numbers) rsa-key-YYYYMMDD  where YYYYMMDD is the year month and day you made the key. It’s that last bit (and only that last bit) you can safely change.
8. Make sure the authorized_keys2 file is readable only by you (chmod 600 or 700).
9. If this is going to be for the root user do steps 9 -
10. cd /etc/ssh
11. cp sshd_config sshd_config.save
12. vi (or vim, pico,etc) sshd_config
13. find the PermitRootLogin  line and change it to read ‘PermitRootLogin without-password’
14. Save/close  the file
15. Restart sshd with ‘service sshd restart’ or ‘/etc/init.d/sshd restart’  — Remember don’t close your session until we know everything works correctly!!
16. Start another PuTTY, and load (not start) the session
17. On the left-hand side, select the Data Category under Connection
18. Specify the user’s name in the Auto-login username field
19. Again under Connection, expand out the SSH branch and select Auth
20. Click the browse button for the Private key for authentication field and find and select the id_rsa.ppk file you created in step 4.
21. This one has caught me a couple of times… Go back up to the Sessions branch all the way at the top left side, and click Save for the session on the right. Otherwise, you’re going to do the PuTTY side config again.
22. Test the passwordless login… Be absolutely sure it works, before dropping that first session. If it doesn’t you NEED to restore the sshd_config.save file back to sshd_config AND restart SSHD again, undo the PuTTY changes and test that you have put it back to where you can get in again BEFORE you drop that connection.

Provided everything worked, you now have an automated login that’s using a nice long keypair and not some little password… and provided you did yesterday’s changing of SSHD port numbers, you’ve probably locked out 99+% of anyone’s chance of getting into you machine through brute force methods, so take a break and enjoy the enhanced security (well until you learn about all the other methods of getting into the machine anyway…) Seriously though, most hack attempts prey on the people that don’t take the precautions, so you’ve just dropped your chances quite a bit just through these 2 little procedures.  You’re not safe and secure, but you are a lot better off than you were 2 days ago.

1. Login into your server via ssh — don’t close this session until I tell you to!!
2. cd /etc/ssh
3. cp sshd_config sshd_config.orig
4. vi (or vim, pico, etc. – whatever editor you prefer)  sshd_config
5. find the line that says Port 22
6. Remove the # at the begining of the line if there is one.
7. Change the 22 to some other number – do NOT use anything less than 1024
8. Save & Close the file
9. Restart sshd – usually with “service sshd restart”  or “/etc/init.d/sshd restart”
10. Start ANOTHER session this time connecting to the new port – if prompted to accept the key, do so.
11. Provided you get logged in, you’re ok to drop the first connection. If not you need to restore the sshd_config.orig back to sshd_config and restart the ssh server again (step 9).
12. Save your new port settings in your client.

One note … if you ssh, scp or rsync from another machine you will need to slightly modify the command lines for the new port.
ssh -p #### … (rest of command) …
scp -P ####  … (rest of command) …
rsync -e ‘ssh -p ####’ … (rest of command) …

Stay tuned … tomorrow we’re going to enhance ssh security a little more…