Great video as always. It is amazing the amount of information you are able to deliver on the topics and surrounding the topics on such a clear manner. For the same reason, to me, the third edition of your book "mastering ubuntu server" is a master piece.
Super video Jay. Is there an ansible playbook for this? :) Also, do you create a separate sudo user for ansible commands or same non-root user can be used? as well separate key for this without a pass?
Good info. Thanks Jay!! If u get a chance i would love to see a video showing how to manually set up an open lightspeed server with wordpress and SSL config.
7:00 I doubt `sudo ls /etc` is a good command, to test, whether the sudo command works, since normally, you can do `ls /etc` without sudo with the same result. `sudo ls /etc/ssl/*` would be fine, which normally gives you a mixed output of files you are allowed to see and an error message for /etc/ssl/private. Imho it is a bad practice, to constantly clear the screen while teaching. I'm often still reading in the output or the last command. At 9:40 for instance, you clear the screen and talk until 10:15, without typing anything at the prompt. If you do a double enter when starting a new point, it is easy to follow and to find the breaks while being able to read commands and output and think about them.
if sudo still can be considered secure and more, recommended fo use? And if we going to use sudo, we can disable root account completely. or use “su” and have separate password (for root user)? Dont understand, if we can add our ip (or ip range) in ignoreip in fail2ban, why we cant just allow only that ips with firewall?
Wonderful video as usual brother , thanks a lot for ur rfforts & work. I m ew to linux, request you to pleaase make such tweaks & security things for desktop distros too. I m on LinuxMint 21.3 Cinemon. Really appreciate u, thanks once again. TC.
Personally I'd advise against unattended upgrades. Don't want an upgrade to docker being installed on a live system, potentially restarting all containers. At the very least, specific packages should be put on hold when they're operation critical and cannot be restarted under normal circumstances.
Hmm, good question! Does the setting above that (remove-NEW...) get rid of enough, or should they both be true? Seems to me they should both be true, but let's see what Jay says.
Is this way of connecting to servers on by default if you install a Linux Mint server at home to connect to? I would prefer to only allow LAN connections.
On RHEL/clones and Fedora, try update-crypto-policies. Really nice tool. It allows for easy, global cyrpto settings changes that previously would have required knowledge of every service and their particular crypto config syntax.
Just like your rant about using root as primary user. Please don't base 24hr service, on servers never having to reboot. HA means systems stadig up, even is services or servers needs downtime.
Rather pointless using a non root user with sudo privileges, root and non root sudo have the exact same privillage, it is completely pointless in terms of increasing security
I don’t believe this is true. Brute force attacks, both external and internal, target the root user. If I set my user to some arbitrary value, it is less likely to be discovered and battered.
@@JeffreyHorn for good security you should not be allowing people to brute force usernames and passwords to try gain access, security by obscurity is bad advice
@@mulletman1705 but this isn't security through obscurity? If more scrips target root than brute forcing, wouldn't disallowing root login just be security, since you're shutting out at least a plurality of threats?
@@mulletman1705 like, I understand that a username and password shouldn't be treated as a line of defense, but I also don't see why using a non-root user is a bad practice. It's not going to make things more secure, but I don't see why you'd discourage the practice, especially on something you expect to be logging into at some point.
Great video Jay, i think this should be somewhat of a series if possible "Securing Linux servers 101"
Love the security content! Keep it coming!
Great video as always. It is amazing the amount of information you are able to deliver on the topics and surrounding the topics on such a clear manner.
For the same reason, to me, the third edition of your book "mastering ubuntu server" is a master piece.
Back on track again :) Thanks for all that you do, Jay.
5 easy tweaks, 40 minutes long video 😵
JK, now I will watch it.
Super video Jay. Is there an ansible playbook for this? :) Also, do you create a separate sudo user for ansible commands or same non-root user can be used? as well separate key for this without a pass?
Good questions. did you find your anwsers youre self? I was wondering the same
Hi Jay, Thank you for the video, very helpful.
excellent video as always
Good info. Thanks Jay!! If u get a chance i would love to see a video showing how to manually set up an open lightspeed server with wordpress and SSL config.
7:00 I doubt `sudo ls /etc` is a good command, to test, whether the sudo command works, since normally, you can do `ls /etc` without sudo with the same result. `sudo ls /etc/ssl/*` would be fine, which normally gives you a mixed output of files you are allowed to see and an error message for /etc/ssl/private.
Imho it is a bad practice, to constantly clear the screen while teaching. I'm often still reading in the output or the last command. At 9:40 for instance, you clear the screen and talk until 10:15, without typing anything at the prompt. If you do a double enter when starting a new point, it is easy to follow and to find the breaks while being able to read commands and output and think about them.
if sudo still can be considered secure and more, recommended fo use? And if we going to use sudo, we can disable root account completely. or use “su” and have separate password (for root user)?
Dont understand, if we can add our ip (or ip range) in ignoreip in fail2ban, why we cant just allow only that ips with firewall?
Wonderful video as usual brother , thanks a lot for ur rfforts & work. I m ew to linux, request you to pleaase make such tweaks & security things for desktop distros too. I m on LinuxMint 21.3 Cinemon. Really appreciate u, thanks once again. TC.
Personally I'd advise against unattended upgrades. Don't want an upgrade to docker being installed on a live system, potentially restarting all containers. At the very least, specific packages should be put on hold when they're operation critical and cannot be restarted under normal circumstances.
Hi, Jay. What is the music on chapter changing?
18:05 Is „false“ right there? (Unattended-Upgrade::Remove-Unused_Dependencies)?
Hmm, good question! Does the setting above that (remove-NEW...) get rid of enough, or should they both be true? Seems to me they should both be true, but let's see what Jay says.
I have the same question. I decided to go ahead and change this to "true" because it makes sense, but I'm no expert.
So, but leaving the "False" Commented as before, It was true then...??.?.?.?
This video is geared towards linux distros that use `apt`
Thanks Jay.
Question: isn't the 'ignoreip' option in fail2ban irrelevant if we're using a public key to access the server?
Is this way of connecting to servers on by default if you install a Linux Mint server at home to connect to? I would prefer to only allow LAN connections.
supersecure as a password? I like it. ;-)
Can I enable VPN on my router to my server? Is this possible?
Can you prevent your SSH passphrase from being cached?
On RHEL/clones and Fedora, try update-crypto-policies. Really nice tool. It allows for easy, global cyrpto settings changes that previously would have required knowledge of every service and their particular crypto config syntax.
Thanks for this tutorial!
Btw, can these tweaks be used for Linux Desktop environment?
Yep!
@@JeffreyHorn
I see.
Just like your rant about using root as primary user. Please don't base 24hr service, on servers never having to reboot. HA means systems stadig up, even is services or servers needs downtime.
Rather pointless using a non root user with sudo privileges, root and non root sudo have the exact same privillage, it is completely pointless in terms of increasing security
I don’t believe this is true. Brute force attacks, both external and internal, target the root user. If I set my user to some arbitrary value, it is less likely to be discovered and battered.
@@JeffreyHorn for good security you should not be allowing people to brute force usernames and passwords to try gain access, security by obscurity is bad advice
@@mulletman1705 but this isn't security through obscurity? If more scrips target root than brute forcing, wouldn't disallowing root login just be security, since you're shutting out at least a plurality of threats?
@@talktothehand1212 no because your hoping by obscuring a username that the attacker will not be able to brute force access by guessing the username.
@@mulletman1705 like, I understand that a username and password shouldn't be treated as a line of defense, but I also don't see why using a non-root user is a bad practice. It's not going to make things more secure, but I don't see why you'd discourage the practice, especially on something you expect to be logging into at some point.
5 easy things - video is 40 min long