The Raspberry Pi Model B was introduced in 2012 as the first sellable unit, and the company has since released many more models. There are even low-cost models like the Raspberry Pi Zero Series, which is quite small and tailored to embedded systems applications. All the models operate on an operating system called the Raspberry Pi OS, a Linux flavor niched for Raspberry PI Computers.

In this tutorial, we’ll be using the Raspberry Pi 4 Model for a headless setup through a SSH connection using Visual Studio Code (VS Code). The Raspberry Pi 4 Model has a Quad-core ARM Cortex-A72 (64-bit) SoC at 1.5GHz, up to 8GB RAM options, video inputs, Ethernet shield, USB ports, MicroSD card slot for storage, USB-C power input and 40 General Purpose Inputs and Outputs Pins (GPIO). Impressive, right?

You’ll be able to use the Raspberry Pi as a personal computer, for home automation and IoT projects, robotics projects, network applications, educational tools, and Artificial Intelligence projects.

Table of Contents

• Understanding the Headless Setup

• Prerequisites

• Preparing the MicroSD Card

• How to Boot the Raspberry Pi

• Understanding the LED of the Raspberry Pi During Setup

• How to Establish an SSH Connection

• How to Set Up Visual Studio Code for Remote Development

• How to Write and Run the Code Remotely

• Conclusion

Understanding the Headless Setup

Many Raspberry Pi computers are sold with additional peripherals, including a keyboard, mouse, and monitor, that are essential for the Raspberry Pi's setup. A headless setup is the process of configuring the Raspberry Pi or preparing it for use without needing these peripherals. This entails operating the Raspberry Pi through a network protocol like SSH (Secure Shell) or VNC (Virtual Network Computing).

This is really helpful when you don’t need peripherals, as it lets you use your personal computer to connect to the Raspberry Pi without needing to purchase specialized peripherals. It’s also excellent for remote access. This headless setup is also essential for remote monitoring systems, such as surveillance systems with remote camera access, and IoT systems.

Remote development lets you write code and modify your Raspberry Pi and other devices connected to the GPIO pins through a headless configuration via SSH.

SSH guarantees a secure connection for transferring and modifying files, as well as transferring and debugging commands from one computer (your personal computer) to another computer (the Raspberry Pi). It restricts unauthorized access from any other system that aims to intercept the communication channel.

Prerequisites

Here’s what you’ll need to follow along with this tutorial:

Hardware Requirements

1. Raspberry Pi 4 or 5

2. MicroSD Card (8GB or higher recommended)

3. Flash Drive with SD Card Slot or a MicroSD Card Adapter

4. Power Supply (5V 2A/3A)

5. Network Connection (Wi-Fi, Pi, and laptop must be on the same network)

6. Personal Computer (Windows, macOS, Linux)

Software Requirements

1. Raspberry Pi Operating System (Raspberry Pi OS)

2. Visual Studio Code

3. Remote SSH Extension in VS Code

Preparing the MicroSD Card

The Raspberry Pi requires a MicroSD Card that serves as the storage of your the Raspberry Pi OS using Raspberry Pi Imager. The operating system of the Raspberry Pi provides a graphical interface to interact with the Raspberry Pi, store files and datasets, and write commands to get your Raspberry Pi working.

But the Raspberry Pi needs an empty MicroSD Card to install the Raspberry Pi OS in the MicroSD Card. Here are some step by step instructions that’ll show you how to get your MicroSD Card setup before inserting it back into the Raspberry Pi for SSH Connection.

Downloading and flashing Raspberry Pi OS

Insert your MicroSD Card into a flash drive with a SD Card slot

Aside from using a flash drive with an SD Card slot (so as to get the memory card connected to the computer), you can also use a SD Card adapter. Make sure it’s inserted into your computer where you have the Raspberry PI Imager downloaded to flash – that is, transfer the OS into the SD Card.

Download the Raspberry Pi Imager based on your PC’s operating system

This involves clicking the link and selecting your operating system (either MacOS, Windows or Linux operating system). The Raspberry Pi OS comes in these variants for different OSes

Next, install and open the Raspberry Pi imager

Click the Raspberry Pi Imager download, follow all the instructions during the installation process. Once this screen pops up, you’re good to go!

Choose your Raspberry Pi Device and operating system and select Storage

For each of the three configurations, you must select one sequentially. Select a device according to the type of Raspberry Pi you have, and various options will appear. I selected the Raspberry Pi 4, as it is my preferred device. You may choose between the Raspberry Pi 5 and the Raspberry Pi Zero 2 W, depending on your device requirements.

Next, proceed to the operating system – I would recommend choosing the 64-bit version. While many people opt for the legacy version (32-bit), I think the 64-bit version is best. Once you're finished, you can choose a storage option, and your MicroSD should appear. My storage is around 128GB, which is why you can see 125.1GB displayed there in the screenshot below:

Click on “Next” and edit the settings

It is a customary practice to keep your username as "pi", but it’s not required. The goal is to have something simple and easy to remember when setting up your SSH connection. It’s also helpful to make your password simple. I used 'roboticsai'.

