In this blog, I'll approach the explanation as if you were my Zomato Delivery Boy, with minimal prior experience in technology. I'll simplify the concept of SSH and guide you to a point where you:
won't be scared of the tricky "SSH" term because now you have a clear idea in your mind.
will grasp how top-tier developers use SSH to try out code changes, tweak server settings, and do other important tasks.
will see why SSH stands out from the crowd, that keep things safe and secure – making it better than other tools.
Let's get started!
Conceptualizing SSH
What is SSH? Instead of starting with the tech jumbo, let me use an analogy to help you conceptualize it.
After a hectic day at work, I find myself back home in my bedroom, craving excitement. Boredom makes me to put on my VR headset and step into the Metaverse—an immersive realm that transports me from the physical world into a virtual environment.
As I log in, typing my username and password, the digital space recognizes me. My digital avatar materializes before me, a mirror image of myself—tall, with impeccable hair, and sporting a fantastic sense of style. Before my eyes, a digital representation of a forest unfolds.
Despite being in the familiar confines of my bedroom with a VR headset snugly in place, I instinctively move my head to explore the virtual surroundings. Miraculously, my avatar mimics every movement. Testing the waters, I utter a casual "hello, forest" in my bedroom, and to my delight, my avatar echoes the sentiment in the VR world. The line between reality and the virtual realm blurs, creating a seamless and immersive experience.
In real life, this is what the analogy translates to:
I == developer.
My bedroom == your laptop, or whatever local machine you're typing on.
My Metaverse == a remote machine/server you are trying to access from your local machine.
My VR headset == the SSH tunnel that allows you to access the remote machine (Metaverse) from your local machine (bedroom).
Login screen == the SSH key pair that ensures only authorized parties can use the SSH tunnel. I'll explain this more thoroughly in a later section of this blog.
The analogy of "putting on a VR headset to access the Metaverse" when thinking about SSH helps demystify the concept for those unfamiliar with it. Instead of being overwhelmed by the vague idea of SSH, one can relate it to a more concrete and familiar scenario.
In simpler terms, SSH is akin to a secure, secret tunnel that allows you to connect to another computer over the internet. Visualize it as a means to perform actions on that distant computer as if you were physically present in front of it.
This analogy serves as a starting point for a conceptual understanding of SSH, providing a relatable mental image.
Why do I need to use SSH?
SSH plays a pivotal role for developers who often need to connect to remote machines. Consider large applications that demand substantial memory and computing power, making it impractical to run them on a personal laptop.
These applications are typically hosted on cloud platforms such as AWS, Azure, or Google Cloud, necessitating remote access. Additionally, in scenarios where development teams are dispersed across different locations, SSH becomes essential.
Remote servers enable team members to collaborate and share code in a unified space, fostering consistency even when physical presence is not possible.
Certainly, let's explore two instances where an industry-level developer might find it necessary to SSH into a remote machine:
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.
In this context, you would utilize SSH to access the remote server hosting your staging environment.
You might be wondering why a staging environment is situated on a remote server rather than on your local machine. Several reasons contribute to this choice. Firstly, having a staging environment on a remote server allows for the simulation of a realistic setup. This is beneficial for identifying performance bottlenecks and scalability concerns that may only manifest in a server environment, providing a more accurate representation of the application's behaviour.
Another significant reason is the need for consistency within the development team. By centralizing the staging environment on a remote server, all team members can test and validate features in a uniform environment. This ensures that everyone is working with the same configurations and dependencies, avoiding potential issues arising from individual setups.
It's a practical approach to maintain a cohesive testing environment and prevents the complications of each team member managing their own staging setup or, less desirable, relying on a single local machine for testing purposes.
Updating a server configuration - Certainly, let's consider an example of commands you might run to adjust the server configuration for a growing web application, especially in the context of increased traffic:
a. SSH into the server
ssh user@your-server-ipb. Locate Apache configuration files
cd /etc/apache2c. Backup the configuration files
cp apache2.conf apache2.conf.bakd. Edit configuration files.
vi apache2.confe. Verify configuration
apache2ctl configtestPlease 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 is indeed recognizing the types of commands a developer might execute while SSH'ed into a server. These often involve straightforward actions like navigating directories (
cd), copying files (cp), and editing files (vior any other text editor).
Why SSH?
Certainly, let's delve into a brief history lesson and explore the alternatives to SSH, along with the reasons for SSH's dominance.
Before SSH became widely adopted, several other protocols facilitated communication between two machines. Some notable ones include Telnet, RSH (Remote Shell), FTP (File Transfer Protocol), and Rlogin. However, each of these protocols suffered from a critical drawback – the lack of encryption and robust security features.
To illustrate the vulnerability of these older protocols, let's take Telnet as an example. If an attacker gained access to the network through which Telnet traffic was passing, they could use tools like Wireshark to capture the traffic. Since Telnet transmitted data in plaintext, the attacker could easily decipher login attempts and obtain sensitive information. The lack of encryption meant that all data was human-readable, posing a significant security risk.
The advent of SSH addressed these security concerns by introducing strong encryption and authentication mechanisms. SSH (Secure Shell) ensured that data transmitted between two machines was secure, confidential, and resistant to eavesdropping or unauthorized access. As a result, SSH emerged as the preferred protocol for secure remote access and communication.
In summary, SSH's dominance over alternatives stemmed from its focus on security, encryption, and authentication, addressing the inherent vulnerabilities of older protocols like Telnet, RSH, FTP, and Rlogin.
In 1995, the invention of SSH marked a significant advancement in secure communication for two primary reasons:
Encrypting Data: The introduction of encryption was a pivotal improvement. Consider a scenario where sensitive information, like a login string ("username: udurgesh6 password: ?IamC00l!"), is transmitted from your machine to a remote machine. Older protocols like Telnet or FTP would transmit this data in plaintext, making it susceptible to interception by hackers. In contrast, with encryption, the transmitted data is transformed into a secure, unreadable sequence of bytes. While the actual encrypted data adheres to algorithmic standards, the key takeaway is that it provides a robust layer of confidentiality, safeguarding sensitive information during transmission.
Authentication: Unlike older programs such as Telnet, which relied solely on password-based authentication, SSH introduced a more secure approach known as public-key authentication. In Telnet, connecting to a remote system prompts the user to enter a username and password, and these credentials are transmitted in plaintext, exposing them to potential interception. In contrast, public-key authentication in SSH involves a key pair: a public key and a private key. The public key is shared with the server, while the private key remains securely on the user's machine. This asymmetric authentication method enhances security, as even if intercepted, the public key alone is insufficient for unauthorized access. It significantly reduces the risk associated with password-based 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 john@123.456.789.123.
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.
Conclusion
Though it's relatively easy to SSH into another server (maybe your co-workers 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.