Skip to main content

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.


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:
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
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.


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.


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.


Popular posts from this blog

OnlyOffice: keyboard inaccessible, so not useable, therefore not tested

I installed OnlyOffice I had intended to test it with my now-standard test suite of two linked workbooks.

Unfortunately, in spite of a promising look, I quickly discovered that - with one exception - everything was navigable only by mouse.

That makes it a child's toy.  Unfit for purpose!  No point in testing it further.

I uninstalled it within 10 minutes of installing it.

Adjusting screen brightness

The machine on which Linux Mint is installed an old Acer Aspire 5732Z ("Gandalf")

It has buttons to adjust the brightness of the screen's backlight.  When the user uses these buttons, Linux Mint correctly presented a fading-popup box (a slider bar) to denote relative brightness.  But Linux Mint did not actually adjust the brightness of the screen.

It seems to be a known issue in the Linux Mint forums and solved in multiple  stages by the Easy Tips Project.

I followed the instructions on Easy Tips section 5.2 in Gandalf's admin account, then re-booted, then logged in using the user account, and the brightness adjustment function worked correctly.

Easy Tips asks the user to discover the relevant property of the machine, then creates a file that contains a script of parameters that other programs in Linux Mint understand.

This method worked for Gandalf, because Gandalf has an integrated Intel chipset.

Useful commands at the Terminal ALT+T (or the Mint) menu gets to the …

Keepass and KeepassX

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 password manager, Keepass.
Environment & required functionality A number of encrypted password vaults synchronise between three machines:

The Linux Mint Xfce laptop "Gandalf";The Windows 10 laptop "Legolas";Another Windows 10 machine, name withheld to protect the guilty.
The synchronisation agent is Google Drive in Windows 10, and grive2 in Linux Mint.
Alternatives My original decision to use Keepass was in 2016 and was based on:

Keepass is open-source;Keepass is locally stored, not stored in the cloud;Keepass does not automatically plug into the browser (a plugin permits this if ever necessary);higher security standards at the office, worth deploying at home;portability of the password vault via Google Drive, encrypted such that Google would not be able to slurp data from an otherwise-unencrypted vault.overall …