Thanks for coming. This is open SSH internals for PowerShell pros. That would be you guys, right? I am going to turn my clicker on and then click. Anthony No Centeno. I'm a consultant and trainer and founder of Centeno Systems where I specialize in system architecture and performance.

So I like to make the really bad joke that I like to design systems and make them go fast. Data platform MVP. I do a lot of work in the SQL Server community. I also operate in a Linux world. I'm a Linux Foundation certified engineer and all that fun stuff. There's my contact info. Please feel free to email me.

I love interacting with you guys. It'll be at the end of the deck too. Interacting with you guys if there are any questions about, you know, PowerShell, SQL Server, Linux, things like that. Follow me on Twitter. It's my main way to get information out to the community if you aren't following me already. So, you know, things like speaking engagements and blog posts. I blog relatively frequently. It's gotten a little sparse in the beginning of this year, but it'll get better, I promise. Or at least that's what we all say, right?

I'm also a Pluralsight author. I have some free cards up here for you guys. A lot of today's material exists in Pluralsight courses that I have at a much deeper level and come to see more topics. So if you want free access to that content, take a card. I'll leave them up here for you guys so you can spend some time with that after this because we have only 45 minutes

today to talk about what we want to talk about. So let's talk about what we want to talk about with the agenda. We're going to talk about remote access concepts and OpenSSH's architecture. Like why is it secure and like what are the facets of a secure system that we need to be concerned about when we provide remote access to our system.

We're going to talk about authenticating users and the various authentication methods that are available to you in SSH and clear up some confusion with how things work in that world. And then we're going to look at how to configure OpenSSH. So where the configuration files live and things like that. So we're going to look at how to do some fun stuff there. Tomorrow I'm doing a session with Richard Sidway where we're going to go over the remoting stuff.

So today we're going to be kind of solely focused on OpenSSH, how to configure it, how to auth users, things like that and how it works under the hood. But tomorrow we're going to go into from zero to fully feature from a Windows system all the way up through installing OpenSSH and configuring remoting and things like that and what to do along the way when things go wrong. So that's tomorrow. Today is just OpenSSH.

So we're going to start off with remote access concepts and OpenSSH architecture or OpenSSH, How to Learn to Stop Worrying and Love Remote Access. That's Dr. Strangelove. You guys get the reference. That is Creative Commons or not Creative Commons. That is a public domain picture. So I did not steal that.

There's a thing. I'll tell you about the thing. So remote access concepts. Let's talk about why remote access is hard and what are the big buckets of things that we have to worry about, right? Primarily we have to worry about authentication. We need to verify the identity of the people that we're letting into our systems. That's kind of important, right? Because they go and do stuff and take data and execute commands and do various things.

Then we want to differentiate that between authorization, right? Not only are we letting people in, but who are we letting in, right? And how do we control that? And so granting access to the system. Out of the box, if you install OpenSSH on... Wait, don't install OpenSSH. Out of the box on the CentOS system, anybody can log in and anybody can log in remotely with a root. That's bad news, right? If you think about putting something like that on the internet.

And so controlling that is an important thing. And then another big chunk for remote access to have to be concerned about is integrity, right? Making sure that the message that I sent to the server is the message that gets received by the server, right? If we're doing something like a remote command execution, if someone can change the data midstream, that's bad news, right? Because they could change what I want to have happen or intercept my data or anything like that.

And so integrity is a big facet of making sure secure systems for remote access. On the architectural side of the house, let's take a look at this picture. This is from an O'Reilly book in 2009, The Definitive Guide to SSH, which is aptly named because it's really that good. And it's totally pertinent nowadays. I was going to redraw this picture on my own, but I think this is a pretty good

graphic of what's going on. Because one of the things that trips people up a lot when they're working with SSH is keys, right? The term's thrown around a lot. And so we've got this really good picture to show us where all these different keys live. When you log into a system for the first time, like on the server side of the house, you're presented with what's called a host key, right?