Try to avoid using numbers simply to make things easier, because you may not be able to see what you are entering in the terminal. Then, make sure that your wireless LAN and SSID (WIFI or Hotspot name if you're using a phone, as well as the password for your WIFI or Hotspot) is the same network as the one linked to your computer.

Click on “SERVICES” and enable SSH. Then use password authentication for security and Click on “SAVE”.

After you've completed the changes in the General Section, go to the Services section and click the checkbox button “Enable SSH”. Once highlighted, make sure you pick “Use password authentication”, avoid the “RUN SSH-KEYGEN” button at the moment, and then click Save.

Click “YES” to apply the customizations, and the Raspberry Pi OS should get flashed into your SD Card.

Following the previous stage, you will be shown various buttons to apply the adjustments you have made. Pick yes, and the Raspberry Pi OS will be flashed or transferred to your Memory Card. This could take between 10 and 20 minutes to go from transferring to writing or customizing. Hold on and enjoy the process.

After a successful installation into the disk, remove your SD Card.

You will receive a successful popup like the one shown below. This demonstrates that all processes were completed successfully, and the Raspberry Pi OS is now installed.

How to Boot the Raspberry Pi

Eject the MicroSD safely from your computer

Once the installation is successful, eject the MicroSD safely from the computer.

Insert it “upside down” into the MicroSD card slot of your Raspberry Pi

To properly insert the MicroSD card, place it gently into the slot with the back or gold side facing upward. It will protrude slightly once it is inserted. You are good to go!

Connect the USB-C port of your Raspberry Pi to your computer. Give the Raspberry Pi some time to load

Get a USB-C cable and connect one end to your Raspberry Pi's USB-C port and the other to a laptop port. It should light up red, indicating that there is an adequate power source. You may also power your Raspberry Pi directly by plugging into a wall socket.

After a while, the memory card should begin to boot into the Raspberry Pi, and the green LED will blink for a while. In the next section, we’ll talk about the different states of the two LEDs during and after a successful boot.

Understanding the LED Status of the Raspberry Pi During Setup

The below table describes the LED statuses you might see when you power on your Raspberry Pi and the SD Card is in the slot.

How to Establish an SSH Connection

The SSH (Secure Shell) connection is a network protocol that allows two computers to safely communicate without leaking any information. It’s also used for remote command line execution and for file transfers between two computers.

To establish an SSH connection, you’ll have to complete a few steps. Then I’ll explain how to enable SSH using a Visual Studio Code extension

Create a wpa_supplicant.conf.txt in the same folder of your Raspberry Pi SD Card

Insert your MicroSD card back into the computer. Then the files that comprise the Raspberry Pi OS will appear on your computer. Create a new text (.txt) document on your computer, similar to the image below, under the SD Card storage section.

Add the code below, making sure that "ssid" is the name of your Wi-Fi network and "psk" is your network's password.

country=NG # Your 2-digit country code
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
network={
    ssid="Josiah"
    psk="roboticsai"
    key_mgmt=WPA-PSK
}

Save the file on the same SD Card

Once you've finished producing the text file, save it to the SD Card storage, as shown in the image below.

Create a .ssh folder

In your personal computer, create a .ssh folder if it doesn’t exist on your personal computer.

If it exists, the .ssh folder should contain files like id_rsa, known_hosts, and config files. It shouldn’t be empty.

After a successful boot, open your terminal or command line application on your personal computer.

Make sure that the Raspberry Pi is connected to the same network before moving ahead. Once your wifi or mobile hotspot is switched on, make sure it’s the same password as the wpa_supplicant.conf.txt and the settings page while installing the Raspberry Pi.

As long as the SD card is in the Raspberry Pi and there is adequate power supply for at least 2-5 minutes, the Raspberry Pi will get connected to the wifi or your mobile hotspot.

How to Resolve Connection Problems

If there is no connection, reinstall the Raspberry Pi OS Imager on the SD Card again. Then you can also change the network AP Band from 5GHz to 2.5GHz or vice-versa. This can be very tricky.

It should get connected after trying this. Just make sure that the passwords are consistent and that you don’t accidentally have the caps lock key switched on while typing, for example.

To confirm if the Raspberry Pi is connected using the command line interface, use the ping command – it shows the devices connected to the device.

ping raspberrypi.local

After running the above command, you should see an image showing the connection once it’s successful like this:

For establishing an SSH connection using the terminal, run the code below:

ssh pi@raspberrypi.local

This will result in a request for a password. If it shows an error like the image below, it means you have to delete the known_hosts.old and known_hosts if either or both exist in the .ssh folder in your PC. This is because the keys are conflicting with each other. Then re-run the above code ssh pi@raspberrypi.local in your terminal.

After successful entry, type “yes” in the terminal.

Connection Closed should show when the connection is successful.

How to Set Up Visual Studio Code for Remote Development

Download and install Visual Studio Code if you don’t have it already.

Then, click on the VS Code extension and search for Remote - SSH by Microsoft and install it to your machine.

Next, click on the “Remote Explorer” icon that looks like a monitor. Select the SSH config in your C:\Users\{name}\.ssh\config folder.

Make sure the config has this command:

Host raspberrypi.local
    HostName raspberrypi.local
    User pi

Enter your username as raspberrypi.local and input your password – the same as the password during loading Raspbian OS.

After inputting the correct password, it should start downloading the server.

Congratulations! The image below has a blue rectangle button showing SSH:raspberrypi.local which shows a successful SSH Connection through Visual Studio Code. This also means you can start remote development as we discussed earlier in this tutorial.

How to Write and Run the Code Remotely

Create a new file on your VS Code. This way, you’re creating files and writing to them directly. Go to the terminal and type the commands to create a folder and a file:

Create a new file and write in your code

Create a new file and name it led.py on your Visual Studio Code. It should be in the same folder as test-raspberry on the Raspberry Pi remote network through the SSH connection on VSCode.

Once you have your file created, you can write in your code such as blinking LED to a Raspberry Pi, as you can see in the code below:

from gpiozero import LED
from time import sleep

# Set the GPIO pin where the LED is connected
led = LED(17)  # Replace 17 with your GPIO pin number

# Blink the LED in a loop
while True:
    led.on()        # Turn LED on
    sleep(1)        # Wait for 1 second
    led.off()       # Turn LED off
    sleep(1)        # Wait for 1 second

After writing this code in the new file you’ve created, run the code by typing the command below in your terminal:

python led.py

As soon as this command is sent, the LED positive terminal is connected to the GPIO 17 according to the code and the negative terminal is connected to the GND GPIO pin of the Raspberry Pi. The image from Random Nerd Tutorials below shows the GPIO pins and their number to understand the connection. Just note that the connection of the LED is beyond the scope of this tutorial.

The LED should start blinking each second according to the code. With this, you can now control your Raspberry Pi (a tiny computer) with another computer (your personal computer) through an SSH connection on Visual Studio Code.

Conclusion

In this tutorial, you went through the whole process of setting up a headless Raspberry Pi for remote development using VS Code.

This offers a wide range of benefits: there’s no need for external peripherals, it provides remote access from anywhere within your network, and it leverages efficient coding and debugging with VS Code integration.

You can use this to deploy web servers and IoT dashboards, and you can explore with automating processes using Python scripts and GPIO control.

If you need a basic introduction to cloud computing, here’s a beginner-friendly tutorial for you: What is Cloud Computing? A Guide for Beginners.

In this guide, I’ll show you how to create an AWS EC2 instance. This is one of AWS’s top services for building applications. By the end of this guide, you'll know how to launch an AWS EC2 instance and connect it to VS Code.

Table of Contents

• Prerequisites

• What is an AWS EC2 Instance?

• Why Connect Your AWS EC2 Instance to VS Code?

• How to Launch and Connect Your AWS EC2 Instance to VS Code

  • Step 1: Create an AWS EC2 Instance

  • Step 2: Connect the AWS EC2 Instance to Your Code Editor

  • Step 3: Install the Programming Language

  • Step 4: Open a Remote Window

  • Step 5: Access Your Project Folder

• Conclusion

Prerequisites

Before you start, make sure you have:

• An AWS account. If you do not have one, sign up here.

• A GitHub repository with your source code. If you don’t have a GitHub account, sign up here.

• Basic knowledge of web development and version control.

• A code editor. For this tutorial, I’m using VS Code.

Let’s jump right in!

What is an AWS EC2 Instance?

AWS EC2 (Elastic Compute Cloud) allows you to run virtual machines in the cloud. These computers allow you to run your applications without needing physical hardware.

There are a number of things you can you do with AWS EC2, such as hosting websites or apps, running big data or machine-learning tasks, creating testing environments, and handling tasks that need flexible, scalable computing power.

Why Connect Your AWS EC2 Instance to VS Code?

Connecting your AWS EC2 instance to VS Code is helpful for several reasons. Before we start the setup process, it’s important to learn why it’s beneficial.

1. Using VS Code provides a familiar and efficient development space. It feels like coding on your own machine.

2. You don’t have to log into your AWS EC2 instance each time. You can edit files, run commands, and debug code from a distance.

3. You can streamline your workflow with built-in terminal access and extensions. This way, you won't have to switch between SSH clients all the time.

4. You can push changes to GitHub. This makes working together and deploying much smoother.

5. VS Code works well with Java, Node.js, and Python. It supports many languages and frameworks, so it's great for cloud development.

Now that you understand the benefits, let’s move on to setting up the connection.

How to Launch and Connect Your AWS EC2 Instance to VS Code

To launch an EC2 instance on AWS, just follow these steps:

Step 1: Create an AWS EC2 Instance

First, log into your AWS account. Then, use the search bar to find EC2 and select it.

Click EC2 and follow the on-screen instructions to create a new instance.

1. Choose an AMI (Amazon Machine Image): This is a pre-configured template that includes an operating system and may come with additional software.

2. Select an instance type: Pick the right size for your needs. For example, t2.micro is a good option for beginners and small workloads.

3. Configure Your EC2 Instance: Set up networking, storage, security groups, and other options based on your requirements.

4. Launch Your Instance: Start your virtual server and access it remotely to begin using it.

Launched instance running:

So what’s happening in Step 1?

By launching an AWS EC2 instance, you are setting up a remote server in the cloud. AWS offers different AMIs that serve as pre-configured environments.

Step 2: Connect the AWS EC2 Instance to Your Code Editor

To connect your EC2 instance created in AWS to your VS Code, you need SSH.

What is SSH?

SSH (Secure Shell) is a secure way to connect and communicate with other devices. It keeps your connection safe. This is important when you access servers or repositories. In Git, you can use SSH instead of HTTPS to clone repositories with a secure connection.

Why is SSH important here?

With SSH, you can link your local code editor (like VS Code) to your AWS EC2 instance. This allows you to work on files stored on the EC2 instance directly from your editor as if on your local computer.

To connect your AWS EC2 instance to your local editor using SSH, follow these steps:

• Open your terminal.

• Go to the folder where your .pem key file is. The key file (.pem) downloads automatically when you create your EC2 instance (usually in the Downloads folder).

• Update the file permissions to keep your key secure and ensure proper authentication.

For Linux users, use this command to update the file permissions:

chmod 400 codebuild-keypair.pem

For Windows users, first you’ll need to find the username of your laptop, as you’ll need it to update the file permissions.

To do this, open your terminal and type:

whoami

This will display your current username.

Once you have your username, use the following command to update the file permissions:

icacls "codebuild-keypair.pem" /reset
icacls "codbuild-keypair.pem" /grant:r "%USERNAME%:R"
icacls "codebuld-keypair.pem" /inheritance:r

Here's what I mean: My username is ijeon, so you should replace it with your laptop's username and own key, which ends with .pem extension.

Running this command above updates the file permissions. So with this, you can work with your remote server.

Now that you have set the correct file permissions, you can use the SSH command along with the IPv4 address to connect to our EC2 instance. Type the following command:

ssh -i [PATH TO YOUR .PEM FILE] ec2-user@[YOUR PUBLIC IPV4 DNS]

Example:

ssh -i "C:\Users\ijeon\OneDrive\Desktop\devops-series-nextwork\codebuild-keypair.pem" ec2-user@ec2-35-178-142-201.eu-west-2.compute.amazonaws.

Breaking it down:

1. ssh: This starts a secure remote connection.

2. -i "C:\Users\ijeon\...\codebuild-keypair.pem": This tells SSH to use the .pem key file for secure access.

3. ec2-user@ec2-35-178-142-201.eu-west-2.compute.amazonaws.com:

   • ec2-user is the default username for EC2 instances.

   • @ec2-35-178-142-201... is the public address of your EC2 instance.

This command logs you into your EC2 instance remotely from your computer. It then uses the key (.pem file) instead of a password for security. It also lets you control the EC2 instance from your terminal as if you were using it directly.

If everything is set up correctly, a “success message” will appear. This confirms that you've logged in and can access the remote server.

Step 3: Install the Programming Language

Now that you’ve linked your instance to the editor, you can install the packages needed to build your web app. You can use any programming language you're comfortable with, but we’ll use Java for this tutorial. This will be a simple web application – we don’t need to go into advanced details.

1. Install Java

In your terminal, run the following commands to install Java:

sudo dnf install -y java-1.8.0-amazon-corretto-devel

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64

export PATH=/usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64/jre/bin/:$PATH

This installs Java on your system. You also need Maven. It helps manage Java projects and create templates for web applications.

2. Install Maven

Maven helps you organize Java projects. It also lets you create templates for web applications. Run these commands to install Maven:

wget https://archive.apache.org/dist/maven/maven-3/3.5.2/binaries/apache-maven-3.5.2-bin.tar.gz

sudo tar -xzf apache-maven-3.5.2-bin.tar.gz -C /opt

echo "export PATH=/opt/apache-maven-3.5.2/bin:$PATH" >> ~/.bashrc

source ~/.bashrc

To confirm Maven's correct installation, run this command:

mvn -v

Also, run the following command to check whether you have Java installed:

java -version

Now that you have installed Maven, you can use it to create a Java web app with the following command:

mvn archetype:generate \
  -DgroupId=com.nextwork.app \
  -DartifactId=nextwork-web-project \
  -Dpackage=com.nextwork.app \
  -DarchetypeArtifactId=maven-archetype-webapp \
  -DarchetypeVersion=1.4 \
  -DinteractiveMode=false

Running the command above generates a template for your application. In the terminal, it should show a "Build Success" message. This means the setup worked.

Step 4: Open a Remote Window

Now that you’ve installed the necessary packages and set up your app template, you need to open your IDE or code editor. This will let you access the folders on your remote server.

In your terminal, click the double arrow icon at the bottom left.

When you click on it, it opens a modal window for you.

A window will appear. Click "Connect to Host," which will open another window.

Then choose "Add New SSH Host" to open the SSH connection terminal.

Input your SSH command to configure the host.

After pressing "Enter," a configuration file will open. In this file, ensure that the .pem file and the IP4v DNS addresses from your EC2 instance are correct.

Here’s a GIF view of the image above:

Here’s the configuration file:

Go back to your editor and click on that double arrow again. This will automatically open a new window.

If your editor displays the IPv4 DNS address, your VS Code is successfully connected to the EC2 instance.

Now that you’re connected and a new window has opened, let’s access the folder stored in the cloud.

Step 5: Access Your Project Folder

In step 3, remember when you installed Maven? It created a template for your web app. Now, you’ll access the folder where you created this.

1. Go to the Explorer panel in the window.

2. Click the “Open Folder” button.

Clicking on this button opens a modal box for you to select your folder, which was created by the Maven template:

To access the template file, click the “src” folder. This takes you to the index.jsp file.

With this template created, you can decide to tweak it and send it to your Git repository for storage.

Conclusion

Great job! You’ve set up an AWS EC2 instance, linked it to your code editor, and installed the tools needed for your web app. In this tutorial, we used Java, but you can also choose other languages like Node.js or Python.

If you found this article helpful, please share it with others who may find it interesting.

Stay updated with my projects by following me on Twitter, LinkedIn and GitHub.

Thank you for reading.

Authentication means that the remote server can verify that it’s actually you and not somebody else talking on your behalf.

You may already be using GitHub’s SSH authentication, but do you know how it actually works? In this article, you’ll learn what happens under the hood and how SSH authentication actually works.

Along the way, you’ll understand the fundamental concepts of cryptography that every developer should know about: symmetric key encryption, asymmetric key encryption, cryptographic hash functions, and digital signatures.

Some developers usually don’t get the chance to learn and understand these cryptography fundamentals, but these concepts will help you in the long run. Also, they’ll help you be in a much better position to take informed security decisions for your production web applications.

So come on, fasten your seat belts, and let’s start!

Here’s what we’ll cover:

1. First, Why is Authentication So Important?

2. Symmetric Key Encryption

3. Asymmetric Key Encryption

4. Cryptographic Hash Functions

5. Digital Signatures

6. How SSH Authentication Works

7. Wrapping it All Up

First, Why is Authentication So Important?

When we run git push, GitHub needs to verify that the right person is interacting with GitHub. Imagine if an attacker could manage to do git push on your behalf.

Then all your repositories would be under that attacker's control. They could delete all your code along with all the commit history.

This sounds quite dangerous, doesn’t it? So to verify that it’s actually you who’s talking to GitHub, and not an attacker, GitHub has several ways to authenticate you.

The most widely used method to authenticate with GitHub is SSH authentication.

Before we understand how SSH authentication works under the hood, we will need to understand the fundamental cryptography concepts, namely — symmetric key encryption, asymmetric key encryption, cryptographic hash functions, and digital signatures.

Let’s begin!

Symmetric Key Encryption

In the ancient days, rulers devised various methods of communicating secret military messages to their army commanders.

One of the earliest methods, likely used by ancient Greek rulers and possibly later the Romans, involved using a cylindrical wooden rod called a Scytale.

Before a military invasion, the ruler would have two exact same cylindrical wooden rods made called scytales. Then he would give one scytale to the army commander and keep one for himself.

The device worked by winding a strip of leather around the scytale. After doing this, the ruler would write the message on top of the wound-up leather strip so that it could only be read when properly wound again.

Suppose the scytale allowed him to write three letters around in a circle and five letters straight across/along its length. The wound leather strip with the message attackfromright written on it would look like this:

       |   |   |   |   |   |
       | a | t | t | a | c |  |
     __| k | f | r | o | m |__|
    |  | r | i | g | h | t |
    |  |   |   |   |   |   |

After writing the message on the scytale, the ruler would unwind the leather strip and send it to the army commander. When it was unwound, the leather strip would have the following jumbled message:

----------------
akrtfitrgaohcmt
----------------

So now you see, even if the leather strip got intercepted by an enemy spy, the message would not make sense. Isn't this fascinating? The smart use of a wooden rod and a leather strip might have helped some ancient rulers win battles!

When the leather strip reached the army commander, he would wind it around his own scytale (which would be exactly the same as ruler’s), and then the commander would be able to understand the message properly.

This scytale technique is actually an example of symmetric key encryption in practice.

Encryption is a process in which the original message is modified (or encoded) in such a way that only the intended recipient can decode and see the actual message.

The original message is called plaintext, while the encoded message is called ciphertext. Encryption converts plaintext to ciphertext with the help of a key.

To decrypt the message, that is to convert ciphertext to plaintext, a person must have access to that same key.

If we compare it to the scytale technique, the scytale is the key. The ruler only shares the key (scytale) with the army commander who needs to know what the message says.

Here's what the encryption process looks like:

The decryption process will look like this:

We call this symmetric key encryption because the same key is used to both encrypt and decrypt the message.

This key (the scytale) must be kept protected from enemy access. If the enemy get’s access to this key, then they’ll be able to decrypt the messages.

But there’s another type of encryption called asymmetric key encryption. Now that you understand symmetric key encryption, let’s move on to asymmetric key encryption.

Asymmetric Key Encryption

In symmetric key encryption, like we saw above, the same key was used by both the ruler and the army commander to encrypt and decrypt the message.

But in an asymmetric key encryption, there are two keys (called a key pair). Out of the two keys, one is a private key and the other is a public key.

The public key can be shared with everyone (which is why it’s called public). But the private key is meant to be kept secret! It must never ever be revealed to anybody.

The interesting thing about asymmetric key encryption is that, if a message is encrypted with the public key, then it can only be decrypted with the corresponding private key. No other key can decrypt it.

And it works the other way too. If a message is encrypted with the private key then it can only be decrypted using the corresponding public key.

The two keys – public and private – are mathematically linked with each other. While one encrypts, the other decrypts.

Just a small note that asymmetric key encryption is also called public key encryption. These two terms are used interchangeably but they mean the same thing.

Cryptographic Hash Functions

A cryptographic hash function is designed to take in an input of any length and produce a fixed-length output. The fixed-length output is called as hash value.

A popular example of a cryptographic hash function is SHA-256.

The above image shows the SHA-256 hash value of the input “freeCodeCamp.org“. Cryptographic hash function has three properties that make it very useful (we’ll see how in the coming sections).

First, it’s practically impossible to take the hash value and figure out the input from the hash value.

For example, if we are given the hash value c9c31315ef2257e4b7698, there’s no way for us to figure out that the input to the hash function was “freeCodeCamp.org“.

Second, if we pass the same input to the hash function, we get the same hash value as output.

If we pass “freeCodeCamp.org“ again to the SHA-256 hash function, we will get the same hash output as our previous call.

Third, two different inputs never share the same hash value. Even the slightest change in input produces an entirely different output.

Suppose if we provide “freeCodeCamp“ as input instead of “freeCodeCamp.org“ – we would get a totally different output.

Digital Signatures

In your daily lives, you might have to sign various documents. These might be legal documents, or your kids’ school report card, or maybe something else.

When your signature is present on the document, it conveys to the other party that it is you who agrees with whatever is written on that document.

Later on, you cannot walk back from doing what’s written on the document. Correct?

Similarly, in the digital world, we have digital signatures – or we can simply call them signatures.

Let’s understand how signatures works using an example. We have two users named “Alice“ and “Bob“.

Bob wants to transfer some money to Alice’s bank account. So Bob asks Alice about her bank account information.

Alice knows about digital signatures and decided to use one. At the end, you will understand why Alice opted for a digital signature.

Before Alice can create a digital signature. Alice provides Bob with her public key (and keeps the private key to herself).

Then Alice creates a digital signature and places it at the end of the document.

A digital signature is created by first passing the document contents to a cryptographic hash function like SHA-256. In Alice’s case, the document’s content is her bank account number.

Once we get the hash value, it gets encrypted with Alice’s private key. The output of this encryption is the signature which gets placed at the end of the document.

This is then sent to Bob over the Internet.

When Bob receives this document, he verifies whether the signature is valid or not.

To verify the signature, Bob first decrypts the signature with Alice’s public key. If you remember, Alice generated the signature by encrypting the hash value.

 plaintext                         ciphertext  
     |                                 |
     |                                 |
     |                                 |
hash value --------encrypt--------> signature

So, when Bob decrypts the signature, he will get the hash value that Alice calculated. Let’s call this Alice’s hash value.

 ciphertext                         plaintext  
     |                                 |
     |                                 |
     |                                 |
signature --------decrypt--------> hash value

Then Bob takes the bank account number that’s present on the document and passes it to the hash function.

Finally, Bob matches the Alice’s hash value (the decrypted signature) and the hash value that he just calculated. If both the hash values match then that means the signature is valid.

OK — but why did we need to do all this? What does it mean if the signature is valid?

When the signature verification is successful, it proves two things.

First, it proves that the document has been sent by Alice only. Nobody else could have sent this document.

The assurance that only Alice has sent this document comes from the fact that we were able to decrypt the signature using Alice’s public key.

We have learned that if something is encrypted using a private key then it can only be decrypted using its linked public key.

So, if Bob was successfully able to decrypt the signature using Alice’s public key, it means that it was encrypted using Alice’s private key, correct?

And only Alice has access to her private key. This means that Alice is the only person who could have sent this document!

Second, it proves that the content of the message has not been modified by an attacker during network transmission.

We did two things to verify the signature. We decrypted the signature, and it gave us the hash value that Alice calculated. And we also hashed the received bank account number.

If the hash value that Alice calculated and the hash value that Bob calculated are the same, this means that Alice and Bob gave exactly the same input to the hash function.

And this means that the bank account number that Alice sent and that Bob received are exactly same.

If an attacker would have changed the bank account number before the document reached Bob, then Bob would’ve received a modified bank account number.

When Bob went to calculate the hash value of this modified bank account number, the hash value would’ve come out to be different than what Alice had calculated.

So while matching Alice’s hash value (decrypted signature) and the hash value that Bob calculated, the matching would fail. And it would prevent Bob from transferring money to the wrong bank account number.

To conclude, when the signature is successfully verified, it means that:

1. The document is only from Alice.

2. The document’s contents were not modified by any third party.

Now you’ve learned about symmetric key encryption, asymmetric key encryption, cryptographic hash functions, and digital signatures. That’s awesome!

We have built a really solid foundation. Now understanding SSH authentication is going to be much easier for you.

How SSH Authentication Works

If you have not setup SSH authentication with GitHub, then after completing this article you can follow GitHub’s detailed documentation on how to do it. For now, please stay here till the end.

The crux of the setup process is that you create a public and private key pair on your local computer. Then you upload your public key to your GitHub profile – and that’s it!

After we have created our public-private key pair, in Ubuntu, public-private key pair are stored inside the ~/.ssh directory.

The above image shows my public key. I have this public key uploaded to my GitHub profile:

Now, when I run git push or any other command that wants to communicate with GitHub, I will be authenticated using SSH authentication.

SSH is a client-server protocol. Our computer that runs git push is the SSH client. GitHub is the SSH server.

The client starts off the authentication process by first fetching our public key that we have inside ~/.ssh.

The client then prepares a message which has our public key. And then the client generates the signature using the corresponding private key.

The public key and signature are sent to GitHub. Upon receiving this message, GitHub does two things:

First, it verifies whether the public key mentioned in the message is connected to a GitHub profile or not. Since we upload our public key to GitHub, this step checks out successfully.

Second, GitHub verifies the signature using the public key that we have uploaded.

We have learned that if the signature verification turns out to be successful this means that only the person who is in the possession of the corresponding private key could have sent the message.

Since only we have the private key linked to the uploaded public key, this proves to GitHub that it is indeed us attempting to communicate with GitHub and not an attacker.

Now, GitHub is 100% sure that we are the correct person, we are successfully authenticated, and our git push is allowed to proceed further.

See, it became so easy to understand SSH authentication as you already learned the fundamentals.

The above image is from the popular xkcd comic. The character there (named Cueball) is thinking about revealing his private key. I hope now you know why it’s bad to reveal your private key.

If you reveal your private key then someone else can authenticate to GitHub on your behalf. You don’t want that to happen, right? ;)

