[ananonymoususer]

And for those who don't understand why this is a bad thing, I will present my own use case. I run pi-hole at home and frequently work from there for another company. That company has provided me with a laptop that uses Cisco's DNS "Umbrella", which is some sort of security feature: https://docs.umbrella.com/deployment-umbrella/docs/point-you... Because my company laptop doesn't pay attention to the DNS servers recommended by DHCP, and ignores the local domain search TLD, if I try to ssh into a machine on my local network (without a FQDN) from the company laptop, it replaces the local search domain with the corporate domain, then does the lookup, and gets an A record from Umbrella that is not on my local network. It makes the ssh connection and (surprisingly) reaches an ssh server, which asks me for my password. The login fails, and my password (in plain text) could very well have been harvested by the ssh server on the catchall host. Now you are going to tell me that I shouldn't use ssh passwords, and should instead be using RSA keys for ssh. Regardless of what the NSA tells you, THIS IS ALWAYS A BAD IDEA because once any account is compromised, ALL OTHER ACCOUNTS with locally stored keys ARE ALSO COMPROMISED.

Sorry for the rant, but wildcard catchall DNS is a REALLY BAD THING.

[zootboy]

> THIS IS ALWAYS A BAD IDEA because once any account is compromised, ALL OTHER ACCOUNTS with locally stored keys ARE ALSO COMPROMISED.

This is not universally true. If you generate separate private keys for each server-client pair, compromising one private key will limit the damage to just the one server.

[ananonymoususer]

That is just not true. It may be the case if the key itself is compromised, but consider that you may have many different accounts scattered on different servers. Once one of them is compromised, the attacker now has access to every other account because they are all chained together.

[shawnz]

Can you describe the attack scenario you're imagining in a bit more detail? Because that doesn't sound possible to me.

[aaronAgain]

Yeah, the argument you are making about all keys being compromised doesn't make sense. You are leaving out a key assumption in your setup, and without it is not possible (for us) to accept the chained compromise you are describing.

[noodlesUK]

User managed passwords aren’t ideal. If you’re looking for more security and you’re concerned about compromise of local keys, you could purchase a couple of yubikeys (or similar), or you could use an SSH CA (Hashicorp vault and Step come to mind). However, if you’re very concerned about storing creds on a company laptop, or compromising your passwords by logging into a honeypot server (which known_hosts should be protecting you from), you ought to be much more scared of your company keylogging you...

[shawnz]

> should instead be using RSA keys for ssh.

No, you should be using ed25519 keys

> THIS IS ALWAYS A BAD IDEA because once any account is compromised, ALL OTHER ACCOUNTS with locally stored keys ARE ALSO COMPROMISED.

Not if you use passphrases on the key, generally together with an ssh agent, which is the best practice

[fiskfiskfisk]

In that case you should get a host key differing message (or not present) at least.

[dbetteridge]

Heh Umbrella is such a shitty app, if you've got root you can

cd /opt/cisco/anyconnect/bin

sudo sh umbrella_uninstall.sh

That should leave VPN functionality intact, but remove the ridiculous MITM of DNS queries.

[meh206]

Actually I would tell you to use ed25519 keys instead of passwords lol

[dylz]

My personal thought is that you shouldn't be connecting to anything personal or local from a work provided, likely heavily keylogged, device.