On Tue, May 02, 2006 at 09:49:07PM +0100, Constantine A. Murenin wrote: > On 02/05/06, jared r r spiegel <[EMAIL PROTECTED]> wrote: > > > > if we didn't have that little PIII/450 sitting next to the > > machine now, for the purposes of bringing live, getting > > patches onto, making .tgzs, and then copying them over to > > untar onto host B, what bob beck criticized about would be > > entirely accurate about me. > > One thing I didn't follow in this story is why did this 'virus' change > the host key? > It's not like you can't use the old key with the new sshd install, is it?
it installed its own replacement sshd and host_*_keys. had its own config dir. didn't overwrite anything in /etc/ssh .. was either /etc/ssh2 or /usr/local/etc/ssh2.... i don't believe we found the src for it lying around, but here's the stuff i did find and save from it: ( the sshd is gone, might've been some symlinks i whacked too ) --- $ find r00* r00t3d r00t3d/ssh-askpass r00t3d/ssh-askpass.old r00t3d/ssh-add.old r00t3d/ssh-add r00t3d/ssh-agent.old r00t3d/ssh-add2 r00t3d/ssh-agent r00t3d/ssh-chrootmgr r00t3d/ssh-agent2 r00t3d/ssh-dummy-shell r00t3d/ssh-keygen r00t3d/ssh-keygen.old r00t3d/ssh-keygen2 r00t3d/ssh-probe r00t3d/ssh-probe.old r00t3d/ssh-probe2 r00t3d/ssh-pubkeymgr r00t3d/ssh-signer r00t3d/ssh-signer.old r00t3d/ssh-signer2 r00t3d-2/ssh2 r00t3d-2/ssh2/hostkey.pub r00t3d-2/ssh2/hostkey r00t3d-2/ssh2/ssh_dummy_shell.out r00t3d-2/ssh2/random_seed r00t3d-2/ssh2/ssh2_config r00t3d-2/ssh2/sshd2_config r00t3d-man/ssh2_config.5 r00t3d-man/ssh2.1 --- commandline utils ( eg: ssh-keygen ) were also suid root. > Another thing is trusting the updated hostkey. Imagine you are a > sysadmin at a university. Do you keep the old hostkey when you > reinstall the system on a specific host? in this case, no, :). the "host B" has since been replaced/installed afresh. in situations of non-compromise, regarding the question of hostkey-retention after reinstall/etc, i usually let the new one ride and just give anyone appropriate a heads-up. i've also had it in my mind to finish up a setup using SSHFP records and a reasonably noncomplicated infrastructure to allow various users to update the hostkeys they're responsible for ( eg in a VPN or an environment where a team of persons have individual primary maintainership of a variety of hosts ). that's wicked OT tho. > What about when you upgrade a > Sun workstation, but keep the old hostname? How am I as a student may > know if the new hostkey is legitimate? Good thing if I have an entry > of another Sun workstation in the destination network in my > .ssh/known_hosts, to which I could ssh and see if the host in question > shows the same signature 'locally', but what if I don't? would using a global /etc/ssh/ssh_known_hosts file (which was under your jurisdiction) help solve that? i haven't ever used a global one so don't know first-hand if that's its purpose. certainly wouldn't help if the student accessed the newly-upg'd workstation from their own desktop or whatever; but if they hit it from some other lab workstation (or etc) instead of from their personal machine... -- jared [ openbsd 3.9-current GENERIC ( mar 15 ) // i386 ]