And that host key exists on the server side and is generated from a public and private key pair. What's presented to you is that host key when you log into the system for the first time, right? You log in, you see that yes-no prompt, right? What do you do with that? You accept that key and you will download that key and stick it in your known host file. Which is interesting because you need to make sure, at that point in time,

it's up to you to make sure that that system is who it says it is. That host key is coming from a system that you're logging into and all subsequent connections will be compared to that host key. So when you log in, that server will present the host key to you. You'll look in your known host file. It'll say, oh, I recognize you. I'm gonna let you log in. If that key changes for some reason, you have to ask yourself the question,

why did that key change before you go and interact with that system again? It could be that the system was re-platformed, just simply rebuilt, a new host key was generated, things like that. Or it could be that the system was compromised and the key had to be regenerated. Or maybe there was a DNS hijack and you're no longer logging into the system that you think you're logging into, right?

So that's why having that host key protect it and understanding what it means is super critical to your system. And if you do have to make a change, understand why it changed. On the user side of the house, we're gonna talk about authentication methods in a few minutes. But I do want to call out user keys right now. We can use those to authenticate to the system. We generate a public and private key pair.

We take our public key, we stick it on a target server that we're going to log into, into what's called an authorization file. When we log in, we exchange the key information and I get logged into the server with or without a password. Which brings up an interesting point, the key-based authentication, which I'll talk about in a second, actually.

Once we get logged in, we transition to a connected state where a session key is generated. A session key is going to be exchanged during the connection setup. We're going to use asymmetric encryption to exchange this key to feed a symmetric encryption algorithm, which is then going to be used for the duration of our connection.

So there's lots of keys getting thrown around. I just felt like it was important to sort through that right on the head end before we talk about key OpenSSH functionality. All right, super bad pun there, come on. Thank you for laughing. So the number one thing out of the box that we get with OpenSSH is secure client-to-server communication, right? We have symmetric encryption for our connection,

which is pretty much as good as it's going to get when we're exchanging data securely between a client and the server. We also have the ability to do remote command execution. I can blast a command, add a target, and get the output of that command back over standard out and look at those results on my system. Very valuable piece of information there. You guys are probably used to that with remoting.

Secure file copy. So I can exchange data between source and destination systems very easily without having to open up new ports, create shares, do anything like that. I can simply exchange data. I can put it on a server or I can pull it off of a server with zero configuration. I can also tunnel arbitrary TCP services to get around things like firewalls, which is actually quite fun.

Or if you have an insecure service or maybe you can't get your security team to open up a port for a particular service, you can tunnel that over TCP IP or over SSH, that TCP connection over SSH, to get around those security rules. I'm not actually covering that today, but that does exist in my Pluralsight course if you want to get into how that works.

SSH also provides the ability to ensure the system is who, the remote system is who it says it is via host keys, right? And that's so critical when we're exchanging data on the public internet. And then finally message integrity. It also provides that out of the box. So pretty broad, this is actually not all of the features, but pretty broad scope of things that we can get done with just open SSH.

So I'm going to hit you with a little bit of theory, but it can become very practical very quickly. So we're going to talk about the process model that exists inside of open SSH and this concept called privilege separation. If I'm on a client and I make a connection to a server, that port that lives on the internet or that port that's open on my server on a Linux system,

or by default it's going to be on open SSH would be port 22. On a Linux system, ports below 1024 have to be opened by a privileged user or aka root, right? Which means my remote access system will have an exposed port on the internet potentially running as root. That sounds kind of scary, right? If you think about that and the potential implications of if someone's able to breach my system

through a security vulnerability or things like that. And so the process model that exists inside of open SSH, as soon as you connect, what's going to happen is it's going to fork a separate process that's called the privilege monitor process, which is going to facilitate your connection now, right? So basically it accepts it, forks a new process, and hands you off to that other process ID.

You're going to set up your connection for user authentication, and then you're going to make another connection or another process that's going to be used for actual data exchange. And this becomes interesting and very practical to us because how many times have you guys restarted your SSH daemon and have not gotten kicked out of your system, right? Just raise your hand if that's happened to you, right? This is why, because you're literally running in a separate process space.

