Our goal is to transfer information securely between a known client (Alice) and a service (Bob) such that Bob and Alice can be certain that only they are privy to the information being exchanged. Once the information is in their hands, they trust each other not to pass it on to anyone else. A spy (Charles) cannot masquerade as either Alice or Bob and he cannot evesdrop on what Alice and Bob are saying to one another.
OpenSSL remains the best option for Alice and Bob. It is used throughout the Internet to access servers and all manner of critical information. The recent issues with the heartbleed only serve to underline why Open Source is the most effective route to secure transactions: The problem was identified and rapidly addressed across the world. If OpenSSL had been closed source, this vulnerability might have languished until it was extensively exploited. As it is, the only known exploits followed on the heels of the public discovery of, and solution to, the problem and thus have only affected those servers whose administrators did not quickly address the problem.
To understand how OpenSSL works, consider the following analogy:
SSL relies on the concept of “public key cryptography” to accomplish these same tasks. In normal “symmetric” encryption, the two parties communicating share a “password” and that password is used to both encrypt and decrypt messages. While this is fast and efficient, how do you communicate the shared passwords to people you have not yet met in a way that is itself secure?
In “public key cryptography”, each person has two keys — a “public” key and a “private” key. Anything encrypted with the person’s public key can only be decrypted with the private key and vice versa. Each person then tells the world what his public key is and keeps his private key safe, secure, and, well, private.
If Alice sends Bob a message encrypted with Bob’s public key, then only Bob can open it, as only he has his private key. This is like an envelope that anyone can seal but which only Bob can open.
If Alice sends Bob a message encrypted with Alice’s private key, then anyone can open it, as everyone has access to Alice’s public key. However, successfully opening the message proves that it was sent by Alice and no one else, as only Alice has access to her private key. This is like an envelope that only Alice can seal, but which anyone can open and thus prove that Alice sealed it.
To make use of OpenSSL to transfer files directly to services, you need to first generate a key pair. You will never need to divulge your private key - it is important that you keep this secure and do not reveal it to anyone. If using Linux (best) or a Mac (OK) then the following instructions will create (or locate) your key pair. For less secure client systems using Microsoft Windows, there are various utilities available which google will quickly find.
First, we need to check for existing SSH keys on your computer. Open up your Terminal and type:
cd ~/.ssh ls -al # Lists the files in your .ssh directory
Check the directory listing to see if you have files named either
id_dsa.pub. If you don't have either of those files go to step 2. Otherwise, you can skip to step 3.
To generate a new SSH key, copy and paste the text below, making sure to substitute in your email. The default settings are preferred so, when you're asked to "enter a file in which to save the key", just press enter to continue.
ssh-keygen -t rsa -C "email@example.com" # Creates a new ssh key, using the provided email as a label # Generating public/private rsa key pair. # Enter file in which to save the key (/home/you/.ssh/id_rsa):
Next, you'll be asked to enter a passphrase.
Tip: We strongly recommend a very good, secure passphrase. For more information, see Working with SSH key passphrases.
# Enter passphrase (empty for no passphrase): [Type a passphrase] # Enter same passphrase again: [Type passphrase again]
Which should give you something like this:
# Your identification has been saved in /home/you/.ssh/id_rsa. # Your public key has been saved in /home/you/.ssh/id_rsa.pub. # The key fingerprint is: # 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db firstname.lastname@example.org
Then add your new key to the ssh-agent:
Supply your system administrator with the
id_rsa.pub file and your username on your local system if they don't already know it (using the same username on the service will avoid you ever needing to type in your username explicitly).
id_rsa.pub is your public key so you can email it to them safely. Remember, you never need to supply your private key to anybody for any reason.
Once your administrator has set up your account with your public key, you can use the
rsync command to efficiently copy files to the service and
ssh to login to the service in order to review the files and do other work (depending upon your privileges).
$ rsync my_datafile.csv example_server.com: $ ssh example_server.com ...$ ls my_datafile.csv ...$ logout $
Use google or the
man command to find more that you can do with ssh and rsync.
Australia: 07 3103 2894
International: +61 410 545 357