WEBVTT

1
00:00:00.160 --> 00:00:03.319
<v Speaker 1>Welcome back to the deep dive. So today we're tackling

2
00:00:03.439 --> 00:00:10.039
<v Speaker 1>secure shell SSH. If you're managing systems remotely, you're definitely

3
00:00:10.080 --> 00:00:12.240
<v Speaker 1>using it, probably open ssh.

4
00:00:12.359 --> 00:00:15.919
<v Speaker 2>Yeah, it's pretty much the standard for anything you and

5
00:00:15.960 --> 00:00:18.359
<v Speaker 2>I X like. But you know, the source material we

6
00:00:18.359 --> 00:00:20.679
<v Speaker 2>look at makes a great point, which is that most

7
00:00:20.679 --> 00:00:23.359
<v Speaker 2>people well they only really scratch the surface, just the

8
00:00:23.359 --> 00:00:25.280
<v Speaker 2>bare minimum functionality, right, and.

9
00:00:25.239 --> 00:00:28.640
<v Speaker 1>There's so much more, especially around you know, doing it securely.

10
00:00:28.679 --> 00:00:29.960
<v Speaker 1>That's what we want to unlock today.

11
00:00:30.039 --> 00:00:33.920
<v Speaker 2>Absolutely true mastery means understanding the security underneath it all.

12
00:00:34.240 --> 00:00:36.159
<v Speaker 1>So our mission for you today, we're going to break

13
00:00:36.200 --> 00:00:40.439
<v Speaker 1>down the core architecture, try to demystify some of that

14
00:00:40.479 --> 00:00:41.560
<v Speaker 1>crypto stuff.

15
00:00:41.240 --> 00:00:42.759
<v Speaker 2>Which you can seem pretty intimidating.

16
00:00:42.840 --> 00:00:45.719
<v Speaker 1>Yeah, definitely, and we'll get into the configurations, the files

17
00:00:45.719 --> 00:00:48.359
<v Speaker 1>you need to know and critically that one habit the

18
00:00:48.439 --> 00:00:50.920
<v Speaker 1>single most important thing you can do to protect yourself

19
00:00:50.920 --> 00:00:53.359
<v Speaker 1>from well the most common network attack.

20
00:00:53.439 --> 00:00:56.000
<v Speaker 2>It's a big one. But maybe a little history first, just.

21
00:00:56.000 --> 00:00:59.159
<v Speaker 1>Quickly, good idea, Yeah, where did SSH come from?

22
00:00:59.280 --> 00:01:03.520
<v Speaker 2>Okay, so back in nineteen ninety five, Tattoo Yelenen He

23
00:01:03.560 --> 00:01:06.519
<v Speaker 2>created it basically because the tools people were using them

24
00:01:06.799 --> 00:01:08.760
<v Speaker 2>telnet rsh are log in.

25
00:01:08.879 --> 00:01:10.879
<v Speaker 1>Oh those were bad sending passwords in the clear.

26
00:01:11.000 --> 00:01:14.560
<v Speaker 2>He totally insecured, just asking for trouble. SSH was built

27
00:01:14.599 --> 00:01:18.680
<v Speaker 2>specifically to create an encrypted, trustworthy channel between two machines

28
00:01:18.760 --> 00:01:19.560
<v Speaker 2>over a network.

29
00:01:19.680 --> 00:01:22.599
<v Speaker 1>And the version everyone uses now open ssh.

30
00:01:22.319 --> 00:01:25.159
<v Speaker 2>That came out of the OPENBSK project, and those folks

31
00:01:25.200 --> 00:01:28.680
<v Speaker 2>have a serious reputation for writing secure code. It's kind

32
00:01:28.680 --> 00:01:29.200
<v Speaker 2>of their thing.

33
00:01:29.319 --> 00:01:32.799
<v Speaker 1>Okay, solid foundation. Then let's dive into the protocol itself.

34
00:01:33.200 --> 00:01:34.359
<v Speaker 1>The main pieces.

35
00:01:34.159 --> 00:01:37.239
<v Speaker 2>Pretty straightforward really. You've got the server side, usually a

36
00:01:37.239 --> 00:01:40.519
<v Speaker 2>program called slewy that's listening for connections.

37
00:01:40.040 --> 00:01:42.400
<v Speaker 1>And then the client side like the slush command on

38
00:01:42.480 --> 00:01:42.959
<v Speaker 1>Linux or.

39
00:01:42.959 --> 00:01:45.959
<v Speaker 2>Mac os exactly, or you know pewdy if you're on Windows.

40
00:01:46.000 --> 00:01:48.319
<v Speaker 2>Microsoft even has its own native client now though I

41
00:01:48.319 --> 00:01:49.519
<v Speaker 2>think it's still experimental.

42
00:01:49.640 --> 00:01:53.799
<v Speaker 1>Right, But now the first big warning sign protocol versions