So it's become to our advantage if we have to make configuration changes or things like that. So let's get into a demo. So we're going to do some basic stuff. We're just getting started with SSH. We're going to look at some host keys. We're going to examine privileged separation, how it works, basic remote command execution.

Quick layout of my lab here because we're doing like remote access stuff from me jumping around between computers. This is what we have going on. I have a domain controller, a Linux management workstation, CentOS SW1, a Linux server that we're going to play with, a CentOS S1, and a Windows Server in this awesome cross-platform world that we live in nowadays.

If you guys have questions, feel free to ask. So I'm going to put these demos online so you guys be able to walk through it on your own. But we're going to go through some basic plumbing stuff right now. So to log into a system, it's going to be username at

hostname, so CentOS-S1. And that's going to be how I can go and attempt to get from the system that I'm in to the system that I want to be in. I am then presented with my host key or the host key from CentOS-S1. At this point in time, I have to make this decision. Do I actually trust the system that I'm trying to log into? I built it. I don't trust it. So let's go ahead and

accept that key, and it's going to bring that down, and then it's going to pass me into... Really? What are you doing? Ah, there we go, okay. Don't type in demos. I pass in my password. I get authenticated to the system CentOS-S1.

You can see the new prompt there. So let's get out of that system and look at what actually just occurred. So what actually just occurred is when I downloaded that host key from the remote system, it created this directory just a second ago with these particular permissions, which we're going to talk about a little bit later, and

inside there, we have this thing, now a known host file. Wait, hold on. PowerShell is not. No, that'll be alright. Cool. Known host. So inside that file, we had the representation of the host key for the system that we just logged into, the host name, the IP, the key type, and the actual key, right? So that exists on our system. So now all subsequent logins between me and that server will exchange that information to validate that remote system. Very important.

So let's go ahead and see that in action. If you haven't used the minus-v attribute on SSH client, it's pretty cool because it does things like this. You get to see what actually is occurring in your connection. And so we can see the entire process to understand how

it actually works. So as we scroll up, we can see that it goes and starts the connection. I'm going to jump through the, I say the less important stuff, but stuff that isn't exactly poignant right now. It's going to find our host key identified in our file.

So you see known host colon one. It's in position number one. So if you do see an error, you'll see an error on a host key that's changed. That value will be the number of the key inside your known host file. We then do a key exchange, and then we transition into authentication, which we'll talk about in the next demo. So with that, let's go ahead and log into the system.

Because, you know, passwords. Oh, oh, permission denied. Okay, good. Let's go ahead and ask.

We're going to log in the nesento-s1. Tudo netstat minus, this is very easy to remember, netstat minus plant. Gives you some really cool output. Watch this. grep SSH. We get all the listening ports on the system and active connection.

So you see we're listening on the SSH statement. Its process ID is listening on all IPs. We also see the IPv6 version, so SSH-D, listening, but we also see my connection. So that privilege monitor process, SSH-D, 1599 is established. That's my connection running independently of the other one. So let's take this command. I'm going to copy and paste this because it's challenging to type in demos.

What this command will do is gives me the process tree for that particular process. So we can see the command that I'm executing, the shell that I'm running in, the pseudo-terminal, so PTS is pseudo -terminal, which is my environment that I'm running in, that's being managed by my privilege monitor process that forked off of the original SSH-D process, right, the actual daemon that's listening.

So now if I do sudo systemctl restart SSH-D, I didn't get kicked out. That's pretty cool. And then if I go and check that again, we can see that it forked the process off. I get the same process ID 1599.

And I just go about my day, right. So understanding that it's a nice little feature, but also keeps us from having to be so terribly concerned about the surface area that's exposed to the world on our system. Now finally, the super basic demo is we're going to do this.

