Earlier in the day, I was forced to generate a new public key/private key pair for one of the systems I work with, as it appeared to have been hacked into at some point during the night. The system in question was running a process called 'Slony', which is used for database replication. After building the new key and adding the public keys for the other systems that slony's replication fed, I noticed a rather strange problem.
In addition to the main database, the server that got hacked runs a second archival db, which is supposed to be replicated to and updated alongside the remote systems. When I created the new keys, the replication to the system stopped working. I had originally included a passphrase, and the perl files which ran the replication as a cron job were throwing errors about bad passwords. I decided to rebuild the key again, this time leaving the space blank. That is, I just hit 'Enter' when the system requested a passphrase. It requested the same phrase be repeated, though, and that may be the core of my problem...I may not have gotten rid of the passphrase.
Anyway, when I try to run the system now, it tries to scp the replication files, but the scp times out. As far as I can tell, the timeout is getting called from this segment of code, which comes from a system-installed file called Expect.pm:
unless($scp->expect($timeout,-re=>'[Pp]assword.*?:|[Pp]assphrase.*?:')){
my $err=$scp->before() || $scp->match();
if($err){
if($handler){$handler->($err) }
croak("Problem performing scp: $err");
}
croak("scp timed out while trying to connect to $host");
}I'm getting the 'scp timed out while trying to connect' error message, but not the other one. Anybody have any clue why this is, or what might be done to solve the problem? I was able to force replication today by manually copying the files and removing the call to scp from the cron script, but I'd rather not have to do that; it's an hourly job and can't really afford to get too backed up.
Thanks in advance,
-EnderX
