61–70 of 89 posts
Usernames are not a secret, passwords are a secret.
Does anyone still use password authentication on servers that actually matter? I mean, I'm just a hobbyist, and I switched to keys several years ago. Basically, I just use root and user, because anything else unnecessarily adds information.
Earlier quoted context omitted.
A correct sshd_config includes: PasswordAuthentication no
You can also use https://tinyssh.org instead of the sshd from OpenSSH. It only implements key based authentication and newer encryption algorithms. It's available on Ubuntu: sudo apt install tinyssh wget https://github.com/yourusername.keys -O ~/.ssh/authorized_keys sudo systemctl enable tinysshd.socket but it's not widely used, which makes using it risky. To my knowledge there hasn't been a formal audit. Also it doe…
Immediate pro: Public domain / CC0
Immediate potential-con: Doesn't implement compression
Earlier quoted context omitted.
ChallengeResponseAuthentication no # \ PasswordAuthentication no # | nukes "Password: " UsePAM no # / PermitRootLogin no # (duh) PubkeyAuthentication yes # enables public keys; very important AllowUsers user1 user2 # maybe? combine with an obscure username...
If you're doing admin on the machine you might not want to disallow root login.
Incidentally I only ever used it at home, on a LAN that only has devices I know about on it. In a work environment I'd only ever do the same running off an isolated lab switch.
But in certain situations, "login to the box as root w/ no pw" is awesome for rapid bringup/diagnosis/repair/whatever.
Earlier quoted context omitted.
Does anyone still use password authentication on servers that actually matter? I mean, I'm just a hobbyist, and I switched to keys several years ago. Basically, I just use root and user, because anything else unnecessarily adds information.
Some servers I manage accept either password with two-factor code, or keys. Helpful when logging in from a new machine without having to carry authorized keys around somehow.
Earlier quoted context omitted.
For non trivial environments with audit requirements this is not an option. Running all software under the same uid is also usually best avoided, you'll always have data at rest somewhere (which needs to be backed up, access controlled, and so on).
Of course there is other users but they aren't configured for SSH via AllowUser. Additionally most of those are containers where running it all as the same UID isn't a problem.
Containerization isn't really relevant to protecting data, as you'd normally find data volumes and backups attached.
Earlier quoted context omitted.
I think he’s saying: a) Why are you using bleeding edge software in production, and especially so unreleased versions of OpenSSH? b) Why are your SSH servers exposed to public traffic? c) User enumeration is useful for finding accounts with weak passwords. Why do you have personal accounts on prod servers? Why do you have _any_ accounts not using public key authentication at all?
b) If not SSH what else would one use? c) Not only production servers utilize internet.
c) fair enough, although you should probably be using keypairs and a vpn for test and dev envs too.
Earlier quoted context omitted.
b) If not SSH what else would one use? c) Not only production servers utilize internet.
b) use ssh, but control access with a firewall or vpn. c) fair enough, although you should probably be using keypairs and a vpn for test and dev envs too.
low security impact, best practice as others has mentioned
If you strictly use public key authentication and don’t expose your SSH server to the public internet, this is a non-issue. Furthermore there’s no defensible reason not to do that - it’s very straightforward to firewall SSH access behind a private network, and VPNs exist precisely for this reason. Access to the network and access to machines within the network should be strictly decomposed. If you allow SSH access from the public internet and have a VPN, you have to worry about two (privileged) points of failure, not one. Put everything behind a public-key authenticated VPN and SSH vulnerabilities are obviated, with the exception of insider threats in the organization.
Earlier quoted context omitted.
Of course there is other users but they aren't configured for SSH via AllowUser. Additionally most of those are containers where running it all as the same UID isn't a problem.
User ids without login privileges can be just as interesting to enumerate. Containerization isn't really relevant to protecting data, as you'd normally find data volumes and backups attached.
Plus, this is LXC, not Docker. There is no data volumes or backups attached. Backups are shipped to an append only server via SSH tunnel with low privileges, which also doesn't have nonstandard users setup.
Earlier quoted context omitted.
A correct sshd_config includes: PasswordAuthentication no
To disable logging in with password you also need: ChallengeResponseAuthentication no
Though, if you're using TOTP via a PAM module, you'll want it