Working with remote servers with SSH and SCP.
SSH is a secure connection method between servers or computers over untrusted networks.
Often times in computational work it's neccesssary to communicate with, or through, and control remote servers from some local machine. Perhaps the most common protocol through which such remote control and communication is done is the Secure SHell or (as it's more commonly refered to as) the SSH protocol. SSH also has an associated protocol specifically for secure file transfer over untrusted networks, termed the Secure Copy Protocol or SCP (see also SFTP). Below, a brief overview of the cryptographic methods are given, as well as a working minimum of code in the cases of most common usage.
SSH Protocol: Overview
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 for key distribution are untrusted.
The SSH protocol works around this by providing a secure means of transfer, specifically for the symmetric key to be used in further transactions. The common analogy is that two (physically) separated people each have their own key and padlock, and they'd like to communicate securely through some courier they don't trust. So, they first agree to use some briefcase or box through which they will pass their written message. Then, the one first sends the box with the message in it and locked with his own padlock. The intended recipient receives this package and places his own padlock, locked, onto it (since he doesn't have the key to the other padlock). This doubly locked package is then returned to the sender, who removes his padlock; and returns it to the recipient, now locked only with the recipient's padlock. This is effectively done once to communicate the means/key by which all further communication will be encrypted, in essence opening a secure channel between the two parties.
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.
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), and 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 always.
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 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.