43
00:01:54.239 --> 00:01:56.040
<v Speaker 1>SSH one versus SSH two.

44
00:01:56.239 --> 00:01:59.040
<v Speaker 2>Ah, yes, this is non negotiable.

45
00:01:59.200 --> 00:01:59.799
<v Speaker 1>What's the rule?

46
00:02:00.040 --> 00:02:03.359
<v Speaker 2>Always always use SSH two, period full stop?

47
00:02:03.640 --> 00:02:08.080
<v Speaker 1>Okay, always SSH two? But why? I mean obviously SSH

48
00:02:08.120 --> 00:02:10.759
<v Speaker 1>one is older? But how bad is it? Really? What's

49
00:02:10.800 --> 00:02:14.280
<v Speaker 1>the risk If say, a server is still consigured to allow.

50
00:02:14.000 --> 00:02:18.319
<v Speaker 2>It, it's incredibly dangerous. The source material literally says it's

51
00:02:18.800 --> 00:02:21.159
<v Speaker 2>barely more secure than unencrypted telnet.

52
00:02:21.639 --> 00:02:23.000
<v Speaker 1>Wow, okay, yeah.

53
00:02:23.000 --> 00:02:25.960
<v Speaker 2>It's not just old. It has fundamental flaws from its

54
00:02:26.599 --> 00:02:31.439
<v Speaker 2>nineteen nineties design, weak key exchange, vulnerable to session hijacking.

55
00:02:31.639 --> 00:02:34.080
<v Speaker 1>So an attacker could actually get into an active session.

56
00:02:34.319 --> 00:02:37.680
<v Speaker 2>They could. They can potentially grab log in credentials, decrypt

57
00:02:37.680 --> 00:02:40.520
<v Speaker 2>your data as it flies by, and maybe the scariest part,

58
00:02:40.840 --> 00:02:43.800
<v Speaker 2>they can inject their own text fuck commands militia shell

59
00:02:43.879 --> 00:02:47.240
<v Speaker 2>command think rmrf something catastrophic and sorted right into what

60
00:02:47.319 --> 00:02:48.639
<v Speaker 2>you thought was a secure.

61
00:02:48.280 --> 00:02:51.479
<v Speaker 1>Session, got terrifying, a total system white command slipped in.

62
00:02:51.560 --> 00:02:54.199
<v Speaker 2>It's the nightmare scenario. And the real danger is how

63
00:02:54.240 --> 00:02:57.280
<v Speaker 2>the connection gets set up. The client and server negotiate

64
00:02:57.319 --> 00:03:00.639
<v Speaker 2>the version. If either one is willing to speak as one,

65
00:03:00.840 --> 00:03:02.680
<v Speaker 2>even if they prefer SSH.

66
00:03:02.280 --> 00:03:04.280
<v Speaker 1>Two, an attacker can force it down.

67
00:03:04.240 --> 00:03:07.719
<v Speaker 2>Exactly a downgrade attack during that initial handshakee. It exploits

68
00:03:07.719 --> 00:03:12.199
<v Speaker 2>that tolerance. Thankfully open ssh itself. It ripped out SSH

69
00:03:12.240 --> 00:03:14.080
<v Speaker 2>one support completely some time ago.

70
00:03:14.240 --> 00:03:17.159
<v Speaker 1>Good, so it forces you onto the modern secure standard. Right.

71
00:03:17.360 --> 00:03:21.240
<v Speaker 2>SSH two has been continuously improved, flaws found and fixed.

72
00:03:21.280 --> 00:03:22.080
<v Speaker 2>It's where you need to be.

73
00:03:22.319 --> 00:03:25.639
<v Speaker 1>Okay, So ssh two it is. Now, let's get into

74
00:03:25.879 --> 00:03:31.400
<v Speaker 1>how SSH two actually protects the data, the cryptography, encryption keys,

75
00:03:32.400 --> 00:03:33.240
<v Speaker 1>the core ideas.

76
00:03:33.400 --> 00:03:37.960
<v Speaker 2>Right, So encryption is basically scrambling turning readable stuff plaintext

77
00:03:38.000 --> 00:03:41.080
<v Speaker 2>into unreadable ciphertext. You need an algorithm like a mathematical

78
00:03:41.120 --> 00:03:41.800
<v Speaker 2>recipe and a.

79
00:03:41.840 --> 00:03:44.319
<v Speaker 1>Key, and open ssh handles the keys, right. It doesn't

80
00:03:44.360 --> 00:03:47.039
<v Speaker 1>let users pick their own password for the encryption itself.

81
00:03:47.080 --> 00:03:50.280
<v Speaker 2>Correct. And that's a deliberate security choice because humans we

82
00:03:50.319 --> 00:03:53.759
<v Speaker 2>are terrible at choosing strong random keys. We pick birthdays,

