ssh Archives • Page 3 of 4 • Linux Tips

Disallow SSH Login For A Specific User

In today’s article, we’re going to learn how to disallow SSH login for a specific user. The reasons you might want to do this should be obvious, so that’ll save some time! Read on to learn how!

I’ve covered SSH in many articles. If you search for “SSH”, you’ll find a bunch of articles covering the subject. I’m not sure why there are so many, but there are. I seem to have a lot of notes on the subject.

Here, this link will help you search for SSH articles.

SSH is “Secure Shell”, a method to login to remote computers so that you can manage them without being their physically. It’s used by systems administrators regularly, without ever needing a GUI to manage their Linux systems.

It’s also used by people like me, too lazy to walk to the other side of the room. I’m literally using SSH to manage stuff on my laptop from here on this desktop as I write this. On top of that, while not logged in right now, I was using SSH to manage a VPS earlier today.

So, SSH isn’t just for professional system administrators and, if you use SSH at home, you might as well know how to secure it. This article will help you secure your system – by learning how to disallow SSH login for a specific user.

Disallow SSH Login For A Specific User:

This article requires an open terminal on (and connection to) the computer you wish to change. That may require you to login to that computer remotely. If you’re on a local device and you don’t know how to open the terminal, you can do so with your keyboard – just press CTRL + ALT + T and your default terminal should open. Otherwise, SSH into it like a boss.

With your terminal/connection now open, enter the following command:

sudo nano /etc/ssh/sshd_config

1	sudo nano /etc/ssh/sshd_config

Find a place to make a new line and enter the following with some care:

DenyUsers          <username>

1	DenyUsers <username>

Now, this one is a bit picky. Obviously, you substitute <username> with the real name – but in between “DenyUsers” and the username you absolutely MUST press the TAB key. If you try to just use spaces, it will not work! You MUST use the TAB key which will appear to insert spaces for you!

Assuming you’ve done everything correctly, you’ll need to restart SSH for the changes to take effect. You can do that with this command:

sudo systemctl restart ssh

1	sudo systemctl restart ssh

If you were logged into a remote system to make the changes on that system, the above command is gonna log you out and you’ll need to login again. You knew that, but I figure I’ll mention it.

Hmm… If you’re a barbarian that doesn’t use systemd, try this:

sudo service ssh restart

1	sudo service ssh restart

When SSH restarts, the prohibited user will get a “Permission Denied” message when they try to login. Ha! That’ll teach Jerry in accounting from thinking he’s a system admin!

Closure:

Whelp… You have another article. This one has shown you how to disable SSH login for a specific user (Jerry in accounting, who had no business accessing the server anyhow). You’re welcome!

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

Check Your SSH Server Configuration

Today, I’m going to show you how to check your SSH server configuration. It’s a simple process, but not one many people seem to know about. It’s also a pretty handy tool if you’re having SSH issues. Once again, this one isn’t all that complicated, I think… Read on!

So, why would you want to check your SSH server configuration?

Your SSH server might not be working. You may have made some changes and want to test it before moving it to production. An upgrade to the SSH application may have made some of the options different or even removed the options entirely.

There are all sorts of reasons why you’d want to check your SSH server configuration. Those are just a few of them. Not only will the article show you how to check your SSH configuration files – it’ll show you how to test alternative configurations. So, you can test your changes before making them – potentially saving you a physical trip to the server.

Check Your SSH Server Configuration:

This article requires an open terminal, like many other articles on this site. If you don’t know how to open the terminal, you can do so with your keyboard – just press CTRL + ALT + T and your default terminal should open.

By the way, I would test/learn this on a local system. You’re potentially going to break things. In fact, let’s start by breaking them! Well, let’s create a backup first, and then we’ll break stuff.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

1	sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Okay. Now let’s break something! Run this command:

sudo nano /etc/ssh/sshd_config

1	sudo nano /etc/ssh/sshd_config

Find a line that has a command and doesn’t start with a #. You can also remove the # from an option and it’ll be work. Find a one line option that has a “no” option field and change it to “oh_no” *sans quotes, though that probably won’t matter) and then save the file.

(Also, to save the file in nano, press CTRL + X, then Y, and then ENTER and that should do it.)

Now, let’s check that SSH server configuration with the following command:

sudo sshd -t

1	sudo sshd -t

If things go according to plan, it will tell you that you have an error. On top of that, it will tell you on which line you have the error. If it doesn’t throw an error, it means your configuration is fine – or that you may need to restart your SSH service for it to see the new configuration.

If you do somehow need to restart SSH server (you shouldn’t have to), restart it with the following command:

sudo systemctl restart ssh