So, always make sure to keep your private key just to yourself.

Wrapping it All Up

If you have read this far, then Congratulations 🥳.

You’ve learned how SSH authentication actually works — when the signature was successfully verified by GitHub, it confirms to GitHub that it is we who are talking to it not an attacker.

Along the way you built a foundational understanding of symmetric key encryption, asymmetric key encryption, cryptographic hash functions and digital signatures.

Thanks for being with me on this one, I hope you are going away with some new and valuable learnings.

I put useful ideas and resources on my Twitter. You should follow me there. I will respect your time.

SSH is widely used for accessing remote servers and managing code repositories securely, particularly in environments like GitHub. You’ll learn about the fundamental concepts of SSH, how it works, and practical steps to set it up on Windows. We will cover everything from generating SSH keys to testing your connection and cloning repositories.

By the end of this guide, you will have a solid understanding of SSH and be equipped to enhance your workflow with secure connections.

What we’ll cover:

1. What is SSH?

2. How Does the Secure Shell Protocol Work?

• TCP/IP

• The SSH Connection Process

3. How to Use SSH in Windows

• Windows PowerShell or Command Prompt

• Windows Subsystem for Linux (WSL)

• Third-Party SSH Clients (for example, PuTTY)

4. How to Use SSH In Windows To Connect To GitHub

• Install Through Windows Optional Features

• Download And Install From Github

• How To Generate SSH Keys

• How To Add The Public Key To GitHub

• Testing The SSH Connection

• Cloning A Repository Using SSH

5. Conclusion

Prerequisites

Before you begin this tutorial, ensure you have the following:

• Basic Understanding of Command Line: You should be familiar with using the command line interface (CLI) on Windows, including how to open PowerShell or Command Prompt.

• Windows Operating System: This tutorial is specifically tailored for users running Windows 10 or later versions.

• OpenSSH Client Installed: Ensure that you have the OpenSSH client installed on your system. You can check this by typing ssh in your command line interface.

• GitHub Account: You’ll need a GitHub for testing SSH connections and managing repositories.

• Text Editor: You’ll also need a code editor (like Visual Studio Code, Notepad++, or similar) to edit configuration files if needed.

What is SSH?

SSH stands for secure shell (protocol). The secure shell protocol is a cryptographic network protocol for operating network services securely over an unsecured network.

In simpler terms, SSH is a way to safely use services on a network, like accessing a remote computer, even when the network itself isn’t fully secure. It protects your data and communications by scrambling (encrypting) everything, so no one can eavesdrop or tamper with it, even if they intercept it.

This is especially useful when connecting to services like GitHub, where you want to securely manage code on a remote server.

How Does The Secure Shell Protocol Work?

SSH runs on the TCP/IP set of rules that computers use to communicate over the internet.

TCP/IP

TCP stands for Transmission Control Protocol. It’s one of the core protocols in the TCP/IP suite, which is used to send data over the internet. The IP stands for Internet Protocol. It's part of the TCP/IP set of rules also, and its job is to guide packets of data to the right destination on the internet.

You can read more about the TCP/IP protocol here if you’d like to go deeper.

The SSH Connection Process

The Secure Shell protocol operates by establishing a secure connection between a client (your local machine) and a remote server.