83
00:03:53.840 --> 00:03:58.000
<v Speaker 2>pet names, predictable stuff exactly. So open ssh generates the

84
00:03:58.039 --> 00:04:01.800
<v Speaker 2>strong cryptographic keys needed. It takes that responsibility away from

85
00:04:01.840 --> 00:04:03.719
<v Speaker 2>the user, which is a good thing here.

86
00:04:03.919 --> 00:04:06.520
<v Speaker 1>You know the algorithms, there are two main types, right,

87
00:04:06.560 --> 00:04:08.960
<v Speaker 1>symmetric and asymmetric. Maybe we can use those analogies from

88
00:04:08.960 --> 00:04:09.360
<v Speaker 1>the source.

89
00:04:09.680 --> 00:04:13.039
<v Speaker 2>Yeah, they're helpful. Symmetric is like think of a simple

90
00:04:13.120 --> 00:04:17.439
<v Speaker 2>kids substitution cipher ABBC, that kind of thing. You use

91
00:04:17.480 --> 00:04:21.040
<v Speaker 2>the same key to lock it, encrypt and unlock it.

92
00:04:21.079 --> 00:04:25.040
<v Speaker 2>Decrypt algorithms like as or symmetric they're very fast, very efficient.

93
00:04:25.160 --> 00:04:28.319
<v Speaker 2>So the catches, how do you securely share that single key?

94
00:04:28.639 --> 00:04:30.720
<v Speaker 2>If I want to talk to your server. How do

95
00:04:30.800 --> 00:04:33.240
<v Speaker 2>I get that secret key over to you without someone

96
00:04:33.279 --> 00:04:35.759
<v Speaker 2>else grabbing it on the way. That's the challenge, right.

97
00:04:35.800 --> 00:04:39.120
<v Speaker 1>Which brings us to asymmetric public key crypto.

98
00:04:39.360 --> 00:04:43.199
<v Speaker 2>Yep. This uses two keys mathematically linked. A public key

99
00:04:43.199 --> 00:04:46.040
<v Speaker 2>you can share with anyone, like putting it on a website,

100
00:04:46.480 --> 00:04:48.720
<v Speaker 2>and a private key you guard with your life.

101
00:04:48.839 --> 00:04:50.600
<v Speaker 1>So I could use your public key to encrypt a

102
00:04:50.600 --> 00:04:51.839
<v Speaker 1>message and only.

103
00:04:51.639 --> 00:04:54.199
<v Speaker 2>My private key can decrypt it. It's very secure for

104
00:04:54.319 --> 00:04:56.240
<v Speaker 2>establishing identity and sharing secrets.

105
00:04:56.319 --> 00:04:59.399
<v Speaker 1>But you said symmetric was fast. Is asymmetric slow?

106
00:04:59.560 --> 00:05:02.759
<v Speaker 2>Much slow? It's computationally intensive. Doing all the encryption and

107
00:05:02.800 --> 00:05:06.480
<v Speaker 2>decryption for an entire SSAF session using just asymmetric keys,

108
00:05:06.800 --> 00:05:08.879
<v Speaker 2>it would be painfully slow, unusable.

109
00:05:08.959 --> 00:05:12.079
<v Speaker 1>Really? Ah okay? So SSH does something clever.

110
00:05:12.199 --> 00:05:16.199
<v Speaker 2>A mix exactly, a hybrid approach. This is the genius part.

111
00:05:16.480 --> 00:05:19.879
<v Speaker 2>When you first connect the client and server use the

112
00:05:19.920 --> 00:05:23.879
<v Speaker 2>server's public key, that's the slow but secure asymmetric part,

113
00:05:24.360 --> 00:05:29.360
<v Speaker 2>just long enough to securely negotiate a brand new temporary symmetric.

114
00:05:28.920 --> 00:05:31.560
<v Speaker 1>Key, the key just for this one session, just for

115
00:05:31.639 --> 00:05:32.199
<v Speaker 1>this session.

116
00:05:32.680 --> 00:05:35.839
<v Speaker 2>Once they've both agreed on that shared secret symmetric key,

117
00:05:36.120 --> 00:05:39.000
<v Speaker 2>they switch all the rest of the communication, all the

118
00:05:39.040 --> 00:05:42.959
<v Speaker 2>commands you type, the file transfers, that's all encrypted using

119
00:05:43.000 --> 00:05:44.079
<v Speaker 2>the fast symmetric key.

120
00:05:44.160 --> 00:05:48.040
<v Speaker 1>The best of both worlds, secure key exchange then fast encryption.

121
00:05:48.560 --> 00:05:50.560
<v Speaker 2>Precisely speed and security.

122
00:05:50.639 --> 00:05:54.199
<v Speaker 1>Okay, that makes sense, but people love the tinker. We

123
00:05:54.240 --> 00:05:57.439
<v Speaker 1>see admins sometimes trying to change the default crypto settings,

