SSH Mastery: OpenSSH, PuTTY, Tunnels and Keys (IT Mastery)

Welcome back to the deep dive. So today we're tackling secure shell SSH. If you're managing systems remotely, you're definitely using it, probably open ssh.

Yeah, it's pretty much the standard for anything you and I X like. But you know, the source material we look at makes a great point, which is that most people well they only really scratch the surface, just the bare minimum functionality, right, and.

There's so much more, especially around you know, doing it securely. That's what we want to unlock today.

Absolutely true mastery means understanding the security underneath it all.

So our mission for you today, we're going to break down the core architecture, try to demystify some of that crypto stuff.

Which you can seem pretty intimidating.

Yeah, definitely, and we'll get into the configurations, the files you need to know and critically that one habit the single most important thing you can do to protect yourself from well the most common network attack.

It's a big one. But maybe a little history first, just.

Quickly, good idea, Yeah, where did SSH come from?

Okay, so back in nineteen ninety five, Tattoo Yelenen He created it basically because the tools people were using them telnet rsh are log in.

Oh those were bad sending passwords in the clear.

He totally insecured, just asking for trouble. SSH was built specifically to create an encrypted, trustworthy channel between two machines over a network.

And the version everyone uses now open ssh.

That came out of the OPENBSK project, and those folks have a serious reputation for writing secure code. It's kind of their thing.

Okay, solid foundation. Then let's dive into the protocol itself. The main pieces.

Pretty straightforward really. You've got the server side, usually a program called slewy that's listening for connections.

And then the client side like the slush command on Linux or.

Mac os exactly, or you know pewdy if you're on Windows. Microsoft even has its own native client now though I think it's still experimental.

Right, But now the first big warning sign protocol versions SSH one versus SSH two.

Ah, yes, this is non negotiable.

What's the rule?

Always always use SSH two, period full stop?

Okay, always SSH two? But why? I mean obviously SSH one is older? But how bad is it? Really? What's the risk If say, a server is still consigured to allow.

It, it's incredibly dangerous. The source material literally says it's barely more secure than unencrypted telnet.

Wow, okay, yeah.

It's not just old. It has fundamental flaws from its nineteen nineties design, weak key exchange, vulnerable to session hijacking.

So an attacker could actually get into an active session.

They could. They can potentially grab log in credentials, decrypt your data as it flies by, and maybe the scariest part, they can inject their own text fuck commands militia shell command think rmrf something catastrophic and sorted right into what you thought was a secure.

Session, got terrifying, a total system white command slipped in.

It's the nightmare scenario. And the real danger is how the connection gets set up. The client and server negotiate the version. If either one is willing to speak as one, even if they prefer SSH.

Two, an attacker can force it down.

Exactly a downgrade attack during that initial handshakee. It exploits that tolerance. Thankfully open ssh itself. It ripped out SSH one support completely some time ago.

Good, so it forces you onto the modern secure standard. Right.

SSH two has been continuously improved, flaws found and fixed. It's where you need to be.

Okay, So ssh two it is. Now, let's get into how SSH two actually protects the data, the cryptography, encryption keys, the core ideas.

Right, So encryption is basically scrambling turning readable stuff plaintext into unreadable ciphertext. You need an algorithm like a mathematical recipe and a.

Key, and open ssh handles the keys, right. It doesn't let users pick their own password for the encryption itself.

Correct. And that's a deliberate security choice because humans we are terrible at choosing strong random keys. We pick birthdays, pet names, predictable stuff exactly. So open ssh generates the strong cryptographic keys needed. It takes that responsibility away from the user, which is a good thing here.

You know the algorithms, there are two main types, right, symmetric and asymmetric. Maybe we can use those analogies from the source.

Yeah, they're helpful. Symmetric is like think of a simple kids substitution cipher ABBC, that kind of thing. You use the same key to lock it, encrypt and unlock it. Decrypt algorithms like as or symmetric they're very fast, very efficient. So the catches, how do you securely share that single key? If I want to talk to your server. How do I get that secret key over to you without someone else grabbing it on the way. That's the challenge, right.

Which brings us to asymmetric public key crypto.

Yep. This uses two keys mathematically linked. A public key you can share with anyone, like putting it on a website, and a private key you guard with your life.

So I could use your public key to encrypt a message and only.

My private key can decrypt it. It's very secure for establishing identity and sharing secrets.

But you said symmetric was fast. Is asymmetric slow?

