61–70 of 298 posts
Also, they complain about log spam (from failed SSH attempts) this is one reason to move SSH to a different port. It does NOT increase security, but it DOES reduce log spam from bots trying for easy targets.
Can someone explain me, let's say I disabled password logins and only allow login via a key, what are potential downsides of logging in as a root?
I don't mean to sound flippant but why can't these "lock down your new box" tutorials just be a bash script? Shouldn't they be?
I always worry that adding 2FA could make your machine inaccessible if anything happens to google-authenticator in this case. Maybe it's a little bit of paranoia but I don't like the idea of giving control over my ability to log into my server.
It'd be perfectly reasonable if libpam-google-authenticator relied on Google's infrastructure, but despite the infelicitous name, it does not; it just implements the server side of TOTP. The authentication flow is identical to any other correct TOTP implementation, and you can use any compatible client; no integration with Google services or infrastructure is required. (In fact, I don't think it's even possible.) Spe…
OTP Auth is another excellent, free OTP client.
Edit: clarified both are free.
> "You should never be logging on to a server as root." Can someone explain me, let's say I disabled password logins and only allow login via a key, what are potential downsides of logging in as a root?
I don't mean to sound flippant but why can't these "lock down your new box" tutorials just be a bash script? Shouldn't they be?
It's one of those cases where a tutorial explaining every change you're making and why you're making it really is pretty important.
I don't mean to sound flippant but why can't these "lock down your new box" tutorials just be a bash script? Shouldn't they be?
su -
curl -sS https://some.random.host/trust-me.sh | bash -
I don't mean to sound flippant but why can't these "lock down your new box" tutorials just be a bash script? Shouldn't they be?
As a side note, it's also sometimes better having a tutorial full of manual steps as that helps educate the "sysadmin" regarding best practices and some of the basics of Linux administration (if they weren't already familiar). That experience can be just as valuable as hardening the server itself.
Fail2ban? sshguard? unnecessary. Just disable ssh passwd auth (which generally is a good idea) -> done/done If you don't like lognoise from ssh scanners (even if you disable passwd auth), move your sshd port to some random high port and make note of it in your ~/.ssh/config Generally: if in doubt, take the more simple and elegant solution to a problem.
I'd be interested in learning from the community if fail2ban adds much value. As I've looked into the service, it seems like simply running the latest security patches obviates the need for fail2ban.
> "You should never be logging on to a server as root." Can someone explain me, let's say I disabled password logins and only allow login via a key, what are potential downsides of logging in as a root?
Well for one, every command you run has root privileges (instead of requiring sudo). Every process you spawn has root privileges. You're safer keeping your privileges limited and sudoing when required. Also you lose your real-life audit log if multiple people log in as root.