openMosixview - a cluster-management GUI


the home of openMosix



SourceForge Logo

freshmeat.net

openMosixview + ssh:


(this HowTo is for SSH2)

You can read the reasons why you should use SSH instead of RSH everyday
on the newspaper when another script-kiddy hacked into an insecure system/network.
So SSH is a good decision at all.

freedom x security = constant    (from a security newsgroup)

That is why it is a bit tricky to configure SSH. SSH is secure even if you use
it to login without being prompted for a password.

Here is a (one) short way to configure it.
exectute :

   ssh-keygen -t rsa

(give no password/passphrase)
put the resulting key from
/root/.ssh/id_rsa.pub
into the /root/.ssh/authorized_keys2 of the target system
That's it ;)



Here is a (one) longer way to configure it.

At first a running secure-shell daemon on the remote site is required.
If it is not already installed install it!
(rpm -i [sshd_rpm_packeage_from_your_linux_distribution_cd])
If it is not already running start it with:

   /etc/init.d/sshd start

Now you have to generate a keypair for SSH on your local computer whith ssh-keygen.

   ssh-keygen -t dsa -b 2048

This is a really strong key, so be patient.
You will be prompt for a passphrase for that keypair.
The passphrase normally is longer than a password and may be a whole sentence.
The keypair is encrypted with that passphrase and saved in

  /root/.ssh/identity    //your private key
and
  /root/.ssh/identity.pub     //your public key

Do NOT give your private-key to anybody!!!

Now copy the whole content of /root/.ssh/identity.pub
(your public-key which should be one long line) into /root/.ssh/authorized_keys
on the remote host.
(also copy the content of /root/.ssh/identity.pub to
your local /root/.ssh/authorized_keys like you did it with the remote-node
because openMosixview needed password-less login to the local-node too!)

If you ssh to this remote host now you will be prompted for the passphrase
of your public-key. Giving the right passphrase should give you a login.
In our setup we didn't provide a passphrase for the public key, that's why we
just login via ssh to the node without providing any passphrase!
You can experience some troubles during this ssh setup.
First, it could happen that you did all the above, but you're still asked for a password
while trying to login to your host by root. In this case, check that your sshd_config

have these options enabled:
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords yes

, if they are set, but it doesn't work, enable the logging option in sshd_config: LogLevel DEBUG3

and try to connect via again (don't forget to restart sshd each time you modify sshd_config!!!).
Then you have to check your /var/log/messages, and there could be some warnings from sshd
about bad permissions for /.ssh directory and maybe some key files permissions.
If so, you have to correct the premise permissions - in a few words the keys must be available
only for reading for root group (except your private key), and /.ssh respectively available
for entrance to the root group.

What is the advantage right now???
The passphrase is normally a lot longer than a password!

The advantage you can get using the ssh-agent.
It manage the passphrase during ssh login.

   ssh-agent

The ssh-agent is started now and gives you two environment-variables you should set
(if not set already).
Type:

   echo $SSH_AUTH_SOCK
and
   echo $SSH_AGENT_PID

to see if they are exported to your shell right now.
If not just cut and paste from your terminal.
e.g. for the bash-shell:

   SSH_AUTH_SOCK=/tmp/ssh-XXYqbMRe/agent.1065
   export SSH_AUTH_SOCK
   SSH_AGENT_PID=1066
   export SSH_AGENT_PID

example for the csh-shell:

   setenv SSH_AUTH_SOCK /tmp/ssh-XXYqbMRe/agent.1065
   setenv SSH_AGENT_PID 1066

With these variables the remote-sshd-daemon can connect your local ssh-agent
by using the socket-file in /tmp (in this example /tmp/ssh-XXYqbMRe/agent.1065).
The ssh-agent can now give the passphrase to the remote host by using this socket
(it is of course an encrypted transfer)!

You just have to add your public-key to the ssh-agent with the ssh-add command.

   ssh-add

Now you should be able to login using ssh to the remote host without
being prompted for a passwod!


You could (should) add the ssh-agent and ssh-add commands in your
login-profile e.g.

   eval `ssh-agent`
   ssh-add

Now it is started when you login on your local workstation.
You have done it! I wish you secure logins now.

openMosixview
There is a menu-entry which toggles using rsh/ssh with openMosixview.
Just enable this and you can use openMosixview even in insecure
network-environments. You should also save this configuration
(the possibility for saveing the current config in openMosixview
was added in the 0.7 version) because it gets initial data from the slave
using rsh or ssh (just like you configured).

If you choose a service wich is not installed properly openMosixview will not work!
(e.g. if you cannot rsh to a slave without being prompted for a password
you cannot use openMosixview with RSH; if you cannot ssh to a slave
without being prompted for a password you cannot use openMosixview with SSH)

howto created by M. Rechenburg
i forgot something? sure. Mail what should be added.


Linux is a registered trademark of Linus Torvalds; openMosix is developed by Moshe Bar, All rights and copyright on openMosix reserved by Moshe Bar; MOSIX is developed by Prof. Amnon Barak, All rights and Copyright on MOSIX reserved by amnon at cs.huji.ac.il; SuSE Linux is a registered trademark of SuSE; RedHat Linux is a registered trademark of RedHat; Mandrake Linux is a registered trademark of Mandrake; Debian Linux is a registered trademark of Debian; openMosixview/Mosixview is GPL software and based on QT from Trolltech (please read the GPL-Licence policy); the 3dmosmon is developed by Johnny Cache. all other registered trademarks are owned by their owners