Menu

Secure Shell (SSH)

file_transfer_pfp

(SSH): Transferring files from client to server

0

If you’re a developer using both Windows and Mac or you want to create you own space, securely transferring files and setting up passwordless SSH login can make your life easier. In this post, I’ll walk through how to make your Mac a remote SSH server and use Windows as a client to:

  • Access the Mac via SSH
  • Transfer files securely using scp
  • Set up SSH key authentication with ED25519

ssh_file_transfer

Before we dive into file transfers or SSH keys, let’s first set up our two systems to communicate over SSH.

In this guide, we’ll:

  • Use Mac as the SSH server
  • Use Windows as the SSH client

This means our Mac will accept incoming SSH connections, and our Windows machine will connect to it — either to log in or transfer files.

Step 1: Make Your Mac an SSH Server

Your Mac has a built-in SSH server. Here’s how to enable it:

  1. Go to System Settings → General → Sharing
  2. Turn on Remote Login

Step 2: Get Your Mac’s IP Address

Open Terminal on Mac and run:

    ipconfig getifaddr en0

(For Ethernet, use en1)

Step 3: Transfer a File Using scp

Now that the Mac is ready to accept connections, let’s transfer a file.

What is scp?

scp (Secure Copy) lets you send files over a network securely using SSH. It uses TCP and encrypts the data in transit.

From PowerShell on Windows, run:

    scp C:\Users\YourName\Desktop\file.txt remote_user@remotemachine:/Users/YourName/Desktop/

For example:

    scp C:\Users\YourName\Desktop\file.txt vignesh@192.168.1.10:/Users/vignesh/Desktop/

This command copies file.txt from your Windows Desktop to your Mac Desktop.

You’ll be prompted for your Mac login password. That’s normal for now!

Step 4: Set Up SSH Key Authentication (To Skip Passwords)

Entering your password every time can get annoying. Let’s fix that by setting up SSH keys.

Generate an SSH Key on Windows

Run this in PowerShell:

    ssh-keygen -t ed25519
  • Press Enter to save in the default location.
  • You can skip the passphrase or set one for added security.

Your keys will be saved in:

    C:\Users\YourName\.ssh\

Send Your Public Key to the Mac

Now copy the public key (id_ed25519.pub) to your Mac:

Add the Key to authorized_keys on Mac

SSH into your Mac:

    ssh vignesh@192.168.1.10

 

remote_user: vignesh

remote_machine: 192.168.1.10

Then on the Mac terminal:

    mkdir -p ~/.ssh
cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh
rm ~/id_ed25519.pub

This installs the key and sets the correct permissions.

Final Test: Try SSH Again

Back in PowerShell:

    ssh vignesh@192.168.1.10

You should now log in without a password prompt.

Quick Tech Note: Is scp using TCP?

Yes — both scp and ssh use TCP on port 22. TCP ensures that:

  • Packets are delivered reliably

  • Data arrives in the correct order

  • The connection is encrypted via SSH

To know more about how SSH works and what Packets are. Checkout my blogs below!!

ssh_keys

SSH Keys with Git

0

Using username-passwords for Git authentication used to be common, but from a security standpoint, it’s far from ideal as they are easy to hack if targeted, inconvenient among developers as you need to authenticate every time & deprecated by Git hosting platforms

Instead, platforms transitioned to SSH Keys and Personal Access Tokens (PATs) for secure authentication.

Why SSH Keys?

SSH keys provide stronger security, eliminate the need to repeatedly enter credentials, and are widely used among developers and organizations.

How Do SSH Keys Provide Stronger Security?

SSH keys use asymmetric encryption algorithms, such as Ed25519, RSA and other algorithms to establish secure authentication. Unlike passwords, which can be easily compromised through brute force attacks or phishing, SSH keys are significantly harder to crack due to their cryptographic strength:

  • Ed25519: Uses the Edwards-curve Digital Signature Algorithm (EdDSA) for enhanced security, optimized for speed and smaller key sizes.
  • RSA (2048-bit or higher): A widely used public-key encryption system, though it requires larger key sizes (e.g., 3072-bit or 4096-bit) to maintain security.

By leveraging these cryptographic algorithms, SSH authentication ensures secure communication between the client and server, preventing unauthorized access.

Cryptography is the practice of securing information by converting it into an unreadable format using mathematical algorithms, ensuring confidentiality, integrity, and authentication.

SSH keys work in pairs:

  • Private Key (id_ed25519) → Keep it secret! Never share it.
  • Public Key (id_ed25519.pub) → Safe to share, uploaded to the Git server.

If someone gets your private key, they have full access to your GitHub account

  • The private key remains on your system.
  • The public key is uploaded to the Git server.

Behind the scenes

When you push or pull from your Git repository using SSH, this is what happens behind

  1. Your computer(client) uses SSH to request authentication to the remote server
  2. The remote server(Git) now checks if it has your corresponding public key
  3. If the public key is found, the server generates a random challenge, encrypts it with the public key, and sends it back
  4. Now, your computer(client) tries to decrypt the puzzle using the private key and sends the proof back
  5. If the decryption is successful, you gain access to the server to do your changes

💡 Only your private key can decrypt the puzzle of public key

SSH_keys

 

