João Freitas

After the success of “Explaining Kubernetes to my Uber driver”, the author is back to story tell how she would explain how SSH works to his Uber driver.

https://dev.to/therubberduckiee/explaining-ssh-to-my-uber-driver-38a

In this blog, I’d like to explain SSH to you as if you were my Uber driver. The point of this exercise is to pretend like you have no prior experience with SSH or even much knowledge of technology in general, and get you to a point where you:

  1. Aren’t afraid by the vague term “SSH” because you have a concrete image in your head.
  2. Understand how industry-level developers use SSH to test code changes, make server configurations, and more.
  3. Understand how SSH’s encryption/authorization protocols make it better than other tools.

Let’s get started!

Conceptualizing SSH

What is SSH? Instead of starting with the conventional tech jumbo you’d see at the top of a Cloudflare article or Wikipedia, let me use an analogy to help you conceptualize it.

Imagine you’ve just gotten off school and you’re back home in your bedroom. You’re bored, and decide to put on your VR headset to access the Metaverse - an immersive experience that blocks out the physical world and embeds you in a virtual environment. You log in, punching in your username and password to verify that it’s you. Once that’s done, you see your ditigal avatar pop up. It looks like a spitting image of you - tall, great hair, and a fantastic sense of style. In front of you, you see a forest - or rather, a digital representation of a forest. Still standing in your bedroom with your VR headset on, you physically move your head to look around, and your avatar does the same. You say “hello forest” in your bedroom, and your avatar also says “hello forest” in the VR world.

In real life, this is what the analogy translates to:

How does this analogy help you? Next time you hear somebody say “I SSH-ed into the server”, you don’t need to freak out about this vague concept of “SSH”. Instead, reword it in your head to mean “I put on a VR headset to access the Metaverse”, and this will ground it something more concrete.

In layman’s terms, SSH is like a secure, secret tunnel that lets you connect to another computer over the internet. It helps you do things on that computer as if you were sitting right in front of it.

Of course, this is just a surface-level, conceptual understanding of SSH. I’m hoping right now, you’re thinking of some questions to help you dig more into SSH. I can’t read your mind, but here some questions I had, answered for myself, and I think would be useful to explain to you.

Why do I need to use SSH?

SSH is important because developers commonly need to access remote machines. For example, large applications that would consume too much memory and computing power on your own measly laptop is hosted on cloud platforms like AWS, Azure, or Google Cloud, which all need to be accessed remotely. Other times, development teams are distributed across different locations, so remote servers allows team members to collaborate and share code in one consistent place even if they aren’t physically in the same location.

Let me walk you through 2 examples of when an industry-level developer would need to SSH into a remote machine.

1: Deploying Code

As a developer, you need to deploy a new version of your website to your staging server. This is how it might work, using SSH.

On your local machine, you push your latest code changes up using Git.

Then you would SSH into the remote server that has your staging environment.

(By the way, you might be thinking why I need to have my staging environment in a remote server and not on my local machine. Here are some reasons. One is that it’s better to simulate a realistic setup, like checking for performance bottlenecks or scalability concerns that would only happen in a server environment and not your laptop. another is simply ensuring that all team members can test in a consistent environment, instead of them all having a staging environment on their own machines or (god forbid), using your local machine whenever they needed to test something.)