Log back out to the workstation, so w1. I'm going to use SSH, my credentials, and then pass a command, simple command hostname, the remote system. I have no idea what that's all about. I even reboot it before the demos. It's always DNS, right.

Given my password, it executes that command. That command's output comes across over standard streams and goes to my console here. This becomes very valuable in being able to blast commands at lots of systems and also retrieve data concurrently. So we retrieve data programmatically. All right, so demos, we did that. Let's talk about

authentication methods. Sorry. All right, so authentication methods. So getting users into your service. So now that we know how to get there, let's talk about how people get authenticated to our systems. So authentication methods.

GSS API, generic security services API, Kerberos. Not the Kerberos that you're thinking of when it comes to AD authentication. This is the actual daemon itself doing authentication for users and the service, right. So we're going to skip over that and go to, or not skip over that,

we're going to talk about how we would do AD auth in a little bit. Host-based authentication, where I can say two systems can log into each other without a password. That sounds not good, right. Not commonly used, but legacy systems find that they have that, the need for that sometimes. PowerShell has a similar concept too, doesn't it, in remoting. We're talking about host-based authentication. No one is nodding, so I guess not.

Yeah, basically you can figure that in your server side and say this host and this host can talk to each other.

Yeah, that's a lot better than that. But we have this public key authentication, which we dabbled with a minute ago when we looked at the graphic at the beginning of the session. Key-based authentication. We generate the user key pair. We can put that on a service, right, and execute jobs like that with passwordless authentication. When you generate a key, which we're going to do in a little bit,

it asks you, do you want to put a password on there? Most of the time people say no, enter, enter, enter, enter, and the key gets generated. And then you can do what's called passwordless authentication, which is great, right. But if you're into it, put a password on your key, because then boom, you have two-factor authentication and you didn't have to pay a vendor a million dollars to get that, right. So very valuable.

Something you have, your key, and something you know, your password. Interesting side story. When I was a PhD student, my PhD advisor had come from the University of Hampshire to the University of Mississippi, and he literally had the same public key, private key pair, for 11 years with no password. I'm like, dude, really? And so at the time, I was a systems guy for the computer science department.

Like, you have to do this. He's like, I'm not doing it. It's like, I like servers all over the planet that I have to work with. We did a whole bunch of like geo-cluster stuff. And so that was challenging. So not only that, but people get under the misconception that you have to have one key. You know, you can actually specify multiple keys and generate those per systems or groups of systems,

so you're not restricted to using just that one key. Challenge response. Actual two-factor authentication and in passwords. Who loves password authentication? Right. So actually password authentication, I think, is a misnomer. I actually don't like the fact that it's called password authentication on SSH, because what it's really doing is handing off your authentication to the underlying operating system, which, yes, is passwords.

But this is also how we would configure AD authentication, because we're asking the system to do is we'll configure Linux to authenticate users against AD. And then we just we just say that SSH, we use password auth. So we'll hit password auth. We'll pan off the authentication to the underlying operating system.

It will make the decision, do I authenticate you against a local user database or active directory based on the configuration of the system? So password auth is how you get that done. Another thing that's very interesting is these are processed in this order from top down, right? How many times you've distributed a key to a system and all of a sudden you get challenged with a password, right? Because something went wrong with the key distribution, right?

This is why, because they are processed in order by default. If you remove password authentication from that, from that, let's say, from the lineage of authentication methods for your system, and you had an issue with your public key, then you won't be able to get in, right? Because you don't have that authentication model enabled. So make good choices when you want to figure out how to do that.

So authenticate users. So we talked a little bit about this already. We have the local user databases on our system on both Windows and Linux. On Windows, you have the on a local SAM database, I think it's whatever that's called. On Windows or on Linux systems, you have the password file and the shadow password file that authenticates local users.

We can configure AD authentication. Out of the box, on the Windows side of the house, pretty straightforward. Configure AD authentication, you join a domain. It works. Yay. So AD authentication can be used on Windows and Linux. So when you install OpenSSH on a Windows machine, you do nothing. It just works if the thing is domain joined. We do want to differentiate when we're talking about authentication between user lookup and

