Live data from Hacker News

How I spend my first 5 minutes on a server

plusbryan.com

41–50 of 355 posts

Re: How I spend my first 5 minutes on a server

#42
post #35

To prevent having to log into root via remote console, set up a second backup account with an ssh key and sudo access, and then put that key somewhere safe. The chances of both that and the deploy user getting corrupted at the same time is unlikely.

That's a good alternative. At least for Linode, remote console is fairly easy, but some don't offer this feature.

Re: How I spend my first 5 minutes on a server

#43
post #11

I've never understood the point of fail2ban if you disable ssh password authentication. Yeah, it might eliminate some spam in the logs, but if you only allow key-based authentication that doesn't really matter.

Keys can be brute-forced.

That is way down on my list of things to worry about.

Re: How I spend my first 5 minutes on a server

#47
post #18

Beginner or not, you should probably use visudo [1] instead of vim /etc/sudoers for the sanity checks that it provides, if nothing else. A botched edit of /etc/sudoers that locks you (along with every other user) out of administrative access is an unpleasant way to learn this. [1] http://linux.die.net/man/8/visudo

Similarly "ufw allow from {ipaddress-you-will-access-from} to any port 22" sounds like a good way to accidentally lock yourself out unless you have an out of band backup

FWIW I never understood UFW over straight IP tables, is it really easier to read?

Re: How I spend my first 5 minutes on a server

#48
The premise of this thing is not good advice.

1) Your first couple minutes on a server should be used to install a configuration management client, if your bootstrap policies somehow don't already install one.

2) Everything else listed in this document should be configured by a configuration management system.

3) "User account sync tools" should have no place in a modern infrastructure, you should use your configuration management tool to (at the bare minimum) deploy /etc/passwd and /etc/sudoers across your infrastructure.

4) You should not use shared/role accounts. The "incremental cost" is paid back immediately when someone leaves your organization; having to update everyone of a changed password or having a password change have any negative impact at all should not be a thing your company does.

This stuff isn't hard. It's worth doing right.

Re: How I spend my first 5 minutes on a server

#50
post #33
post #21

I also recommend changing the default SSH port.

Don't do this. It adds almost no extra security and makes it hard for routers that prioritizes port 22 traffic as interactive.

Sure, it'll not stop dedicated manual intrusion attempts, but it will actually prevent a ton of automated bots from even just trying to connect with common passwords through SSH.
Post reply on HN