1	sudo systemctl restart ssh

Run the command again and that should definitely show the error, which you can easily fix by simply undoing what you did in the steps above and saving it. You almost certainly shouldn’t need to restart SSH to show the error, though you may want to restart it after you’re done playing around in the config file. Of course, if you did have to restart the SSH server, you’ll need to do so again after fixing the error you intentionally introduced.

BONUS: If you want, you can list the path and check a configuration file that’s not actually in use. So, you can check the configuration file before putting it into production. That’s just:

sudo sshd -t /path/to/new_config

1	sudo sshd -t /path/to/new_config

Again, under normal circumstances, it won’t show any output if it finds no errors. It only outputs information if there’s actually an error. So, a null response is considered normal and good.

Closure:

See? Nice and easy. Now you can check your SSH server configuration for errors – even doing so before putting the config into production. It’s a pretty handy tool to have. Also, you’ll need SSH installed and running on the machine you’ll be testing with. I figure that’s obvious, but I better mention it somewhere or someone will point it out or ask about it. Then again, people seldom read this far down in an article.

How To: Transfer Files Over SSH with SCP

In this article, you will learn how to transfer files over SSH by using ‘scp’. If you need to transfer files over a network, this is one way to do so. There are numerous other options to transfer files over a network, and this is just one of them. Feel free to leave a comment sharing other ways you use to transfer files over SSH.

We have had quite a number of articles about SSH. It stands for “Secure Shell” and you can click to find a collection of SSH articles. If you’re entirely new to SSH, you’d probably enjoy learning how to install/enable SSH. As mentioned, there have been a bunch of articles covering this subject.

Today, we’ll be using ‘scp’, which defines itself as:

OpenSSH secure file copy

It shares quite a bit of similarity with the ‘cp’ command, a command we oddly haven’t covered yet. That’s not too important. We’ll eventually get to that article and maybe remember to link back to this one. What’s important to know is that it shares some similar features and syntax.

So, today we’re going to use ‘scp’ to transfer files over SSH, over a network. It’s a pretty good skill to know, as copying files is probably the 2nd most frequently used feature over SSH, with device management being first. At least it’d be 2nd most for me, I’m not sure what you all do with it.

Transfer Files Over SSH with scp:

You’re also going to need a device you can SSH into, and I can’t really help you with that. You can always install OpenSSH on your desktop and practice by using SSH over localhost.

Now, with your terminal open, it’s time to transfer a file. The very most basic command to copy a file to the remote server would be:

scp <file> user@server:/path/to/folder/

1	scp <file> user@server:/path/to/folder/

You can also copy multiple files to the remote server:

scp <file_1> <file_1> user@server:/path/to/folder/

1	scp <file_1> <file_1> user@server:/path/to/folder/

You can copy all files from the directory you’re in (on the local device) easily enough. It’s just our beloved asterisk.

scp * user@server:/path/to/folder/

1	scp * user@server:/path/to/folder/

If you want to copy the files from the folder in AND the files from the folders in that directory (recursively), then the command just requires a -r flag.

scp -r * user@server:/path/to/folder/

1	scp -r * user@server:/path/to/folder/

You can actually go the other direction. If you want to transfer remote files to your local device, then you’d be looking at this command:

scp user@server:/path/to/file/<file>.txt <new_file>.txt

1	scp user@server:/path/to/file/<file>.txt <new_file>.txt

From that, you can use the above commands, extrapolate if you will, for ways to transfer the file to your local device from the remote device. It’s not terribly difficult, and ‘scp’ is something everyone should know if they’re working with remote computers on a regular basis.

By the way, setting up SSH on your computer isn’t a bad idea. Sometimes a malfunctioning computer can be accessed via SSH when nothing else will work. I have SSH installed (and secured) on pretty much every computer in the house.

Closure:

See? Now you know how to use ‘scp’ to copy files over a network via SSH. It’s a pretty awesome skill to have and one you may need until the end of time, or at least as long as Linux lasts as an operating system – which should be quite a long time. So, it’s in your best interests to learn how to use ‘scp’ with at least a basic level of skill.

How To: Disable Password Login For SSH

In today’s article, I’m going to show you how to disable password login for SSH. Security is important and this can be a step in your securing SSH. After all, without password login enabled, you can’t have someone brute force your password!

And that right there nips in the bud why you’d want to make this change. You want to eliminate an attack vector, so you disable password login for SSH and you rely on SSH keys.

NOTE: I’ve had a number of SSH articles. Feel free to scroll through them, as they cover a number of SSH options. If you don’t know what SSH is, click the links in the above two paragraphs and we’ll be on the same page. In short, it’s a tool to remotely login to systems so that you can manage them without actually being at the computer physically. It’s a widely used tool.

