CW> Sure, but that's a problem with *their* machine (i.e. it allows access CW> from unauthorised persons) rather than a problem with your machine.
But from us regular users point of view it is *my* account on their machine that is the problem (if the administrator is not the up to date type.) CW> (If they aren't running an sshd with blacklisting support, then that's CW> primarily their problem. However, nobody who has applied any of the CW> Debian openssh upgrades has this problem.) But if they haven't, then it is my account that is putting their whole machine in danger, and I'm blissfully unaware even though having done sid upgrades. Idea: new ssh _client_ that will also block outgoing ssh contacts if bad keys are detected. $ ssh bla.com ***You are using a bad key. Override with --override-bad-key. You must fix this by doing ... else it is just like leaving one of your vacation homes' door unlocked.*** Exit 1. Or maybe you already do this. OK, breaks upstream compatibility. CW> /usr/share/doc/openssh-server/README.compromised-keys.gz You might want to add some dates into that file, lest they read it months later etc. I see there OpenSSH keys used for user authentication must be manually regenerated, including those which may have since been transferred to a different system after being generated. which indeed probably covers somewhat what I'm talking about. But doesn't mention the danger present before one does any updating. If I got half of this wrong, no problem, as I'm kinda hazy of course. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]