actual user authentication and host authentication. So when you are doing things like combining AD authentication with passwords or with keys, you'll figure you'll see why there's a difference when we do that demonstration in a few minutes. On a Linux side of the house, the system security services daemon, or SSSD, is

what's basically going to broker the deal for your user lookup and your authentication to AD. So we install this thing, SSSD, on Linux. We run one command to join the Linux machine to the domain, and we will get AD integrated authentication out of the box. SSSD will manage that all under the hood for you. Configure LDAP, configure Kerberos, and also

configure your local PAM authentication libraries to differentiate between local and remote user database lookups. I'm going to demo this tomorrow, that configuration tomorrow, in my session with Richard. When we do AD auth, you get this wonderful syntax that's going to be the username at the domain name at the hostname. You can shorten it up if you want to, but I

actually don't mind it as much. In most of the systems that I've done, where I've done AD integrated authentication on Linux boxes, I have taken it off. So I would just do AEN at hostname. That's a little bit more of an advanced configuration. So like I said, tomorrow we are going to go through this stuff. So key-based auth. Let's talk about key-based auth because it's a common thing that trips people up and how it works.

So let's get through the concepts and we'll show you guys how to do it and how to troubleshoot it in a few minutes. SSSKeyGen is the command that we would use to generate a key, a public and private key pair, for us, right, as users. We generate a public key. By default, it's going to be called ID underscore RSA dot pub or whatever dot pub, right? You can name it and then use that for other things. And so, but ID underscore RSA dot pub is the default and what your configuration files will look for

out of the box. But you could specify a key. If you guys use AWS, right, you know, you use that minus I attribute when you download the key from them. That's the same concept. The private key has no file extension by default and it's called ID underscore RSA. That's the thing that you want to keep very, very, very, very secure.

Getting keys out to servers can be interesting, to say the least, especially in a cross-platform world. In the Linux world, super easy. We have a command called SSH copy ID, which is a bash script that will look at my local keys. It will then SCP that over to the remote server, put it in the right place, set the permissions correctly for you, and that'll get you what you need.

And we'll demo that today. That does not exist in the Windows world, being able to do something like SSH copy ID, because SSH copy ID does remote command execution. So it's not cross-platform. So things like mkdir don't mean a lot on, or chmod don't mean a lot on Windows systems, right? I wrote a blog post about how to distribute keys to Windows systems a couple weeks ago. That's pretty cool.

You can use DSC to push keys out. So if you're doing any sort of automation, that's actually quite cool. And you can use actual PKI. I used to have a link to a Facebook post about this, like the engineering team Facebook post, but they kind of aren't in a good situation when it comes to information security right now. So let's get a little demo and look at generating and distributing the user key, and also using a specific key for

authentication. So to generate a key, pretty straightforward, SSH minus key gen.

Where do I want to save it? I want to save it in that dot SSH directory, which is where all of my other SSH stuff type stuff lives for my user. I'm going to call it id underscore RSA for the private key. I'm not going to give it a password because I'm lazy, even though I told you you should do that. Let's see. Now with that,

here, we can see we have id underscore RSA, id underscore RSA dot pub, and known hosts, which is the host keys. So let's take those, SSH, and copy them to our system. We're going to copy them over to this guy.

Mostly, yeah, it's part of the OpenSSH installation. So if you go, which is really kind of funny that it's not supported on Windows, but it's part of the GitHub project that's managed by the PowerShell team because it's a direct fork of the code. So it just literally exists in their build.

So I don't know why this is so slow. So right now it's going to ask me for my password because it's going to SCP it over there the first time, and during that transaction, it's going to make the directory and stick it in the right spot and set their permissions for me. So let's go ahead and log CentOS

into the server, and I should be able to get in no password. Excuse me. Okay, totally. Hold on. We'll get there. Hang tight. So inside there on a remote system, we're going to have

