telnet. It is a lot safer and more functional too.
sloginfor connection to the SP:
$HOMEboth on the SP and on the Ships machines. That directory must be readable and executable to you only.
$ ssh-keygenThis command will generate your keys for you and will store the result on three files in the
cat -vto see what's inside.
~/.ssh/authorized_keyson the SP.
ssh. This file is not an ASCI file.
identity.pubfrom the Ships cluster to the SP.
$ cat identity.pub >> ~/.ssh/authorized_keys
identity.pubfrom the SP to
~/.ssh/authorized_keyson the Ships Cluster.
sloginfrom the Ships cluster:
$ ssh-agent bashor
$ ssh-agent tcshdepending on your personal preference. This will spawn a shell, which will run under the
$ ssh-addYou will be asked to type your pass phrase, which you have defined earlier when calling
ssh-keygen. This pass phrase can be very long. A nice thing about using
ssh-agentis that you only have to type it once.
ssh-agentthusly, issue the command:
$ xterm -bg white -ls -sb -sl 300 -n sp20 -T sp20 -e slogin sp20 &If everything has been set up correctly, you should now get a shell in that xterm that runs on node sp20 of the SP. You will not be asked for a password. Your
ssh-agenttakes care of that.
sshdaemon running on the SP will set up appropriate socket connections, entries in the
.Xauthorityfile, and will define your
DISPLAYenvironmental variable, so that it will point to an appropriate socket. All communication that goes through that socket is encrypted!
sshdon the SP issue the commands:
$ xclock & $ xterm -bg white -ls -sb -sl 300 -n xterm@sp20 -T xterm@sp20 &You will see a clock and an xterm appear on your display. The communication between your machine in the laboratory and the SP that is redirected to both windows is encrypted, and cannot be captured easily by network sniffing.
sshtakes a little work, once it's done the system is considerably easier to use than
rsh. To begin with the
DISPLAYenvironmental variable and the corresponding entries in
.Xauthorityare set up automatically.