Why Use Ed25519 Instead of RSA?

Modern SSH implementations recommend Ed25519 over RSA because they are more secure, fast & smaller key size (256-bit Ed25519 ≈ 3000-bit RSA)

Setting Up SSH for GitHub

1. Generate SSH key (if not already done): 

    ssh-keygen -t ed25519 -C "your_email@example.com"

 

2. Copy the public key to your clipboard:

    cat ~/.ssh/id_ed25519.pub

 

3. Add the key to GitHub:

    • Go to GitHub → Settings → SSH and GPG keys → New SSH Key
    • Paste your public key and save

4. Test the connection:

    ssh -T git@github.com

 

If successful, you’ll see:

    Hi username! You've successfully authenticated.

 

Conclusion

SSH authentication is not just limited to Git; it is widely used in remote server access (SSH login), cloud computing (AWS, Google Cloud), CI/CD pipelines, and secure file transfers (SCP, SFTP).

I hope I have explained well how SSH keys work by using Git as an example.

Sign up to my weekly newsletter

whats_ssh

What’s secure shell (SSH)

0

“A bit of history is good for Impressing your friends at lunch!”

Telnet was one of the earliest communication protocols existed to communicate between your host machine(the client) and remote servers. In the early days, communication mostly happened within closed networks like universities or research campuses, where administrators could control security. This worked fine when the networks were private, but as the internet grew, so did the need for security!

protocols – set of rules to be followed to achieve something

In those early days, any information sent from your host machine(the client) to a remote server was transmitted in plaintext, meaning that the data could be easily read by anyone with access to the network. As the internet expanded and more communication started happening over public networks, it became increasingly risky. Bad guys/girls could intercept and read your data with a tool called a packet sniffer, which is definitely not a good thing.

Telnet

The Birth of SSH

In 1995, Tatu Ylönen, a Finnish researcher, was facing a serious security problem—a password sniffing attack. To overcome this, he realized that encryption could provide a solution. By using encryption, he discovered a secure connection can be made and protect his sensitive data while it was in transit. This led to the creation of SSH (Secure Shell)

 

 SSH

Think of SSH as the “secure tunnel” for communication between two systems. When you connect to a remote server using SSH, all data transmitted between your computer (the client) and the server is encrypted, ensuring that even if someone intercepts the data, they won’t be able to read or manipulate it.

Any data you send or receive over SSH will be converted into small pieces called packets.

What’s in a packet?

When you initiate an SSH connection to another machine, the first thing that happens is the establishment of a TCP connection. Once the connection is up, SSH breaks down the data into small units called packets.

It’s up to the client to choose the communication medium—the default is TCP, but SSH can also use other methods such as UDP, serial connections, or even VPNs.

Think of SSH as a bus that securely transports data, but it needs a road to travel on. This is where TCP comes in—it’s the “road” that provides the pathway for SSH to deliver the data securely.

Each packet is not just a chunk of data; it carries essential information to ensure it reaches the correct destination safely. You can think of each packet like a sealed envelope containing the data, but also with extra details about where it’s going and how to get there.

Packet Size – The total size of the packet, including all parts (4 bytes)

Padding Length – A small value that tells how much padding is added at the end (1 byte)

Payload (actual data) – The main content being sent/received like text, images, commands

Padding – Extra random data added to make all packets the same size, improving security and preventing attackers from guessing what’s inside

Message Authentication Code – A security check to ensure the packet hasn’t been tampered with while traveling. It’s like a digital fingerprint to verify authenticity

 

packets

 

The Padding Length and Padding Data are random bytes added to the packet to ensure that every packet is the same size. This makes it harder for attackers to determine the contents of the packet, as the padding creates uniformity and adds randomness. It’s like adding “fake” content to a message to disguise its true size and nature, helping to protect the data from being easily identified or tampered with.

Encryption and Decryption of Packets

When the data is ready to be sent, the entire packet (excluding the packet size and MAC) gets encrypted using a chosen encryption algorithm. The encryption and MAC algorithms are selected by the client and server at the beginning of the SSH session. These choices determine how the data will be scrambled to ensure privacy and integrity.

At the receiver’s end, the server or client decrypts the packet, checks the MAC to ensure it’s intact, and then reads the payload. This process happens for all the packets exchanged during the session.

Why Are Some Parts of the Packet Left Unencrypted?

You might be wondering why the packet length and MAC are left unencrypted. The reason is that TCP (which is used for the transmission) needs to know the size of each packet to properly route it. The MAC is also needed to check the authenticity and integrity of the packet, ensuring that it hasn’t been tampered with during transit.

So, while the payload (the actual data) is encrypted to protect it, the packet length and MAC are left intact to allow the system to ensure everything is in order and hasn’t been altered.

Final Thoughts

In a world where data can be intercepted and tampered with, SSH provides a much-needed solution for secure communication. By using encryption and carefully structured packets, SSH ensures that your data stays private and untampered with—even when transmitted over insecure public networks.

SSH is an essential tool for anyone who needs to remotely access systems or transfer sensitive data across networks. It’s the secure tunnel that keeps your digital life safe.

In the next posts, I’ll dive deeper into how SSH is used with Git, Remote server management, tunneling & multiplexing

Sign up to my weekly newsletter