Communicating securely over network connections

Communicating securely over networks, particularly systems exposed to public internet, is an ongoing challenge.   The bad news is, every criminal in the world who has access to the internet is constantly trying to break into your computer, your tablet, your smartphone, and your Raspberry Pi.  The good news is that there are very good, secure tools that are well recognized as "secure".  Some provisos apply:

1. configuration of software used for such communications, to disable features that are considered security weaknesses.
2. understanding that all software is defective in some way, it is a necessity to patch vulnerable software when you are notified, and for open source software, that means signing up for notifications
3. many free security capabilities include multi-factor authentication, including a personal and account-specific code generated on your smartphone, so only the person (presumably you) who is holding the smartphone, can log in to your account.

One of these tools is SSH, or Secure SHell.  There are many free versions:
-- OpenSSH for Linux
-- PuTTy for Windows
-- there are Java based SSH clients
-- there is even a Chrome browser plugin that runs SSH client

A properly configured SSH client and server connection might be called a "gold standard" of communication over public (untrusted) networks.

SSH is a mature technology that has many interested features and capabilities, well beyond a command line interface to a system:

A. SCP and SFTP for file transfer is encrypted using the same mechanisms in SSH
B. rsync can use SSH as the connection between synchronization of files between systems
C. Port forwarding is one of the most powerful and overlooked capabilities,   I'll post a link to a presentation on SSH in an upcoming blog entry.

However, a poorly configured SSH scenario only gives users and administrators an illusion and assumption of security,   For example, if no one actually checks or validates the server key that is presented at an initial connection from an SSH client, the user really has no idea whether they are connecting to a hostile server that is capturing all your communications.   This scenario is typically referred to as MITM, or "man in the middle" attack.