Much slow? It's computationally intensive. Doing all the encryption and decryption for an entire SSAF session using just asymmetric keys, it would be painfully slow, unusable.

Really? Ah okay? So SSH does something clever.

A mix exactly, a hybrid approach. This is the genius part. When you first connect the client and server use the server's public key, that's the slow but secure asymmetric part, just long enough to securely negotiate a brand new temporary symmetric.

Key, the key just for this one session, just for this session.

Once they've both agreed on that shared secret symmetric key, they switch all the rest of the communication, all the commands you type, the file transfers, that's all encrypted using the fast symmetric key.

The best of both worlds, secure key exchange then fast encryption.

Precisely speed and security.

Okay, that makes sense, but people love the tinker. We see admins sometimes trying to change the default crypto settings, maybe choosing different algorithms, thinking they'll get more speeded. What's the advice there.

Simple, don't do it. Just leave the defaults alone.

Really, why not?

Because the open ssh developers, they are deep cryptography experts. They chose those defaults, the specific algorithms, the order of preference, for very good security reasons. They understand the attacks, the weaknesses, and if I change it, you're basically saying you know better than them. You might accidentally enable an older weak or SOFA, or make yourself vulnerable to like a timing attack, or enable a downgrade attack you didn't intend.

So chasing a tiny speed boost could wreck the actual security.

Completely undermines the whole point of using Ssh in the first place. Stick with the defaults unless you have an extremely specific, expert validated reason to change something.

Security first, okay, message re seat, leave the crypto engine alone.

Let's talk configuration files. Then, where do all these settings actually live? On a typical system.

Right on most Unix like systems, you'll look in the etceters directory. That's system wide stuff inside there. The service configuration is in a file called ship config that controls how the SSH server behaves.

Okay, shits config for the server. What about the client? If I'm connecting out.

There's a system wide client config two usually its setters can fig But more importantly for you as a user, you have your own personal config file in your home directory. It's home dot shish config and that.

One overrides the system defaults exactly. Let's you set up custom settings, aliases for hosts, specific keys to use for certain connections. Very handy.

The syntax looked pretty simple in the source material, like keyword value so port twenty two or something.

Yeah, it's generally straightforward, and a really nice touch is that the default config files often have lots of options already listed, but they're commented out with the hash sign hashtag.

Ah, so they service documentation pretty much.

You can see what's possible, uncomment the line and change the value if you need to. But there's a really powerful feature in the servers config stip canfig that we should highlight what's the match keyword? This thing is amazing for flexible security.

Match How does it work?

It lets you apply specific configuration lines only if certain conditions are met, like only for a particular user, or only for connections coming from a specific IP address range, or only for members of a certain group.

Well, that sounds useful. Give me an example.

Okay, Let's say you want to disable x eleven forwarding. That's running graphical apps over SSH for everyone by.

Default security best practice, right right, So you'd put x eleven forwarding no somewhere near the top exactly.

But then maybe your system administrators, the people in the wheel group actually need that ability sometimes, so at the very end of the config file, match blocks always have to go. At the end, you'd add something like match group wheel on one line and indented on the next line x eleven forwarding.

Yes. Ah, so it creates an exception just for.

That group precisely script default then target it overrides based on user, group, IP address host. Incredibly flexible for setting up fine grained security policies.

That's really powerful. Okay, speaking of powerful settings, you mentioned one earlier when we talked about moving away from insecure practices. The password setting.

Yes, this ties into the whole security deposture. Once you're set up with user keys, which we'll touch on at the end. The absolute next step is to go into your shit canfig and set password authentication no.

Turn off passwords completely completely.

Don't even let the server offer password log in as an option. This shuts down brute forests password guessing attacks cold. It's probably the single biggest hardening step you can take on the server side. After ensuring SSH one.

Is off, okay, makes sense, disable the weaklink. So we've covered the right version SSH two, the crypto basics hybrid approach that can fig files, fig choes, can fig match, and turning off passwords. Now the big one, the single most vital security habit you.

Mentioned this is it host key verification. This directly tackles the man in the.

Middle attack that attack again briefly.

Okay, imagine you're trying to connect to your server server dot example dot com. A bad guy manages to intercept your network traffic. They pretend to be server dot example dot com.

So my SSH client connects to the attacker instead of the real server.