124
00:05:57.480 --> 00:06:01.040
<v Speaker 1>maybe choosing different algorithms, thinking they'll get more speeded. What's

125
00:06:01.079 --> 00:06:02.040
<v Speaker 1>the advice there.

126
00:06:02.000 --> 00:06:04.639
<v Speaker 2>Simple, don't do it. Just leave the defaults alone.

127
00:06:04.800 --> 00:06:05.439
<v Speaker 1>Really, why not?

128
00:06:05.680 --> 00:06:09.839
<v Speaker 2>Because the open ssh developers, they are deep cryptography experts.

129
00:06:09.920 --> 00:06:13.480
<v Speaker 2>They chose those defaults, the specific algorithms, the order of preference,

130
00:06:13.519 --> 00:06:17.319
<v Speaker 2>for very good security reasons. They understand the attacks, the weaknesses,

131
00:06:17.439 --> 00:06:19.439
<v Speaker 2>and if I change it, you're basically saying you know

132
00:06:19.519 --> 00:06:22.519
<v Speaker 2>better than them. You might accidentally enable an older weak

133
00:06:22.600 --> 00:06:26.079
<v Speaker 2>or SOFA, or make yourself vulnerable to like a timing attack,

134
00:06:26.720 --> 00:06:29.240
<v Speaker 2>or enable a downgrade attack you didn't intend.

135
00:06:29.360 --> 00:06:33.160
<v Speaker 1>So chasing a tiny speed boost could wreck the actual security.

136
00:06:32.879 --> 00:06:35.800
<v Speaker 2>Completely undermines the whole point of using Ssh in the

137
00:06:35.839 --> 00:06:38.199
<v Speaker 2>first place. Stick with the defaults unless you have an

138
00:06:38.240 --> 00:06:42.600
<v Speaker 2>extremely specific, expert validated reason to change something.

139
00:06:43.079 --> 00:06:47.480
<v Speaker 1>Security first, okay, message re seat, leave the crypto engine alone.

140
00:06:48.279 --> 00:06:51.800
<v Speaker 2>Let's talk configuration files. Then, where do all these settings

141
00:06:51.839 --> 00:06:53.920
<v Speaker 2>actually live? On a typical system.

142
00:06:54.439 --> 00:06:57.079
<v Speaker 1>Right on most Unix like systems, you'll look in the

143
00:06:57.199 --> 00:07:01.279
<v Speaker 1>etceters directory. That's system wide stuff inside there. The service

144
00:07:01.319 --> 00:07:04.759
<v Speaker 1>configuration is in a file called ship config that controls

145
00:07:04.759 --> 00:07:06.240
<v Speaker 1>how the SSH server behaves.

146
00:07:06.279 --> 00:07:08.920
<v Speaker 2>Okay, shits config for the server. What about the client?

147
00:07:09.120 --> 00:07:10.120
<v Speaker 2>If I'm connecting out.

148
00:07:10.040 --> 00:07:12.759
<v Speaker 1>There's a system wide client config two usually its setters

149
00:07:12.800 --> 00:07:15.040
<v Speaker 1>can fig But more importantly for you as a user,

150
00:07:15.319 --> 00:07:18.120
<v Speaker 1>you have your own personal config file in your home directory.

151
00:07:18.360 --> 00:07:20.959
<v Speaker 1>It's home dot shish config and that.

152
00:07:20.920 --> 00:07:24.120
<v Speaker 2>One overrides the system defaults exactly. Let's you set up

153
00:07:24.120 --> 00:07:28.279
<v Speaker 2>custom settings, aliases for hosts, specific keys to use for

154
00:07:28.319 --> 00:07:30.759
<v Speaker 2>certain connections. Very handy.

155
00:07:31.120 --> 00:07:34.079
<v Speaker 1>The syntax looked pretty simple in the source material, like

156
00:07:34.199 --> 00:07:36.959
<v Speaker 1>keyword value so port twenty two or something.

157
00:07:37.040 --> 00:07:40.040
<v Speaker 2>Yeah, it's generally straightforward, and a really nice touch is

158
00:07:40.040 --> 00:07:43.560
<v Speaker 2>that the default config files often have lots of options

159
00:07:43.600 --> 00:07:48.279
<v Speaker 2>already listed, but they're commented out with the hash sign hashtag.

160
00:07:47.839 --> 00:07:50.240
<v Speaker 1>Ah, so they service documentation pretty much.

161
00:07:50.399 --> 00:07:52.639
<v Speaker 2>You can see what's possible, uncomment the line and change

162
00:07:52.639 --> 00:07:55.399
<v Speaker 2>the value if you need to. But there's a really

163
00:07:55.480 --> 00:07:58.800
<v Speaker 2>powerful feature in the servers config stip canfig that we

164
00:07:58.839 --> 00:08:02.959
<v Speaker 2>should highlight what's the match keyword? This thing is amazing

