www.redhat.com Open in urlscan Pro
23.213.187.2  Public Scan

Form analysis
2 forms found in the DOM

GET /sysadmin/search

<form id="site-search" class="form-inline m-2" action="/sysadmin/search" accept-charset="UTF-8" method="get">
  <div class="input-group flex-fill">
    <input class="form-control" type="search" name="search" id="search" value="" placeholder="Search this site…" aria-label="Search this site…">
    <div class="input-group-append">
      <button class="btn btn-secondary font-weight-bold" type="submit">Search</button>
    </div>
  </div>
</form>

GET /sysadmin/search

<form id="site-search" class="form-inline m-2" action="/sysadmin/search" accept-charset="UTF-8" method="get">
  <div class="input-group flex-fill">
    <input class="form-control" type="search" name="search" id="search" value="" placeholder="Search this site…" aria-label="Search this site…">
    <div class="input-group-append">
      <button class="btn btn-secondary font-weight-bold" type="submit">GO</button>
    </div>
  </div>
</form>

Text Content

Skip to main content
Search
Search
Enable Sysadmin  
 * Articles
   Automation Career Cloud Containers Kubernetes Linux Programming Security

Enable Sysadmin  
 * Articles
   Automation Career Cloud Containers Kubernetes Linux Programming Security

Subscribe to our RSS feed or Email newsletter Subscribe to our RSS feed or Email
newsletter.
GO


EIGHT WAYS TO PROTECT SSH ACCESS ON YOUR SYSTEM

The Secure Shell is a critical tool in the administrator's arsenal. Here are
eight ways you can better secure SSH, and some suggestions for basic SSH
centralization.

Posted: October 29, 2020 | %t min read | by Damon Garn

Image


Image by Pexels from Pixabay

SSH. We know it. We love it. We must use it.

I'm going to take you through eight steps to better help you secure the SSH
service on your network. I think we all appreciate the importance of SSH. It
allows us to connect to and from Linux devices, Unix servers, network
appliances, and sometimes even Windows boxes. I'm not going to try to sell you
on how often SSH is used or how important it is. I'm going to provide a solid
checklist you can use to ensure SSH services in your environment are locked
down.

Skip to the bottom of list


GREAT LINUX RESOURCES

 * Advanced Linux commands cheat sheet
 * Download RHEL 9 at no charge through the Red Hat Developer program
 * A guide to installing applications on Linux
 * Linux system administration skills assessment
 * How well do you know Linux? Take a quiz and get a badge


1. BACKUP THE CONFIG FILE

First, back up the configuration file before making major changes. This is a
common bit of advice, but it's a real one. It's easy, takes only a moment, and
protects you in case of a mistake when editing the file. And who hasn't made a
mistake in Vim?

# cp /etc/ssh/sshd_config ~/sshd_config_original

See, that's not so bad.

Challenge - Do you consistently back up configuration files before making major
edits?


2. SET A BANNER MESSAGE

Admittedly, this is as much about legal requirements as anything else, but
again, this setting only takes a moment. You can actually provide some pretty
good information in banner messages, too. First, we'll write the banner message
in the /etc/issue.net file by using Vim. Then we'll open the sshd_config file
and tell it to use the content of issue.net as the banner.

# vim /etc/issue.net

Warning! Authorized use only.
This server is the property of MyCompanyName.com

[ You might also like: SSH password automation in Linux with sshpass ]

Obviously, you'll want to come up with something specific to your organization.
Remove any information that's already in the issue.net file.

Next, tell SSH to use the banner message. Open the sshd_config file in Vim, and
find the line that reads Banner. You do remember that you can use the
forward-slash character in Vim's Command mode to keyword-search a file, right?
For example, /banner

# vim /etc/ssh/sshd_config

Find the line that reads # no default banner path, and then uncomment the next
line (it says Banner).


# no default banner path
Banner /etc/issue.net

Save your changes in Vim with :wq and then restart the SSH service:

# systemctl restart sshd

Note: I'm not going to remind you to restart SSH from this point forward. Any
time you make a change to the configuration file, you must restart the service.

Challenge - Is the banner message consistent across all the SSH devices on your
network?


3. PREVENT EMPTY PASSWORDS

