Unable to run perl script for ssh login to Windows server (using Net::SSH::Perl) from crontab

I have a Perl script which is doing remote login to the Windows server via the Net::SSH::Perl module.

If I run the script manually from my shell, it gives no error. Running from a crontab, however, it connects properly to the remote Windows server but can't log in.

Here is the script:

use Net::SSH::Perl;
use Date::Calc qw(:all);
use DateTime::Format::Epoch;

$lin_host = `hostname -s`;
chomp($lin_host);
print "Test script is started on server $lin_host at time ",join(":",Now()),"\n";
$host = "any valid ip";
$user = "valid username";
$pass = "valid password";
$port = "valid port";

if ($ARGV[0] eq "eodupdate")
{
        $host = "valid host";
}

print "Connecting : $host with user $user and pwd $pass\n";
my $ssh = Net::SSH::Perl->new($host,port=>$port);
if ($ssh eq undef)
{
        print "Can't connect to server $host\n";
        exit;
}
print "Connected ... \nNow ,Trying to loggin ,sever ip : $host\n";
$ssh->login($user, $pass);
print "Yeah , successfully logged in to $host\n";

On server A, By running this script in csh shell I get output like :

Test script is started on server name
Connecting : * with user * and pwd *
Connected ...
Now ,Trying to loggin ,sever ip : *
Yeah , successfully logged in to *

In the shell, perl test.pl and sudo perl test.pl both work fine.

But running this script in cron as user root:

Test script is started on server name
Connecting : * with user * and pwd *
Connected ...
Now ,Trying to loggin ,sever ip : * 

Note: I am able to do this on another Linux server B with same file permissions, same username, and same password. The difference is that when I run this Perl script without sudo on server B, I am getting this error:

host key has changed! at /usr/local/share/perl5/Net/SSH/Perl/Kex/DH1.pm line 49

I don't see this error from Linux server A (the one on which I can't connect via cron)

What is wrong and how can I solve it?

It looks like host key verification is failing preventing the authentication. There may be host keys stored in ~/.ssh/known_hosts in the user's(root) home directory try deleting the remote host key from "known_hosts" and then re-try.