Using ssh in place of rsh.

Before we could start on this first take a look how authentication is worked in ssh . Authentication varies depending upon the version of protocol.

SSH protocol version 1
The first authentication method is the rhosts or hosts.equiv method combined with RSA-based host authentication. If the machine the user logs in from is listed in /etc/hosts.equiv or /etc/shosts.equiv on the remote machine, and the user names are the same on both sides, or if the files ~/.rhosts or ~/.shosts exist in the user's home directory on the remote machine and contain a line containing the name of the client machine and the name of the user on that machine, the user is considered for log in. Additionally, if the server can verify the client's host key (see /etc/ssh_known_hosts and ~/.ssh/known_hosts in the FILES section), only then is login permitted. This authentication method closes security holes due to IP spoofing, DNS spoofing and routing spoofing. [Note to the administrator: /etc/hosts.equiv, ~/.rhosts, and the rlogin/rsh protocol in general, are inherently insecure and should be disabled if security is desired.] I am call this mechanishm as server authentication mechanism.

As a second authentication method, ssh supports RSA based authenticationThe scheme is based on public-key cryptography: there are cryptosystems.

SSH protocol version 2
When a user connects using protocol version 2, similar authenticationmethods are available. Using the default values for PreferredAuthentications, the client will try to authenticate first using the hostbased method; if this method fails, public key authentication is attempted, and finally if this method fails, keyboard-interactive and password authentication are tried.

The public key method is similar to RSA authentication described in the previous section and allows the RSA or DSA algorithm to be used: The client uses his private key ~/.ssh/id_dsa or ~/.ssh/id_rsa, to sign the session identifier and sends the result to the server. The server checks whether the matching public key is listed in ~/.ssh/authorized_keys and grants access if both the key is found and the signature is correct. The session identifier is derived from a shared Diffie-Hellman value and is only known to the client and the server.

If public key authentication fails or is not available, a password can be sent encrypted to the remote host to prove the user's identity.

Lets go little bit more depth on Server authentication because I am using this.

ssh automatically maintains and checks a database containing identifications for all hosts it has ever been used with. Host keys are stored in ~/.ssh/known_hosts in the user's home directory. Additionally, the file /etc/ssh_known_hosts is automatically checked for known hosts. Any new hosts are automatically added to the user's file. If a host's identification ever changes, ssh warns about this and disables password authentication to prevent a trojan horse from getting the user's password. Another purpose of this mechanism is to prevent man-in-the-middle attacks which could otherwise be used to circumvent the encryption.The StrictHostKeyChecking option can be used to prevent logins to machines whose host key is not known or has changed.

So once every thing is set use following command.

# ssh -t \server\ \command
Ex.
# ssh -t server2.keekar.com ls -ltr

Output will come on the calling screen not on remote screen. Also their is no login shell is allocated means once the command finished it itself colsed.