5 Must Have Tweaks to Secure OpenSSH

OpenSSH is a fantastic tool for remotely managing Linux servers, but with great power comes great responsibility! If a threat actor is able to gain access to OpenSSH on your Linux server, then they have full access to cause all kinds of mischief. In this video, Jay goes over 5 must-have tweaks to strengthen the security of OpenSSH on your server.
Thanks yet again to Linode for sponsoring this video!
- Support LearnLinuxTV and Set up your own cloud server with Akamai Connected Cloud ➜ learnlinux.link/akamai
Check out the LLTV Shop!
Shirts, bags, cups and much more! ➜ merch.learnlinux.tv
Support the Channel
Show your support for Learn Linux TV and get access to exclusive perks!
• Become a Channel Member ➜ learnlinux.link/member
• Become a Patron ➜ learnlinux.link/patron
Official Stores and Merchandise
• Linux Merch ➜ merch.learnlinux.tv
• Latest book: Mastering Ubuntu Server ➜ ubuntuserverbook.com
• Linux stuff from Amazon ➜ learnlinux.link/amazon
• Awesome Pi-powered KVM ➜ learnlinux.link/tinypilot
• 5% discount on LPI exam vouchers ➜ learnlinux.link/lpi-voucher
Note: Royalties and/or commission is earned from each of the above links
Time Codes
00:00 - intro
01:32 - Spin up your very own Linux server on Linode (sponsor) ➜ learnlinux.link/akamai
03:12 - Tweak 0: Disable the OpenSSH service if you don't plan on using it
05:07 - Tweak 1: Change the default port that SSH listens on
10:05 - Tweak 2: Preventing access to ssh from the root account
14:07 - Tweak 3: Disabling password authentication completely
17:09 - Tweak 4: Suggestion: Use a firewall rule to further protect SSH
19:21 - Tweak 5: Suggestion: Use a hardware key for extra security
Full Courses from Learn Linux TV
• Linux Crash Course series ➜ linux.video/cc
• Learn how to use tmux ➜ linux.video/tmux
• Learn how to use vim ➜ linux.video/vim
• Bash Scripting Series ➜ linux.video/bash
• Proxmox VE Cluster Full Course ➜ linux.video/pve
• Learn Ansible ➜ linux.video/ansible
Boost your Linux skills with these stand-alone tutorials
• Essential tweaks for ALL Linux Servers ➜ linux.video/all-servers
• Install Arch Linux ➜ linux.video/arch-guide
• Use Ventoy to create a multi-distro flash drive ➜ linux.video/ventoy
• Browse the web from within your Linux terminal ➜ linux.video/term-web
• From Zero to Proxmox ➜ linux.video/zero-to-pve
• Check out Neovim ➜ linux.video/neovim
• Systemd Deep Dive ➜ linux.video/systemd
• Systemd Timers ➜ • Automate Your Tasks wi...
• Installing an operating system for Raspberry Pi ➜ linux.video/pi-imager
• Connecting to a Linux server via ssh ➜ linux.video/ssh
• Linux permissions ➜ linux.video/perms
• OpenSSH Guide ➜ linux.video/ssh-guide
• 10 Linux Terminal Tips and Tricks ➜ linux.video/cli-tricks-1
• Over 15 Terminal Tricks ➜ linux.video/cli-tricks-2
Linux-related Podcasts
• Enterprise Linux Security ➜ enterpriselinuxsecurity.show
• The Homelab Show ➜ thehomelab.show
Learn Linux TV on the Web
• Main site ➜ www.learnlinux.tv
• Community ➜ community.learnlinux.tv
• Enterprise Linux Security Podcast ➜ enterpriselinuxsecurity.show
• The Homelab Show Podcast ➜ thehomelab.show
• Content Ethics ➜ www.learnlinux.tv/content-ethics
• Request Assistance ➜ www.learnlinux.tv/request-ass...
Disclaimer
Learn Linux TV provides technical content that will hopefully be helpful to you and teach you something new. However, this content is provided without any warranty (expressed or implied). Learn Linux TV is not responsible for any damages that may arise from any use of this content. The person viewing Learn Linux TV's content is expected to follow their best judgement and to make their best decisions while working with any related technology. Always make sure you have written permission before working with any infrastructure. Also, be sure that you're compliant with all company rules, change control procedures, and local laws.
#LinuxServer #DevOps #OpenSSH

[@koltonward7078]

