> If you are logged in as a sudo user, provided allowing only an ssh key, can you can't do anything unless: > - you know the password This assumes one isn't using password-less sudo (NOPASSWD), which several distros do set by default and many users change to it for convenience.
What are some examples of these "several distros" that set it by default? Of the major ones I'm willing to use in production (Debian, Ubuntu, RHEL and derivs, SuSE, hesitantly Arch), none offer NOPASSWD sudo to users marked as administrative in each distro's normal way. (i.e. various group memberships) NOPASSWD is poor hygiene.
Raspbian doesn't require a password when using sudo.
> If you are logged in as a sudo user, provided allowing only an ssh key, can you can't do anything unless: > - you know the password This assumes one isn't using password-less sudo (NOPASSWD), which several distros do set by default and many users change to it for convenience.
What are some examples of these "several distros" that set it by default? Of the major ones I'm willing to use in production (Debian, Ubuntu, RHEL and derivs, SuSE, hesitantly Arch), none offer NOPASSWD sudo to users marked as administrative in each distro's normal way. (i.e. various group memberships) NOPASSWD is poor hygiene.
Doesn't help much when shodan has already portscanned everyone. I just searched for "ssh -port:22" and found many hits. But also yes. Switching port (or just blocking China) will vastly reduce SSH probes.
Don’t forget to block Brazil And Romania And Kazakhstan And …
Back in the EFNet days everyone with a lick of sense autobanned all of Eastern Europe, Asia, and South America. It was literally nothing but script kiddies.
Doesn't help much when shodan has already portscanned everyone. I just searched for "ssh -port:22" and found many hits. But also yes. Switching port (or just blocking China) will vastly reduce SSH probes.
Don’t forget to block Brazil And Romania And Kazakhstan And …
Any decent firewall can do geo location allow. I block all but specific counties. Can't trust Christmas Island....
Just a quick note on this excerpt: > Disallowing root login is also frequently recommended. I believe this has limited merit in our current landscape since 95% of the time, the user you log in with has sudo privileges. Then it adds no extra security. But you should really judge this for your own situation. Disallowing explicit `root` login makes it harder for attackers to guess the usernames which have sudo access, t…
> Disallowing explicit `root` login makes it harder for attackers to guess the usernames (...)
Technically correct I guess, but isn't password logins considered bad practice anyway? So if you have passphrase protected, key-based authentication only, is it really relevant whether you have it against root or a user with sudo permissions?
Basing things on source IP is really inexact and easily muddied, though. For instance, the source IP is a workstation or a laptop—now we have to go through DHCP logs to figure out who had that IP address at the time the incident occurred. Or if we've properly implemented source limitations through a bastion host, all we'll see on the end server is the source IP of the bastion host, so we'll need to go to the bastion…
`sudo su -` is always a nuisance. As an individual developer I prefer to ssh as root directly. Even more, I use mosh and connect to hosts with something like `mosh root@host -- screen -xRR -D`. Enterprisey server management tools issue short-lived keys that they push through backchannels to hosts. Hosts do not have users aside from system or applicaiton users. Anything else is quickly becoming outdated.
If you have the sort of system that has automated key issuance and low interactivity on hosts, I agree that makes sense. But then, that's exactly the 'ssh as yourself and then sudo to root' model, just abstracted in a different way, isn't it? In both cases you're authenticating to some intermediary as yourself first and then being given access to the local root account—it's just that in my system the 'intermediary' is a local unique user account, whereas in yours it would be the individual authenticating to the temporary-ssh-key-issuance system like Vault. As long as that system does a unique authentication, the two are more-or-less identical, although you'd have to be careful to ensure you can untangle the auth logs to the intermediary system and associate them with local root sessions.