Those failures in the “grep(1)-centric script” are pretty alarming; hopefully they’re fixed now, and no one tried to log in with a username of `exploit_written_in_bashcode_here`
Interesting thought. The scriptery that finds usernames from ssh login failures as it stands now (and has for a number of years) is more like a two-step process.
The first extracts the likely user names and the IP addresses from the failures from the auth log. This part is naive enough that if what is where a username should be in the log line contains any kind of whitespace, the IP address output file will have at least one non-IP-address in it (typically the word “from”).
The next is a one-liner that compares each line in the usernames output file (the namestotry.txt file referenced in the article) to the list of existing spamtraps.
So I suppose there is a chance that if they managed to get a still valid exploit into the auth log with no whitespace that would lead to bits being just chopped off at the end, that attack vector could succeed, if it is structured so grep would somehow feed the thing to a subshell.
I’ve been pondering rewriting those things as something not-shellscript for a while, but there’s always the issue of sitting down to actually do that.