This seems like a no-brainer, but empty passwords are clearly a bad idea. You
may have other utilities, such as Pluggable Authentication Modules (PAM),
regulating your regular passwords, but it's also a good idea to make sure SSH
enforces responsible security settings, too.

Open the /etc/ssh/sshd_config file in Vim, and then find the line that reads
PermitEmptyPasswords. Uncomment it, and replace the yes value with no.

PermitEmptyPasswords no

That's it.


4. PREVENT THE ROOT USER FROM CROSSING THE NETWORK VIA SSH

The idea here is pretty straightforward. Send standard user credentials across
the network instead of root credentials. Once you've established your SSH
connection using a standard user account, use su or sudo to elevate your
privileges.

Open the SSH configuration file, and then uncomment the PermitRootLogin line.
Edit the setting from yes to no.

PermitRootLogin no

Challenge - your organization has embraced sudo, right?


5. WHITELIST SPECIFIC USER ACCOUNTS

If you're already preventing the use of the root user account across SSH, why
not go a step further and explicitly state which users can connect to the
server? Perhaps you have a regular non-root admin account you use or one that's
already configured with sudo privileges.

In the SSH configuration file, add the following line (it's not in there by
default):

AllowUsers user1

I'd put it near the PermitRootLogin no setting.

By the way, you can actually filter with all of the following settings:
AllowUsers, DenyUsers, AllowGroups, DenyGroups. I wrote them in that order on
purpose—that's the order in which they are processed. You can discover more
information on the man page for sshd_config.

Challenge - be careful about exactly who is authorized.

Note: You can limit connections via iptables, too.


6. NO MORE PORT 22

Another common change is to configure SSH to listen on a different port than the
standard 22/tcp that we've all memorized. There's already an entry in the
sshd_config file.

You can comment out the default port setting and add another line, as I've done
below:

#Run SSH on a non-standard port
#Port 22
Port 2222

I suspect many folks use 2222 as the replacement port number, so you may want to
standardize on something a little more unique.

You must remember to append the new non-standard port number to your SSH
connection attempts from this point on. For example:

# ssh -p 2222 user1@10.1.0.42

Challenge - do you have the same non-standard port number configured for all
your SSH destinations? Consistency will make your life much easier.


7. TIME'S UP!

The next tip deals with timing out connections. The ClientAliveInterval manages
idle SSH connections. The server sends a message to the client and expects a
response. The ClientAliveInterval is the space of time between the messages. The
ClientAliveCountMax defines how many times the server will do this before
deciding the client isn't really there anymore. At that point, the connection is
dropped.

Here is an example configuration that checks every 60 seconds and will do so
three times:

ClientAliveInterval 60
ClientAliveCountMax 3

Edit these values to something that makes sense for your environment.

Note: If you're using SSH to tunnel for other connections, you may need to
ensure that the interval is long enough to properly support whatever other
applications are using it.

There's a ServerAliveInterval value that you can configure on the client-side,
too. This allows clients to drop connections to non-responsive SSH servers.


8. HERE'S THE KEY

One of the most common security settings for SSH these days is key-based
authentication. Through the years that I've taught Linux, this authentication
method has become more and more common. In fact, I wouldn't attempt a Red Hat
admin exam without feeling confident in this process. Fortunately, it's not
difficult.

Let's do a quick review. Key-based authentication uses asymmetric cryptography.
That means there are two keys, different but mathematically related to each
other. One is private and never sent across the network. The other is public and
may be transferred across the network. Because the keys are related, they can be
used to confirm identities—identities such as SSH authentication attempts.

You'll need to generate the key pair on the local SSH client computer and then
transfer the public key across the network to the destination SSH server. In
other words, the keys will identify you on your admin workstation. Once this
configuration is in place, you are no longer challenged for a password when you
establish an SSH connection.

The process only requires a few steps.

First, generate the key pair:

# ssh-keygen

The keys are stored in your home directory in a hidden directory named .ssh, and
the default key names are id_rsa (private key) and id_rsa.pub (public key).

Next, send the user1 public key across the network to the destination SSH server
located at 10.1.0.42:

# ssh-copy-id user1@10.1.0.42

Finally, test the connection:

# ssh user1@10.1.0.42

Notice that you are not challenged for a password.

Since you have now embraced key-based authentication, you can edit the
sshd_config file to prevent any logins based on passwords. Once you configure
this setting, only key-based authentication will be accepted.

Edit these two lines in the file:

PasswordAuthentication no
PublicKeyAuthentication yes

[ Want to learn more about security? Check out the IT security and compliance
checklist. ] 


WRAP UP

I have listed several common but effective SSH configurations to help you better
secure your environment. Remember, with security, no one setting is likely to
protect your devices. The goal is layers of security, the combination of which
helps to mitigate security threats. I strongly suggest that you carefully
organize your keys if you implement key-based authentication. You might also
consider using a centralized /etc/ssh/sshd_config file to maintain consistent
security configurations on your SSH servers. Don't forget to restart SSH any
time you change the configuration file.

Image

How SSH establishes secure communication
Curious about how SSH establishes secure communication between two systems? Read
on.
Posted: November 5, 2019
Author: Shashank Nandishwar Hegde (Sudoer alumni, Red Hat)
Image

A little SSH file copy magic at the command line
You might not be aware that SSH is a magical tool with many different uses.
Using it, you can copy files between systems without logging into them, as if by
magic.
Posted: October 10, 2019
Author: Ken Hess (Sudoer alumni)
Image

Passwordless SSH using public-private key pairs
Did you know you can passwordless SSH? Here's how, and how to decide whether you
should.
Posted: September 6, 2019
Author: Susan Lauber
Topics:   Linux   Linux administration   Security  


DAMON GARN

Damon Garn owns Cogspinner Coaction, LLC, a technical writing, editing, and IT
project company based in Colorado Springs, CO. Damon authored many CompTIA
Official Instructor and Student Guides (Linux+, Cloud+, Cloud Essentials+,
Server+) and developed a broad library of interactive, scored labs. He regularly
contributes to Enable Sysadmin, SearchNetworking, and CompTIA article
repositories. Damon has 20 years of experience as a technical trainer covering
Linux, Windows Server, and security content. He is a former sysadmin for US
Figure Skating. He lives in Colorado Springs with his family and is a writer,
musician, and amateur genealogist. More about me




TRY RED HAT ENTERPRISE LINUX

DOWNLOAD IT AT NO CHARGE FROM THE RED HAT DEVELOPER PROGRAM.


RELATED CONTENT

Image

8 open source 'Easter eggs' to have fun with your Linux terminal
Hunt these 8 hidden or surprising features to make your Linux experience more
entertaining.
Posted: April 10, 2023
Author: Ricardo Gerardi (Editorial Team, Sudoer alumni, Red Hat)
Image

Troubleshooting Linux performance, building a golden image for your RHEL
homelab, and more tips for sysadmins
Check out Enable Sysadmin's top 10 articles from March 2023.
Posted: April 4, 2023
Author: Vicki Walker (Editorial Team, Red Hat)
Image

Do advanced Linux disk usage diagnostics with this sysadmin tool
Use topdiskconsumer to address disk space issues when you're unable to interrupt
production.
Posted: March 31, 2023
Author: Kimberly Lazarski (Red Hat)



The opinions expressed on this website are those of each author, not of the
author's employer or of Red Hat. The content published on this site are
community contributions and are for informational purpose only AND ARE NOT, AND
ARE NOT INTENDED TO BE, RED HAT DOCUMENTATION, SUPPORT, OR ADVICE.

Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the
United States and other countries.


RED HAT LEGAL AND PRIVACY LINKS

 * About Red Hat
 * Jobs
 * Events
 * Locations
 * Contact Red Hat
 * Red Hat Blog
 * Diversity, equity, and inclusion
 * Cool Stuff Store
 * Red Hat Summit

© 2023 Red Hat, Inc.


RED HAT LEGAL AND PRIVACY LINKS

 * Privacy statement
 * Terms of use
 * All policies and guidelines
 * Digital accessibility
 * Cookie preferences


HOW WE USE COOKIES

We use cookies on our websites to deliver our online services. Details about how
we use cookies and how you may disable them are set out in our Privacy
Statement. By using this website you agree to our use of cookies.