First, the client initiates the connection by specifying the server's address (IP or domain) and login credentials. During the authentication phase, the server verifies the identity of the client, typically using a password or, more securely, SSH keys. These are a pair consisting of a private key stored on the client and a public key on the server.

Once authenticated, SSH encrypts all data transferred between the client and the server, ensuring confidentiality and integrity. This secure channel allows the client to execute commands, transfer files, and manage the server remotely as if physically present while safeguarding the data from potential interception or tampering.

IP is responsible for addressing and routing the initial connection request from the client to the server. It ensures that the request, which includes the server's address, is sent to the correct destination.

Once the SSH connection request reaches the server, TCP establishes a reliable communication channel. It manages data transmission between the client and the server, ensuring that all packets are delivered accurately and in the correct order.

During the SSH session, TCP ensures that data packets are correctly transmitted and reassembled, while IP handles the addressing. SSH then uses this secure and reliable channel to authenticate the client, encrypt all transferred data, and maintain a secure connection. This allows remote management and file transfer with confidentiality and integrity.

How to Use SSH in Windows

Windows provides a few different ways to use SSH:

Windows PowerShell or Command Prompt

Windows comes with a built-in OpenSSH client. You can access this by opening PowerShell or Command Prompt and typing ssh This method is simple and requires no additional software.

Windows Subsystem for Linux (WSL)

You can enable Windows Subsystem for Linux to run a Linux distribution directly on your Windows PC. Many Linux distros come with OpenSSH pre-installed, allowing you to use ssh commands from the Linux terminal. This method is great if you prefer a Linux-like environment.

Third-Party SSH Clients (for example, PuTTY)

If you prefer a standalone application, tools like PuTTY offer a graphical interface to manage SSH connections. PuTTY is widely used for connecting to servers and supports advanced options like saving connection profiles.

Windows 10 and later versions come with a native OpenSSH client, which allows you to securely connect to remote systems over an SSH (Secure Shell) connection.

How to Use SSH in Windows to Connect to GitHub

If you're using Windows 10 or a later version, you can take advantage of the built-in SSH capabilities.

To get started, open your Windows Terminal or PowerShell, preferably as an administrator. In the command line interface, you can check if SSH is installed by typing the command ssh. This will confirm if the SSH client is available on your system.

If you got the above image, it means SSH is available on your local system.

The first thing you'll need to set up an SSH connection is a pair of SSH keys – a public key and a private key. These are typically located in the .ssh directory in your home directory if generated already.

On Windows, your home directory is usually C:\Users\owner\.ssh. This is where you will find your SSH key files if they've already been generated.

You can easily install OpenSSH on your Windows system. There are a couple of ways to do this:

Install Through Windows Optional Features

1. Open the Windows Start menu and type "optional features" in the search bar.

2. Click on "Add or remove Windows optional features" to open the Optional Features window.

3. In the Optional Features window, scroll down and find the "OpenSSH Client" option.

4. Check the box next to it and click the "Install" button at the bottom to install the OpenSSH client.

Download and Install from GitHub

1. Visit the GitHub repository for the Win32-OpenSSH (32-bit) or Win64-OpenSSH (64-bit) release, depending on your Windows version:

   • 32-bit: https://github.com/PowerShell/Win32-OpenShell/releases

   • 64-bit: https://github.com/PowerShell/Win64-OpenShell/releases

2. Download the latest .msi installer file that matches your Windows architecture.

3. Run the .msi installer to install the OpenSSH client on your system.

After installing OpenSSH, you can now generate SSH keys by opening the Windows Terminal or PowerShell and running the ssh-keygen command. This will walk you through the process of creating a new public-private key pair that you can use to authenticate your SSH connections, such as to your GitHub account.

The public key can then be added to your GitHub account settings, allowing you to connect to your repositories using the SSH protocol instead of HTTPS. Remember to keep your private key safe and secure, as it provides access to your GitHub account.

By installing OpenSSH, you've set up the necessary foundation to work with SSH keys and establish secure connections to remote systems and services like GitHub.

Now you can check if the OpenSSH server is running by accessing the Windows Services utility. To do this, press the Windows key + R to open the Run dialog, then input "services.msc" and press Enter. This will open the services manager.

The services manager:

Scroll and look for the openSSH SSH server:

If the OpenSSH Server service is running in the Services window, it means that the OpenSSH server component is properly set up on your Windows system. This is an important first step in enabling secure SSH connections.

To ensure the OpenSSH server starts automatically whenever your PC is turned on, you can further configure the service's startup type. In the Services window, right-click on the "OpenSSH Server" service and select "Properties."

In the service properties, look for the "Startup type" dropdown and select "Automatic." This will ensure the OpenSSH Server service starts up automatically whenever your computer is powered on, rather than requiring you to manually start it each time.

By setting the OpenSSH Server service to start automatically, you can be confident that the server will be ready to accept incoming SSH connections at all times, without needing to remember to start it manually. This streamlines the process of using SSH-based authentication and remote access on your Windows machine.

Remember, having the OpenSSH Server service running and set to start automatically is just the first step. You'll still need to generate SSH keys and configure your GitHub account (or other services) to use the public key for authentication. But this initial setup of the OpenSSH server lays the foundation for seamless SSH usage going forward.

Now that you've confirmed the OpenSSH Server is running on your Windows system, the next step is to ensure it can communicate through the Windows Firewall. The easiest way to do this is by using a PowerShell command.

Open PowerShell as an administrator and run the following command:

New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH SSH Server' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22 -Program "C:\Program Files\OpenSSH\sshd.exe"

This PowerShell command will create a new firewall rule that allows inbound TCP traffic on port 22 (the default SSH port) for the OpenSSH Server executable located at "C:\Program Files\OpenSSH\sshd.exe".

Here's a breakdown of the different parameters used in the command:

• -Name sshd: Assigns the name "sshd" to the new firewall rule.

• -DisplayName 'OpenSSH SSH Server': Provides a descriptive display name for the rule.

• -Enabled True: Ensures the rule is active and enabled.

• -Direction Inbound: Specifies that the rule applies to inbound network traffic.

• -Protocol TCP: Configures the rule to allow TCP protocol connections.

• -Action Allow: Instructs the firewall to allow the specified traffic.

• -LocalPort 22: Sets the local port to 22, which is the default SSH port.

• -Program "C:\Program Files\OpenSSH\sshd.exe": Identifies the specific program (the OpenSSH Server executable) that the rule should apply to.

By running this PowerShell command, you're creating a dedicated firewall rule that permits the OpenSSH Server to communicate through the Windows Firewall, enabling you to establish secure SSH connections to your system.

Remember, it's always a good practice to review your firewall settings periodically, especially if you make changes to your network configuration or want to refine access to the OpenSSH Server further.

If successful, you should get this:

Summary of the above CLI response:

• Rule Name: sshd

• Display Name: OpenSSH SSH Server

• Direction: Inbound

• Action: Allow

• Enabled: True

• Profile: Any

The rule is designed to allow inbound traffic, enabling external clients to connect to the server. The "Enabled" status confirms that the rule is currently active, while the "Profile" set to "Any" indicates that it applies to all network types, including public, private, and domain.

Security Policies:

• Edge Traversal Policy: Block

• Loose Source Mapping: False

• Local Only Mapping: False

The "EdgeTraversalPolicy" is configured to "Block," preventing traffic from traversing the network boundary, specifically disallowing connections from public networks to private ones. This helps enhance security by mitigating potential vulnerabilities.

The settings for "LooseSourceMapping" and "LocalOnlyMapping" are both set to false, ensuring that only direct connections are allowed without additional mapping.

Status and Enforcement:

• Primary Status: OK

• Status: The rule was parsed successfully from the store.

• Enforcement Status: NotApplicable

• Policy Store Source: PersistentStore

• Policy Store Source Type: Local

The "Status" field confirms that the rule has been successfully parsed from the policy store, indicating no configuration issues. The "EnforcementStatus" marked as "NotApplicable" suggests there are no restrictions that would prevent the rule from being enforced.

Remember, to set up an SSH connection we need a pair of SSH keys – a public key and a private key. Let’s see how to do that now.

How to Generate SSH Keys

• Open your Windows Terminal or PowerShell.

• Run the command ssh-keygen to generate a new SSH key pair.

• Follow the prompts to specify the save location and passphrase (optional) for your keys.

You will get what you see in the above image if you’re successful.

The public key will be saved as id_rsa.pub in the .ssh directory of your user's home folder (for example, C:\Users\you\.ssh\id_rsa.pub).

How to Add the Public Key to GitHub

• Log in to your GitHub account and go to your account settings.

• Navigate to the "SSH and GPG keys" section.

• Click on the "New SSH key" button. Give your key a descriptive title, and then copy the contents of the id_rsa.pub file (your public key) into the "Key" field.

• Click "Add SSH key" to save the new key.

Testing the SSH Connection

In your Windows Terminal or PowerShell, execute the following command to test your SSH connection to GitHub:

bashCopy codessh -T git@github.com

If prompted, enter your passphrase if you set one during the key generation process. If you did not set a passphrase, simply type "yes" when asked for a response to the handshake.

If the connection is successful, you should see a message like "Hi username! You've successfully authenticated, but GitHub does not provide shell access."

You can solve this by following the process here.

Cloning a Repository Using SSH

Navigate to one of your GitHub repositories and copy the SSH clone URL, which typically starts with git@github.com:

In your local terminal, run the command git clone git@github.com:username/repository.git to clone the repository using the SSH protocol.

Conclusion

You now have SSH working between your Windows computer and your GitHub account. This means you can work with your GitHub projects more easily and securely.

Why SSH is Cool:

1. It's super secure. SSH scrambles your data so others can't snoop on it.

2. It's convenient. No more typing passwords all the time!

3. It's flexible. You can use it for more than just GitHub.

4. You can have different "keys" for different projects.

5. It works well with automatic coding tools.

But it’s not perfect:

1. Keeping track of many SSH keys can be a headache.

2. If someone gets your private key, they could access your stuff.

3. Setting it up the first time can be tricky.

4. You need to remember to change your keys yourself for extra safety.

5. Some networks might block SSH, which can be annoying.

Remember to keep your private SSH key safe. It's like a special password for your GitHub account, so guard it well.

Even with these small downsides, SSH is still awesome for most coders. You are now all set to work on your GitHub projects more easily and safely. Have fun with your improved coding setup, and keep learning about ways to keep your work secure.

Secure Shell (SSH) is a widely used network protocol that provides a secure way to access remote servers and computers.

In Linux, SSH is an essential tool for remote administration and file transfer. In this article, we will go over the meaning of SSH in Linux, its history, features, configuration, and use cases.

What is SSH?

SSH is a cryptographic network protocol that allows secure communication between networked devices. It was developed as a replacement for Telnet, which sends all data, including passwords, in clear text, making it susceptible to eavesdropping and interception.

SSH provides encryption and authentication mechanisms to protect the confidentiality and integrity of network communications.

Brief History of SSH

The first version of SSH, SSH-1, was developed by Tatu Ylönen in 1995 as a response to the insecurity of Telnet and FTP.

In 1996, SSH Communications Security released a commercial version of SSH-1, which became widely used in the industry.

But SSH-1 had some security vulnerabilities, and in 1998, Ylönen developed SSH-2, which addressed these issues and became the most widely used version of SSH.

How SSH Works

SSH uses a client-server architecture, where the client initiates a connection to the server and requests a secure communication channel. The server responds by generating a pair of cryptographic keys, one public and one private.

The public key is sent to the client, while the private key is kept securely on the server. The client then encrypts a random session key using the server's public key and sends it back to the server. The server decrypts the session key using its private key and sends an acknowledgement to the client. From this point on, all data transmitted between the client and server is encrypted using the session key.