that, which is going to be our public key on the remote system. We're going to talk about the security applications of this now. On a Windows system, actually, we're not going to do that right yet. We're going to back out and do this one more time. So now I'm back on the workstation. I'm going to throw a minus V on here and then log into the system again because I want you guys to see

how this works under the hood. So connection attempt, host key, random delay because of demos, and we get logged in. But I do want you guys to see this. What happens from authentication? They're processed in order, right? So we see a GSS API first, Kerberos, that fails, and then it goes into public key. It presents the key, and

then we see authentication succeeded, and the method public key, right? So then we're authenticated to the system, and then we get in. And so that's a good command to know. Like if something's going wrong, SSH minus V. Yes.

I'll have to look into exactly why that's defined that way, but yeah, I mean you would think that it would be pub in there. we looked at that already. So cat

SSH Authorized keys. So that's my key on a remote system living its life. Now, let's do this one more time. Let's go in SSH. Now we're going to do SSH keygen minus F windows. So I'm going to generate another key named windows.

No password, and we look in here. We see we have another pair, windows and windows pub. To emphasize the point, we have to do this. So in windows, and the

authorized keys are going to live in your windows profile in the dot SSH directory, right? So we see C users AEN dot SSH. In that directory, the parent directory, by default, since it's in my profile, will inherit the permissions from the parent. Right? There's a concept called strict modes in SSH, in your SSH configuration, that requires that the

folder containing your public key, and on the remote side, the authorized keys, is not world readable, right? So if we look at this, not world readable. We see just read and write.

The same concept exists on the windows side. So we have to do these shenanigans to make this work, right? So when I said SSH copy ID did the work for you under the hood to make the permissions correctly, it does that. But we don't have that feature in Windows yet. So I just put these commands together to go ahead and have the ability to put the key on the remote system and show you guys, in gory detail, how that works. So we're going to use this command sequence to make the directory.

We're going to copy our windows key over to S1. We are then going to, I'm going to copy it over as my authorized keys, because if there is a key over there, I don't want to stop over it. So I just take that and I append it to the bottom of the file. I remove the inheritance attribute, I grant system rights to it, and then I grant rights for me. We add system in there because the SSH

process, the server, needs to be able to read the key to auth the user. You can just stick it in the bottom, it'll search it.

We can go try to put in a space in the front of it, I've never tried that before, but it'll search the file sequentially. so we're logging into the Windows system for the first time. We need to accept its host key because we're sending it over to the Windows box. I think that totally just, oh, I got it right. So we're making a directory. We're going to copy the file with SCP over there.

Paste. We're going to then append it to the bottom of the file. Paste that in there. Deal with the permissions inheritance. So we'd have to do this on the Linux side of the house conceptually, but it's all buried inside of SSH copy ID for us.

Set the system permissions. Give that our password again. I couldn't find a good way to combine this all in one line. So we're stuck doing it this way. There's another way I would have liked to have handled this, but the OpenSSH on Windows doesn't implement a particular feature that I want or need to have it work that way.

So if you notice the last time I copied it over, it actually didn't ask me for my password when I changed it and added me because system was able to read it and I gave, I got keyless authentication into the system. So now let's do this. Let's do minus vvv, which is really verbose.

If we go and we look at, where is it, we see our key based authentication. So this actually might be similar to the question that you were asking. It sends over ID underscore RSA, which isn't on that Windows system, right?

We sent over Windows to the other system. That fails. So we see the failure. We then send the next key, which reads the next key that's available in that configuration directory, which happens to be the second key that we generate it, that one. We then authenticate to our system and so we can see that

there. If you want to specify the key, this is why I love, what do you call this, VS code. If you want to specify the key, we can use this command. So we do minus vvv this time because there's a particular piece of output that I want to show you guys. Minus I and then I specify the key and then we get logged into the system.

But this time it used that particular key that we wanted to use. So this is a good way to be very specific with which key that we use. So the first one it sent over is Windows.pub and it doesn't have to search for the next key.