165
00:08:03.040 --> 00:08:04.199
<v Speaker 2>for flexible security.

166
00:08:04.600 --> 00:08:05.839
<v Speaker 1>Match How does it work?

167
00:08:06.240 --> 00:08:09.600
<v Speaker 2>It lets you apply specific configuration lines only if certain

168
00:08:09.639 --> 00:08:12.439
<v Speaker 2>conditions are met, like only for a particular user, or

169
00:08:12.439 --> 00:08:15.639
<v Speaker 2>only for connections coming from a specific IP address range,

170
00:08:16.000 --> 00:08:17.600
<v Speaker 2>or only for members of a certain group.

171
00:08:17.759 --> 00:08:19.839
<v Speaker 1>Well, that sounds useful. Give me an example.

172
00:08:19.920 --> 00:08:22.240
<v Speaker 2>Okay, Let's say you want to disable x eleven forwarding.

173
00:08:22.240 --> 00:08:25.319
<v Speaker 2>That's running graphical apps over SSH for everyone by.

174
00:08:25.199 --> 00:08:28.399
<v Speaker 1>Default security best practice, right right, So you'd put x

175
00:08:28.439 --> 00:08:31.399
<v Speaker 1>eleven forwarding no somewhere near the top exactly.

176
00:08:31.639 --> 00:08:34.759
<v Speaker 2>But then maybe your system administrators, the people in the

177
00:08:34.759 --> 00:08:38.399
<v Speaker 2>wheel group actually need that ability sometimes, so at the

178
00:08:38.519 --> 00:08:41.159
<v Speaker 2>very end of the config file, match blocks always have

179
00:08:41.240 --> 00:08:43.519
<v Speaker 2>to go. At the end, you'd add something like match

180
00:08:43.519 --> 00:08:46.159
<v Speaker 2>group wheel on one line and indented on the next

181
00:08:46.200 --> 00:08:47.679
<v Speaker 2>line x eleven forwarding.

182
00:08:47.799 --> 00:08:51.200
<v Speaker 1>Yes. Ah, so it creates an exception just for.

183
00:08:51.200 --> 00:08:55.440
<v Speaker 2>That group precisely script default then target it overrides based

184
00:08:55.480 --> 00:09:00.600
<v Speaker 2>on user, group, IP address host. Incredibly flexible for setting

185
00:09:00.639 --> 00:09:02.240
<v Speaker 2>up fine grained security policies.

186
00:09:02.360 --> 00:09:05.720
<v Speaker 1>That's really powerful. Okay, speaking of powerful settings, you mentioned

187
00:09:05.720 --> 00:09:08.440
<v Speaker 1>one earlier when we talked about moving away from insecure practices.

188
00:09:09.320 --> 00:09:10.559
<v Speaker 1>The password setting.

189
00:09:10.480 --> 00:09:13.679
<v Speaker 2>Yes, this ties into the whole security deposture. Once you're

190
00:09:13.720 --> 00:09:15.519
<v Speaker 2>set up with user keys, which we'll touch on at

191
00:09:15.559 --> 00:09:18.440
<v Speaker 2>the end. The absolute next step is to go into

192
00:09:18.440 --> 00:09:21.759
<v Speaker 2>your shit canfig and set password authentication no.

193
00:09:21.639 --> 00:09:24.279
<v Speaker 1>Turn off passwords completely completely.

194
00:09:24.159 --> 00:09:26.679
<v Speaker 2>Don't even let the server offer password log in as

195
00:09:26.679 --> 00:09:31.200
<v Speaker 2>an option. This shuts down brute forests password guessing attacks cold.

196
00:09:31.720 --> 00:09:34.559
<v Speaker 2>It's probably the single biggest hardening step you can take

197
00:09:34.600 --> 00:09:37.320
<v Speaker 2>on the server side. After ensuring SSH one.

198
00:09:37.240 --> 00:09:41.159
<v Speaker 1>Is off, okay, makes sense, disable the weaklink. So we've

199
00:09:41.159 --> 00:09:44.279
<v Speaker 1>covered the right version SSH two, the crypto basics hybrid

200
00:09:44.279 --> 00:09:48.639
<v Speaker 1>approach that can fig files, fig choes, can fig match,

201
00:09:49.000 --> 00:09:52.639
<v Speaker 1>and turning off passwords. Now the big one, the single

202
00:09:52.679 --> 00:09:54.320
<v Speaker 1>most vital security habit you.

203
00:09:54.279 --> 00:09:58.279
<v Speaker 2>Mentioned this is it host key verification. This directly tackles

204
00:09:58.320 --> 00:09:58.879
<v Speaker 2>the man in the.

205
00:09:58.799 --> 00:10:01.840
<v Speaker 1>Middle attack that attack again briefly.

206
00:10:01.600 --> 00:10:04.000
<v Speaker 2>Okay, imagine you're trying to connect to your server server

