Difference between revisions of "Workflow"

From CSE330 Wiki
Jump to navigationJump to search
(Fixing up the SSH client and server configuration)
Line 137: Line 137:
 
Secure SHell, or '''SSH''', is the leading interface for connecting from your local computer to something on the cloud.  You will be using exclusively SSH to execute commands and upload files to your cloud instance.  If you use a Git hosting service like BitBucket or Github, you will need SSH in order to save your changes there as well.
 
Secure SHell, or '''SSH''', is the leading interface for connecting from your local computer to something on the cloud.  You will be using exclusively SSH to execute commands and upload files to your cloud instance.  If you use a Git hosting service like BitBucket or Github, you will need SSH in order to save your changes there as well.
  
This section discusses how to set up your computer for SSH.
+
This section discusses how to set up your computer and your instance for SSH.  You need to do this only once.
  
 
=== SSH Keys ===
 
=== SSH Keys ===
Line 164: Line 164:
 
</source>
 
</source>
  
''id_rsa'' is your private key, and ''id_rsa.pub'' is your public key.
+
''id_rsa'' is your private key, and ''id_rsa.pub'' is your public key.  Let's look at the public signature of your key pair:
 +
 
 +
<source lang="bash">
 +
$ cat ~/.ssh/id_rsa.pub
 +
ssh-rsa SomeLongGibberishStringOfCharacters
 +
</source>
 +
 
 +
We will need this later.
  
 
''' Cygwin Only:''' In order to make the SSH agent run when you start Cygwin, you need to add a couple of lines to your .bashrc file:
 
''' Cygwin Only:''' In order to make the SSH agent run when you start Cygwin, you need to add a couple of lines to your .bashrc file:
Line 171: Line 178:
 
$ source ~/.bashrc # reload the Bash shell</source>
 
$ source ~/.bashrc # reload the Bash shell</source>
  
=== Connecting to your Cloud Instance ===
+
=== Connecting to Your Cloud Instance ===
 +
 
 +
When you first created your EC2 instance, you downloaded a *.pem file.  This is the ''private key'' for the default user ('''ubuntu''' on Ubuntu or '''ec2-user''' on AMI).  We need use this key to connect to your instance using the default user, at which point we will create a new custom user.  We will give that new user the public key that you created in the previous step.  You will then be able to log into your custom user using your personal key pair, so you won't need the default user again (although you should keep the *.pem file around just in case).
 +
 
 +
==== Logging In as the Default User ====
 +
 
 +
To connect to the default user on your Amazon EC2 instance, run this command in Terminal or Cygwin:
 +
 
 +
<source lang="bash">
 +
$ ssh -i /path/to/default-privatekey.pem ubuntu@ec2-xx-xx-xx-xx.compute-1.amazonaws.com # or ec2-user@... for AMI
 +
</source>
 +
 
 +
If you get this scary-looking warning:
  
Now that you have your own public/private key pair, we are going to give the public key to your EC2 instance.
+
<source lang="text">
 +
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 +
@        WARNING: UNPROTECTED PRIVATE KEY FILE!          @
 +
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 +
</source>
  
In order to access your instance, we need to use the *.pem file you downloaded in the [[Amazon Web Services]] guide.  This file is nothing more than a private key.
+
…then you need to correctly set the permissions on your *.pem file.  You should know how to do this from the Linux guide, but in case you didn't catch that detail, run:
  
<span style="color:red">QUESTION: Should students use the *.pem key pair throughout the process, or should they give their public key to Amazon?  (Discuss.)</span>
+
<source lang="bash">
 +
$ chmod 600 /path/to/default-privatekey.pem
 +
</source>
  
#: '''Note:''' Once you have downloaded your key, set the permissions on it such that only you can read it; that is, the *.pem file you downloaded should have permissions <code>-r--------</code> on your computer.  For more information on setting file permissions, refer to [[Linux#File Permissions|the Linux guide]].  (Can you think of any reason why you wouldn't want other people viewing your private key file?)
+
'''Food for Thought:''' Why you wouldn't want other people viewing your private key file?
  
=== Adding SSH Users ===
+
You should now be able to SSH into your instance.
  
If you want to log into your EC2 instance using your own account rather than the default '''ec2-user''' or '''ubuntu''' account that Amazon made for you, you need to do some additional configurations.
+
==== Creating a New User with SSH Permissions ====
  