Just wanted to say thanks for all that you do! I didn’t know anything about Linux a month ago, and now I’m able to start up my own servers from scratch and maintain them with ease.

[@LearnLinuxTV]

Awesome, that’s what I want to hear!

[@timrobertson8242]

I will suggest that when you do you Firewall Video collection, you include Tweak #4.5 - Leverage a Bastion Host, all others will only allow ssh from the Bastion local IP (which is fixed) and the Bastion is the only box allowed to be seen from the Internet SE LINUX turned on, very regularly patched, and nothing of consequence running on it. So, once someone goes to multiple servers or VMs, they all can just be accessed only from the Bastion. It would also be great to have the various video links you mention in your description, so I can find them easily without having to go to that place in the video :^). Great job making these security issues clear and understandable!😀

[@Dr10na1995]

Thanks to your channel I was able to learn so much and it helps me to do my job, support my family. All this great, well structured learning content for free is a God's work. Thank you!

[@anoldslowhorse]

1st class video, I used it review my own ssh setting , thanks ..

[@HadToChangeMyName_YoutubeSucks]

I'm actually a bit surprised you didn't go ahead with making the key. Making a key and copying it over is just such a quick and easy thing to do, but I understand it's already a bit long video. Good tips for the newer folk though. I've been using for quite a few many years, and I just learned about the whence command while I was tinkering at the keyboard out of boredom, so us less than newbie folk can still learn new tricks too. That's why I watch your lower level stuff when you post it, once in a while there's something I didn't know or hadn't used for so long I'd forgotten it.

[@Timjstewart]

I didn't see any cards to other videos pop up. Great video!

[@kychemclass5850]

Tq Jay. Very helpful!

[@wyfyj]

Great 4k quality!

[@ThePswiegers]

just a fyi for all interested - enable and start a service in systemd with single command - " systemctl enable {service} --now " - thank you Jay for all your content ... always a pleasure

[@jonathanrider4417]

Thanks Jay for your wonderful work. I don't know how to suggest topics so I will just mention here: how about explaining ports; servers - (e.g.nwhere is my docker server? ...or my nextcloud server? How can I manage the port assignments to avoid conflicts? If this is not of interest then maybe a segment on where to find this info? You are doing a fantastic job - please keep it up!!!

[@LearnLinuxTV]

Great idea! I haven’t finalized next years conte t so you never know.

[@MisterSilenzo]

Great video even if title is clickbaity. I would just like to point that because of port scanning mentioned in Tweak 1 and dynamic IPs mentioned in Tweak 4, another good method is to lock the SSH connection to the Local Network of the server and VPN into it, this way SSH is not exposed to the internet and cannot be compromised by port scanning, you don't have to bother with fail2ban and checking logs and would only have to take good care of securing your VPN server.

[@MisterSilenzo]

And if you have static public IP it's just the matter of firewall config at this point to secure VPN.

[@AquariusTurtle]

Another great video. So for those of us traveling more than half the month, on various networks, and always on a VPN provider, with changing IPs, is there a suggestion of how to set up IP security? I know the question answers itself, but I was wondering if there's a way to get maximum security with an extremely mobile lifestyle.

[@tutacat]

Another way is to only allow ssh through LAN and use a different server to run internet ssh. This could be through a vpn or tunnel, but obscurity is not security.

[@GustavAgar]

Thank you so much !!!!

[@evodefense]

Thank you!

[@funkykong9001]

To expand on Tweak 4, install and use Tailscale. No ssh port exposed to the world and ssh is only available to authenticated Tailscale clients

[@benverdel3073]

Very interesting. What what about knockd or when the destination user account is encrypted?

[@joeyr9876]

I like to create a group called “sshusers”, add this group to the necessary users, then in sshd_config, add an entry “AllowGroups sshusers”. This limits the scope of users who can ssh in to a box. (There is also an “AllowUsers” option)

[@nintendu64]

I’m using OVH Cloud right now but I did have some recommendations for linode it seems they are comparatively cheaper might give it a shot switching over. Need to make some migration scripts so it’s a smooth transition

[@wva5089]

why constantly clear screen? makes scrubbing to look for the commands your looking for very painful. Thanks for your videos.

[@michalroesler]

Great video.

[@SuprousOxide]

