Drop #193 (2023-02-06): Serendipitous SSH
sftp > scp; ssh-keyscan; ssheasy
Web browsers (speaking of which, my 5 Arc browser invites were replenished) get all the 💙 . They provide a window to the world [wide web], and have been the powerhouse behind our ability to waste countless, precious hours on social media or binge-watching inane shows. Yes, they are also, increasingly, the primary interface tool to get interactive work done.
As a reader of these Drops, chances are you also get work done at the CLI, and not just on your local system. Modern, secure remote access generally means using the venerable secure shell (SSH) to perform remote interactive login, command execution, and file transfer operations. Your remote git-ops are also almost certainly powered by SSH.
Most of us rarely give a thought to the use of the various SSH CLI tools after an initial SSH configuration / key-generation. Odds are, most users also rarely keep up with OpenSSH releases. Today's Drop makes a case for using the
sftp CLI utility (vs
scp), surfaces a neat SSH utility you may not know exists, and introduces an SSH WebAssembly component that could be beneficial when the CLI is not available. It should also be a good reminder to keep an eye on changelogs of foundational and ubiquitous technologies.
sftp > scp
Late last year, Andrew Lefevre made a case for using sftp (vs scp) for all your remote file operation needs. This is Andrew's core argument against scp:
scp is widely known and used to copy files over the Secure Shell (SSH) protocol. It's a tad bit confusing that it shares a name with the protocol it implements, the Secure Copy Protocol (SCP). scp was designed to be a more secure version of the BSD Remote Copy Protocol (RCP), which supported file copying to and from remote machines. The problem with RCP is the protocol is unencrypted. RCP was designed in 1983 when network protocols generally didn't use any cryptography. A malicious adversary could take advantage of this and either read or modify sensitive file contents as they are being transferred. scp solves this problem by operating on top of SSH. SSH provides authenticity, confidentiality, and integrity, which scp takes advantage of.
The article is long-ish, but very readable and errs on the side of being comprehensive. The (mostly) complete argument can be boiled down to the following, shorter summary for each category of benefits:
encryption: both sftp and scp use encryption to secure file transfers, however sftp provides a more comprehensive and secure encryption method compared to scp which only encrypts data in transit and not the authentication information.
authentication: sftp supports multiple authentication methods including password authentication, public key authentication and keyboard-interactive authentication. scp only supports password authentication, which is less secure.
functionality: sftp provides a full-fledged file transfer solution, allowing for file uploads, downloads, deletions, and permissions changes. scp only supports basic file transfers.
user interactivity: sftp is interactive, allowing for the exchange of messages between the client and server, making it easier to diagnose and fix problems. scp is a non-interactive protocol, which can make it more difficult to troubleshoot issues.
portability: sftp is a more widely supported protocol and is available on most modern platforms, whereas scp is often not as widely supported, making it less portable.
Now, the SFTP protocol started powering scp since OpenSSH 8.7 (2021-08-20).
Well, that's not entirely true, since they yanked that feature shortly after; but, it was reinstated as the default in OpenSSH 9.0 (2022-04-08).
On my Ventura Macs, the base SSH version (
ssh -V) is OpenSSH 9.0, but on a recently installed Ubuntu 22.04.01 setup, the installed version was OpenSSH 8.9. Older installs should be able to use the
-s option to force the use of the SFTP protocol (which you can verify by using the
-v flag when
scping to a remote machine).
It's great when defaults are changed to help ensure you're working as securely as possible, but double check what OpenSSH version is running before assuming you're in tip-top SSHape, and consider adding the
-s flag as a "just in case" measure when remote copying files on disparate systems.
Remote git-ops are possibly the most used SSH-protocol use case on the modern internet. When you work with a remote repository, such as one of the major social coding sites, you have likely come across a message like this at least once:
The authenticity of host '22.214.171.124 (126.96.36.199)' can't be established.
Said message also includes the fingerprint of the remote host key, and the operation itself prompts you to trust the remote host by adding it to the
~/.ssh/known_hosts file. The entries in that file look like this:
github.com,188.8.131.52 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
Being prompted during the middle of an operation is, at best, annoying. At worst, it could break automation.
For infrastructure you control — or in the context of an SSH cluster, backed by a load balancer — using duplicate host keys is an option. Outside the cluster scenario, it's not a great option.
It'd be great if there was a way to keep
known_hosts updated to help prevent interstitial interruptions. That was such a good idea and popular use case that OpenSSH birthed
ssh-keyscan, a utility for gathering the public SSH host keys of a number of hosts.
Simply do something like:
$ ssh-keyscan github.com
to retrieve keys from the remote system.
Before OpenSSH 9.2 (released on 2023-02-02), you had to specify multiple hosts/IPs with the command or in a file. As of this new release, you can also use CIDR notation, which is handy for corporate networks, home networks, and especially WireGuard virtual networks.
Now, you can :
$ ssh-keyscan 192.168.0.0/24
to probe all the hosts on that subnet and get a copy of their keys.
Another nice feature of
ssh-keyscan is the
-H flag, which will hash all hostnames and addresses in the output. These names/addresses aren't so seekrit when it comes to general use public services (like GitHub), so keeping them in cleartext in
known_hosts is fine. In a private network setting, hashing this information provides one more hurdle for attackers who may use these files to perform further reconnaissance.
The utility has a bunch more options that are most aSSHuridly worth investigating, especially if you're into automation or auditing.
This last section is short and SSHweet.
ssheasy [GH] is a Golang / WASM SSH library and client. With it, you use your browser as an SSH gateway, which can be helpful when you can't get down a terminal interface for some reason.
After cloning the repo, just do a
docker-compose up command which will compile the WASM ssh, sftp client, the proxy component that proxies tcp connections for the client running in the browser through websocket and sets up nginx server serving the web frontend. Additionally, prometheus and grafana is set up as well to monitor the connections proxied, plus an sshd instance is also started in a container for testing.
It feels a bit rough around the edges, but it’s 100% a project to keep an eye on.
Hope everyone's week will consist of temperatures all above 0°F! ☮