SSH Features

• Encryption: SSH uses strong encryption algorithms, such as AES, to protect the confidentiality and integrity of data transmitted over the network.
• Secure file transfer: It provides secure file transfer (SFTP) capabilities, which allow users to transfer files between remote servers securely.
• Remote login: SSH provides a secure way to login to remote servers and computers, without exposing login credentials to attackers.
• Port forwarding: It provides port forwarding capabilities, which allow users to access restricted services on remote servers through a secure communication channel.
• X11 forwarding: SSH provides X11 forwarding capabilities, which allow users to run graphical applications remotely, without having to install them locally.
• Agent forwarding: It also provides agent forwarding capabilities, which allow users to use SSH keys for authentication on remote servers, without having to enter their password every time.

SSH Configuration

SSH configuration involves various settings and options that can be customized to optimize the SSH connection and improve security. Here are some common SSH configuration tasks:

• Generating SSH keys: Before using SSH, users must generate a pair of cryptographic keys, one public and one private. The public key is shared with the server, while the private key is kept securely on the user's computer.
• Editing configuration files: Users can create and edit SSH configuration files to customize their SSH settings, such as specifying the preferred encryption algorithm or setting up port forwarding. The SSH configuration files are usually located in the /etc/ssh/ directory.
• Authentication methods: SSH supports various authentication methods, such as password authentication, public key authentication, and multi-factor authentication. Users can choose the most suitable authentication method based on their security needs.
• Secure SSH configuration: To ensure maximum security, users should follow best practices for secure SSH configuration, such as disabling root login, enforcing strong passwords, and limiting the number of failed login attempts. Users can also use tools like Fail2Ban to prevent brute-force attacks on SSH.
• Enabling X11 forwarding: SSH provides X11 forwarding capabilities, which allow users to run graphical applications remotely, without having to install them locally. To enable X11 forwarding, users can add the -X or -Y flag when connecting to the remote server.
• Port forwarding: SSH allows users to set up port forwarding, which can be useful for accessing restricted services on remote servers through a secure communication channel. Users can set up local or remote port forwarding, depending on their needs.
• Compression: SSH supports data compression, which can improve the performance of the SSH connection, especially when transferring large files or running resource-intensive applications. Users can enable compression by adding the -C flag when connecting to the remote server.

SSH Examples and Use Cases

• Remote server administration: SSH is commonly used for remote server administration, allowing users to execute commands and manage servers from a remote location.
• Secure file transfer: provides a secure way to transfer files between remote servers, without exposing the files or login credentials to attackers.
• Running graphical applications remotely: allows users to run graphical applications remotely, without having to install them locally, which can be useful for resource-intensive applications or when using a low-power device.
• Port forwarding for accessing restricted services: allows users to access restricted services on remote servers through a secure communication channel, by setting up port forwarding.
• Tunneling for secure communication: SSH allows users to set up encrypted tunnels for secure communication between two networked devices, which can be useful for accessing resources on a private network.

Conclusion

To end this article, here's a recap of what we covered and what you should know about SSH:

• SSH is a secure protocol for remote communication in Linux.
• SSH uses encryption to protect data and authentication mechanisms to verify users.
• SSH is a reliable and efficient way to communicate securely over the internet, and is a vital tool for Linux system administration and development.
• SSH provides remote login, secure file transfer, port forwarding, X11 forwarding, and agent forwarding capabilities.
• To use SSH, users must generate a pair of cryptographic keys, one public and one private.
• SSH configuration files can be customized to optimize the SSH connection and improve security.
• SSH supports various authentication methods, such as password authentication, public key authentication, and multi-factor authentication.
• To ensure maximum security, users should follow best practices for secure SSH configuration, such as disabling root login, enforcing strong passwords, and limiting the number of failed login attempts.
• SSH can be used for remote server administration, secure file transfer, running graphical applications remotely, port forwarding, and tunneling for secure communication.
• SSH is a widely used and supported protocol, with many SSH clients and servers available for different platforms.

Let's connect on Twitter and on LinkedIn. You can also subscribe to my YouTube channel.

Happy Coding!

The purpose of cryptography is to ensure secure communication between two people or devices who are connecting through insecure channels.

The sender often employs an encryption key to lock the message, while the recipient uses a decryption key to unlock the message.

In general, cryptography employs two strategies:

1. Symmetric-key Cryptography (Private key): With this technique, the encryption and decryption keys are both known to the sender and receiver. Some examples of algorithms that use this technique include One Time Pad cipher, Vernam cipher, Playfair, Row column cipher, and Data Encryption Standard (DES).

2. Asymmetric Key Cryptography (Public key): With this technique, each person has two keys: the Private (secret and accessible to the creator) and Public keys (freely available to anyone). The sender and receiver use different keys for encryption and decryption. Some examples of algorithms that use this technique include the Rivest–Shamir–Adleman algorithm (RSA), Diffie - Hellman Key Exchange (DHE), and the Digital Signature Algorithm (DSA).

The Encryption Model for Secured Data Transmission

Software engineers generally have to authenticate with servers or other services like GitHub for version control.

As opposed to using password authentication, they can use public key authentication to generate and store a pair of cryptographic keys on their computer. Then they can configure the server running on another computer to recognize and accept those keys.

This is the asymmetric key cryptography technique flow we discussed earlier and it is a more secure authentication process.

In this tutorial, you will learn how it all works, what SSH means, and how to generate SSH keys with an RSA algorithm using SSH keygen.

Prerequisites

• A working computer running on any operating system.

• Basic knowledge of navigating around the command-line.

• A smile on your face :)

Brief Introduction to SSH (Secure Shell Protocol)

Public key authentication using SSH is a more secure approach for logging into services than passwords. Understanding SSH is easier once you understand how cryptography works from the above intro.

Here's a helpful basic definition:

"The Secure Shell Protocol is a cryptographic network protocol for operating network services securely over an unsecured network." (Source)

SSH is used between a client and a server both running on the SSH protocol to remotely login into the server and access certain resources through the command line.

Source: SSH Academy

There is an open-source version of the SSH protocol (version 2) with a suite of tools called OpenSSH (also known as OpenBSD Secure Shell). This project includes the following tools:

• Remote operations: ssh, scp, and sftp.

• Key generation: ssh-add, ssh-keysign, ssh-keyscan, and ssh-keygen.

• Service side: sshd, sftp-server, and ssh-agent.

How to Generate an SSH Public Key for RSA Login

Our goal is to use ssh-keygen to generate an SSH public key using the RSA algorithm. This will create a key pair containing a private key (saved to your local computer) and a public key (uploaded to your chosen service).

Now to proceed, follow the steps below to achieve this:

1. Install OpenSSH if you don't have it installed already using the command below:

// for mac

brew install openssh

// for linux

sudo apt install openssh-client && sudo apt install openssh-server

2. Create a private/public key pair with an RSA algorithm (2046-bit encryption by default), using the command:

ssh-keygen -t rsa

3. Or, if you want to create with an RSA algorithm with 4096-bit encryption, use the command:

ssh-keygen -t rsa -b 4096