I generally make a point of verifying that I can still make a connection via ssh after every restart of sshd when making changes, by making a new connection from a remote machine, while the original connection is still active. This way if something is wrong and I cannot connect with the new config, I still have access and can restore the old config. Even with a VPS there's ways to get a console without ssh, but it's a pain I prefer to avoid.

[@LearnLinuxTV]

Fantastic idea!

[@yorkshireplumbing]

I was a bit scared of using ssh keys at first, fear of being locked out etc, but loved them very quickly, and have all my clients and apps (filezilla, winscp, juicessh etc etc) all config'ed now to use ssh keys instead of password. You didn't mention this in the video I think, but disabling password auth, seemed to hide my (custom) ssh port from nmap network/port scans now, too.

[@slalomsk8er397]

did you really mean ssh (you wrote ssl) certs or did you mean ssh keys? If you meant keys then you are in for a tread if you combine it with a password manager that can act as a ssh-agent like KeePassXC. If you meant ssh-certs that is sick and I haven't yet managed to set this one up myself but I definitely keep it on the to do list to get rid of tofu (Trust On First Use).

[@yorkshireplumbing]

@@slalomsk8er397 ssh keys, sorry... getting the terminology mixed up! Calling it an SSH Cert is legit though? I've seen other people call them certs I believe. Or are certs different to keys?

[@slalomsk8er397]

@@yorkshireplumbing don't worry, there is a certificate feature that builds on top of the keys so is quite advanced and makes a lot of sense if one has to manage a lot of servers or short lived servers as it gets rid of the scary warning if a key changes. I guess using certs to sign the keys is the last step in managing ssh. did you try to store your ssh keys in KeePassXC yet?

[@greob]

As an addendum to the firewall point, I was hoping you would mention port knocking!

[@MartinMllerSkarbiniksPedersen]

port knocking is not a good idea

[@ziad_m_404]

I wanted to ask you about Port Knocking instead of Tweak 1, what do you think of such a method ?! Have you seen it implemented before ?! Thanks for all your efforts ^^,

[@donaldwilliams6821]

A tweak I use with systemctl to enable and start at same time is: $sudo sysstemctl enable --now

[@ameador01]

One of my frustrations at the moment is how to manage SSH keys across many devices in a small enterprise network. We have switches, APs, routers, server, clients (Windows, Linux, etc). I find videos galore taking about how to set up the keys and to secure the SSH server - but nothing about how to manage the keys. Such as, if I as an admin have a key that is used within the network and placed on many devices, if any of my workstations is compromised and the private keys are accessed - then the system is in great danger. Where are the keys implemented? Keep this in a spreadsheet? How to push new keys out to all those systems in mass quickly? It seems to be a decentralized mess that in itself is a large security risk - making me inclined to turn off SSH everywhere and use the GUI UI tools most of these devices have verses the SSH approach and a password manager instead. Are there some kind of central management tools out there for this? If so, a video reviewing and going over some of those and their pros/cons would be awesome. I makes me like Microsoft's Server management systems - like Active Directory for central user management (including authentication and access to systems via the permissions granted per security groups and such) much more and appreciate them more as I have been delving deeper into Linux.

[@wrkt98]

Just asking, what font is used on this terminal ? I kinda like it

[@LearnLinuxTV]

I’m pretty sure it’s Fira Code.

[@wrkt98]

@@LearnLinuxTV Thanks! And great video as always, keep up ! 😁

[@send2gl]

Is there a way of allowing password access but only from local LAN? Outside LAN then ssh key.

[@daysiewaysie]

how about ... run a second instance of sshd which uses a second/modified sshd_config file. if you're using systemd then you need to create a new sshd.service unit file under /etc/systemd/system/multi-user.target.wants/ (on manjaro, this is a symlinked to /usr/lib/systemd/.... ). in the new service file configuration be sure to specify your local lan sshd_conf file using the -f switch and then ensure that whatever port you are running this local lan instance on (must be different to the other instance) is not exposed through your firewall/router. as an afterthought, if you are running your external facing sshd on standard port 22, there no need to explicitly specify the port when connecting (as ssh client will default to 22 if none is given), but now you have a 2nd instance of sshd listening on a non-standard port for connections (from local lan clients; denied through your firewall or router), it can get cumbersome having to type in the non-standard port with each connection: ssh -p 1234 me@internalhost so to keep things simple, you can also create a config file within your ~/.ssh directory. within your local config file you can list any connection-specific options for the hosts you want to connect to. one option per line so you would have something like (just an example): Host internalhost {an alias for the hostname} HostName internalhost.home.lan {dnsname or ip address} Port 1234 User me {the username to connect using} IdentityFile /home/me/.ssh/id_rsa

