Trust, but verify

Trust, but verify

Posted Feb 22, 2010 17:14 UTC (Mon) by nix (subscriber, #2304)
In reply to: Trust, but verify by micah
Parent article: Trust, but verify

(I've said this before. Sorry for repeating myself, but, well, I think it bears repeating every so often.)

All too often the most capable users fail to verify keys out of band

A large part of the problem here is that everyone who uses multiple Unix machines by now uses OpenSSH, but the manpages say nothing about how to verify the validity of the remote host key if you get a man-in-the-middle warning. The SSH book may, but anything that depends for its security on all its users buying an expensive book is not going to work.

(FWIW, it was nine years after I started using OpenSSH that I figured out what the fingerprints that ssh-keygen could print were good for, and I'm not technically clueless, merely not a crypto geek. Maybe if I was a crypto geek I'd have known this instantly on reading the manpage, but, again, not everyone is a crypto geek, and you shouldn't have to be a crypto geek to be secure. Right now, thanks to documentation issues like this, no matter how secure OpenSSH is technically, it's open to all sorts of social-engineering attacks simply because its users can't tell how to respond to reports of potential security problems. I'd fix this, but I can't because I don't know the answers myself.)

This is not an academic problem. Last month I got a panicky Sunday phone call from one huge banking client, who'd reinstalled a production server and had started getting 'IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY' errors. It took a lot of effort to calm the poor man down, and he kept on asking why none of the documentation he'd read had explained what the 'SOMETHING NASTY' might be, or had bothered to say 'if you reinstall your OS but keep the same IP address, you'll get this message on all the machines that connect to it'. Then he asked how to identify all those clients and teach them what the new machine was, and I had to say there wasn't a way: ssh-keyscan(1) does the opposite. That didn't go down very well. He's constructing known-hosts files centrally with ssh-keyscan(1) and pushing them out to clients, now, but of course none of the documentation mentions that you might need to do that, either. (Admittedly I hadn't thought of it either, until it was too late.)

(this is your annual djm@ nose-tweaking. I think it's been almost a year since my last one. Anyone written that HOWTO yet? It's really silly that's not there, it's probably vastly simpler to write it than OpenSSH was to write... at least a wiki somewhere on which people can collect common OpenSSH problems and solutions to them, so Google can pick it up. Now that I can set up, I just haven't, so pre-emptive apologies, also I only thought of it ten seconds ago.)

---

(Log in to post comments)