If you are using keys, you need to associate your private key with the user on the serverTo do this, run the following commands:
+
First, you need to create your new user with sudo permissionsAgain, the instructions for this are in the Linux guide, but to keep everything in one place, the commands are:
  
 
<source lang="bash">
 
<source lang="bash">
$ sudo su # you need to be root in order to access another user's directory
+
# Run these on your instance, not on your local machine!
$ cd /home/myUserName/
+
$ sudo useradd -r -m -c "My Full Name" <username here> # don't forget to customize `My Full Name` and `<username here>`
$ sudo mkdir .ssh
+
$ sudo passwd <username here>
$ sudo cp /home/originalUserName/.ssh/authorized_keys .ssh  # originalUserName should be ec2-user in the Amazon Linux AMI or ubuntu in Ubuntu Server 12.04 LTS
+
$ sudo chsh -s /bin/bash <username here> # Ubuntu only
$ sudo chmod 700 .ssh
+
$ sudo visudo # you need to add your username to the sudoers list.  In my demo installation, this was near line 19.
$ sudo chmod 600 .ssh/authorized_keys
 
$ sudo chown -R myUserName:myUserGroup .ssh  # myUserGroup is probably the same as myUserName; for example, if the username were alice, you could run: sudo chown -R alice:alice .ssh
 
$
 
 
</source>
 
</source>
  
You should now be able to log into your server using your custom username with SSH keys!
+
Okay, cool: we have created our custom username on our remote instance.  Now, we need to enable this account to accept our SSH key when authenticating.  To do this, we need to add our public key to a file named '''authorized_keys''', which is stored in your remote username's SSH configuration directory.
  
'''IMPORTANT:''' From here on out it is recommended that you always login as your user account instead of '''ec2-user''' or '''ubuntu'''.  Previous versions of the Amazon EC2 cloud created an account named "root", instead of the default account '''ec2-user''' or '''ubuntu'''.  If you really want to login as root, you can set the password for that account by typing: sudo passwd root.  As explained below, it is not recommended to use the root account or allow ssh connections with that username.  It is advisable to use the account you created instead of the root account (or '''ec2-user''' or '''ubuntu''') for security reasons. Additionally, the act of requiring you to type "sudo" in order to run commands as root serves as a reminder that the command you are typing in should be examined carefully.
+
To create the directory and edit the file, run on your instance:
  
=== SSH Client Configuration ===
+
<source lang="bash">
 +
$ sudo su <username here> # switch to our own user to ensure that permissions are set correctly
 +
$ cd  # change the working directory to our user's home directory
 +
$ mkdir .ssh  # make the nonexistent SSH configuration directory
 +
$ nano .ssh/authorized_keys  # create and edit the `authorized_keys` file
 +
</source>
  
==== Unix-Based Systems (including Mac OS X) ====
+
Inside of the `authorized_keys` file, paste in your public key.  (Hint: your public key is the output of running <code>$ cat ~/.ssh/id_rsa.pub</code> on your local machine, which you did earlier.  It starts with "ssh-rsa".) When finished, save and close the file.  '''Food for Thought:''' How would you enable your remote user to authenticate over SSH using the same default key instead of the one you created using ''ssh-keygen''?
  
Mac OS X is based on BSD, a flavor of Unix.  As such, Mac OS X comes pre-built with all the tools you need to use SSH! Simply fire up Terminal and enter the command
+
That should be all that we need to do!
  
ssh username@hostname
+
==== Logging In as your New User ====
  
To use SSH with a key pair, use the command
+
Let's test whether we can log into our instance using our own username and our own key pair. Open up a new Terminal or Cygwin and run:
  
ssh -i /path/to/key.pem username@hostname
+
<source lang="bash">
 +
$ ssh <username here>@ec2-xx-xx-xx-xx.compute-1.amazonaws.com
 +
</source>
  
==== Non-Unix-Based Systems (including Microsoft Windows) ====
+
This is how you will be SSHing into your instances for the remainder of the semester.
  