All right, so more computer stuff. So OpenSSH configuration. Let's talk about how to do some stuff. We're gonna talk about where the configuration files live on the server and on the client. First up, on the server side of the house in Linux, your server daemon's configuration file lives in etc, SSH, SSH D underscore config. On Windows it lives in percent program data, SSH D underscore config. Conventionally

we install things in program files. That's where all the binaries live. Your configuration files, your logs, and your host keys will live in percent program data percent. Same configuration file, all very similar configuration syntax. The files are nearly identical with the exception of platform specific things like paths.

On the client side of the house, we have SSH underscore config, which is going to configure global client functionality for the entire system that we're on. As people get confused between SSH config and SSH D config. SSH D daemon, SSH client. That also can live in your home directory. So you can make a specific configuration file for you and build up some good shortcuts and aliases and things like that

for your connections. That lives in percent user profile percent on Windows systems in dot SSH config. So let's look at that. I totally

didn't tell you what the demo was going to do. That's probably an important thing, right? We're going to do some server configuration overview. We're going to look at the configuration file. We're going to limit access to a particular group because out of the box on CentOS machines and on Windows machines

anybody can get in. And so we're going to use an AD group to secure the system with the scope who can actually log into the system. And then we're going to look at some configuration overview where we're going to configure aliases and specifying those keys so we don't have to specify that every time we log into a system.

I'm going to make a really bad judgment call right here and do this because sometimes that the terminal color gets all spoiled and I don't know how to fix that.

So what we're going to do is we're going to log into from the workstation that we're on, log into at CentOS dash S1. We're going to get logged into our server and the first thing we're going to do is configure group filtering.

I'm going to use the command ID to get the user attributes for this particular user. The CentOS machine is already domain joined so I have the ability to go and ask Active Directory for the user attributes for this particular user with the command ID.

So basically I'm just testing the plumbing right to make sure that that works so my demo doesn't bomb. You can see that I am in a group called SSH users which is a simple AD group that this user just so happens to be in. I want to go ahead and use sudo to edit

SSH SSH D config. So inside of here, grab this and put this in my clipboard. No, no, no, is where you'll have all of the configuration stuff that you will need for your SSH daemon.

If you're not familiar with the man pages, the man pages is basically online documentation. On Linux systems, man sshd underscore config and you'll get pretty much everything you need to know that's a configurable attribute inside this system or inside this configuration file. One of the things that is neat, or not neat, but nice to have is that's commented out

so it's actually not an active configuration, but that's the default value, right? So that's nice to know when you're going through this. So it's gonna be on port 22 for any address family on all IPs and things like that.

I have a page down key for the first time in 20 years, which is kind of nice. Permit root login, yes, that's the default value. Obviously, that's a bad thing if this thing's gonna live on the internet. Strict modes, yes, that's that thing that makes sure that the parent directory that our configuration data lives in is not world readable. Public key authentication, yes, that's where that file lives on the system, but we're gonna authorize users into.

Let's see, host-based authentication and things like that. Password authentication exists there. And so let's go ahead and jump to the bottom and add this line. Allow groups SSH users at lab.centinosystems.com.

So basically now I'm gonna scope and no longer allow anyone else except unless you're in that group to get into the system. Which is, I think, a pretty good thing to do out of the box. All right, so let's go ahead and restart SSH D.

Didn't get kicked out. That's a nice thing. Let's go ahead and do this. So we made that configuration change on CentOS-S1. We're on W1 now and we're gonna go ahead and log into that system like so.

Machine is so slow. Right, right. The hackers just get impatient and leave. So I'm gonna log into the system and it's gonna take forever and it's gonna tell me my password or my permission is denied.

Can anyone tell me why I can't log into the system? A little louder. Right, that's the local user AEN, not the domain user. So I'll simply just go back. See you guys are paying attention. Such a warm and fuzzy feeling. .com. This is why you don't type in demos. The magic of command-line logins. Yay, right. So I logged in as

