Establishing remote connection to a Xserver from a UNIX Box

Hello Guys ,

I have been working on a script where we are looking to connect a remote Xserver from a Unix box. Once a connection is made , i need to run several commands on remote machine to check various stuffs.

As per my knowledge on unix (which is like a drop in ocean) , i found SSH as a best option for doing my task as it allows freely to run any command on remote machine . I declined using ftp or sftp , as these connections do not satisfy my needs i.e running commands like "kill, ps, sed , grep etc". I considered telnet but server do not supports it.

I frankly cannot thing of any other best option then SSH.

I tried implementing SSH in my shell script , but got stuck when on password step. I had no idea to overcome this password thing automatically in my shell script. After googling a lot , i found options like sshpass, scp, spawn and others utilities , but none of them works at my unix server.I don't have options to use RSA here.

i am looking for some solution so i can use SSH in my script and pass the password and then log in to remote machine .

Also if u guys have better solution then SSH , it will always be welcomed.

Looking forward for expert's help.

Cheers !!!!!!!!:slight_smile:

Try using the ssh keyed-access mechanism. You generate a key pair with ssh-keygen as part of this mechinism. See the man pages.

thanks for ur comments.

But as i have mentioned before , i am not authorised to use keygen here. Also i have list of X servers which i will be login to and even if i get keygen done , i have to form a RSA , copy it to remote machine and then use ssh in my script.

Just like below :

Step 1: Create public and private keys using ssh-key-gen on local-host

jsmith@local-host$ [Note: You are on local-host here]

jsmith@local-host$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/jsmith/.ssh/id_rsa):[Enter key]
Enter passphrase (empty for no passphrase): [Press enter key]
Enter same passphrase again: [Pess enter key]
Your identification has been saved in /home/jsmith/.ssh/id_rsa.
Your public key has been saved in /home/jsmith/.ssh/id_rsa.pub.
The key fingerprint is:
33:b3:fe:af:95:95:18:11:31:d5:de:96:2f:f2:35:f9 jsmith@local-host
Step 2: Copy the public key to remote-host using ssh-copy-id

jsmith@local-host$ ssh-copy-id -i ~/.ssh/id_rsa.pub remote-host
jsmith@remote-host's password:
Now try logging into the machine, with "ssh 'remote-host'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.
Note: ssh-copy-id appends the keys to the remote-host�s .ssh/authorized_key.

Step 3: Login to remote-host without entering the password

jsmith@local-host$ ssh remote-host
Last login: Sun Nov 16 17:22:33 2008 from 192.168.1.2
[Note: SSH did not ask for password.]

jsmith@remote-host$ [Note: You are on remote-host here]

oh, can't used key'ed access, use expect to pass password.

If he's not even allowed to use keygen, his administrators will be livid to find someone circumventing it with the expect brute-forcing tool.

i have no idea about "expect ". Hw do i use it ?

Or is there no other way through scripting , that i can pass password to console ?

Regards,
Himanshu Sood

"interactive password authentication" means "password typed by a human being in realtime authentication" and nothing else will do. It insists on a password typed into a terminal, not a file, not a pipe. You literally have to fool it with a brute-forcing tool like expect to make it believe its coming from a terminal.

But if you're not even allowed to use safe and secure keys, your administrators will be absolutely livid to discover you using an unsafe, insecure expect kludge instead.

If you can login with SSH by typing the password at the terminal to gain legitimate access to the remote server, why are you not allowed to use keys? Did you think to ask your administrator that? It's surely preferable to any other solution you may concoct (likely against his wishes and in violation of some policy or other), and would surely be more secure.