Check out a free preview of the full Full Stack for Front-End Engineers, v3 course

The "File Permissions" Lesson is part of the full, Full Stack for Front-End Engineers, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Jem walks through updating the file permission authorized keys and disabling logging into the root to prevent unauthorized access to the server.


Transcript from the "File Permissions" Lesson

>> So next we're gonna change the file permission authorized keys, ssh will complain over time because it's very particular about the permissions. We're gonna change it to 644. Then we're gonna disable our root login. And then we're gonna restart the ssh daemon. So why do we disable our root login?

I will show you. I have gone on about it, but I wanna demonstrate this. So we're gonna say sudo Slash cat again, slash var. And we're gonna take a look at the auth log. So remember, logs live at /var/log/auth.log here. And we can say auth.log, Then you put in your password.

So what's going on in the world today? So auth.log is gonna say, hey, what's going on in our system? And this is not, it's hard to read when it's so zoomed in. But auth.log just says, hey, who's trying to connect to our system and what's going on? And already this brand new server barely connected to the internet, doesn't do anything.

What do you see in your auth log?
>> Invalid user. Trying to connect.
>> Yeah. You see a lot of, you might see random usernames. They're guessing commonly used. Usernames see a lot for root cuz that's pretty common. Where's a good one here. Invalid user called user. So the minute you bring a server online into the world.

People are gonna try to connect into it. Over time you'll see this grow, you'll see various different types of exploits trying to be applied common passwords, common usernames, common ports. So I talk a lot about security, I spent a long time on it probably not enough time, honestly, because this is the reality of the world you're living in.

Everybody is trying to get into your system, and if you give them even a little bit, they will take over, and then it's gone. The only way you can solve that is to delete your system entirely, which sometimes, if they get far enough, you can't even do. You've lost control of your system.

Hence, SSH keys. No passwords. We're gonna disable root login, just to be sure, cuz we don't ever ever need to be logged in as root anymore. I found that SSH authorized keys was already there and maybe there. It kind of depends on how you set up the system.

If you follow those same steps, it's never been there for me. I've always had to create it but Again, there's so many things going on. It's possible you did something a little bit different this time around, maybe use a different operating system or a different version, or something else.

>> Still logged in as root possibly?
>> Yeah, if you're like this route, that authorized keys file will probably be there. So you need to switch to the user you actually need otherwise none of this will work. You'll just be logging in. You're just like saying the same information that's already there.

Yeah, good. Good call there Kyle. So the next thing we wanna do is we wanna change the permissions of the authorized keys files. Otherwise when we restart the ssh daemon, the thing the process that's actually listening for ssh connections, it's probably gonna complain. So we're gonna use something called chmod change.

Actually, we meant chmod change file mode bits, yes. So remember we said ls- la shows the permissions. So these are the actual permissions for the files. Read, RS stands for read, write sensor right x stands for execute but there's different levels, there's route, there's anybody and then there's the user itself, and I forget the actual order cuz we'll cover permissions a little bit.

Let it on the road but chmod is just saying we're changing the bits of access to that. So in this case, we're gonna say chmod 644 and I don't think we need sudo for this. Yeah, we don't need sudo for this, and we're just gonna change the permissions on the ssh file.

Actually we're diving into that just to check all the permissions here. Clear ls- la, so I'll take a look, right, so it's chmod 644 and then we're doing the authorized keys. Now let's do ls -la. Okay, so we see we've changed the, it's never executable, authorized_keys will never be executed it's not a script.

So all we did by change the permissions we just flipped a few more bits saying, we are the only ones allowed to write to it are using. Everyone else can read from it that's totally fine, any process, any system can read from it, but we're doing once you're allowed to read through it.

And that's what we did with 644. We'll talk a bit more about permissions, the numbers don't line up the way you think, it's not like a straight forward thing. It's just something we had to do for this html, the next thing we wanna do is what do we say, we wanna disable the root login.

So now we're gonna look at our ssh_config. So config and files, when we get to ngnx, it's always gonna live under the /etc. So let's go ahead and check that out. However, we do need to be sudo. Anything in etc is gonna need to be sudo cuz we're messing with things now, getting real serious.

So I'm gonna say, sudo vi/etc/ssh, and we want the sshd so that's the ssh daemon, the process that's running, we want the config file there. First diver. All right, so there's a few parts of this whole process where I say if you touch things, they can go off the rails very quickly, you can lock yourself out.

This is one of these times. Try not to mess with the ssh config file unless you know what you're doing. There's a reason why we follow these exact steps for creating the user, double-checking SEO access, logging out, making sure we can log in as the user before we disable root.

Because if you can't log in with your new user and you disable root, what happens?
>> You lose access to your server.
>> You lose access to your server and no one can get it back. You have to delete your entire server and start over. So we don't want that.

That's why we follow these very, very tight steps just to double-check we're in the right place. So if you're not there yet, do not do this step until you have all the previous steps. So let's scroll down to PermitRootLogin, and we're just gonna edit that file to say no.

No There's a lot of other fun we can have in here, we can enforce passwords ssh keys, you need to have passwords, we can disable them, we can change our port, we can do lots of things. But again, don't mess around in here too much unless you know what you're doing, you can put yourself in a corner very quickly.

So we're gonna escape. We're gonna write quit. But that's not it. Anytime we change a config for a daemon, a daemon is an process. It's not reading the config file. It only reads it once at runtime and then it keeps it in memory. So we need to restart the ssh process.

So we can say sudo service sshd restart, all right. Hopefully you didn't get kicked out at this point. If you had kicked out, something bad happened and I don't know. All right, a quick tip if you ever, I'm tired of suing everything I really wanna be root. If you say sudo-i, you can jump back to root.

So the user is always there, root is always there. You can't get rid of it, obviously. But we don't operate as root most of the time or actually any of the time. There are some cases where do you wanna do is when you're tired of suing, but I really don't recommend it.

So we'll say exit, we'll jump back out to our original user. And let's just test this out just to be sure that we actually did something. So I'm going to SSH and exit out. I'm going to try to log in as roots, and it should deny me if we did things correctly, which is good.

So I'm going to ssh back in. So if you did something wrong, you can't log in as root and you can't log in as your user, it's okay. Go back through the slides and the steps and just follow the steps again to recreate the server and bring it back up and double check every single line you're doing.

This I will say is the most dangerous part of the course in terms of where things can go pretty wrong for you but we're pretty careful.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now