Actually, I don't want to do that. I'm gonna do that. So AEN at lab.centinosystems.com. So that actually works quite well. We have to do one more demo. It just couldn't be available to the world. Yeah, so you wanted to look like that. So breaking down the permission set, the owner in the group, right?

And so read write and execute, that's just for me. All the other ones are dashes, which means the group doesn't have access and other or world doesn't have access to the directory. Is that what you mean?

I was trying to copy a file as part of an automated process, but the account that was logging in to run the script was different than the account that I set the key up for. It wouldn't work. And so if there were nothing else before I processed and figured all that out, I learned that it has to be the user who set the key.

Right, because if I have, if that If that's Bob, right, and I try to log in as AEN, Bob doesn't, or if that's Bob and I try to log in as AEN, well, I don't have access to that because it's owned by Bob, right? Yeah, and so we want to restrict it to the user that is configured. So let's do one more demo. So we're gonna go and look at configuring.

So that was my point, actually. So it's not the DRWX, it's the user part, right? It has to be, right?

Can I actually do a, what is it, CH? Chamod? Yeah, yeah. Did it make the username correct? That would be chalen or chagroup to do that, yeah. So, it still has to be 7, 0, 0, or? Yes. Yeah. Well, not world readable is what strict mode is.

All right, so let's do this. So I'm gonna show, this is gonna demo this right now. Oh, SSH copy ID? Yeah, look at the source code of that. Like, go to GitHub, even for the PowerShell project. Just look at the source code, and it'll explain in gory details. You'll see how it does its thing.

So let's do some aliases real fast. So in our .sh directory, I'm gonna create a file called config. And in there, I'm gonna drop in this text. And we're gonna walk through what this means together.

So this is a user specific configuration because I'm creating this file in my home directory. I could certainly put this in etc SSH, SSH underscore config, for reals, SSH config, and have this be system wide. But I'm doing this just for me. And so what I'm doing is I'm declaring a host name Linux with the user.

I'm gonna use, always use those attributes for that connection. And so that particular user, that particular host name, and that particular file. There's several, I'm gonna say several hundred, but there's many, many, many configuration options that you can use. Very advanced stuff that you can set up your tunnels this way so you don't have to go and memorize that syntax every time to make that, to do those more advanced configurations.

And that's SSH config file. So, to call it, I just call what I named it, right? So I say SSH windows. And I get a bad ownership problem because strict modes is enabled. So I have to deal with that on that file.

So that file gets created with the fact that it's world readable, which is bad news, right, in this world. So we do chmod, someone said six hundred, seven hundred, I do six hundred. And we do config. So I will get this permission set where it's just read and write and no access to anybody else.

And now I can say SSH windows and I'll connect into that system, I'll specify the right key and all that stuff. So that's a good way to, you know, build up a nice short set of aliases for the systems they have to get in and out of very frequently.

Yeah, so if you are setting up things, group membership is super easy to do, right, but it also provides a lot of value, right? Being able to scope who the authorized users are to get onto your system. So let's wrap it up, they already clapped, I guess it's my signal to wrap it up.

Let's talk about what we talked about. Remote access concepts, right, we learned about the important things like authentication, authorization and integrity. And how that's implemented in OpenSSH with the features that it has like host keys, user authentication methods and groups, right? Now we kind of went through those big bucket configuration items and why those things are important to configure out of the box to make your system more secure. We talked about, we did talk about authentication methods and we also talked about how to configure that stuff in our system and some of the gotchas.

Tomorrow I'm going to do basically from a zero, on a Windows system, no OpenSSH installed all the way up to AD integrated authentication, key-based, all that stuff. Richard and I will be doing that tomorrow at 9 o'clock.

So here's my contact info again, the two Pluralsight courses, if you want more access to this stuff, free cards right here. And if you guys want to get into that much more time and details, I do have things like TCP tunneling is covered, remote command execution, iterating over sets of hosts and things like that is covered in there and how to deal with the command output and things like that.

So check that out and thank you guys for coming. I appreciate all of your time. Have a good rest of your day.