5 Must Have Tweaks to Secure 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!

[@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

[@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!😀

[@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.

[@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!

[@binbashbuddy]

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.

[@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

[@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)

[@Timjstewart]

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

[@wyfyj]

Great 4k quality!

[@anoldslowhorse]

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

[@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.

[@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.

[@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?

[@0eieiei]

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

[@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.

[@donaldwilliams6821]

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

[@kychemclass5850]

Tq Jay. Very helpful!

[@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

[@evodefense]

Thank you!

[@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 ^^,

[@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

[@GustavAgar]

Thank you so much !!!!

[@laz0rbra1n]

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

[@binbashbuddy]

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]

@@binbashbuddy yeah I've been eyeing ufw

[@wva5089]

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

[@michalroesler]

Great video.

[@benverdel3073]

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

[@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.

[@raughboy188]

Here is one thing to add: Force ssh version 2.

[@rcdenis1]

"nano -B /file.txt" will save a copy of the original file txt when saving the changes

[@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.

[@definty]

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

[@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).

[@mihai6564]

good video

[@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 ! 😁

[@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).

[@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?

[@johnyferreira8733]

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

[@jwspock1690]

first :-) Greetings from Germany

[@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

[@giuliogemino6407]

second ;-) Ciao Italy

[@_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.

[@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.

[@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.

[@iftakharhusan]

fail2ban

[@DrazenMarjanovic]

tnx much great video

[@mojoblues66]

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

[@greob]

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

[@MartinMllerSkarbiniksPedersen]

port knocking is not a good idea

[@dougphillips5686]

Better solution, Use Fail2ban.