4. Enter a file location to save the key to (by default it will save to your users directory (for example, (/Users/bolajiayodeji/.ssh/id_rsa) ).

5. Enter a passphrase for extra security to your private key. Generally, a good passphrase should have at least 15 characters (including at least one upper case letter, lower case letters, numerical digits, and special characters) and must be difficult to guess. You can use one of those password generators online or use hexdump to generate a paraphrase easily like so:

hexdump -vn16 -e'4/4 "%08X" 1 "\n"' /dev/urandom

6. Once you've successfully created your password, your private key will be saved in /<your_chosen_directory>/.ssh/id_rsa and your public key will be saved in /<your_chosen_directory>/.ssh/id_rsa.pub.

Now you can copy the created key into the authorized_keys file of the server you want to connect to using ssh-copy-id (this tool is a part of openSSH) like so:

ssh-copy-id username@remote_host

Alternatively, you'd want to add your SSH private key to the ssh-agent and store your passphrase in the keychain. You can then add the SHH key to your server's account via a dashboard UI or so (for example, using tools like Git or GitHub).

Conclusion

Although a strong password helps prevent brute-force attacks, public key authentication provides a much more secure authentication process using cryptography.

I hope you found this article helpful. In addition, you can check out the ssh-keygen manual page and the following resources for further learning:

• Connecting to GitHub with SSH

• Get started with OpenSSH for Windows

Cheers! 💙

Containers are the bread and butter for running applications today. And the most popular container technology is called Docker.

Knowing how to SSH into a container is essential to using, debugging, and operating containers on your local operating system or remote setup.

This article will describe different methods for doing so along with their constraints.

Method 1 – Attach to a Running Container using docker exec

The most common and helpful command for getting a shell in a container is docker exec -it. It runs a new command in the container, which allows you to start a new interactive shell:

# start a container
$ docker run --name nginx --rm -p 8080:80  -d nginx

# create and connect to a bash shell in the container
$ docker exec -it nginx bash

root@a84ad71521b1:/#

You can exit the current shell by pressing control + d or typing exit.

It works because:

• docker exec runs a new command,
• -i adds a stdin stream,
• -t adds a terminal driver,
• -it combines -i and -t, which allows you to interact with the process.

‌‌It can happen that your container does not have bash installed. In case you can not start bash, you can try starting a sh-shell:

docker exec -it nginx sh

‌‌Also, there might not be a shell installed in the container. Therefore, there is no way to get a shell in that container in a plain docker Universum and you can not start any shell.‌‌

Depending on your container orchestration tool, you might still be able to access the container. For example, distroless containers are getting more popular to reduce the footprint of the container. If you use Kubernetes, an ephemeral container feature allows you to debug containers without a shell as well as crashed containers.

Method 2 – Attach to a Running Container using docker attach

The docker attach command attaches your terminal’s standard input, output, and error to a running container using the container’s id or name. (Source docker.com)

In practice, this means everything you enter gets forwarded to the container, and everything that is printed will be shown in your console.

Now, you attach to the running container:

$ docker attach nginx                              

172.17.0.1 - - [18/Mar/2022:08:37:14 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36" "-"

While running this, you can open http://localhost:8080. Because the container prints access logs on each page opened, you will see the output in your terminal.

Additionally, input is forwarded as well to the container. So if you press control + c, which triggers a kill signal, your container will shut down.

$ docker attach nginx                              
172.17.0.1 - - [18/Mar/2022:08:37:14 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36" "-"
^[[A^C2022/03/18 08:39:50 [notice] 1#1: signal 2 (SIGINT) received, exiting
2022/03/18 08:39:50 [notice] 32#32: exiting

Detaching can be tricky because control + c is also used for detaching. To be able to detach without stopping the container, you can attach to the container by disabling forwarding signals:

# start the container again
docker run --name nginx --rm -p 8080:80  -d nginx

# attach with proxying signals
docker attach --sig-proxy=false nginx

Conclusion

To connect to a container using plain docker commands, you can use docker exec and docker attach.

docker exec is a lot more popular because you can run a new command that allows you to spawn a new shell. You can check processes, files and operate like in your local environment.

docker attach is more restricted because it attaches your terminal’s standard input, output, and error to the main process of a running container.

I hope you enjoyed the article.

If you liked it and felt the need to give me a round of applause or just want to get in touch, follow me on Twitter.

I work at eBay Kleinanzeigen, one of the world’s biggest classified companies. By the way, we are hiring!

References

• How to SSH into a Running Docker Container and Run Commands
• How to Detach From a Docker Container Without Stopping It
• Docker attach documentation
• Docker exec documentation

What RSync Is

Rsync is faster than tools like Secure Copy Protocol (SCP). It uses the delta-transfer algorithm that minimizes the data transfer by copying only the sections of a file that have been updated.

Some of the additional features of Rsync include:

• Supports copying links, devices, owners, groups, and permissions
• Does not require super-user privileges
• Pipelines file transfers to minimize latency costs

You can only transfer files from local  to  remote or remote  to  local. Rsync does not support remote  to  remote file transfers.

How RSync Works

Now that you know what Rsync is, let's look at how to work with it.

Rsync works similarly to other remote server management tools like SSH and SCP.

Here is the basic syntax of Rsync:

rsync [options] source [destination]

Here is the syntax to transfer a file from your local system to a remote server. It is also called a “push” operation.

rsync local_file_path user@remote-host:remote_file_path

Here's how to transfer a file from a remote server to your local system, also called a “pull” operation.

rsync user@remote-host:remote_file_path local_file_path

Note: When working with remote systems, make sure you have SSH access to the remote system. Rsync establishes the connection using SSH in order to enable file transfer.

How to Use Flags in RSync

Rsync lets you add additional options via command-line flags. Let's look at a few useful flags.

Recursive

If you add the -r option, RSync will execute a recursive file transfer. This is useful when working with directories. Here is an example:

rsync -r user@remote-host:remote_directory/ local_directory

Archive

The -a flag is used to preserve symbolic links while transferring files. The archive flag also preserves special and device files, modification times, and permissions from the source directory.

The archive flag also syncs files recursively, so it is used more than the recursive flag. Here is how you use it:

rsync -a user@remote-host:remote_directory/ local_directory

Compression

You can also compress files using the -z flag. Compressing files can reduce network load and speed up file transfer.

rsync -az user@remote-host:remote_directory/ local_directory

Progress

For large file transfers, it is useful to know the progress of the operation. You can use the -P flag to know the progress of the file transfer. With Rsync, you can also resume file transfers if they are interrupted.

rsync -aP user@remote-host:remote_directory/ local_directory

Verbose

Finally, the verbose command can help you understand every step of the file transfer. You can use the -v flag for this.

rsync -av user@remote-host:remote_directory/ local_directory

You can also use the help command with RSnsc to get a list of all the options and flags.

rsync --help

rsync help

Conclusion

Rsync simplifies the whole file transfer process by offering a robust, versatile, and flexible tool compared to alternatives like SCP.

RSync is great for maintenance operations, backups, and general file operations between local and remote machines.

References

• https://www.digitalocean.com/community/tutorials/how-to-use-rsync-to-sync-local-and-remote-directories-on-a-vps
• https://linux.die.net/man/1/rsync
• https://www.geeksforgeeks.org/rsync-command-in-linux-with-examples/

I am Manish and I write about Cybersecurity, Artificial Intelligence, and DevOps. If you liked this article, you can find my blog here.

Even though it is considered a good practice to have one private-public key pair per device, sometimes you need to use multiple keys and/or you have unorthodox key names.

You might be using one SSH key-pair for working on your company’s internal projects but you might be using a different key for accessing some corporate client’s servers. You might even be using a different key for accessing your own private server.

Managing SSH keys can become cumbersome as soon as you need to use a second key. I hope this article will be of help to anyone who is having issues with SSH key management.

I assume the reader has basic knowledge of Git and SSH. Most examples throughout the article will be using Git. Of course, all of this will apply to any other SSH communication. That being said, there are some Git-specific tricks included.

Strap in, here we go!

Dealing with one SSH key

First, let us see what your workflow might look like before having multiple keys to worry about.

You have one private key stored in ~/.ssh/id_rsa with a corresponding public key ~/.ssh/id_rsa.pub.

Let us imagine that you want to push/pull code changes to/from a remote Git server – say GitHub, why not. To do so, you first have to add your public key to GitHub.

I will not go over that step, it should be easy enough to find out how to do that. I have also assumed that your name is Steve and you are working on a top-secret project which uses Raspberry Pies to sniff network traffic.

To start your work, you have to clone a git repository using SSH:

git clone git@github.com:steve/raspberry-spy.git

At this moment GitHub will be like: “Yo, this a private repository! We need to encrypt traffic using this public key I have here and your private key.”

You have added the public key to your profile on GitHub, but SSH has to somehow figure out where your corresponding private key is located.

Since we have no clue which private key should be used when SSH-ing into git@github.com, SSH client tries to find a key in default location, which is ~/.ssh/id_rsa - it’s his best guess. If there is no file in that location, you will get an error:

Cloning into 'raspberry-spy'...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

If you have some private key stored in file ~/.ssh/id_rsa, SSH client will use that private key for communication encryption. If that key is passworded (as it should be), you will be prompted for a password, like so:

Enter passphrase for key '/Users/steve/.ssh/id_rsa':

If you enter the correct passphrase and if that private key indeed is the one which corresponds to the public key which you attached to your profile, all will go fine and the repository will be cloned successfully.

But what if you named your key differently (ex. ~/.ssh/_id_rsa)? SSH client will not be able to determine where the private key is stored. You will get the same Permission denied ... error as before.

If you want to use a private key that you named differently, you have to add it manually:

ssh-add ~/.ssh/_id_rsa

After entering the passphrase you can check if the key was added to ssh-agent (SSH client) by executing ssh-add -l. This command will list all keys which are currently available to the SSH client.

If you try cloning the repository now, it will be successful.

So far, so good?

If you are keen-eyed, you might start noticing some potential issues.

Firstly, if you restart your computer, ssh-agent will restart and you will have to add your not-default-named keys using ssh-add all over again, typing passwords and all that tedious stuff.

Can we automate adding keys or somehow specify which key to use when accessing certain servers?

Can we somehow save passwords so we don’t have to type them in every time? If only there was something like a keychain for saving password-protected SSH keys ?.

Rest assured, there are answers to all those questions.

Enter, SSH config

As it turns out, SSH configuration file is a thing, a thing which can help us out. It is a per-user configuration file for SSH communication. Create a new file: ~/.ssh/config and open it for editing.

Managing custom-named SSH keys

First thing we are going to solve using this config file is avoid having to add custom-named SSH keys using ssh-add. Assuming your SSH key is named ~/.ssh/_id_rsa, add following to the config file:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/_id_rsa
  IdentitiesOnly yes

Now make sure that ~/.ssh/_id_rsa is not in ssh-agent by executing ssh-add -D. This command will remove all keys from currently active ssh-agent session. The session gets reset every time you log out or reboot (or if you kill ssh-agent process manually). We can “simulate” rebooting by executing the mentioned command.

If you try cloning your GitHub repository now, it will be the same as if we added the key manually (like we did before). You will be asked for password:

git clone git@github.com:steve/raspberry-spy.git
Cloning into 'raspberry-spy'...
Enter passphrase for key '/Users/steve/.ssh/_id_rsa':

You will have noticed that the key for whose password we are prompted for is the same key which we specified in our config file. After entering the correct SSH key password, repository will be successfully cloned.

Note: if, after successful cloning, you try git pull, you will be prompted for password again. We will solve that later.

It is important that Host github.com from config and github.com from URI git@github.com:steve/raspberry-spy.git match. You can also change config to be Host mygithub and clone using URI git@mygithub:steve/raspberry-spy.git.

This opens the floodgates. As you are reding this, your mind is racing and thinking about how all your troubles with SSH keys are over. Here are some useful configuration examples:

Host bitbucket-corporate
        HostName bitbucket.org
        User git
        IdentityFile ~/.ssh/id_rsa_corp
        IdentitiesOnly yes

Now you can use git clone git@bitbucket-corporate:company/project.git

Host bitbucket-personal
        HostName bitbucket.org
        User git
        IdentityFile ~/.ssh/id_rsa_personal
        IdentitiesOnly yes

Now you can use git clone git@bitbucket-personal:steve/other-pi-project.git

Host myserver
        HostName ssh.steve.com
        Port 1111
        IdentityFile ~/.ssh/id_rsa_personal
        IdentitiesOnly yes
        User steve
        IdentitiesOnly yes

Now you can SSH into your server using ssh myserver. How cool is that? You do not need to enter port and username manually every time you execute ssh command.

Bonus: Per-repository settings

You can also define which specific key should be used for certain repository, overriding anything in SSH config. Specific SSH command can be defined by setting sshCommand under core in <project>/.git/config. Example:

[core]
        sshCommand = ssh -i ~/.ssh/id_rsa_corp

This is possible with git 2.10 or later. You can also use this command to avoid editing the file manually:

git config core.sshCommand 'ssh -i ~/.ssh/id_rsa_corp'

Password managemet

Last piece of the puzzle is managing passwords. We want to avoid having to enter password every time when SSH connection is initiating. To do so, we can utilize keychain management software that comes with MacOS and various Linux distributions.

Start by adding your key to the keychain by passing -K option to the ssh-add command:

ssh-add -K ~/.ssh/id_rsa_whatever

Now you can see your SSH key in the keychain. On MacOS it looks something like this:

If you remove the keys from ssh-agent via ssh-add -D (this will happen when you restart your computer, as mentioned before) and try SSH-ing, you will be prompted for password again. Why? We just added the the key to the keychain. If you check Keychain Access again, you will notice that the key you added using ssh-add -K is still in the keychain. Weird, huh?

It turns out there is one more hoop to jump through. Open your SSH config file and add the following:

Host *
  AddKeysToAgent yes
  UseKeychain yes

Now, SSH will look for key in keychain and if it finds it you will not be prompted for password. Key will also be added to ssh-agent. On MacOS this will work on MacOS Sierra 10.12.2 or later. On Linux you can use something like gnome-keyring and it might work even without this last modification to SSH config. As for Windows - who knows, right?

I hope someone found this useful. Now go and configure your SSH config file!

Learn more about SSH:

• The ultimate guide to SSH keys
• A top-down introduction to SSH

All of which means that even if you wanted to go around logging into each of your many servers, it just wouldn't make sense. In most cases in fact, it wouldn't even be possible. Instead, you're going to be running a lot of clever scripts. And the tools you use to run those kinds of scripts are generally called orchestrators.

I'm sure you've encountered at least one or two members of the orchestration club. Besides Ansible, there's Terraform, Chef, Puppet and others. But there are also lower-level tools that work as add-ons to core Linux tools like SSH. Although, seeing how it'll run natively on Windows and, of course, macOS, I'm not sure it's quite correct to call SSH a "Linux" tool any more.

One of those SSH add-ons is a tool set called pssh - which stands for Parallel SSH. That's what we're going to be learning about in this article - which is excerpted from my new Pluralsight course, Linux System Optimization.

For now, though, I'm going to tell you a bit about the lab I'm using so that you can more easily reproduce it and follow along at home. I've got three Ubuntu LXD containers running. The base for all of our operations will be the one with an IP address of 10.0.3.140, while the two host nodes we'll be remotely provisioning will use 10.0.3.93 and 10.0.3.43.

Everything we'll do assumes that we've got passwordless SSH access from my base container to each of the two nodes. If you're not sure how to do that, you can view the SSH module of my Protocol Deep Dive: SSH and Telnet course on Pluralsight. If you're in a hurry, this Red Hat tutorial will get you to the same place.

Installing pssh on Ubuntu is simple and quick: sudo apt install pssh. It doesn't get any harder on CentOS.

I created a simple host inventory file called sshhosts.txt that contains nothing more than the IP addresses of my two nodes:

$ less sshhosts.txt
10.0.3.93
10.0.3.43

Now I'm going to run the pssh parallel-ssh command to execute a single command on my hosts.

$ parallel-ssh -i -h sshhosts.txt df -ht ext4

-i tells the program to run as interactive - otherwise we wouldn't be shown any command output. -h points to the hosts file that I called sshhosts.txt. And the command itself will be the old Unix utility df. That'll return a list of drives attached to the system along with their mount points and usage information. The -h here will display disk space in human readable units and the t will restrict access to only drives formatted as ext4.

Why do I care about that ext4 business? Because Ubuntu uses the snap package manager and each snap creates its own virtual device. So what? Well, I don't want to have to comb through a dozen or so virtual devices reporting 0 free space just to get to the real drives reporting actual usage.

$ parallel-ssh -i -h sshhosts.txt df -ht ext4
[1] 22:02:00 [SUCCESS] 10.0.3.43
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       457G  131G  304G  30% /
[2] 22:02:00 [SUCCESS] 10.0.3.93
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       457G  131G  304G  30% /

And there you go! Full disk space information about both of my nodes. I'm sure you noticed that the information is identical. That's because these are both containers running on my workstation, so as far as they know, they both have full access to my own drive.

For my next trick, I'll collect the /etc/group files from each of my nodes. This is the kind of operation that could be useful to quickly monitor the security status of your nodes. You could add a script that parses the incoming data and alerts you if there are any anomalies.

Before I begin, I'll create a directory locally called host-files. Then I'll use the parallel-slurp command - whose name wonderfully describes its function. Again, -h points to the hosts file. The -L sets the host-files directory as the target location for writing the data we're going to generate, /etc/group is the remote file we want to slurp up, and group is the name we'd like to assign the data locally.

mkdir host-files
parallel-slurp -h sshhosts.txt -L host-files/ /etc/group group

When it's done, your host-files directory will contain sub-directories named after the IP address of each of your nodes. As you can see, there's a file called "group" that contains the /etc/group data from each node.

$ tree host-files/
host-files/
├── 10.0.3.43
│   └── group
└── 10.0.3.93
    └── group

Does pssh come with any other treats? Yup. And running apropos gives you the whole list.

$ apropos parallel
parallel-nuke (1)    - parallel process kill program
parallel-rsync (1)   - parallel process kill program
parallel-scp (1)     - parallel process kill program
parallel-slurp (1)   - parallel process kill program
parallel-ssh (1)     - parallel ssh program

This article is based on content in my Pluralsight course, "Linux System Optimization." There's much more administration goodness in the form of books, courses, and articles available at bootstrap-it.com.

Well no more. Here's a quick guide to generate and configure an SSH key with GitHub so you never have to authenticate the old fashioned way again.

Check for an existing SSH key

First, check if you've already generated SSH keys for your machine. Open a terminal and enter the following command:

ls -al ~/.ssh

If you've already generated SSH keys, you should see output similar to this:

-rw-------  1 user_name user_name  1766 Jul  7  2018 id_rsa
-rw-r--r--  1 user_name user_name   414 Jul  7  2018 id_rsa.pub
-rw-------  1 user_name user_name 12892 Feb  5 18:39 known_hosts

If your keys already exist, skip ahead to the Copy your public SSH key section below.

If you don't see any output or that directory doesn't exist (you get a No such file or directory message), then run:

mkdir $HOME/.ssh

Then generate a new set of keys with:

ssh-keygen -t rsa -b 4096 -C your@email.com

Now check that your keys exist with the ls -al ~/.ssh command and ensure that the output is similar to the one listed above.

Note: SSH keys are always generated as a pair of public (id_rsa.pub) and private (id_rsa) keys. It's extremely important that you never reveal your private key, and only use your public key for things like GitHub authentication. You can read more about how SSH / RSA key pairs work here.

Add your SSH key to ssh-agent

ssh-agent is a program that starts when you log in and stores your private keys. For it to work properly, it needs to be running and have a copy of your private key.

First, make sure that ssh-agent is running with:

eval "$(ssh-agent -s)" # for Mac and Linux

or:

eval `ssh-agent -s`
ssh-agent -s # for Windows

Then, add your private key to ssh-agent with:

ssh-add ~/.ssh/id_rsa

Copy your public SSH key

Next, you need to copy your public SSH key to the clipboard.

For Linux or Mac, print the contents of your public key to the console with:

cat ~/.ssh/id_rsa.pub # Linux

Then highlight and copy the output.

Or for Windows, simply run:

clip < ~/.ssh/id_rsa.pub # Windows

Add your public SSH key to GitHub

Go to your GitHub settings page and click the "New SSH key" button:

Then give your key a recognizable title and paste in your public (id_rsa.pub) key:

Finally, test your authentication with:

ssh -T git@github.com

If you've followed all of these steps correctly, you should see this message:

Hi your_user_name! You've successfully authenticated, but GitHub does not provide shell access.

More info on SSH:

• Ultimate guide to SSH
• A top-down intro to SSH

Create a New SSH Key Pair

Open a terminal and run the following command:

ssh-keygen

You will see the following text:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):

Press enter to save your keys to the default /home/username/.ssh directory.

Then you'll be prompted to enter a password:

Enter passphrase (empty for no passphrase):

It's recommended to enter a password here for an extra layer of security. By setting a password, you could prevent unauthorized access to your servers and accounts if someone ever gets a hold of your private SSH key or your machine.

After entering and confirming your password, you'll see the following:

Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:/qRoWhRcIBTw0D4KpTUyK6YepyL6RQ2CQrtWsaicCb4 username@871e129f767b
The key's randomart image is:
+---[RSA 2048]----+
| .o=+....        |
|+.*o+o .         |
|+X.=o o          |
|@.=.oo .         |
|=O ...o S        |
|o.oo . .         |
|.E+ . . . .      |
|oo . ... +       |
|=.. .o. . .      |
+----[SHA256]-----+

You now have a public and private SSH key pair you can use to access remote servers and to handle authentication for command line programs like Git.

Manage Multiple SSH Keys

Though it's considered good practice to have only one public-private key pair per device, sometimes you need to use multiple keys or you have unorthodox key names. For example, you might be using one SSH key pair for working on your company's internal projects, but you might be using a different key for accessing a client's servers. On top of that, you might be using a different key pair for accessing your own private server.

Managing SSH keys can become cumbersome as soon as you need to use a second key. Traditionally, you would use ssh-add to store your keys to ssh-agent, typing in the password for each key. The problem is that you would need to do this every time you restart your computer, which can quickly become tedious.

A better solution is to automate adding keys, store passwords, and to specify which key to use when accessing certain servers.

SSH config

Enter SSH config, which is a per-user configuration file for SSH communication. Create a new file: ~/.ssh/config and open it for editing:

nano ~/.ssh/config

Managing Custom Named SSH key

The first thing we are going to solve using this config file is to avoid having to add custom-named SSH keys using ssh-add. Assuming your private SSH key is named ~/.ssh/id_rsa, add following to the config file:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes

Next, make sure that ~/.ssh/id_rsa is not in ssh-agent by opening another terminal and running the following command:

ssh-add -D

This command will remove all keys from currently active ssh-agent session.

Now if you try closing a GitHub repository, your config file will use the key at ~/.ssh/ida_rsa.

Here are some other useful configuration examples:

Host bitbucket-corporate
        HostName bitbucket.org
        User git
        IdentityFile ~/.ssh/id_rsa_corp
        IdentitiesOnly yes

Now you can use git clone git@bitbucket-corporate:company/project.git

Host bitbucket-personal
        HostName bitbucket.org
        User git
        IdentityFile ~/.ssh/id_rsa_personal
        IdentitiesOnly yes

Now you can use git clone git@bitbucket-personal:username/other-pi-project.git

Host myserver
        HostName ssh.username.com
        Port 1111
        IdentityFile ~/.ssh/id_rsa_personal
        IdentitiesOnly yes
        User username
        IdentitiesOnly yes

Now you can SSH into your server using ssh myserver. You no longer need to enter a port and username every time you SSH into your private server.

Password management

The last piece of the puzzle is managing passwords. It can get very tedious entering a password every time you initialize an SSH connection. To get around this, we can use the password management software that comes with macOS and various Linux distributions.

For this tutorial we will use macOS's Keychain Access program. Start by adding your key to the Keychain Access by passing -K option to the ssh-add command:

ssh-add -K ~/.ssh/id_rsa_whatever

Now you can see your SSH key in Keychain Access:

But if you remove the keys from ssh-agent with ssh-add -D or restart your computer, you will be prompted for password again when you try to use SSH. Turns out there's one more hoop to jump through. Open your SSH config file by running nano ~/.ssh/config and add the following:

Host *
  AddKeysToAgent yes
  UseKeychain yes

With that, whenever you run ssh it will look for keys in Keychain Access. If it finds one, you will no longer be prompted for a password. Keys will also automatically be added to ssh-agent every time you restart your machine.

Now that you know the basics of creating new SSH keys and managing multiple keys, go out and ssh to your heart's content!

This article will take a high-level and top-down approach to explain how SSH works and how it is used for securely communicating with remote computers.

We will look at how an SSH session is actually ‘secure’ and how computers establish and set-up an SSH session in the first place. We will also look at the benefits of using SSH.

Note: This is intended as future notes to myself, but I hope you learn something from it too!

_Photo by [Unsplash](https://unsplash.com/photos/pY_AZJfdbHQ?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Matt Artz on <a href="https://unsplash.com/search/photos/key?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

What is SSH?

SSH is short for ‘secure shell’. It is a protocol for sharing data between two computers over the internet.

A protocol is essentially a set of rules that define the language that computers can use to communicate.

Typically, the two computers involved are your computer (the ‘client’) and a remote server (the ‘host’).

Why do we care?

Secure communications between computers

Whenever two computers communicate over the internet we want to be sure that our messages can’t be intercepted and understood by anyone listening to the messages.

Imagine sending your bank details over the internet to buy something online. If your messages weren’t encrypted, then any computer that was listening or any computer that received the messages to pass onwards may be able to see your account number and your password. That isn’t good!

I believe this is an important concept to understand for anyone who aspires to work with web technologies.

Secure access to remote computers

Using SSH to check authentication is a more secure way of authentication than using a password. We will explore how this works below.

How is SSH secure?

SSH is a secure way of sending communications between two computers.

By ‘secure’, I mean a way of encoding the messages on a client computer such that the only other computer that can decode the messages and understand them is the host. This encoding/decoding is called encryption, so what we really mean here is SSH is secure because it uses an encrypted communication channel.

How is a SSH session established?

There are several processes that need to happen between two computers in order for an SSH session to begin.

1. First we need a way of setting up a secure method of exchanging messages between the computers. We need to set up an encrypted channel.
2. We need a way of checking that the data received by the host hasn’t been tampered with. This called verification and here we are verifying the integrity of the data that is sent by the client.
3. Verification (again). We need a way of checking that the computer we are communicating with isn’t an imposter. This is another form of verification but here we are verifying the identity of the computer.

After these three steps, we can now communicate securely with a remote computer.

After these steps, we can share ‘secret’ data securely and we can also check if a client has permission to access a host in a more secure way than using a password. This process is called authentication using asymmetric encryption.

Each of these sections below will go into more detail on these steps.

Setting up an encrypted channel

A core part of the SSH protocol is that is it secure (it is in even in the name!), meaning all information that is sent using SSH is encrypted.

How does this information get encrypted?

Encrypting essentially just means ‘jumbling up the letters’ using some clever maths. Both computers need to have a way of encrypting the information so that only the other computer can decrypt the information and understand it.

How does this work?

Both computers have an identical version of a symmetric key. The symmetric key is just a string of letters stored somewhere on the computers. The computers can use the symmetric keys to encrypt and also decrypt messages sent to them.

Using this symmetric key approach is called symmetric encryption. The ‘symmetric’ part comes from the fact the symmetric key on each computer is identical. This approach works really well … but it only works as long as no other computers have access to the symmetric key.

A problem

How do both computers know what the symmetric key is?

One computer could create it and send it in a message over the internet. But the messages wouldn’t be encrypted yet, so anyone intercepting the messages would instantly have the symmetric key … and can decrypt all future communications. That’s bad!

This is sometimes called the ‘key-exchange’ problem. It is clear that we need to add another step in the process before we can use symmetric keys.

A solution

A solution to the ‘key-exchange’ problem above is that both computers share some public information with each other (it is ‘public’ meaning they don’t mind if anyone intercepts it) and combine this with some information on their own computer to independently create identical symmetric keys.

These symmetric keys can then be used in symmetric encryption in the way outlined above.

How this works

Both computers each have their own private key and public key. Together they form a key-pair. The computers share their public keys with each other over the internet. So, at this point in the process each computer knows

• its own private key,
• its own public key,
• and the other computer’s public key.

Generating Symmetric Keys

Both computers then use these 3 pieces of information to independently generate an identical symmetric key.

Each computer uses a mathematical algorithm which uses the 3 inputs mentioned above. This algorithm is part of the Diffie-Hellman key exchange algorithm. The algorithm that will be executed on each computer is something like this:

Host
pub_2 = other computer's public key
pub_1 = my public key
pri_1 = my private key

f(pub_2, pub_1, pri_1) = abcdefg // Symmetric Key

Client:
f(pub_1, pub_2, pri_2) = abcdefg // Symmetric Key

The important thing to take away here is that computers have shared only public information over the internet but have still been able to create symmetric keys!

The approach of using key-pairs and sharing public information to generate identical symmetric keys is called asymmetric encryption. It is called ‘asymmetric’ because both computers start off with their own, different, key pairs.

So far: we have seen how to use asymmetric encryption to independently generate identical symmetric keys on both computers in a secure way (solving the key-exchange problem) and then securely exchange information between computers using symmetric keys for encryption and decryption.

Verification

So we can communicate securely. But the next part of the process of establishing an SSH session is to verify that the data hasn’t been tampered with as it has been transmitted and that the other computer is actually who it is says it is.

Why do we need this?

Another computer could impersonate one of the computers and initiate the key exchange above. So how do we securely figure out that the message is actually from the other computer and not from an imposter?

Hashing

We have to use a hash function. This is just a mathematical function that takes inputs and produces a string of a fixed size.

The important feature of this function is that it is virtually impossible to work out what the inputs were just using the outputs.

After a client and a host have generated their symmetric keys, the client will use a hashing function to generate a HMAC. This just stands for “hash-based message authentication code”. This is just another string of characters/numbers. The client will send this HMAC to the server for verification.

The ingredients to the hashing function are

• The symmetric key on the client
• The package sequence number (each message that is sent is contained in a ‘package’ of information)
• The (encrypted!!!) message contents

An example with fake data:

symm_key       = abcdefg
pkge_no        = 13
encr_message   = encrypted_password

Hash(symm_key, pkge_no, encr_message) = *HMAC* // Hashed value

How does the host use this information?

When the host receives the HMAC, it can use the same hash function with these three ingredients:

• its own copy of the (identical!) symmetric key,
• the package sequence number,
• and the encrypted message.

If the hashed value it computes is the same as the HMAC it received from the client, then we have verified that the connecting computer is the same as the computer who has the symmetric key.

Remember that only the host and client know what the symmetric key is and no other computers do!

So here it doesn’t matter that the host doesn’t know the decoded contents of the encrypted message —the host has still verified the identity of the connecting computer!

The beauty of this approach is that we have not just verified the identity of the client and made sure that the data hasn’t been tampered, but we have done so securely (without without sharing any private information).

Summary: we used a hash function on the client and then on the host to verify data integrity and verify the identity of the client.

Authentication

The final part of the securely communicating with remote computers is:

even if we have generated symmetric keys with the connecting computer and

even if we are using the symmetric keys to communicate securely and

even if the connecting computer is genuinely the client we expect and not an imposter,

then we have set up an SSH session … but does the connecting computer have permission to access the contents of the host?

This is called ‘authentication’: the act of checking permissions and access rights.

There are two ways of checking authentication:

1—Using a password

The client can send the host an (encrypted) message containing a password. The host can decrypt the message and check the password in a database to check if the client has permission to access the specified ‘user’ (area of the computer). Job done.

2 — Using key-pairs and asymmetric encryption

Earlier, we saw how asymmetric encryption can use two key-pairs to securely generate identical symmetric keys on both the client and the host. Using similar ideas, the client can log in without a password.

This is a very high-level approach to the how the process works:

Setting up:

On the client, head to the terminal and use a command to generate a public key and a private key (under the surface it uses ‘RSA’, a mathematical algorithm) on the client. Copy the public key (NOT the private key!) to the clipboard.

I repeat: Copy the PUBLIC key (NOT THE PRIVATE KEY!) to the clipboard.

Then, in the terminal on the client, use a password to remotely log in to the host. Paste the public key of the client into the appropriate folder on the host alongside any other public keys.

Now, the host has

• It’s own public/private key-pair
• The public key of the client

Looking at the section above on the key-exchange algorithm, you can see how the host has all the ingredients it needs to generate a symmetric key!

Challenging:

When the client wants to connect, the host can use issue a ‘challenge’ by sending a message that has been encrypted (with the host’s symmetric key) and say: ‘I will only authorise you access if you can decrypt this message!’.

The client then has

• its own public and private key
• the public key of the host
• the encrypted message

So now the client has everything needed to generate an (identical) symmetric key … and decrypt the message! It can decrypt the message and send confirmation that is has ‘succeeded’ in the challenge back to the host.

The host is satisfied that the connecting client is authorised and grants permission for access.

Why bother using the second approach?

This is seen as more secure than simply using a password because a bot can use a ‘brute force’ approach to keep using lots of combinations to guess your password, but they will not have they right key-pairs for the second approach to work.

Further reading:

SSH Tutorial for Beginners - How Does SSH Work
_SSH, or Secure Shell, is a remote administration protocol that allows users to control and modify their remote servers…_www.hostinger.com

https://www.udemy.com/the-complete-junior-to-senior-web-developer-roadmap/

Conclusion

SSH is an important tool used to remotely control other computers.

SSH is secure because both computers can encrypt and decrypt message using identical symmetric keys (known as ‘symmetric encryption’).

The main steps to initiate an SSH session are:

1. Setting up an encrypted channel. Using asymmetric encryption to solve the key-exchange problem which independently generates identical symmetric keys on both computers without sharing any private information.
2. Verification: Using hashing on both computers to verify the identity of the connecting computer
3. Verification (again). Using hashing on both computers to verify data integrity hasn’t been compromised in transmission.

We can then use SSH to securely send data between the computers. One important use case of this is for authentication. Although you can use a password, using asymmetric encryption to check the connecting ‘client’ has permission to access the ‘host’ is is seen as more secure.

If you are interested in leveling up your SSH, I seriously recommend this course. I found it really useful to sharpen up some of my skills! (disclaimer: I have no links or ties to the author or the platform. I took the course a while ago and found it really good!)

Thanks for reading!

Google Cloud offers many tools and services. One of these services is creating highly customizable virtual machines. If you are not familiar with what a virtual machine is, here is a definition from Microsoft:

A virtual machine is a computer file, typically called an image, that behaves like an actual computer. In other words, creating a computer within a computer. It runs in a window, much like any other program, giving the end user the same experience on a virtual machine as they would have on the host operating system itself. The virtual machine is sandboxed from the rest of the system, meaning that the software inside a virtual machine can’t escape or tamper with the computer itself.

Virtual machines are needed in many situations to test applications against other operating systems, to access virus-infected data, or to experiment with other operating systems. You can install virtual machines on your computer. You can also create them in the cloud and simply connect to them.

In this tutorial, I will walk you through how to create a virtual machine in Google Cloud. We can connect to it with SSH from your computer.

1. If you don’t have one already, create a Google Cloud account from here.

You will get $300 credit to play around with for a year! It is more than enough to learn and play with everything Google Cloud offers.

2. Create a new project or use an existing one. You can create a new project called project1, for example, as in the following gif:

3. Now you are set to create a virtual machine. Go to the top left corner of your Google Cloud home page, click on the triple bar icon ≡ and select Compute Engine ->VM instance and click Create.

Enter whatever name you want in the Name field as shown below:

Keep the default region and zone. Any region/zone will do for this tutorial. If you are curious about what they mean, you can read Google Cloud’s documentation about them here.

You can keep default machine type or click Customize to select the number of CPU cores, memory, and GPUs you would like your virtual machine to have. You will see the cost on the right side changes!

For your first experiments with Google Cloud, you can be conservative with the $300 credit for some actual work. In such a case, you can choose the following configuration:

Next choose a boot disk. For example, you can choose 20 GB, SSD, Ubuntu 16.04 LTS as shown below:

Then set the Service Account under Identity and API access to No service account as shown below:

Finally, go to the Security tab under Firewall. You will see an SSH Key field as shown below:

This where you are going to connect your computer to the virtual machine using your SSH Key!

If you are not familiar with SSH (Secure Shell) and why you may want to use it, it is a network protocol that provides encrypted data communication between two computers (your computer and Google’s servers, in this case) which are connected over an insecure network (the Internet here).

To establish an SSH connection, you may need an application that can do that, depending on your operating system. Follow the rest of this post depending on your operating system (Windows or Mac/Linux).

Windows

I recommend PuTTY. It is an open-source and easy to use SSH client. You can download PuTTY and install it from here.

After installing PuTTY, open PuTTY Key Generator and click create. It will generate a random key by you moving the mouse over the blank area. After it is done, you will get something like this:

Change the key comment field to something recognizable and easy to type, as this will become a user name later!

Then save both the public and private keys by clicking the corresponding icons shown in the picture above.

Highlight the whole Key field from the PuTTY Key Generator, and copy and paste it in the key data field in Google Cloud:

Click create and wait for the virtual machine instance to be created.

In the meantime, you can go to PuTTY. Go to SSH ->Auth and browse for the private key file that you saved.

Next, go to Google Cloud and copy the external IP from the virtual machine instance that you just created as shown below:

And paste it on the Host field under Sessions in PuTTY and hit Enter:

Note: you might get an error message. Ignore it and click yes. (It just says the key is not already in the registry. Are you sure you want to connect?)

Then enter the username you created when generating the key (key comment above). Boom! you are in the virtual machine that you just created.

You can install python and Google APIs on it, for example, to start making some magic! Don’t forget to shut it down in Google Cloud after you are done to be economic with your credit :)

Mac/Linux

Mac and Linux support SSH connection natively. You just need to generate an SSH key pair (public key/private key) to connect securely to the virtual machine.

The private key is equivalent to a password. Thus, it is kept private, residing on your computer, and should not be shared with any entity. The public key is shared with the computer or server to which you want to establish the connection. To generate the SSH key pair to connect securely to the virtual machine, follow these steps:

Enter the following command in Terminal: ssh-keygen -t rsa . It will start the key generation process. You will be prompted to choose the location to store the SSH key pair. Press ENTER to accept the default location as shown below:

Next, choose a password for your login to the virtual machine or hit ENTER if you wish not to use a password. The private key (i.e. identification) and the public key will be generated as shown below:

Now run the following command: cat ~/.ssh/id_rsa.pub . It will display the public key in the terminal as shown below. Highlight and copy this key:

and paste it in the SSH key field in Google Cloud and hit Create:

Now you can use the External IP of the virtual machine you just created:

to ssh to it as follows:

You will get “The authenticity of host…etc.” warning as shown in the picture below. This is normal. Whenever SSH connects to a system it hasn’t seen before, it will generate a warning like this. Reply yes to connect, and bingo! You are in the virtual machine, as you can see from host name instance-3. To exit the virtual machine, just type exit.

Don’t forget to shut the virtual machine in Google Cloud after you are done to save that $300 credit!

Originally published at assawiel.com/blog on December 23, 2017. Updated: Oct 10, 2018