207
00:10:04.039 --> 00:10:07.200
<v Speaker 2>dot example dot com. A bad guy manages to intercept

208
00:10:07.200 --> 00:10:10.039
<v Speaker 2>your network traffic. They pretend to be server dot example

209
00:10:10.080 --> 00:10:10.480
<v Speaker 2>dot com.

210
00:10:10.480 --> 00:10:12.840
<v Speaker 1>So my SSH client connects to the attacker instead of

211
00:10:12.840 --> 00:10:13.679
<v Speaker 1>the real server.

212
00:10:13.639 --> 00:10:16.559
<v Speaker 2>Exactly, and if you then type your password. Well, you've

213
00:10:16.600 --> 00:10:18.720
<v Speaker 2>just given it to the attacker. They can log your credentials,

214
00:10:18.759 --> 00:10:20.799
<v Speaker 2>maybe pass your connection onto the real server so you

215
00:10:20.799 --> 00:10:24.240
<v Speaker 2>don't notice immediately it's bad. How does SSH stop this

216
00:10:24.720 --> 00:10:29.840
<v Speaker 2>with the server's host keys, Remember the asymmetric keys. Every

217
00:10:30.000 --> 00:10:33.879
<v Speaker 2>SSH server has its own unique public private key pair,

218
00:10:34.440 --> 00:10:38.399
<v Speaker 2>often generated when SSH is first installed. Okay, the attacker

219
00:10:38.440 --> 00:10:41.200
<v Speaker 2>can pretend to be your server, but they cannot have

220
00:10:41.320 --> 00:10:46.360
<v Speaker 2>the real server's secret private key. That key never leaves

221
00:10:46.360 --> 00:10:50.879
<v Speaker 2>the legitimate server, so they can impersonate it perfectly cryptographically. No,

222
00:10:51.519 --> 00:10:54.679
<v Speaker 2>they can't complete the secure handshake authentically. This is where

223
00:10:54.679 --> 00:10:57.320
<v Speaker 2>the verification step comes in for you, the user.

224
00:10:57.159 --> 00:10:58.879
<v Speaker 1>Right, because those keys are huge. I don't type in

225
00:10:58.919 --> 00:10:59.519
<v Speaker 1>a public key.

226
00:10:59.639 --> 00:11:02.120
<v Speaker 2>No, you don't. When your SSH client connects to a

227
00:11:02.200 --> 00:11:04.879
<v Speaker 2>server for the very first time, the server presents its

228
00:11:04.919 --> 00:11:08.799
<v Speaker 2>public key. Your client then calculates a shorter, more manageable

229
00:11:08.799 --> 00:11:11.320
<v Speaker 2>summary of that key. That's the fingerprint, like.

230
00:11:11.480 --> 00:11:13.720
<v Speaker 1>SA two two five six hash or something similar.

231
00:11:13.840 --> 00:11:16.399
<v Speaker 2>Usually yeah, something like SUG two five six. These days,

232
00:11:16.399 --> 00:11:19.080
<v Speaker 2>it's maybe forty or fifty characters, almost human readable, as

233
00:11:19.080 --> 00:11:22.320
<v Speaker 2>the source puts it, still random looking, but much shorter.

234
00:11:22.120 --> 00:11:23.600
<v Speaker 1>Than the full key and what am I supposed to

235
00:11:23.639 --> 00:11:24.519
<v Speaker 1>do with this fingerprint?

236
00:11:24.799 --> 00:11:27.159
<v Speaker 2>This is the crucial habit. You need to verify it.

237
00:11:27.720 --> 00:11:30.320
<v Speaker 2>Your assissedmin or the service provider should give you a

238
00:11:30.399 --> 00:11:33.519
<v Speaker 2>list of the correct fingerprints for their servers, maybe on

239
00:11:33.559 --> 00:11:38.159
<v Speaker 2>a secure internal website or in documentation. You manually compare

240
00:11:38.240 --> 00:11:41.200
<v Speaker 2>the fingerprint your client shows you with the known good one,

241
00:11:41.360 --> 00:11:44.120
<v Speaker 2>and if they match, you tell your client, yes, this

242
00:11:44.240 --> 00:11:47.559
<v Speaker 2>is the correct server. The client then saves that server's

243
00:11:47.600 --> 00:11:50.600
<v Speaker 2>public key and its host name IP into your known

244
00:11:50.720 --> 00:11:54.039
<v Speaker 2>hosts file usually home, dot schnown hosts.

245
00:11:54.279 --> 00:11:56.919
<v Speaker 1>It remembers it. So what happens next time I connect?

246
00:11:57.159 --> 00:11:59.519
<v Speaker 2>Next time? The client already knows what key to expect

247
00:11:59.519 --> 00:12:03.320
<v Speaker 2>from ser example dot com. If the server presents the

