I think that the script could do with some improvements - Use strict and warnings, three arg open with proper error checking, error checking on the close due to the piped open, and using <> instead of <STDIN> would be some best practices that would also make the script more robust and easily debuggable in case of errors.

Anyway, I think huck is on to something. I can reproduce the problem when I run the program as ./1194547.pl <hosts.txt, but when I run the program as cat hosts.txt | perl 1194547.pl, it works. Also, adding the </dev/null to the command as huck suggested makes it work as well, as does using the ssh -n switch, which has the same effect. So while I haven't dug into the details, changing the uptime to cat does seem to show that the problem is ssh is reading STDIN and sending it to the remote command.

However, as I wrote about at length here, shelling out to an external process is not always a good idea, especially when you can't trust the user input. The great Net::OpenSSH module, while it does also use external ssh processes, does this in a more robust fashion, plus it provides a whole lot more functionality (Net::OpenSSH::Parallel might be of interest to you). I would strongly recommend using that module instead of shelling out to ssh yourself.