Exactly, and if you then type your password. Well, you've just given it to the attacker. They can log your credentials, maybe pass your connection onto the real server so you don't notice immediately it's bad. How does SSH stop this with the server's host keys, Remember the asymmetric keys. Every SSH server has its own unique public private key pair, often generated when SSH is first installed. Okay, the attacker can pretend to be your server, but they cannot have

Right, because those keys are huge. I don't type in a public key.

No, you don't. When your SSH client connects to a server for the very first time, the server presents its public key. Your client then calculates a shorter, more manageable summary of that key. That's the fingerprint, like.

SA two two five six hash or something similar.

Usually yeah, something like SUG two five six. These days, it's maybe forty or fifty characters, almost human readable, as the source puts it, still random looking, but much shorter.

Than the full key and what am I supposed to do with this fingerprint?

This is the crucial habit. You need to verify it. Your assissedmin or the service provider should give you a list of the correct fingerprints for their servers, maybe on a secure internal website or in documentation. You manually compare the fingerprint your client shows you with the known good one, and if they match, you tell your client, yes, this

It remembers it. So what happens next time I connect?

Next time? The client already knows what key to expect from ser example dot com. If the server presents the same key again, the connection just happens transparently, no pumps.

What if it's different? What if the server I connect to next time presents a key that doesn't match the one stored in known hosts.

Ah, Now that is the red flag. Your open ssh client will immediately halt the connection and it will print a very loud, very scary looking warning the.

All caps one.

Yeah, the source called it scary looking stuff, something like at warning remote host identification has changed at warn followed by paragraphs explaining the potential danger of a man in the middle attack, and it will refuse to connect.

Okay, So the key takeaway for everyone listening. If you see that massive, scary warning.

Stop, p absolutely stop. Do not under any circumstances, just bypass the warning and connect anyway.

Why not? What does that warning mean?

It means one of two things. Possibility one, it's legitimate the sissedmin rebuilt the server or intentionally generated new keys for some reason. You need to contact them, get the new correct fingerprint, remove the old key from your known host file, and then connect and.

Verify the new key, and possibility too.

Possibility two is that you are under attack. Someone is trying to impersonate your server. If you ignore that warning and type your password or use your key, you're giving your credentials directly to the attacker.

So that warning is your lifeline. You must investigate why the key change before proceeding.

It's the absolute cornerstone of SSH's defense against MITM. Respect the warning, verify the key always.

Fantastic summary. Okay, so we've covered a lot. SSH two is mandatory. We understand the hybrid crypto making it fast and secure. We know where the config files are and how to use match for flexibility, and we absolutely understand the critical importance of host key verification.

That nails the core security and transit and server setup.

But it leaves us with one final thought. We secured the connection, but what about the log in itself?

The authentication right We mentioned turning off passwords, and there's a big reason our source material talks about these hail Mary clouds or those massive botnets, huge networks of compromised computers all over the world, constantly scanning the Internet, hammering SSAH servers. They just try common user names, route admin user and common passwords, dictionary words, leaked password.

Lists, just throwing everything at the wall hoping something sticks.

Exactly. It's relentless. Blocking individual IP addresses is pointless. The attack comes from everywhere. If you rely solely on passwords, eventually one might get guessed, especially if it's not super complex.

So passwords, even complex ones, are still a major risk vector just because of this constant automated assault.

They really are, which leads to the ultimate path for well true SSH mastery and convenience, which is ditching passwords entirely for login and moving to user keys combined with the SSAH agent.

Okay, user keys are like host keys, but for me, the user a public private pair.

Exactly. You general at your own key pair. You put the public key on the servers you need to access in your doutch authorized keys file. There you keep the private key safe on your local machine.

But private keys need protection too.

Write a passphrase, yes, and it should be a long, strong passphrase, much stronger than a typical login password. But here's the magic, the SSAH agent.

What does the agent do.

It's a small background program running on your local machine. When you start your work session, you add your private key to the agent. It asks for your long strong passphrase once, just.

Once per session, like once per day when I start.

Work typically Yeah. Once you unlock the key and load it into the agent's memory, the agent handles authentication for all subsequent SSH connections without asking you for the passphrase again.

Ah, so I type my super strong passphrase once in the morning like in slush, into ten different servers throughout the day without typing any passwords or passphrases at all.

Exactly. It completely defeats the brute force password attacks because password authentication is off and it makes your life incredibly convenient because, as you only authenticate once per session to the agent, high security meets high convenience. That's the goal.

User keys plus the SSAH agent the path to true SSH mastery. Excellent place to leave it