[@stephenrochester6309]

I did this… then couldn’t get back into my server! Luckily was just some junk I was messing with but highlights I really need to understand SSH more

[@definty]

I'm surprised you didn't mention systemd port knocking feature

[@mihai6564]

good video

[@laz0rbra1n]

a firewall video will be very interesting because my server doesn't use one yet

[@HadToChangeMyName_YoutubeSucks]

Not sure what you're running to manage iptables, but ufw is pretty standard everywhere and it's pretty simple to use. You definitely should be running a firewall though.

[@laz0rbra1n]

@@HadToChangeMyName_KZbinSucks yeah I've been eyeing ufw

[@danielstellmon5330]

I would rather use port forwarding on my router to repoint my SSH port, but that is likely outside the scope of this video.

[@0eieiei]

You have that much to teach me?? Let's goooo

[@send2gl]

Most security connections I have watched suggest denying root access, I thought the norm nowadays was for distros not to have a root user so guess if no root user created at installation then disabling root access will have ne effect.

[@LearnLinuxTV]

Some distributions lock the root account. Some do so optimally. But there’s still a root account, it’s just locked. But also, with distros that lock root, some VPS providers unlock root when it normally wouldn’t be available.

[@send2gl]

@@LearnLinuxTV Yes, now you mention have seen it in passed file and I think in the shadow file. So, even if locked good idea to deny root login?

[@jwspock1690]

first :-) Greetings from Germany

[@DrazenMarjanovic]

tnx much great video

[@d00dEEE]

#6, run fail2ban on your server.

[@henfibr]

or sshguard (allegedly a bit lighter and not vulnerable to some log injection attacks)

[@LearnLinuxTV]

That’s useful for preventing passwords from being brute forced, but it’s better to disable password authentication (in which case, solutions like Fail2ban are no longer necessary specifically for ssh).

[@johnyferreira8733]

Works for Ubuntu but not for CentOS or RHEL based OS.

[@giuliogemino6407]

second ;-) Ciao Italy

[@mr.nobody2087]

Why you should NOT change your SSH port to a high (non-privileged) port: The SSH port is 2222. The firewall only allows access to port 2222. Only root is allowed to change the firewall rules. Let's assume that I am an attacker with initial access. I am aware of an exploit that shuts down the SSH daemon, causing a denial-of-service (DoS) situation. Since the port is a "non-privileged" port, I can load tools like netcat or any other malicious software to listen on port 2222 because the system allows me to open that port in the user context. In this scenario, I can spin up a fake SSH server to phish your credentials. Yes, you will likely see a host-key warning, but let's be honest-it's not uncommon for users to ignore or overlook such warnings. If you decide to change the port to a value above the "well-known" ports, it is advisable to implement other security measures like SSHFP (which would be nice to see in a new video).

[@OG900Aero]

Fail2ban, sshguard...

[@LearnLinuxTV]

Those are more useful when you have password authentication enabled.

[@OG900Aero]

​@@LearnLinuxTV It's not only useful then. For example, I always use fail2ban, so that anyone who attempts unauthorized access, especially when flooded, is immediately banned at the firewall level, and also at the prerouting level, so that it can be processed as quickly as possible. This way, they will be blocked at the ip level and cannot consume the server's resources, even though they do not have access.

[@_Xibalba_]

i suggest to dont use that port btw. better one >= 1024, its a security risk use some non-privileged port for SSH. because a non-root user can open that.

[@wva5089]

"5 Must Have Tweaks ".. 1,2, immediately debunked. instead of talking about using only the best cipher suites.. or enabling two factor like google auth.. or even better u2f keys.

[@mojoblues66]

6:47 *cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak* can be abbreviated to *cp /etc/ssh/sshd_config{,.bak}*

[@WebMentorDev]

Few weeks ago, my PC became part of Botnet because i have static ip and windows. my home server didn't, because i took every security measure that i learned from this channel. BTW it has linux. Debian 11 -NOTE- video is sponsored by Linode, but they don't even let me create an account. Just straight up rejected by automated system. they don't even reply any tweet/DM/Support Email. They charge one dollar to verify integrity. i had them in credit card but they didn't charge anything just straight REJECTED. GG

[@dougphillips5686]

Better solution, Use Fail2ban.