Speaker 1: Welcome back to the deep dive. So today we're tackling
Speaker 1: secure shell SSH. If you're managing systems remotely, you're definitely
Speaker 1: using it, probably open ssh.
Speaker 2: Yeah, it's pretty much the standard for anything you and
Speaker 2: I X like. But you know, the source material we
Speaker 2: look at makes a great point, which is that most
Speaker 2: people well they only really scratch the surface, just the
Speaker 2: bare minimum functionality, right, and.
Speaker 1: There's so much more, especially around you know, doing it securely.
Speaker 1: That's what we want to unlock today.
Speaker 2: Absolutely true mastery means understanding the security underneath it all.
Speaker 1: So our mission for you today, we're going to break
Speaker 1: down the core architecture, try to demystify some of that
Speaker 1: crypto stuff.
Speaker 2: Which you can seem pretty intimidating.
Speaker 1: Yeah, definitely, and we'll get into the configurations, the files
Speaker 1: you need to know and critically that one habit the
Speaker 1: single most important thing you can do to protect yourself
Speaker 1: from well the most common network attack.
Speaker 2: It's a big one. But maybe a little history first, just.
Speaker 1: Quickly, good idea, Yeah, where did SSH come from?
Speaker 2: Okay, so back in nineteen ninety five, Tattoo Yelenen He
Speaker 2: created it basically because the tools people were using them
Speaker 2: telnet rsh are log in.
Speaker 1: Oh those were bad sending passwords in the clear.
Speaker 2: He totally insecured, just asking for trouble. SSH was built
Speaker 2: specifically to create an encrypted, trustworthy channel between two machines
Speaker 2: over a network.
Speaker 1: And the version everyone uses now open ssh.
Speaker 2: That came out of the OPENBSK project, and those folks
Speaker 2: have a serious reputation for writing secure code. It's kind
Speaker 2: of their thing.
Speaker 1: Okay, solid foundation. Then let's dive into the protocol itself.
Speaker 1: The main pieces.
Speaker 2: Pretty straightforward really. You've got the server side, usually a
Speaker 2: program called slewy that's listening for connections.
Speaker 1: And then the client side like the slush command on
Speaker 1: Linux or.
Speaker 2: Mac os exactly, or you know pewdy if you're on Windows.
Speaker 2: Microsoft even has its own native client now though I
Speaker 2: think it's still experimental.
Speaker 1: Right, But now the first big warning sign protocol versions
Speaker 1: SSH one versus SSH two.
Speaker 2: Ah, yes, this is non negotiable.
Speaker 1: What's the rule?
Speaker 2: Always always use SSH two, period full stop?
Speaker 1: Okay, always SSH two? But why? I mean obviously SSH
Speaker 1: one is older? But how bad is it? Really? What's
Speaker 1: the risk If say, a server is still consigured to allow.
Speaker 2: It, it's incredibly dangerous. The source material literally says it's
Speaker 2: barely more secure than unencrypted telnet.
Speaker 1: Wow, okay, yeah.
Speaker 2: It's not just old. It has fundamental flaws from its
Speaker 2: nineteen nineties design, weak key exchange, vulnerable to session hijacking.
Speaker 1: So an attacker could actually get into an active session.
Speaker 2: They could. They can potentially grab log in credentials, decrypt
Speaker 2: your data as it flies by, and maybe the scariest part,
Speaker 2: they can inject their own text fuck commands militia shell
Speaker 2: command think rmrf something catastrophic and sorted right into what
Speaker 2: you thought was a secure.
Speaker 1: Session, got terrifying, a total system white command slipped in.
Speaker 2: It's the nightmare scenario. And the real danger is how
Speaker 2: the connection gets set up. The client and server negotiate
Speaker 2: the version. If either one is willing to speak as one,
Speaker 2: even if they prefer SSH.
Speaker 1: Two, an attacker can force it down.
Speaker 2: Exactly a downgrade attack during that initial handshakee. It exploits
Speaker 2: that tolerance. Thankfully open ssh itself. It ripped out SSH
Speaker 2: one support completely some time ago.
Speaker 1: Good, so it forces you onto the modern secure standard. Right.
Speaker 2: SSH two has been continuously improved, flaws found and fixed.
Speaker 2: It's where you need to be.
Speaker 1: Okay, So ssh two it is. Now, let's get into
Speaker 1: how SSH two actually protects the data, the cryptography, encryption keys,
Speaker 1: the core ideas.
Speaker 2: Right, So encryption is basically scrambling turning readable stuff plaintext
Speaker 2: into unreadable ciphertext. You need an algorithm like a mathematical
Speaker 2: recipe and a.
Speaker 1: Key, and open ssh handles the keys, right. It doesn't
Speaker 1: let users pick their own password for the encryption itself.
Speaker 2: Correct. And that's a deliberate security choice because humans we
Speaker 2: are terrible at choosing strong random keys. We pick birthdays,
Speaker 2: pet names, predictable stuff exactly. So open ssh generates the
Speaker 2: strong cryptographic keys needed. It takes that responsibility away from
Speaker 2: the user, which is a good thing here.
Speaker 1: You know the algorithms, there are two main types, right,
Speaker 1: symmetric and asymmetric. Maybe we can use those analogies from
Speaker 1: the source.
Speaker 2: Yeah, they're helpful. Symmetric is like think of a simple
Speaker 2: kids substitution cipher ABBC, that kind of thing. You use
Speaker 2: the same key to lock it, encrypt and unlock it.
Speaker 2: Decrypt algorithms like as or symmetric they're very fast, very efficient.
Speaker 2: So the catches, how do you securely share that single key?
Speaker 2: If I want to talk to your server. How do
Speaker 2: I get that secret key over to you without someone
Speaker 2: else grabbing it on the way. That's the challenge, right.
Speaker 1: Which brings us to asymmetric public key crypto.
Speaker 2: Yep. This uses two keys mathematically linked. A public key
Speaker 2: you can share with anyone, like putting it on a website,
Speaker 2: and a private key you guard with your life.
Speaker 1: So I could use your public key to encrypt a
Speaker 1: message and only.
Speaker 2: My private key can decrypt it. It's very secure for
Speaker 2: establishing identity and sharing secrets.
Speaker 1: But you said symmetric was fast. Is asymmetric slow?
Speaker 2: Much slow? It's computationally intensive. Doing all the encryption and
Speaker 2: decryption for an entire SSAF session using just asymmetric keys,
Speaker 2: it would be painfully slow, unusable.
Speaker 1: Really? Ah okay? So SSH does something clever.
Speaker 2: A mix exactly, a hybrid approach. This is the genius part.
Speaker 2: When you first connect the client and server use the
Speaker 2: server's public key, that's the slow but secure asymmetric part,
Speaker 2: just long enough to securely negotiate a brand new temporary symmetric.
Speaker 1: Key, the key just for this one session, just for
Speaker 1: this session.
Speaker 2: Once they've both agreed on that shared secret symmetric key,
Speaker 2: they switch all the rest of the communication, all the
Speaker 2: commands you type, the file transfers, that's all encrypted using
Speaker 2: the fast symmetric key.
Speaker 1: The best of both worlds, secure key exchange then fast encryption.
Speaker 2: Precisely speed and security.
Speaker 1: Okay, that makes sense, but people love the tinker. We
Speaker 1: see admins sometimes trying to change the default crypto settings,
Speaker 1: maybe choosing different algorithms, thinking they'll get more speeded. What's
Speaker 1: the advice there.
Speaker 2: Simple, don't do it. Just leave the defaults alone.
Speaker 1: Really, why not?
Speaker 2: Because the open ssh developers, they are deep cryptography experts.
Speaker 2: They chose those defaults, the specific algorithms, the order of preference,
Speaker 2: for very good security reasons. They understand the attacks, the weaknesses,
Speaker 2: and if I change it, you're basically saying you know
Speaker 2: better than them. You might accidentally enable an older weak
Speaker 2: or SOFA, or make yourself vulnerable to like a timing attack,
Speaker 2: or enable a downgrade attack you didn't intend.
Speaker 1: So chasing a tiny speed boost could wreck the actual security.
Speaker 2: Completely undermines the whole point of using Ssh in the
Speaker 2: first place. Stick with the defaults unless you have an
Speaker 2: extremely specific, expert validated reason to change something.
Speaker 1: Security first, okay, message re seat, leave the crypto engine alone.
Speaker 2: Let's talk configuration files. Then, where do all these settings
Speaker 2: actually live? On a typical system.
Speaker 1: Right on most Unix like systems, you'll look in the
Speaker 1: etceters directory. That's system wide stuff inside there. The service
Speaker 1: configuration is in a file called ship config that controls
Speaker 1: how the SSH server behaves.
Speaker 2: Okay, shits config for the server. What about the client?
Speaker 2: If I'm connecting out.
Speaker 1: There's a system wide client config two usually its setters
Speaker 1: can fig But more importantly for you as a user,
Speaker 1: you have your own personal config file in your home directory.
Speaker 1: It's home dot shish config and that.
Speaker 2: One overrides the system defaults exactly. Let's you set up
Speaker 2: custom settings, aliases for hosts, specific keys to use for
Speaker 2: certain connections. Very handy.
Speaker 1: The syntax looked pretty simple in the source material, like
Speaker 1: keyword value so port twenty two or something.
Speaker 2: Yeah, it's generally straightforward, and a really nice touch is
Speaker 2: that the default config files often have lots of options
Speaker 2: already listed, but they're commented out with the hash sign hashtag.
Speaker 1: Ah, so they service documentation pretty much.
Speaker 2: You can see what's possible, uncomment the line and change
Speaker 2: the value if you need to. But there's a really
Speaker 2: powerful feature in the servers config stip canfig that we
Speaker 2: should highlight what's the match keyword? This thing is amazing
Speaker 2: for flexible security.
Speaker 1: Match How does it work?
Speaker 2: It lets you apply specific configuration lines only if certain
Speaker 2: conditions are met, like only for a particular user, or
Speaker 2: only for connections coming from a specific IP address range,
Speaker 2: or only for members of a certain group.
Speaker 1: Well, that sounds useful. Give me an example.
Speaker 2: Okay, Let's say you want to disable x eleven forwarding.
Speaker 2: That's running graphical apps over SSH for everyone by.
Speaker 1: Default security best practice, right right, So you'd put x
Speaker 1: eleven forwarding no somewhere near the top exactly.
Speaker 2: But then maybe your system administrators, the people in the
Speaker 2: wheel group actually need that ability sometimes, so at the
Speaker 2: very end of the config file, match blocks always have
Speaker 2: to go. At the end, you'd add something like match
Speaker 2: group wheel on one line and indented on the next
Speaker 2: line x eleven forwarding.
Speaker 1: Yes. Ah, so it creates an exception just for.
Speaker 2: That group precisely script default then target it overrides based
Speaker 2: on user, group, IP address host. Incredibly flexible for setting
Speaker 2: up fine grained security policies.
Speaker 1: That's really powerful. Okay, speaking of powerful settings, you mentioned
Speaker 1: one earlier when we talked about moving away from insecure practices.
Speaker 1: The password setting.
Speaker 2: Yes, this ties into the whole security deposture. Once you're
Speaker 2: set up with user keys, which we'll touch on at
Speaker 2: the end. The absolute next step is to go into
Speaker 2: your shit canfig and set password authentication no.
Speaker 1: Turn off passwords completely completely.
Speaker 2: Don't even let the server offer password log in as
Speaker 2: an option. This shuts down brute forests password guessing attacks cold.
Speaker 2: It's probably the single biggest hardening step you can take
Speaker 2: on the server side. After ensuring SSH one.
Speaker 1: Is off, okay, makes sense, disable the weaklink. So we've
Speaker 1: covered the right version SSH two, the crypto basics hybrid
Speaker 1: approach that can fig files, fig choes, can fig match,
Speaker 1: and turning off passwords. Now the big one, the single
Speaker 1: most vital security habit you.
Speaker 2: Mentioned this is it host key verification. This directly tackles
Speaker 2: the man in the.
Speaker 1: Middle attack that attack again briefly.
Speaker 2: Okay, imagine you're trying to connect to your server server
Speaker 2: dot example dot com. A bad guy manages to intercept
Speaker 2: your network traffic. They pretend to be server dot example
Speaker 2: dot com.
Speaker 1: So my SSH client connects to the attacker instead of
Speaker 1: the real server.
Speaker 2: Exactly, and if you then type your password. Well, you've
Speaker 2: just given it to the attacker. They can log your credentials,
Speaker 2: maybe pass your connection onto the real server so you
Speaker 2: don't notice immediately it's bad. How does SSH stop this
Speaker 2: with the server's host keys, Remember the asymmetric keys. Every
Speaker 2: SSH server has its own unique public private key pair,
Speaker 2: often generated when SSH is first installed. Okay, the attacker
Speaker 2: can pretend to be your server, but they cannot have
Speaker 2: the real server's secret private key. That key never leaves
Speaker 2: the legitimate server, so they can impersonate it perfectly cryptographically. No,
Speaker 2: they can't complete the secure handshake authentically. This is where
Speaker 2: the verification step comes in for you, the user.
Speaker 1: Right, because those keys are huge. I don't type in
Speaker 1: a public key.
Speaker 2: No, you don't. When your SSH client connects to a
Speaker 2: server for the very first time, the server presents its
Speaker 2: public key. Your client then calculates a shorter, more manageable
Speaker 2: summary of that key. That's the fingerprint, like.
Speaker 1: SA two two five six hash or something similar.
Speaker 2: Usually yeah, something like SUG two five six. These days,
Speaker 2: it's maybe forty or fifty characters, almost human readable, as
Speaker 2: the source puts it, still random looking, but much shorter.
Speaker 1: Than the full key and what am I supposed to
Speaker 1: do with this fingerprint?
Speaker 2: This is the crucial habit. You need to verify it.
Speaker 2: Your assissedmin or the service provider should give you a
Speaker 2: list of the correct fingerprints for their servers, maybe on
Speaker 2: a secure internal website or in documentation. You manually compare
Speaker 2: the fingerprint your client shows you with the known good one,
Speaker 2: and if they match, you tell your client, yes, this
Speaker 2: is the correct server. The client then saves that server's
Speaker 2: public key and its host name IP into your known
Speaker 2: hosts file usually home, dot schnown hosts.
Speaker 1: It remembers it. So what happens next time I connect?
Speaker 2: Next time? The client already knows what key to expect
Speaker 2: from ser example dot com. If the server presents the
Speaker 2: same key again, the connection just happens transparently, no pumps.
Speaker 1: What if it's different? What if the server I connect
Speaker 1: to next time presents a key that doesn't match the
Speaker 1: one stored in known hosts.
Speaker 2: Ah, Now that is the red flag. Your open ssh
Speaker 2: client will immediately halt the connection and it will print
Speaker 2: a very loud, very scary looking warning the.
Speaker 1: All caps one.
Speaker 2: Yeah, the source called it scary looking stuff, something like
Speaker 2: at warning remote host identification has changed at warn followed
Speaker 2: by paragraphs explaining the potential danger of a man in
Speaker 2: the middle attack, and it will refuse to connect.
Speaker 1: Okay, So the key takeaway for everyone listening. If you
Speaker 1: see that massive, scary warning.
Speaker 2: Stop, p absolutely stop. Do not under any circumstances, just
Speaker 2: bypass the warning and connect anyway.
Speaker 1: Why not? What does that warning mean?
Speaker 2: It means one of two things. Possibility one, it's legitimate
Speaker 2: the sissedmin rebuilt the server or intentionally generated new keys
Speaker 2: for some reason. You need to contact them, get the
Speaker 2: new correct fingerprint, remove the old key from your known
Speaker 2: host file, and then connect and.
Speaker 1: Verify the new key, and possibility too.
Speaker 2: Possibility two is that you are under attack. Someone is
Speaker 2: trying to impersonate your server. If you ignore that warning
Speaker 2: and type your password or use your key, you're giving
Speaker 2: your credentials directly to the attacker.
Speaker 1: So that warning is your lifeline. You must investigate why
Speaker 1: the key change before proceeding.
Speaker 2: It's the absolute cornerstone of SSH's defense against MITM. Respect
Speaker 2: the warning, verify the key always.
Speaker 1: Fantastic summary. Okay, so we've covered a lot. SSH two
Speaker 1: is mandatory. We understand the hybrid crypto making it fast
Speaker 1: and secure. We know where the config files are and
Speaker 1: how to use match for flexibility, and we absolutely understand
Speaker 1: the critical importance of host key verification.
Speaker 2: That nails the core security and transit and server setup.
Speaker 1: But it leaves us with one final thought. We secured
Speaker 1: the connection, but what about the log in itself?
Speaker 2: The authentication right We mentioned turning off passwords, and there's
Speaker 2: a big reason our source material talks about these hail
Speaker 2: Mary clouds or those massive botnets, huge networks of compromised
Speaker 2: computers all over the world, constantly scanning the Internet, hammering
Speaker 2: SSAH servers. They just try common user names, route admin
Speaker 2: user and common passwords, dictionary words, leaked password.
Speaker 1: Lists, just throwing everything at the wall hoping something sticks.
Speaker 2: Exactly. It's relentless. Blocking individual IP addresses is pointless. The
Speaker 2: attack comes from everywhere. If you rely solely on passwords,
Speaker 2: eventually one might get guessed, especially if it's not super complex.
Speaker 1: So passwords, even complex ones, are still a major risk
Speaker 1: vector just because of this constant automated assault.
Speaker 2: They really are, which leads to the ultimate path for
Speaker 2: well true SSH mastery and convenience, which is ditching passwords
Speaker 2: entirely for login and moving to user keys combined with
Speaker 2: the SSAH agent.
Speaker 1: Okay, user keys are like host keys, but for me,
Speaker 1: the user a public private pair.
Speaker 2: Exactly. You general at your own key pair. You put
Speaker 2: the public key on the servers you need to access
Speaker 2: in your doutch authorized keys file. There you keep the
Speaker 2: private key safe on your local machine.
Speaker 1: But private keys need protection too.
Speaker 2: Write a passphrase, yes, and it should be a long,
Speaker 2: strong passphrase, much stronger than a typical login password. But
Speaker 2: here's the magic, the SSAH agent.
Speaker 1: What does the agent do.
Speaker 2: It's a small background program running on your local machine.
Speaker 2: When you start your work session, you add your private
Speaker 2: key to the agent. It asks for your long strong
Speaker 2: passphrase once, just.
Speaker 1: Once per session, like once per day when I start.
Speaker 2: Work typically Yeah. Once you unlock the key and load
Speaker 2: it into the agent's memory, the agent handles authentication for
Speaker 2: all subsequent SSH connections without asking you for the passphrase again.
Speaker 1: Ah, so I type my super strong passphrase once in
Speaker 1: the morning like in slush, into ten different servers throughout
Speaker 1: the day without typing any passwords or passphrases at all.
Speaker 2: Exactly. It completely defeats the brute force password attacks because
Speaker 2: password authentication is off and it makes your life incredibly
Speaker 2: convenient because, as you only authenticate once per session to
Speaker 2: the agent, high security meets high convenience. That's the goal.
Speaker 1: User keys plus the SSAH agent the path to true
Speaker 1: SSH mastery. Excellent place to leave it