It goes without saying that professional admins tend to do things like secure their SSH logins, and disabling password login for SSH is a good step to take. It’s also a step we laymen can use, ’cause it’s really a very simple operation. So, that’s what this article will be about. It’s an article that tells you how to …

Disable Password Login For SSH:

Now, you’re going to need to do some file editing. For that, we’re going to use our beloved nano. So, start with this command:

sudo nano /etc/ssh/sshd_config

1	sudo nano /etc/ssh/sshd_config

That will open the file with your nano editor, where you’ll look for a line that looks like this:

#PasswordAuthentication yes

1	#PasswordAuthentication yes

And you’re going to change the ‘yes’ to no, and remove the # that means ‘ignore this line’, so that it can take effect. When you’re done, the line should look like:

PasswordAuthentication no

1	PasswordAuthentication no

Now, you’ll want to save it. In nano, to save a file, you press CTRL + X, then Y, and then ENTER.

With that done, you need to restart the service. That’s easy enough, you just run the following command:

sudo systemctl restart sshd

1	sudo systemctl restart sshd

That will restart the service and use the new settings. So, be sure you have your ducks in a row, ’cause once you restart that service you’re not gonna be able to login with a password again. You’re not going to get a redo, ’cause it restarts the service – meaning it logs you out. So, you should probably be logged in using SSH certificates before making this change. That way, you know it works.

Closure:

Huh… I am not, in fact, out of ideas for articles. I’m pretty sure I’m going to run out of ideas eventually, but there seems to always be something new to impart. I did notice that I failed to search well and we have two articles about time zones and how to find out which you’re using. Ah well… Nobody else seemed to notice, so I’ve got that going for me.

Prevent SSH Root Login

Today’s article will tell you how, and why you’d want to, disable root login via SSH. It’s actually a brief article and approachable by even a beginner with SSH. If you have SSH enabled, then you may want to make sure to do this.

In some cases, like Ubuntu, the root account is disabled by default. That’s generally a good thing. In that case, this article may be important to you if you’ve enabled root login. This article may also be of interest for those who have changed the port SSH uses. Even if logging in as root is already disabled, it won’t hurt to disable it via SSH. Even if the port has been changed, disabling SSH root login won’t hurt.

So, why would you want to disable root login for SSH? Well, it’s a known account – meaning ‘root’ is pretty standard across the distros. An attacker already has half the information – the name of the account. It’s also an account that has the keys to the kingdom. If you have control of the root account, you have complete control of the system. This is fine if it’s your system and you with the root account, it’s less appreciated when it’s someone else that has control of your devices.

This article is actually pretty easy and is a step I suggest everyone take. What it does is it prevents root login via SSH entirely. It’s a simple step to make your computer more secure by preventing SSH root login. You can still login with other accounts and use sudo, so it’s really not limiting your ability to control the system.

Prevent SSH Root Login:

Like many other articles on this site, this one needs an open terminal. You can open your terminal with your keyboard – just press CTRL + ALT + T and your default terminal should open.

Once you have your terminal open, enter the following command:

sudo nano /etc/ssh/sshd_config

1	sudo nano /etc/ssh/sshd_config

Once that’s open, you’re looking for #PermitRootLogin no. When you find that line, you simply want to remove the # symbol. The end result should look like this:

PermitRootLogin no

1	PermitRootLogin no

In some default configurations, you may see #PermitRootLogin prohibit-password instead. If you uncomment that line, you could still login as root – you just can’t login with a password and would have to use a key like in this article about SSH keys.

In that case, when the line doesn’t exist or is changed, you can just add the line yourself. It won’t hurt anything and will still work. So, just find a blank section in the config file, add a new blank line, and then add the PermitRootLogin no like above.

Once you’re done, you need to save the file. As we’re using nano, you do that by pressing CTRL + X, then Y, and then ENTER. That should save the file with the correct name.

Finally, you will want to reload SSH. That’s easy enough, you reload SSH with the following command:

sudo systemctl reload sshd

1	sudo systemctl reload sshd

That’s it, that’s all you need to do! Once you’ve done that, and you can test it yourself. You shouldn’t be able to login to SSH with the root account, which is a pretty solid security idea. If you can’t login as root, nobody else should be able to login as root.

By the way, if you decide you want to undo this – just go back into the config file and add a # at the start of the line, save it, and restart the sshd daemon.

Closure:

That’s it. Thanks for reading yet another article! This one is pretty quick and easy, plus it will help you increase your server’s security. There really aren’t many reasons to have SSH root login enabled, and disabling it completely removes that attack vector.