248
00:12:03.360 --> 00:12:07.200
<v Speaker 2>same key again, the connection just happens transparently, no pumps.

249
00:12:07.360 --> 00:12:09.639
<v Speaker 1>What if it's different? What if the server I connect

250
00:12:09.720 --> 00:12:12.159
<v Speaker 1>to next time presents a key that doesn't match the

251
00:12:12.200 --> 00:12:13.960
<v Speaker 1>one stored in known hosts.

252
00:12:14.000 --> 00:12:16.879
<v Speaker 2>Ah, Now that is the red flag. Your open ssh

253
00:12:16.919 --> 00:12:19.919
<v Speaker 2>client will immediately halt the connection and it will print

254
00:12:19.960 --> 00:12:22.559
<v Speaker 2>a very loud, very scary looking warning the.

255
00:12:22.600 --> 00:12:23.360
<v Speaker 1>All caps one.

256
00:12:23.480 --> 00:12:25.919
<v Speaker 2>Yeah, the source called it scary looking stuff, something like

257
00:12:26.600 --> 00:12:32.399
<v Speaker 2>at warning remote host identification has changed at warn followed

258
00:12:32.399 --> 00:12:35.000
<v Speaker 2>by paragraphs explaining the potential danger of a man in

259
00:12:35.039 --> 00:12:37.919
<v Speaker 2>the middle attack, and it will refuse to connect.

260
00:12:38.039 --> 00:12:41.240
<v Speaker 1>Okay, So the key takeaway for everyone listening. If you

261
00:12:41.399 --> 00:12:43.759
<v Speaker 1>see that massive, scary warning.

262
00:12:43.600 --> 00:12:47.519
<v Speaker 2>Stop, p absolutely stop. Do not under any circumstances, just

263
00:12:47.600 --> 00:12:49.559
<v Speaker 2>bypass the warning and connect anyway.

264
00:12:49.639 --> 00:12:50.919
<v Speaker 1>Why not? What does that warning mean?

265
00:12:51.159 --> 00:12:54.759
<v Speaker 2>It means one of two things. Possibility one, it's legitimate

266
00:12:54.960 --> 00:12:58.679
<v Speaker 2>the sissedmin rebuilt the server or intentionally generated new keys

267
00:12:58.720 --> 00:13:01.320
<v Speaker 2>for some reason. You need to contact them, get the

268
00:13:01.360 --> 00:13:04.000
<v Speaker 2>new correct fingerprint, remove the old key from your known

269
00:13:04.000 --> 00:13:05.480
<v Speaker 2>host file, and then connect and.

270
00:13:05.480 --> 00:13:07.399
<v Speaker 1>Verify the new key, and possibility too.

271
00:13:07.519 --> 00:13:10.000
<v Speaker 2>Possibility two is that you are under attack. Someone is

272
00:13:10.039 --> 00:13:13.320
<v Speaker 2>trying to impersonate your server. If you ignore that warning

273
00:13:13.360 --> 00:13:16.039
<v Speaker 2>and type your password or use your key, you're giving

274
00:13:16.039 --> 00:13:18.039
<v Speaker 2>your credentials directly to the attacker.

275
00:13:18.320 --> 00:13:21.279
<v Speaker 1>So that warning is your lifeline. You must investigate why

276
00:13:21.320 --> 00:13:22.879
<v Speaker 1>the key change before proceeding.

277
00:13:23.039 --> 00:13:28.080
<v Speaker 2>It's the absolute cornerstone of SSH's defense against MITM. Respect

278
00:13:28.080 --> 00:13:30.600
<v Speaker 2>the warning, verify the key always.

279
00:13:31.080 --> 00:13:34.799
<v Speaker 1>Fantastic summary. Okay, so we've covered a lot. SSH two

280
00:13:34.840 --> 00:13:38.120
<v Speaker 1>is mandatory. We understand the hybrid crypto making it fast

281
00:13:38.120 --> 00:13:40.639
<v Speaker 1>and secure. We know where the config files are and

282
00:13:40.679 --> 00:13:43.960
<v Speaker 1>how to use match for flexibility, and we absolutely understand

283
00:13:44.000 --> 00:13:46.240
<v Speaker 1>the critical importance of host key verification.

284
00:13:46.559 --> 00:13:49.960
<v Speaker 2>That nails the core security and transit and server setup.

285
00:13:50.039 --> 00:13:52.639
<v Speaker 1>But it leaves us with one final thought. We secured

286
00:13:52.639 --> 00:13:55.440
<v Speaker 1>the connection, but what about the log in itself?

287
00:13:55.799 --> 00:13:59.600
<v Speaker 2>The authentication right We mentioned turning off passwords, and there's

288
00:13:59.639 --> 00:14:02.200
<v Speaker 2>a big reason our source material talks about these hail

289
00:14:02.279 --> 00:14:06.799
<v Speaker 2>Mary clouds or those massive botnets, huge networks of compromised

