Networking using OpenSSH

The project is to build a Linux Mint machine to have the identical functionality and ergonomics as the existing Windows 10 machine.  This stage relates to networking the Windows 10 machine to the Linux Mint machine.

Environment & required functionality

The network should be a local network - to share files and folders - between the following machines:

• The Linux Mint Xfce 18.3 laptop "Gandalf";
• The Windows 10 laptop "Legolas".

The network is a local area network from a domestic router, the usual 192.168.x.x thing.

This is the second attempt to share files and folders between Windows and Linux Mint.

Thankfully, this attempt met the core objectives.

Alternatives

As with the first (failed) attempt, peer-to-peer networking (file sharing, simple two-way server-and-client relationship) is the most efficient way for bulk data transfers, so if the network doesn’t work, then the test has failed.

Software selection

Both machines needed to have new software:

• Legolas (Windows) needed the full PuTTY suite of files for Windows.
• Gandalf (Linux Mint) needed openssh-server.

These are not the only available software.  For example, OpenSSH Server is also available from within Windows 10, as an alternative to using PuTTY.  For example, PuTTY has a Unix package, which might have worked on Linux.  These alternatives are outside the scope of this test.

The software selection assumes a client-server relationship between the two machines.  For this test, as with the first (failed) test, Gandalf/Linux Mint is the server and Legolas/Windows is the client.  The main reason for this choice is a presumption of ease.

Installation experience

On Legolas/Windows, PuTTY was the standard Windows experience: download the MSI file, scan it for malware, install it, run it, done.  Although "installed", the applications run more-or-less as stand-alone applications.  The key app for this test was PSFTP, which is a CLI.

On Gandalf/Linux Mint, the GUI app Software Manager was the easiest way to find, to identify and to install openssh-server.  The admin account installed the software; the software ended up as a service run on Gandalf's start-up, which is the desired functionality.

The initial installation and configuration of openssh-server on Gandalf is set out at RootUsers.

Gandalf then needed a hole punched into its firewall (source):

sudo ufw allow ssh

User experience

On Legolas/Windows, both PuTTY and PSFTP successfully connected to Gandalf.

The remote terminal tool PuTTY was able to log into Gandalf's two user accounts, either the admin user or the non-admin user, using their credentials, and was able to use the terminal as if the user were logged onto Gandalf.  This is the correct functionality.

The remote file transfer tool PSFTP was able to log into Gandalf's two user accounts, either the admin user or the non-admin user, using their credentials.  Once logged in, the CLI for PSFTP required the following series of commands.  The last command was all that was necessary to transfer the entire Music folder on Legolas to the Music folder of Gandalf.  Both environments define a user folder "Music", which is convenient!

psftp> open 192.168.0.20

Login in: <remote_username>

Password: <remote_password>

Remote working directory is /home/<remote_username>

psftp> lpwd

Current local directory is C:\Program Files\PuTTY

psftp> lcd c:\users\<local_username>\

New local directory is c:\users\<local_username>

psftp> pwd

Remote directory is now /home/<remote_username>

psftp> put -r Music

Inevitably, a large batch of files is likely to be interrupted, especially when unattended, because that's the way that sod's law works.  A useful command to resume the transfer process is:

psftp> reput -r Music

Although the remote user can log into the server (in this case, Gandalf) remotely (in this case, from Legolas), the same user logging into and outside his account on Gandalf triggered an interruption of PSFTP's transfer of files!  Moral of the story is that once the process is started, leave everything alone until it's done!

As usual, a CLI requires the user to learn commands within productive memory, because there is no on-screen prompting as would typically be available in a GUI.  However, the commands are simple to learn and simple to use, but somewhat tedious: a Windows user would probably dislike having to be so precise in a CLI when all sorts of sloppiness is possible in a GUI designed for users who rightfully need it simple and rightfully expect the machine to get its own (internal) technicalities right.

Dead-ends

The above represents the process that worked.

There was one dead end during the course of discovering the above process, which was to find that the simple firewall ufw was so simple (!) that it blocked the normal use/operation of port 22 (set aside for SSH).

The admin user installed on Gandalf separate app, nmap, to determine whether the port was open, only to find that nmap produced a misleading result.

Conclusion

This test found that two machines can transfer data between their two platform in a peer-to-peer network.

Secure File Transfer Protocol (SFTP) is not the same experience as a Windows user would expect - all CLI, no drag & drop, copying closed files between machines (i.e. no opening files over the network, which is Samba's objective) - but this test proved that the functionality was possible.

This test did not prove a satisfactory and sustainable method for file synchronisation, nor did it consider the security aspects of the functionality, other than the use of SFTP over SSH (which is secure by design).

Next steps

Having established that SFTP over SSH works, there now needs to be a more efficient way for the user to command the machine to synchronise data between machines.  SFTP works efficiently for the initial mirroring of data from source to destination, but isn't efficient at updating already mirrored data.  For this function, a synchronisation tool is necessary.

Completed June 2018.