What over-wrote my .ssh/id_rsa with a non-sense - malicious code?

Question

This is rather strange story I want to share in case this originates from some kind of hack, so we can better identify signature of the attack.

I work as web developer, I run Ubuntu 20.04, I run strange things in docker on my machine, I have VSC with many development extensions of doubtful quality. I use ansible here and there Python venvs etc. I use ssh agent, my ssh key is password protected and I don't decrypt ssh key after login automatically.

Yesterday I was working as usual, switched off computer in the evening. Today I couldn't ssh to my remote machine with this message.

sign_and_send_pubkey: signing failed for RSA "/home/xxxxx/.ssh/id_rsa" from agent: agent refused operation
ubuntu@xxxxxxxx.xx: Permission denied (publickey).

After little fiddling I checked my private key and to my surprise it was destroyed.

$ cat ~/.ssh/id_rsa
-e 

-e is the content of the file, not happiest moments, but I have cold backup so I resumed work after a while.

But I can't sleep without knowing how this has happened. Lately I did not generate any new keys I did not manipulate files in .ssh/ manually.

The timestamp on the id_rsa is yesterday mid-day during my work, also known_hosts has the same timestamp, other files in .ssh/ have legitimate historical timestamps. Around the time I was sshing onto some old machines, so I can't see reason to touch known_hosts file.

Can anyone think of a situation which would lead to overwriting id_rsa with such non-sense as -e? I'm paranoically thinking of a malicious code in some of the tools I use. Or of course my human error, but I'm usually quite vigilant. Thanks for your ideas.

---

Edit:

1. My bash_history is not complete, because of sub-optimal config of my bash and tmux, see https://askubuntu.com/questions/80371/bash-history-handling-with-multiple-terminals/80882. So tracking down specific command is unfortunately not posible.

2. Based on answer I've discovered that VSCode creates lot of files starting with -, e.g. ~/.config/Code/User/History/-707c1648. Also I was lately having some performance issues with linters (running for couple seconds) and I've seen some temporary files being created next to the processed file. It lead me to hypothesis that maybe there is a clash in VSCode between git command and temporarily created file. This would need extra attention to track down.

Answer 1

No, it's not an attack. It's a mistake somewhere.

Replacing a private key file by invalid content is not a desirable goal for an attacker. An attacker could want to read a private key, but there's no point in changing a private key that's used for authentication, let alone destroy it by replacing it with some invalid text. This gives the attacker no advantage and is easily detectable. An attacker could want to overwrite known_hosts, but only to add their own public key: destroying your own would not give the attacker any advantage either. If it's an attack, it's one that failed in a very weird way, and somehow the attacker didn't even try to clean up. Sure, it's not against the laws of physics, but it is utterly implausible.

With -e as the content, it's very likely a mistake in some shell command where -e was intended as an option but was interpreted as content. With other files modified at the same time, a likely culprit is some file content replacement command: something like find … | xargs perl -i -p -e … where, due to bad quoting or a copy-paste error or a stray space or an unexpected character in a file name or something, the command ended up running on more files than intended.

Check if you have a file name starting with a dash somewhere (locate /- will find it if it's publicly visible, otherwise find ~ -name '-*'). Or perhaps a file name with a space followed by a dash (locate ' -' or find -name '* -*'). That's a likely culprit for mysterious effects resulting from a command that passes file names without using -- and, with the space, not using quotes around variable expansions or using xargs without -0. If you manage to find the culprit and it turns out to be in a shell command that you wrote, see Why does my shell script choke on whitespace or other special characters? and Security implications of forgetting to quote a variable in bash/POSIX shells. If it turns out to be in a shell command that someone else wrote, report a bug and point them to those resources. In your case it was accidental, but an attacker who can control the name of a file could exploit that bug to do useful things.