LDAP logins to Projects VM failing

[warmerdam]

It seems that LDAP logins to the project VM have stopped working. I believe this was first observed on July 12th or so (jmckenna) and I have confirmed this (warmerdam). Martin is apparently looking into the problem without it being immediately obvious what is wrong.

[martin]

It's working again, but I wonder why the person behind the user account 'crschmidt' has installed a custom SSH server binary last Saturday .... If Chris Schmidt himself didn't, then we should consider the 'projects' VM as being compromised and _everyone_ who has tried password authentication on the 'projects' VM, I repeat: _everyone_ is urged to change his LDAP password.

[crschmidt]

No, I did not do this. Presumably my account was compromised in some way. (My password is relatively strong, and I only use it for OSGeo-related activities, so I'm not sure how my account was compromised; I'd apologize, but at this point it doesn't seem like it would do much good.)

[martin]

Ok, all binaries in /bin/, /sbin/, /usr/bin/, /usr/sbin/ as well as all libraries which are linked from SSH binaries do _not_ look suspicious. With a little bit of luck we're done by everybody in the "telascience" shell group changing their LDAP passwords if they tried to log into the 'projects' VM recently (since Saturday). Everybody !!

[tmitchell]

Does this affect shared key authorization for crschmidt under root accounts on other VMs? Just wondering if we should pull any of those keys, if they exist.

[crschmidt]

No, that key is only on my laptop, and from what I can tell, the machine which was compromised was my webserver. So I don't think that we need to worry about anyone having access to the private key for one of the root accounts.

[tmitchell]

Okay, that makes sense. I was thinking more that if the shared key on the servers was changed (or anyone other keys changed), it would give another easy way to log in without needing your private one.

[crschmidt]

Martin checked out a number of things on that server (including the root authorized_keys) and found no other modifications / additions; it looks like we have a full log of the things that were done to the system, and it was just changing the SSH daemon to the manually copied in one. I think the most important part now is just to get everyone with shell access who has logged in since Saturday to change their passwords, so I'll send out an email tonight to everyone in the shell group with this information.