Why do you want to avoid "any Perl module"? This plays against the strengths of Perl. Note that many Perl modules are simply Perl code so that you can just copy the code from the module into your program.

But take a look at IPC::Open3 and/or system to see how you could run one or more ssh processes to connect to other machines. Also see Net::SSH::Perl.

Not very useful as there's no way to supply a password (which you shouldn't do anyways). If you need to, install sshpass. A far better idea is to use SSH keys.

No Perl modules required. -l is the login (user) name

perl -e 'system("ssh -o ConnectTimeout=10 -l smd 192.168.1.139")'

smd@192.168.1.139's password: 

Welcome to Linux Mint 17.1 Rebecca (GNU/Linux 3.13.0-37-generic x86_64
+)
[download]

If you don't want to use a perl module you can try Inline::Python and use a Python module instead. Or just write the whole thing in Python since Inline::Python is a module.

Or if you want to do this seriously, your three best options are, use a CPAN module, open the source code of a CPAN module and work from there, or don't use perl at all and use OpenSSH. If you choose any of the first two options, you'll probably end up using a Core module at the very least.

Now if this is not the answer you expected, you are going to have to give more information on what you are trying to do, and why you have such an impractical restriction as "without using any perl module".

Categorically speaking, you should a-l-w-a-y-s use SSH keys, and n-e-v-e-r use passwords.   Passwords should never be embedded in a script.

When you ssh to a remote server that has the proper key installed (in the hidden .ssh directory of the user you are connecting to), there is no password-challenge.   The ssh-keys daemon, which should be running on the local userid, provides the necessary key to the remote, which authenticates you, asking no further questions.   (In fact, you should set up each sshd so that it will not accept “password” access.)

Instead of saying, “say the magic word,” the remote sshd demands that the client present a known, and should-be unique, badge.   If the remote system possesses a recognized badge, access is granted to that particular account ... which, of course, should be an account specifically dedicated to the use of “this” script.

Your remote should have a set of five unique certificates:   one for each of the five systems, and all five specific to this script (or set of scripts).   Each of the five systems should have, in its list of acceptable certificates for the specified userid, its certificate from this set.   Only the expected script, which possesses all five, can seamlessly connect to all five servers, and then only to the expected userid on each.