Finally, you’ve SSH’ed in the remote server that hosts the staging environment, you can pull your latest code changes from that remote server, run the build, and test your application (by navigating to http://staging.example.com, for example).

2: Updating a server configuration

Let’s say the web application you’re building has grown, and you need to adjust the server configuration to accomodate increased traffic. Here is an example of some commands you might run:

a. SSH into the server

ssh user@your-server-ip

b. Locate Apache configuration files

cd /etc/apache2

c. Backup the configuration files

cp apache2.conf apache2.conf.bak

d. Edit configuration files.

vi apache2.conf

e. Verify configuration

apache2ctl configtest

Please don’t feel like you need to know what these commands do.

In all honesty, I asked ChatGPT to generate an example for me, and don’t quite understand it myself. The takeaway here is understanding the types of commands a developer might run while SSH’ed into a server. A lot of it is simple commands to move directories (cd), manipulate files (cp), and edit files (vi).

Why SSH?

One question I had while learning about SSH were “what are the alternatives to SSH, and why did SSH win out”?

I guess now is a good time for a quick history lesson.

Before SSH was widely adopted, there were other procotols for communication between two machines. Some notable ones include Telnet, RSH, FTP, and Rlogin. But each of them suffered from lack of encryption and security features.

To paint a picture, here’s how it might happen. I (the malicious hacker) gain access to the network where Telnet is passing through - the network through which you’re trying to send information from your laptop to another machine through Telnet protocols. I use a tool like Wireshark to capture the traffic. Once I get the traffic on my machine in the form of downloaded “packets”, I can just click through them and look for any login attempts. All the data is in plaintext (which means it’s human-readable and not some garbled symbols), so if I find it, I can literally use the login information I see in front of me. As you can see, these older tools were not very secure!

In 1995, SSH was invented. It was better for 2 main reasons.

  1. Encrypting data
    Let’s say that part of the data being transmitted from my machine to a remote machine is the string “username: jesswang password: ?IamC00l!”. Without encryption (so with older protocols like Telnet or FTP), a hacker would be able to read that string as you just read it. With encryption, the data they get back might look like “H23kLs*^!d8%PwZx0KsL!9B#N%u@i8”. In reality, the encrypted data would be a different sequence of bytes that adheres to encrypted algorithmic standards (that I don’t know much about), but this is just to give you an idea.

  2. Authentication
    Older programs like Telnet relied solely on password-based authentication. When you connect to a remote system using Telnet, the Telnet server prompts you to enter a username and password to login. However, Telnet transmits your passwords in plaintext, making it easy for hackers to read. SSH primarily uses a different (and better) approach called public-key authentication. I’ll explain how it works below so you can understand how your information is better protected from hackers.

First, your information is put in a briefcase, and you put your own lock on it.

You send the briefcase to your remote server. The remote server doesn’t have the key to unlock your lock, so instead the remote server puts its own lock on the briefcase.

The remote server sends the briefcase back to you, and you unlock your lock.

You send the briefcase back to the remote server, and it unlocks its lock with its key. Then it opens the briefcase, and reads the note.

And that’s the gist of public-key authentication! By the way, SSH also still does support password-based authentication, but even then the password is encrypted so if a hacker were to intercept it, they would not be able to read it.

How do I use SSH?

Enough of the conceptual learning. Here’s the actual commands I would run to SSH into a server.

To SSH into a server, you would typically run something like: ssh username@server_ip_or_hostname

You’d replace username with your actual username on the server
You’d replace server_ip_or_hostname with the IP address or hostname of the server. So for example, ssh [[email protected]](/cdn-cgi/l/email-protection).

After running the command, you may be prompted for a password for the username of the server. Or if your server uses the key-based authentication we covered in the previous section, you might not be prompted for a password.

Once you’re in, you can start executing commands. These commands will be executed on the remote server you’re connected to.

I understand it’s hard to fully learn if you’re not physically typing things yourself and seeing what happens. If you already have a remote server for work or personal that you have set up, feel free to give it a try. If you don’t have a remote serve to connect to, that’s fine. You can follow these steps:

  1. Go to http://sdf.org/
  2. Create an account. You’ll probably receive an email to giving you a generated password for your account. You may have to wait 1-2 for that email (at least that was my experience).
  3. You can SSH into the public UNIX system by running ssh <your_username>@sdf.org. So for example, I made my username poop123. So I ran ssh [[email protected]](/cdn-cgi/l/email-protection).
  4. When prompted, enter the password you got earlier.
  5. You’ve successfully SSH-ed into a server! You can run commands like echo 'hello world' to print out “hello world” or ls to see a list of files in your current directory.

Note To Readers / Conclusion

Though it’s relatively easy to SSH into another server (maybe your coworkers give you a command you just paste into your command line), I find it difficult to use the command if I don’t understand, at least on a high-level, what is happening when I run it. Hopefully, others can relate with me and this blog will help scratch that itch.

If you’re curious how I came up with the title, the story is in the intro paragraphs of the original blog of this series, “Explaining Kubernetes to my Uber Driver”.

As always, I would love any feedback on the information, drawings, or storytelling in this blog. And let me know what other topics you’d like for me to write about.

Here are some resources I referenced when writing this blog:

#reads #jessica wang #ssh #uber #story telling