290
00:14:06.840 --> 00:14:10.720
<v Speaker 2>computers all over the world, constantly scanning the Internet, hammering

291
00:14:10.799 --> 00:14:14.720
<v Speaker 2>SSAH servers. They just try common user names, route admin

292
00:14:15.080 --> 00:14:18.919
<v Speaker 2>user and common passwords, dictionary words, leaked password.

293
00:14:18.519 --> 00:14:21.320
<v Speaker 1>Lists, just throwing everything at the wall hoping something sticks.

294
00:14:21.480 --> 00:14:25.639
<v Speaker 2>Exactly. It's relentless. Blocking individual IP addresses is pointless. The

295
00:14:25.679 --> 00:14:29.159
<v Speaker 2>attack comes from everywhere. If you rely solely on passwords,

296
00:14:29.159 --> 00:14:33.279
<v Speaker 2>eventually one might get guessed, especially if it's not super complex.

297
00:14:33.480 --> 00:14:37.399
<v Speaker 1>So passwords, even complex ones, are still a major risk

298
00:14:37.519 --> 00:14:40.279
<v Speaker 1>vector just because of this constant automated assault.

299
00:14:40.399 --> 00:14:43.440
<v Speaker 2>They really are, which leads to the ultimate path for

300
00:14:43.759 --> 00:14:48.279
<v Speaker 2>well true SSH mastery and convenience, which is ditching passwords

301
00:14:48.440 --> 00:14:51.840
<v Speaker 2>entirely for login and moving to user keys combined with

302
00:14:51.879 --> 00:14:52.960
<v Speaker 2>the SSAH agent.

303
00:14:53.039 --> 00:14:55.559
<v Speaker 1>Okay, user keys are like host keys, but for me,

304
00:14:56.120 --> 00:14:58.879
<v Speaker 1>the user a public private pair.

305
00:14:59.039 --> 00:15:01.600
<v Speaker 2>Exactly. You general at your own key pair. You put

306
00:15:01.600 --> 00:15:04.200
<v Speaker 2>the public key on the servers you need to access

307
00:15:04.240 --> 00:15:06.919
<v Speaker 2>in your doutch authorized keys file. There you keep the

308
00:15:06.919 --> 00:15:09.000
<v Speaker 2>private key safe on your local machine.

309
00:15:09.000 --> 00:15:10.600
<v Speaker 1>But private keys need protection too.

310
00:15:10.639 --> 00:15:13.480
<v Speaker 2>Write a passphrase, yes, and it should be a long,

311
00:15:13.679 --> 00:15:17.399
<v Speaker 2>strong passphrase, much stronger than a typical login password. But

312
00:15:17.480 --> 00:15:19.840
<v Speaker 2>here's the magic, the SSAH agent.

313
00:15:19.919 --> 00:15:20.720
<v Speaker 1>What does the agent do.

314
00:15:21.039 --> 00:15:24.000
<v Speaker 2>It's a small background program running on your local machine.

315
00:15:24.080 --> 00:15:26.440
<v Speaker 2>When you start your work session, you add your private

316
00:15:26.519 --> 00:15:29.000
<v Speaker 2>key to the agent. It asks for your long strong

317
00:15:29.039 --> 00:15:30.480
<v Speaker 2>passphrase once, just.

318
00:15:30.440 --> 00:15:33.000
<v Speaker 1>Once per session, like once per day when I start.

319
00:15:32.759 --> 00:15:36.120
<v Speaker 2>Work typically Yeah. Once you unlock the key and load

320
00:15:36.120 --> 00:15:38.919
<v Speaker 2>it into the agent's memory, the agent handles authentication for

321
00:15:39.000 --> 00:15:42.559
<v Speaker 2>all subsequent SSH connections without asking you for the passphrase again.

322
00:15:42.799 --> 00:15:46.159
<v Speaker 1>Ah, so I type my super strong passphrase once in

323
00:15:46.200 --> 00:15:48.960
<v Speaker 1>the morning like in slush, into ten different servers throughout

324
00:15:49.000 --> 00:15:51.919
<v Speaker 1>the day without typing any passwords or passphrases at all.

325
00:15:52.080 --> 00:15:55.679
<v Speaker 2>Exactly. It completely defeats the brute force password attacks because

326
00:15:55.799 --> 00:15:59.240
<v Speaker 2>password authentication is off and it makes your life incredibly

327
00:15:59.279 --> 00:16:02.320
<v Speaker 2>convenient because, as you only authenticate once per session to

328
00:16:02.360 --> 00:16:05.679
<v Speaker 2>the agent, high security meets high convenience. That's the goal.

329
00:16:05.960 --> 00:16:09.399
<v Speaker 1>User keys plus the SSAH agent the path to true

330
00:16:09.679 --> 00:16:12.080
<v Speaker 1>SSH mastery. Excellent place to leave it