PuTTY and SSH Best Practices are almost opposite ends of a very wide dichotomy. If you’re going to get involved in DevOps and cloud, you might start off on a Windows desktop, or laptop or virtual machine and get halfway decent with maybe some Visual Basic scripting, maybe some PowerShell, but probably don't have any experience in the world of Unix and Linux.
Most likely, you’ve heard about what Unix and Linux can do. And there's probably some limitations in what you can do in the Windows world that entices you to want to learn more about Unix and Linux. In order to get access to that Unix/Linux world, you need to be able to authenticate and log in to a Unix/Linux system, much in the same way that one might use Remote Desktop Protocol (RDP), to gain access to a different Windows system.
Table 1: Authentication differences
Where you'll have an RDP client like Terminal Services to gain access to different Windows Servers, you need to an SSH client to gain access to a Unix or Linux server. And the most popular and SSH client for Windows is PuTTY. It's been around forever.
Once you download and run PuTTY on your Windows system, you connect on port 22 to gain access and authenticate to a Unix or Linux system. That system could be a big physical IBM server in a data center, a virtual machine that is running within VMware, or a VMWare ESX cluster itself, or even something that's in the Cloud- an Amazon EC2 instance or a Docker Container or a Kubernetes Control Plane. Regardless of what UNIX/Linux server you’re connecting to, if your source Operating System is Windows, PuTTY is probably going to be your remote access client to gain access to that Unix/Linux system.
When you first login using PuTTY to the Unix/Linux system, you'll probably be asked for a Username and Password which you’ll have been provided by your Identity and Access Management team or some other Administrator. Once logged in, you’ll be using a text-based interface to navigate UNIX/Linux instead of a Graphical User Interface like what you’re used to in Windows.
The text-based interface is a command prompt that is very roughly similar to a PowerShell or Windows command prompt. However, your interactions with that prompt now use an entirely different set of commands and even technical philosophy (See also: https://en.wikipedia.org/wiki/Unix_philosophy).
Table 2: Sample comparison between commands used in Windows vs. Unix/Linux
There's a million other types of commands that go with Unix and Linux as well. But all of these keystrokes, all the input and output is flowing over a Secure Shell, SSH protocol that is established between the Windows PuTTY SSH client and whatever that SSH server is.
SSH Best Practices: Host Keys
When you first connect from the Windows PuTTY (or any) SSH client to an SSH server, you're provided a fingerprint, which is a representation of the server’s Machine Identity. This Machine Identity is the Server’s SSH Host Key—a public/private keypair, similar in some ways to an SSL/TLS Certificate. You’re provided a choice—are you connected to the right Server? Unfortunately, the fingerprint is not human-readable, and so 99% of the time you’ll probably assume it is correct.
Once you say “Yes”, that SSH Host Key—that machine identity—is stored by PuTTY on your Windows system. You'll not be asked about it again unless somehow that key should change. In that instance, you’ll be warned that an active Man-in-the-Middle (MITM) attack could be occurring.
SSH Best Practices: Audit Logs
There's all sorts of different logs that are retained by the SSH Server—every time somebody (or some other machine) attempts to connect to the SSH server. Very often, one machine automatically connects to another machine using SSH. Anytime you have that automation, anytime that you have commands run, anytime you have authentication completed, the SSH server can be configured to keep logs of this activity. There are authentication logs, there are command logs, there are logs that go with file access. You can get down to a very granular detail in the logs that are kept on an SSH server.
In some instances, there are so many SSH logs that they'll fill up the entire file system on that SSH server. So if you're administering an SSH server, you need to be mindful of that. You'll want to do some sort of automation there to make sure that those logs are pruned and not just kept open especially if you have a busy server.
For example, maybe you're trying to set up a Kubernetes service. You use PuTTY to SSH into the Kubernetes Control Plane. YAML (Yet Another Markup Language) files may be downloaded, edited, and executed to deploy things like Container and Application Services. Given that this Control Plane has the capability to make or break your business, it should be carefully audited and access should be restricted.
SSH Best Practices: User Keys and Non-Interactive Access
Instead of using a Username/Password, an alternate authentication method to a UNIX/Linux server is using an SSH User Key. While in some ways similar to a password, SSH User Keys enable automated access to an SSH Server. These keys are often used by CI/CD pipelines and with concepts like Infrastructure as Code.
If you have interactive access to a Unix or Linux shell, then there's a high probability that that operating system instance of Linux or Unix can be compromised. Somebody might run the wrong command and exhaust the CPU, Memory, or Disk resources on that system.
If you’re interested in using PuTTY, let me welcome you to the world of UNIX and Linux! There’s lots to learn and there is an amazing community of people available to help you every step of the way. If you’re an experienced software developer, I hope you’ve found this basic introduction to SSH Keys to be helpful as you iterate through your next sprint!