6 ms·
I feel this is worse than running rm -rf on a root directory. Just saying.
by SurajMishra 2mo ago
I feel this is worse than running rm -rf on a root directory. Just saying.
- hoppp 2mo agoMuch worse, instead of the data gone it's a data leak. Those ssh keys can be used to access private servers
- steve1977 2mo agoWell, those ssh keys are protected by a strong passphrase, right?
- hoppp 2mo agoThe passphrase is optional, not everyone has it. It also has to be a secure password, people often don't care because it's a local file and generally not exposed to the internet.
- cute_boi 2mo agoI am sure majority of people don't use password for ssh keys. The good solution is to use password manager like 1password which will prompt you to approve ssh.
- crimsonnoodle58 2mo agoSSH keys can be limited by IP in authorized hosts. The SSH port itself can be limited by IP in firewalls. Finally, the SSH private key can be encrypted with a password. Defense in depth is needed. Storing a ssh private key in plain text with no IP restriction is no different to having a password manager store your passwords in plain text on your HD.
- hoppp 2mo agoAll those things are optional. Doesn't make uploading the keys that much better. Now is the time for key rotation everywhere. Fast.
- crimsonnoodle58 2mo agoHow are they optional? You obviously haven't worked anywhere security sensitive. I'm not talking about whether what Grok did is bad or good, I'm talking about protecting your private key and the servers you connect to. An unencrypted private key is no different to an unencrypted password manager, and thats a fact. Dont store secrets in plain text.
- hoppp 2mo agoI meant that not everyone is doing it at home. Do you think a person's private computer is a secure workplace? If it was security sensitive space there would be no agents running amuck.
- t-writescode 2mo agoSigh. Anything that isn’t a default is optional by default. Anything that’s toggleable or configurable is optional. Security is, always, a trade off. It is hilariously common for private keys to work as a full identifier for a person, without concern of IP or anything of the sort. Should they? Maybe, maybe not, that’s the calculus of risk management; but victim-blaming the average person who is following best practices is a bad look.
- grayhatter 2mo agoI'm a security eng and I've worked for both a FAANG and TS government contractor. Neither of them bothered with either of the of the stupid suggestions. IP restrictions prevent roaming, the point of working remotely via SSH. passwords are equally defeated by using an ssh agent, something I'd suggest everyone use. Then on top of that there's no reasonable threat model where something would be given unrestricted access to user env, but also be untrusted. If it can read from ~/.ssh neither IP protection nor keyfile password protection will protect you from maleficence. The only reasonable response from a security perspective is don't use grok, then use it sandboxed. Trying to claim it's the users fault for not using password protection and IP restrictions is completely nonsensical. Same energy as telling someone their computer is more secure when it's off.
- rbanffy 2mo agoReminds me I need to update my `burn.sh` script.
- madaxe_again 2mo agoI once ran rm -rf on a live NFS mount that the live operations of a major brokerage depended upon. I challenge any agent to do worse than an intern with root access.
- grayhatter 2mo agoThe point is to know better than to let the intern hurt themselves. I once saw an engineer try to place the blame on his intern for taking down prod. I was sitting in a meeting with the VP of engineering and someone asked if it was ok for some to blame their intern for the SEV, and I remember the VP saying "I'll talk to $director_for_the_interns_mentor". Interns can't take down prod. An intern's mentor willingly watching an intern take down prod is the closest you can get.