Unfortunately, using SSH with Windows is more complicated. Amazon provides a great tutorial on how to connect to a virtual machine from Windows (follow this link if you are in the Urbauer Lab) [http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/ConnectToInstanceLinux.html#connect-from-windows-machine]. It is necessary to install an SSH client to support the connections.  A widely used SSH client for Windows is PuTTY.  You can download PuTTY from http://www.chiark.greenend.org.uk/~sgtatham/putty/
+
== Using SSH and SFTP ==
  
PuTTY is fairly simple and straight forward with one caveat: Amazon's .pem key pair files are not compatible with PuTTY keys. In order to convert ''.pem'' keys to a PuTTY ''.ppk'' privte key file, you should use the puttygen.exe utility available from the same page [http://www.chiark.greenend.org.uk/~sgtatham/putty/] as PuTTY.  
+
Once you have completed the [[#SSH Configuration]] section above, all you need to do in order to SSH into your instance is to open a terminal and run:
Next select import under the conversions menu,load the amazon ''.pem'' key file and press the save private key button. Be sure to save the file in the directory where PuTTY looks for its keys.
+
 
 +
<source lang="bash">
 +
$ ssh <username here>@ec2-xx-xx-xx-xx.compute-1.amazonaws.com
 +
</source>
 +
 
 +
However, once your configuration is complete, this is not the ''only'' way to log into your instance. For example, your SSH server also supports '''SFTP''', which is a file transfer protocol that enables you to upload files directly to your instance.  This section documents some of these alternative methods of connecting via SSH.
 +
 
 +
=== PuTTY ===
 +
 
 +
If you have Cygwin available, you should use it to SSH into your instance.  However, if you are using a different computer, you might not have Cygwin at your fingertips. In this case, a lighter-weight SSH client called '''PuTTY''' is available for Windows.  You can download PuTTY from: http://www.chiark.greenend.org.uk/~sgtatham/putty/
 +
 
 +
Amazon provides http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/ConnectToInstanceLinux.html#connect-from-windows-machine a great tutorial on how to connect to a virtual machine from Windows].
 +
 
 +
PuTTY is fairly simple and straight forward with one caveat: Amazon's ''*.pem'' files are SSH private key files, and they need to be converted to PuTTY's own '''.ppk''' format.  To do this, use the ''puttygen.exe'' utility available from the same page as PuTTY. Select "Import" under the conversions menu, load the amazon ''*.pem'' key file, and press the "Save Private Key" button.
  
 
Copy and paste works similarly to the X Window System in Unix. You use the left mouse button to select text in the PuTTY window. The act of selection automatically copies the text to the clipboard: there is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact, pressing Ctrl-C will send a Ctrl-C character to the other end of your connection (just like it does the rest of the time), which may have unpleasant effects. The only thing you need to do, to copy text to the clipboard, is to select it.
 
Copy and paste works similarly to the X Window System in Unix. You use the left mouse button to select text in the PuTTY window. The act of selection automatically copies the text to the clipboard: there is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact, pressing Ctrl-C will send a Ctrl-C character to the other end of your connection (just like it does the rest of the time), which may have unpleasant effects. The only thing you need to do, to copy text to the clipboard, is to select it.
Line 225: Line 267:
 
To paste the clipboard contents into a PuTTY window, by default you click the right mouse button. If you have a three-button mouse and are used to X applications, you can configure pasting to be done by the middle button instead, but this is not the default because most Windows users don't have a middle button at all.  
 
To paste the clipboard contents into a PuTTY window, by default you click the right mouse button. If you have a three-button mouse and are used to X applications, you can configure pasting to be done by the middle button instead, but this is not the default because most Windows users don't have a middle button at all.  
  
Also, here is a good PuTTY tutorial that you might find useful to get started: http://kb.mediatemple.net/questions/1595/Using+SSH+in+Putty+%28Windows%29
+
Here is a good PuTTY tutorial that you might find useful to get started: http://kb.mediatemple.net/questions/1595/Using+SSH+in+Putty+%28Windows%29
  
 
=== SSHFS ===
 
=== SSHFS ===
Line 233: Line 275:
 
As you may have inferred from the name, the underlying implementation utilizes SSH File Transfer Protocol in combination with FUSE, a package now included in the kernel that allows unprivileged users to easily create their own file systems in userspace (see the wikipedia entry for more information [http://en.wikipedia.org/wiki/Filesystem_in_Userspace]).
 
As you may have inferred from the name, the underlying implementation utilizes SSH File Transfer Protocol in combination with FUSE, a package now included in the kernel that allows unprivileged users to easily create their own file systems in userspace (see the wikipedia entry for more information [http://en.wikipedia.org/wiki/Filesystem_in_Userspace]).
  
To mount a share using password based authentication, the command is
+
To mount a share using password based authentication, the command is:
sshfs user@domain:/path/to/remote/directory /path/to/local/mountpoint
 
e.g. To mount the directory /home/joe/myfiles in the user ''joe'''s home directory for a machine with the domain schmoesfiles.org using SSHFS you would enter the command
 
sshfs joe@www.schmoesfiles.org:myfiles
 
  
Note that if you are using public key authentication, the command to mount the remote share is slightly different
+
<source lang="bash">
sshfs -o IdentityFile=/path/to/private/key user@domain:/path/to/remote/directory /path/to/local/mountpoint
+
$ sshfs user@domain:/path/to/remote/directory /path/to/local/mountpoint
 +
</source>
  
To unmount the filesystem you can use the following command
+
For example, to mount the directory /home/joe/myfiles in the user ''joe'''s home directory for a machine with the domain schmoesfiles.org using SSHFS you would enter the command
fusermount -u /path/to/local/mountpoint
+
 
 +
<source lang="bash">
 +
$ sshfs joe@www.schmoesfiles.org:myfiles
 +
</source>
 +
 
 +
Note that if you are using public key authentication, the command to mount the remote filesystem may need to be slightly different:
 +
 
 +
<source lang="bash">
 +
$ sshfs -o IdentityFile=/path/to/private/key user@domain:/path/to/remote/directory /path/to/local/mountpoint
 +
</source>
 +
 
 +
To unmount the filesystem, you can use the following command:
 +
 
 +
<source lang="bash">
 +
$ fusermount -u /path/to/local/mountpoint
 +
</source>
  
 
=== SFTP ===
 
=== SFTP ===

Revision as of 05:58, 3 April 2013

The few minutes it takes to optimize your workflow will be the best few minutes you will spend in CSE 330 and your career. It is remarkable how many hours you can save just by using the best interface for text editing and deployment.

Overview

There are going to be several aspects to our workflow in CSE 330, and we will be switching between multiple different programs. Here is how they all fit together.

Running Commands

Mac OS X: You will be running commands on your local machine using Terminal, which you can find in your Applications -> Utilities folder. You will be connecting to your server via SSH also in Terminal.

Windows: You will be running commands on your local machine using Cygwin, which you will install in the next section. You will be connecting to your server via SSH also in Cygwin.

Version Control

You will be using SourceTree as a frontend to the Git version control system. Git enables you to keep track of changes to your source code, and also push your changes up to the CEC.

Text Editing

You will be using Komodo Edit as your text editing tool. Komodo Edit will also enable you to upload files to your Amazon cloud instance.

Flowchart

If you are more visual, this flowchart might help:

CSE-330-Workflow.png

The flowchart illustrates 3 methods to copy files to your cloud instance: via your text editor, via an external SFTP client, and by cloning your remote Git repository. We will be primarily using Option 1 in CSE 330 this semester.

In the flowchart, your Git Client is SourceTree and your Text Editor is Komodo. The optional SFTP Client could be FileZilla.

Cygwin

Cygwin is a Linux Terminal emulator for Windows.

Mac OS X users do not need to install Cygwin since OS X itself is a derivative of Unix, which is an ancestor of Linux. The Terminal utility is all you need.

Installation

The CEC lab machines already have Cygwin installed. Follow these instructions to get Cygwin up and running on your personal PC.

  1. Run setup.exe from http://www.cygwin.com/
  2. Keep the Cygwin directory as the default, C:\cygwin. Choose a place like C:\cygwin\downloads to download the installation files. Choose any download site, although probably one with a .com suffix is best when you're in the US.
  3. In the "Select Packages" screen, select the following packages:
    • Net -> openssh
    • Net -> openssl
    • Python -> python (you will need this for Module 4)
    • One or more of the following:
      • Editors -> vim
      • Editors -> emacs
      • Editors -> nano
  4. Allow the installation to complete.

Throughout the rest of this course, when we say to "open a terminal", if you are on Windows, we mean to "open Cygwin".

SourceTree

SourceTree is a tool that enables you to perform version control using a graphical user interface. It is free and available for Windows 7+ and Mac OS X 10.6+.

SourceTree is available on the Mac App Store. Windows users (and OS X users who don't like the App Store) may install it from http://sourcetreeapp.com/

Git

Git is a distributed version control system that enables you to track changes to your code and work with collaborators on the same code base. In CSE 132, you used Subversion (SVN), which is also version control system.

Git, like SVN, is a command-line tool. However, SourceTree enables you to use Git without having to pull up a Terminal window every time you need to perform an action.

In Module 5, you will learn more advanced techniques for using Git. However, for Modules 2-4, you will be using Git primarily as a method to push your changes to your remote repository.

Configuring Git/SourceTree

Once you install SourceTree, you need to tell it your name so that it knows how to tag changes you make.

  1. Open the SourceTree Preferences (SourceTree->Preferences on OS X or Tools->Options on Windows).
  2. Check the box that says "Allow SourceTree to modify your global Mercurial and Git configuration files".
  3. Enter your name and e-mail address.
    Note: This actually does the same thing as running git config --global user.name <NAME HERE> and git config --global user.email <EMAIL HERE> from the command line.
  4. Finally, go to the "Git" tab in the preferences and uncheck "Use the staging area".
    You will learn about staging in Git in Module 5, but for Modules 2-4 we will skip the staging area.

Cloning a Repository

Screenshot of cloning a repository in SourceTree

We will start by cloning a remote Git repository.

"Cloning" in Git is much like "checking out" in SVN: a remote copy of the repository is copied down to a local working directory. Word of Caution: Git uses the term "checkout" to mean something different (which you will learn in Module 5), so do not use the words "clone" and "checkout" interchangeably.

If you wanted to clone a repository on the command line, the command would be:

$ git clone git://www.example.com/url-of-repo destination-path

In SourceTree, go to File->New, enter the remote repository URL and the destination path, and press "Clone". The destination path is where you want the repository's files to be copied on your personal computer; the path should point to either an empty or a nonexistent directory on your personal computer. In the screenshot, I am cloning the repository for the Fedora Linux kernel.

The remote repository will now be cloned onto your personal computer and all ready to use.

Committing

Screenshot of committing to a repository in SourceTree

When you make changes to files or add new files, you need to commit them to your working repository. Note: When you "commit" something in SVN, it means that you are sending your changes to the remote repository. This is not the case in Git, as we will see shortly.

To prepare your commit, press the "Commit" button in the SourceTree toolbar. See the screenshot for an example.

Select the files you want to commit, and enter a commit message summarizing the changes you've made since your last commit. When you're ready, press "Commit".

The command line equivalent of this would be:

$ git add --all # adds untracked files to the repository and stages them for the commit
$ git commit -am "This is an example commit"

What happens now is that your changes are recorded in your own local working copy of the Git repository. The changes have not been saved in the remote repository. You need to do this by pushing them.

Pushing

Git is different from SVN in that you can use it completely independently from a remote repository. Thus, in Git, you need to perform the "commit" and "push" steps separately.

After you perform a commit, you need to push your commit to your remote repository. To do this, press the "Push" button in SourceTree, and then press "OK". The command line equivalent is:

$ git push master # assuming your branch is still named the default "master"

Note: You do not need to push after every commit. You could have 4 or 5 commits before you actually perform the push. When you push, all commits will be pushed.

Pulling

In SVN, if you want to download changes from your remote repository, you performed an update. In Git, you perform a pull.

Pulling is (usually) as simple as pressing the "Pull" button in SourceTree. The command line equivalent is:

$ git pull master

Note: If you want to download the changes from the remote repository but not overwrite your current working copy, you can perform a fetch instead.

SSH Configuration

Secure SHell, or SSH, is the leading interface for connecting from your local computer to something on the cloud. You will be using exclusively SSH to execute commands and upload files to your cloud instance. If you use a Git hosting service like BitBucket or Github, you will need SSH in order to save your changes there as well.

This section discusses how to set up your computer and your instance for SSH. You need to do this only once.

SSH Keys

SSH can work using password-based authentication, but it is more common nowadays, and also more secure, to use public and private keys, also known as a key pair.

Here's how it works. You have a private copy of your key, called your private key. Servers to which you want to connect have an analog to your private key called your public key. When you attempt to connect to a server using your private key, the server checks to see if any of its public keys "fits" your private key, and if it finds a match, it lets you in.

You can think of the private key as the "key" and the public key as the "lock".

Creating an SSH Key Pair

You should create your own SSH Key Pair. You will keep the private key on your own computer, and you will upload the public key to all places to which you need to connect.

To generate a key pair, open Terminal or Cygwin and run the following command:

$ ssh-keygen

Keep the default location. For the purposes of this course, you do not need to enter a passphrase, although you would probably want one in real life.

Your keys should have been created in ~/.ssh. Check to make sure they exist using the ls command:

$ ls ~/.ssh
id_rsa  id_rsa.pub

id_rsa is your private key, and id_rsa.pub is your public key. Let's look at the public signature of your key pair:

$ cat ~/.ssh/id_rsa.pub
ssh-rsa SomeLongGibberishStringOfCharacters

We will need this later.

Cygwin Only: In order to make the SSH agent run when you start Cygwin, you need to add a couple of lines to your .bashrc file:

$ echo "eval `ssh-agent -s`; ssh-add" >> ~/.bashrc # Cygwin only
$ source ~/.bashrc # reload the Bash shell

Connecting to Your Cloud Instance

When you first created your EC2 instance, you downloaded a *.pem file. This is the private key for the default user (ubuntu on Ubuntu or ec2-user on AMI). We need use this key to connect to your instance using the default user, at which point we will create a new custom user. We will give that new user the public key that you created in the previous step. You will then be able to log into your custom user using your personal key pair, so you won't need the default user again (although you should keep the *.pem file around just in case).

Logging In as the Default User

To connect to the default user on your Amazon EC2 instance, run this command in Terminal or Cygwin:

$ ssh -i /path/to/default-privatekey.pem ubuntu@ec2-xx-xx-xx-xx.compute-1.amazonaws.com # or ec2-user@... for AMI

If you get this scary-looking warning:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

…then you need to correctly set the permissions on your *.pem file. You should know how to do this from the Linux guide, but in case you didn't catch that detail, run:

$ chmod 600 /path/to/default-privatekey.pem

Food for Thought: Why you wouldn't want other people viewing your private key file?

You should now be able to SSH into your instance.

Creating a New User with SSH Permissions

First, you need to create your new user with sudo permissions. Again, the instructions for this are in the Linux guide, but to keep everything in one place, the commands are:

# Run these on your instance, not on your local machine!
$ sudo useradd -r -m -c "My Full Name" <username here> # don't forget to customize `My Full Name` and `<username here>`
$ sudo passwd <username here>
$ sudo chsh -s /bin/bash <username here> # Ubuntu only
$ sudo visudo # you need to add your username to the sudoers list.  In my demo installation, this was near line 19.

Okay, cool: we have created our custom username on our remote instance. Now, we need to enable this account to accept our SSH key when authenticating. To do this, we need to add our public key to a file named authorized_keys, which is stored in your remote username's SSH configuration directory.

To create the directory and edit the file, run on your instance:

$ sudo su <username here> # switch to our own user to ensure that permissions are set correctly
$ cd  # change the working directory to our user's home directory
$ mkdir .ssh  # make the nonexistent SSH configuration directory
$ nano .ssh/authorized_keys  # create and edit the `authorized_keys` file

Inside of the `authorized_keys` file, paste in your public key. (Hint: your public key is the output of running $ cat ~/.ssh/id_rsa.pub on your local machine, which you did earlier. It starts with "ssh-rsa".) When finished, save and close the file. Food for Thought: How would you enable your remote user to authenticate over SSH using the same default key instead of the one you created using ssh-keygen?

That should be all that we need to do!

Logging In as your New User

Let's test whether we can log into our instance using our own username and our own key pair. Open up a new Terminal or Cygwin and run:

$ ssh <username here>@ec2-xx-xx-xx-xx.compute-1.amazonaws.com

This is how you will be SSHing into your instances for the remainder of the semester.

Using SSH and SFTP

Once you have completed the #SSH Configuration section above, all you need to do in order to SSH into your instance is to open a terminal and run:

$ ssh <username here>@ec2-xx-xx-xx-xx.compute-1.amazonaws.com

However, once your configuration is complete, this is not the only way to log into your instance. For example, your SSH server also supports SFTP, which is a file transfer protocol that enables you to upload files directly to your instance. This section documents some of these alternative methods of connecting via SSH.

PuTTY

If you have Cygwin available, you should use it to SSH into your instance. However, if you are using a different computer, you might not have Cygwin at your fingertips. In this case, a lighter-weight SSH client called PuTTY is available for Windows. You can download PuTTY from: http://www.chiark.greenend.org.uk/~sgtatham/putty/

Amazon provides http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/ConnectToInstanceLinux.html#connect-from-windows-machine a great tutorial on how to connect to a virtual machine from Windows].

PuTTY is fairly simple and straight forward with one caveat: Amazon's *.pem files are SSH private key files, and they need to be converted to PuTTY's own .ppk format. To do this, use the puttygen.exe utility available from the same page as PuTTY. Select "Import" under the conversions menu, load the amazon *.pem key file, and press the "Save Private Key" button.

Copy and paste works similarly to the X Window System in Unix. You use the left mouse button to select text in the PuTTY window. The act of selection automatically copies the text to the clipboard: there is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact, pressing Ctrl-C will send a Ctrl-C character to the other end of your connection (just like it does the rest of the time), which may have unpleasant effects. The only thing you need to do, to copy text to the clipboard, is to select it.

To paste the clipboard contents into a PuTTY window, by default you click the right mouse button. If you have a three-button mouse and are used to X applications, you can configure pasting to be done by the middle button instead, but this is not the default because most Windows users don't have a middle button at all.

Here is a good PuTTY tutorial that you might find useful to get started: http://kb.mediatemple.net/questions/1595/Using+SSH+in+Putty+%28Windows%29

SSHFS

SSHFS is a filesystem client which allows secure mounting of remote file systems. While there are other ways to mount remote file systems, SSHFS has the advantage of being able to mount a file system located on any host that has an SSH daemon running without any host side installation or configuration. This means that you can easily access and edit your files using all of your local applications including IDEs.

As you may have inferred from the name, the underlying implementation utilizes SSH File Transfer Protocol in combination with FUSE, a package now included in the kernel that allows unprivileged users to easily create their own file systems in userspace (see the wikipedia entry for more information [1]).

To mount a share using password based authentication, the command is:

$ sshfs user@domain:/path/to/remote/directory /path/to/local/mountpoint

For example, to mount the directory /home/joe/myfiles in the user joe's home directory for a machine with the domain schmoesfiles.org using SSHFS you would enter the command

$ sshfs joe@www.schmoesfiles.org:myfiles

Note that if you are using public key authentication, the command to mount the remote filesystem may need to be slightly different:

$ sshfs -o IdentityFile=/path/to/private/key user@domain:/path/to/remote/directory /path/to/local/mountpoint

To unmount the filesystem, you can use the following command:

$ fusermount -u /path/to/local/mountpoint

SFTP

Any server running an SSH server is also compatible with SFTP or Secure File Transfer Protocol. (Compare to FTP, or File Transfer Protocol.) SFTP is a convenient way to edit files on your computer and then upload them to your server in just a few clicks.

You can use SFTP from the command line, or you can use any GUI file transfer client. All FTP clients I have seen also support SFTP. One popular FTP client is Filezilla.

Using FileZilla

  1. Download and install FileZilla from http://filezilla-project.org/download.php?type=client
    If you are using a lab computer, you can save it to your H drive.
  2. When you launch FileZilla, go to Edit→Settings or FileZilla→Preferences, and go to the SFTP options (under Connection). Click "Add keyfile…", and choose the *.ppk file that you made earlier using Puttygen. (If you lost that file, you can choose your *.pem file, and FileZilla will convert it for you.)
    When finished, press OK (not the red ×) to save your changes.
  3. Back on the main FileZilla screen, there are four fields: Host, Username, Password, and Port. Fill them in as follows:
    • Hostname: sftp://ec2-xxx-xx-xx-xxx.compute-1.amazonaws.com/
    • Username: The username you created on your server.
    • Password: Since you are using a key, you may leave this blank.
      If you changed your SSH settings to allow password-based authentication, then you could put your password in here.
    • Port: 22
  4. Then click Quickconnect. If everything is configured correctly, FileZilla should log into your server.


FileZilla.png


On the left and right of the FileZilla window, you can drag files between your computer and your server. Thus, you can edit a file in a text editor like Notepad++ on your decktop, and then upload it to your server by simply dragging it from the left pane to the right pane in FileZilla.

Komodo Edit

Komodo.png

This semester in CSE 330, we will be using Komodo Edit as our editor of choice. We chose this editor because:

  1. It is free for everyone.
  2. It runs on Windows, Mac OS X, and Linux.
  3. It supports all of the languages we will be using in this class.
  4. It has a decent amount tools like auto-completion that will speed up your workflow.

Installation

Komodo Edit is already installed on the CEC lab machines. If you prefer to use your personal computer, download it from the web site: http://www.activestate.com/komodo-edit

Connecting Komodo to your Remote Instance

With a little time spend on configurations and installing a plugin, Komodo Edit enables you to edit files on your desktop and then upload those files directly to your remote instance.

Adding SSH Public Key to Keychain

In order for Komodo to connect to your instance using SSH Public Key Authentication, you need to add your public key permanently to your SSH agent utility. Instructions are below on how to do this in OS X and Windows. You may skip to the next section if you are using password-based authentication.

Mac OS X
  1. Open Terminal.
  2. Save your *.pem file to ~/.ssh/cse330.pem:
    $ mv /path/to/your/cse330.pem ~/.ssh/cse330.pem
    
  3. Run the following command to add the key to your SSH agent:
    $ ssh-add ~/.ssh/cse330.pem
    
    For more information on ssh-add, see the manual.
Windows

under construction

Configure your Server Settings in Komodo

Once you have your public key in your SSH agent (if applicable), follow these steps to tell Komodo how to connect to your remote instance.

  1. Open the Komodo Edit Preferences. In Windows, this is Edit -> Preferences; in Mac OS X, this is Komodo -> Preferences.
  2. In the menu on the left, choose Servers.
  3. For Server Type, select SFTP. (Since you have an SSH server running, you will be able to connect to your instance via SFTP.)
  4. Name it something like CSE 330 Cloud Instance.
  5. Enter the details of your instance, including your hostname and username.
    • If you are using Public Key Authentication, leave your password empty.
    • Unless you explicitly changed your SSH port, your port will be 22.
  6. Your default path will be where you want to save the files you upload. Generally, this should be the root of your web server.
    Workflow-3.png
  7. Press Add to save the server information, and then press OK.
  8. IF YOU ARE USING PUBLIC KEY AUTHENTICATION, you need to perform these additional steps:
    1. In the Komodo Edit Preferences, choose Environment.
    2. Find the information about your SSH environment:
      • Mac OS X:
        • Enter the command ssh-agent in Terminal. You should see output similar to:
          SSH_AUTH_SOCK=/tmp/ssh-xxxxx/agent.xxxxx; export SSH_AUTH_SOCK;
          SSH_AGENT_PID=xxxxx; export SSH_AGENT_PID;
          echo Agent pid xxxxx;
      • Windows:
        • under construction
    3. Add the following environment variables in Komodo:
      • Name: SSH_AUTH_SOCK
      • Name: SSH_AGENT_PID
      The values for these environment variables should be what you learned earlier in step 2.
    4. Press OK to save your changes.
  9. To test whether Komodo is able to successfully connect to your server, choose File -> Open -> Remote File. Select CSE 330 Cloud Instance from the drop-down menu. You should be able to see a list of files in your public_html directory.

Installing Upload Extension

Strangely, Komodo Edit does not come built-in with a mechanism to upload files from your computer to the server. Fortunately, the community has released an add-on that gives us this feature.

  1. In Komodo, go to Tools -> Addons.
  2. Search for the add-on named Uploader.
  3. Download and install it, and restart Komodo.
  4. In your Server preferences, create a new server (or rename an existing one) to be identical to your project name, but starting with a star. For example, in my project named FileShare, I would name the server *FileShare. The default path will be the location to which Komodo will upload your files. Note: The path should be absolute.
  5. You can now select a file and go to File -> Upload to upload it to your server.

Tip: To make things quicker, you can bind a keyboard shortcut like ctrl/cmd+D to the Upload feature by following these steps:

  1. In Komodo preferences, choose Editor -> Key Bindings.
  2. Find the "Upload" command under "General". Press in the "New Key Sequence" box, and press ctrl/cmd+D. Proceed through the on-screen instructions; you can name your new scheme Custom.
  3. Save the preferences and restart Komodo. You will now be able to upload files by simply pressing ctrl/cmd+D.


Starting a Project

When you start a new project, whether individual or group, you should create a new directory and a new Komodo Project file.

  1. Create a new directory in your repository named after the project you will be starting (e.g., fileshare).
  2. In Komodo, choose Project -> New Project (or press shift-ctrl-N).
  3. Navigate to the directory you just created, enter a name for the project (e.g., FileShare.komodoproject), and press "Save".
  4. You should now see a window like this:
    Workflow-1.png
  5. Press ctrl-N (or cmd-N) to create a new file. Save it in your project. For example, you could create a page named index.html with the Quick and Easy Page Layout:
    Workflow-2.png
  6. Continue creating and editing the files from your site.
    Tip: To change between files without using a mouse, press ctrl-PageUp and ctrl-PageDown (cmd instead of ctrl on OS X). Many computers without explicit PageUp and PageDown buttons bind them to fn-Up and fn-Down. For example, on a MacBook Pro, to change to the next tab, you would press three keys: fn+cmd+down.
  7. When you are ready, upload your files to your remote server. To do this, go to File -> Save as Other -> Remote File.