Nuclear Luck

About Fallout. (Image Credit: Wilding)

In the modern era,

Modern mathematics should be

History: Set Theory's Origin

If one wishes to communicate in private with some other entity over an untrusted network, it's best to assume anyone can see everything you send. The problem then is to encode your information such that, to someone without privileges, you're sending complete gibberish, or completely random messages (of course this is the ideal case). We may substantiate these privileges in the form of another bit of information, termed a key, that allows the recipient or key holder to decode the message into something coherent. Of course, a common problem with such a simple method is how one may initially distribute said key to an remote recipient, since we assume the same available channels are untrusted.

The SSH protocol works around this by providing a secure means of transfer, specifically for the key to be used in symmetric communication (since symm. encryption is generally cheaper computationally).

SSH diagram from Wikimedia Commons (License:

SSH Protocol: Usage

To utilize the SSH protocol, both entities must have some SSH client installed (the most common being OpenSSH, available for most OS distros), and visible on the same network. Mac and Linux distributions have an SSH client (OpenSSH) by default installed and ready for use in terminal; Windows 10 and onward generally do as well (OpenSSH; PuTTy also works well for older versions). Below, the most common use of SSH, as the client trying to connect to a remote server (with OpenSSH) is covered. Then, a few things on the server side needed to allow for such connections are discussed.

If both devices are not on the same network, SSH tunneling may be further be required to establish a connection.

Client Side (OpenSSH)

The most common usage of SSH is to connect from client-side to some user account on the server-side and act on that remote server as the logged in user. This can be accomplished by entering the following into the appropriate local terminal: ssh <username>@<ip.address> Here username field should be filled in with the user account on the remote server one is trying to sign in as, and the ip address should be replaced with any unique and recognized identifier for the remote server on the network.

First Time Connecting: Trust

The first time one connects to a unique server, one must take a small leap of faith and assume that you may trust the initial message of the intended partner. Hence, the first connection to a unique server from some client will (or atleast should) be prefaced by a prompt as to whether you are willing to trust this first transaction.

An example prompt for intial trust of an SSH server's authenticity

After this initial contact, the host's key is saved so this prompt shouldn't appear again for an equivalent connection. If a similar prompt, or one asking about a change in the host's key, appears after this initial instance, suspicions should be raised as to the authenticity of connection.

Additional Fields

Some optional fields are also commonly used with the SSH command in terminal, these include specfiying the port number with -p to connect via (which is 22 by default), whether or not to show extra data about the connection (which is supressed by default) with -v. The usual -h can also be used to display additional options, as usual.

Server Side

As mentioned above, the remote server one is attempting to connect to and control requires that it is acting as an SSH server. The method of initiating this service is varied depending on the SSH client chosen, but the a common case (OpenSSH in Arch Linux terminal) is covered here.

Server Initialization

Regardless of the specifics, setting up an SSH server generally requires the intended server to treat an SSH event listener, such as SSHD, as a service that runs constantly in the background, listening for requests through the network for SSH connections. Starting this service thus constitutes the intitialization of a device as an SSH server and is all one needs to do to set it up as such.

SCP Protocol: Overview

Another common operation one often encounters is that of secure transfer of files from one device to another over an untrusted network. This may be accomplished with the use of a transfer protocol based on SSH such as the Secure File Transfer Protocol (SFTP) or Secure Copy Protocol (SCP), which is discussed here.

SCP Protocol: Usage

The most basic usage of SCP is to copy a file from a local device to a remote server, or vice versa. This may be specficied in the addresses of the files. SCP takes as the first argument the address of the file to be copied and then takes the last argument as the address for the file to be copied to. scp <current file address> <copy destination> Note that one may include several files to be copied, which will be read as all but the last argument given to scp (where the last is always the destination). Hence, to copy multiple files simultaneously to the same directory, the following structure of command should be given. scp <current file address 1> ... <current file address n> <copy destination> The above will then copy files from <file address 1> to <file address n> to the directory specified at the address <copy destination>.

A common problem encountered when using SCP is when one wishes to copy whole directories from one location to another. This case may be handled by applying the additional, optional argument -r (for recursive) letting SCP know you wish to copy those directories recursively to the destination.

Further Resources

A good introduction to the SSH protocol can be found in this netburner article.