Adventures in SSH and SFTP: Getting Logs When the Host Won’t Help
The Scenario: So we had this situation: we needed to grab some logs from a client's website to see if anything was going ahem "cactus" with the site (that's the technical term, of course). Ideally, you'd just log into a hosting dashboard and click on a "Logs" section, right? Unfortunately, our site was hosted on Pantheon, and Pantheon wasn't about to just hand over the logs through its web UI. (Some hosting platforms do offer that convenience - Plesk, for example, lets you view and even download log files in a few clicks - but Pantheon said, "Nope, go use SFTP.") Thus began our little adventure into the world of SSH and SFTP to fetch those logs manually.
SSH vs SFTP: Same Protocol, Different Purpose
What's the deal with SSH vs SFTP? They sound similar (both start with "Secure", after all), but they serve different purposes. SSH (Secure Shell) provides secure remote command-line access to a server - i.e. you can open a terminal on your machine and control the remote server, running commands as if you were physically there. SFTP (Secure File Transfer Protocol), on the other hand, is built on top of SSH and is specifically designed for secure file access and transfer. In other words, SSH is for doing "funky stuff" on the server via commands, while SFTP is for browsing files on the server and transferring files back and forth (without the ability to execute arbitrary shell commands). Both use the same encrypted channel (port 22 by default) and authentication mechanism, but one is basically a remote control for the server and the other is a secure file manager. For our task (fetching log files), SFTP was the tool for the job - we just needed to grab some files, not run server commands. Pantheon, in fact, doesn't even allow arbitrary shell access on its application containers (no bash for you); it only allows SFTP connections for file access. So, SFTP it was.
Setting Up Access: Passwords vs. SSH Keys
To access a server via SSH or SFTP, you need to authenticate yourself. The classic method (especially for old-school FTP) is using a username and password. However, many modern hosts (Pantheon included) prefer using SSH keys for authentication, as it's more secure (no passwords to leak) and often more convenient for frequent access. In our case, Pantheon required an SSH key to let us in. What's an SSH key? It's a cryptographic key pair - you keep the private key on your computer and give the server your public key. We generated an SSH key pair on our computer (that was the "special thing" we did on your machine). For example, on Mac or Linux you can open Terminal and run a command like:
ssh-keygen -t ed25519 -C "[email protected]"
This would create a new Ed25519 key pair (you'd then follow prompts to save it, optionally with a passphrase). On Windows, you could use PuTTYgen (PuTTY's key generator) to do the equivalent. Either way, you end up with two files: e.g. id_ed25519 (your private key) and id_ed25519.pub (your public key). We then uploaded the public key to Pantheon's dashboard (under our account's SSH Keys section). Pantheon will now trust any connection that proves it has the matching private key. In simpler terms: when we connect, our client offers a signature with the private key, and Pantheon checks it against the public key we added to see if it matches. If it does, Pantheon lets us in . (If not, it slams the door shut.)
Side note: Some servers do allow password-based logins for SFTP as well. In fact, Pantheon's SFTP connection info lets you use your Pantheon account password instead of a key if you really want. But using SSH keys is strongly recommended - it's more secure, and you don't have to remember yet another password. Plus, Pantheon requires SSH keys for certain operations (like git pushes), so we went the key route from the start.
Connecting via SFTP (Our Case Study)
With our key set up and authorised, it was time to actually connect and fetch those logs. Pantheon provides specific connection details in its dashboard ("Connection Info" panel) for each site environment. In our case we got something looking like this: a host (e.g. appserver.dev.<site-id>.drush.in), a username (which Pantheon formats as <env>.<site-id> @appserver.dev.<site-id>.drush.in - basically embedding environment and site ID), and a port (2222 instead of the usual port 22). We plugged these into our SFTP client. Important: we had to ensure the client was set to use SFTP protocol (not regular FTP, and not a pure SSH terminal session). Pantheon doesn't offer a normal shell login on this host - if you try to SSH into it, you won't get a typical terminal. The SSH credentials are only for SFTP file access on Pantheon's servers. Naturally, we did initially stumble here: we attempted to connect via Termius (an SSH/SFTP client) but had it in SSH mode at first. That resulted in an immediate failure - either the username/host wasn't recognised for SSH or Pantheon just said "no shell available" and kicked us out. Realising the goof, we switched the connection in Termius to SFTP mode (and double-checked the host/username were exactly as Pantheon specified for SFTP). Voilà! We were in, greeted with a list of files and directories rather than an error message. Once connected through SFTP, we navigated to the directory containing the logs (in Pantheon's case, there's a logs/ directory). Using Termius's GUI, it was just point-and-click to download what we needed. If we had been using command-line SFTP, it would look something like this:
# Example using command-line SFTP
sftp -o Port=2222 <username>@<host>
sftp> cd logs
sftp> pwd
Remote working directory: /srv/bindings/.../logs
sftp> ls -l
# (list of log files prints out)
sftp> get php-error.log
sftp> get nginx/error.log
sftp> bye
Pantheon's docs even suggest a one-liner to grab all logs at once: after connecting, run get -r logs to download the entire logs folder (recursively) to your local machine. That's exactly what we did - pulled down the whole logs directory. Now we had the server logs on our computer to inspect for any caching issues or other errors. Mission accomplished!
Tools of the Trade: Windows vs. macOS
Now, how did we actually perform the SSH/SFTP connection? There are a bunch of tools you can use, depending on your operating system and preference. Here are some popular options (with a bit of personal commentary): * Windows - PuTTY & WinSCP: If you're on Windows, the OG combo for this kind of work is PuTTY (for SSH) and WinSCP (for SFTP). PuTTY is that classic free SSH client that's been around forever (literally since 1999); it gives you a no-frills terminal window to run commands on remote servers. WinSCP is a free GUI program for file transfer - basically like Windows Explorer for your server, over SFTP. We had both at our disposal. For example, in WinSCP you create a new site entry, input the host name Pantheon gave us, username, select SFTP as the protocol, and set port 2222 (Pantheon's special port). Then either enter your Pantheon password or (as we did) configure WinSCP to use our private key for authentication. Connect, and you'll see the remote directory tree. Drag-and-drop the files you need, and you're done.
Example: Configuring an SFTP connection in WinSCP for a Pantheon site. Notice the protocol is set to SFTP and the port to 2222 (as required by Pantheon).
macOS - Terminal, Cyberduck, & Termius: Mac users actually have SSH capabilities built-in via the Terminal app. You can open Terminal and use the
sshcommand to connect to a server orsftpfor file transfers - no additional software needed. But not everyone loves the command line, and sometimes a GUI makes life easier. Cyberduck is a popular free GUI app (for Mac and Windows) that lets you browse and transfer files via SFTP in a friendly way. It's like the Mac equivalent of WinSCP - just open Cyberduck, punch in the SFTP host, username, password or key, and you get an interface to download/upload files easily. We also like Termius, which is a modern cross-platform SSH client (works on Mac, Windows, Linux, even mobile, I know right, really living in the future). Termius not only gives you a slick interface for managing SSH connections, but it also includes an SFTP feature. You can open an SFTP tab to visually transfer files, right alongside your SSH terminal tabs. In our case, we were using Termius on macOS to initiate the connection. We saved the Pantheon host details in Termius, and when it came time to grab files, we simply switched to the SFTP view in Termius to download the log files. It's like PuTTY and WinSCP rolled into one, with a dash of modern usability.
When Platforms Give You a Break (Direct Access)
All this effort was for a Pantheon-hosted site that required SFTP for log access. It's worth noting that not every situation is this tedious. Some hosting platforms actually give you direct access to files and logs via a web interface or other handy tools:
Traditional Hosting Panels: Many control panels like Plesk or cPanel have built-in file managers and log viewers. If our site was on a Plesk server, for instance, we could have simply logged into Plesk, gone to the domain's Logs section, and viewed or downloaded the log files right there in the browser - no external client needed, no keys, no fuss. (Little wonder Plesk remains a favorite for convenience!)
Cloud Platforms: Services like AWS, Google Cloud, or Azure often provide their own mechanisms to fetch logs or access the server. For example, AWS might have your application logs streaming to CloudWatch, or allow you to open a web-based SSH console to an EC2 instance. Google Cloud and Azure have similar offerings (Google's SSH-in-browser, Azure's Cloud Shell or VM Serial Console, etc.). The idea is that depending on your host, you might be able to get what you need without manually SFTPing into the box. Always check if there's a simpler option provided by your platform.
In our scenario, Pantheon's model meant we had to go the SSH/SFTP route. It was a bit of a throwback to the old days of managing servers, but hey - it worked and we got the data we needed.
Final Thoughts
This little case study was a good reminder that sometimes you have to get your hands dirty with SSH/SFTP, especially when the hosting platform doesn't provide a one-click solution. The key takeaways: SSH is your remote command-line for when you need to run things on a server, SFTP is your go-to for grabbing or uploading files securely. Setting up an SSH key pair makes life easier in the long run (no passwords, fewer headaches), and tools like PuTTY/WinSCP or Terminal/Cyberduck/Termius are there to help depending on what environment you're comfortable in. So next time your site is acting up and the fancy web dashboard isn't showing you what you need, don't panic. With the power of SSH/SFTP, you can still dive under the hood and get the job done - securely, of course. Happy tunneling!