[Beowulf] i7-4770R 128MB L4 cache CPU in compact 0.79 litre box - DIY cluster?

Mark Hahn hahn at mcmaster.ca
Tue Jan 21 21:36:42 PST 2014


> *#scp -r /root/.ssh clisterX:/root/.ssh*

you should not do this.
use ssh-copy-id to push public keys to remote authorized_keys files.
it doesn't do anything magical, but it's certainly better than copying the
whole .ssh tree around.  getting the permissions right is probably
where you have a problem, but I think you should also think clearly
about where your private key(s) exist, especially if they're unencrypted.

> *later I try connect to nodo but, I have that put key :(  *

I'm not sure I understand.  creating a keypair doesn't cause it to be used;
only adding a key to the destination/target hosts's authorized_keys file 
lets you connect.

> *when I create key in file authorized_keys in "nodo" to comunicate with
> master with ssh*

just to be clear: authorized_keys exists on the target machine for the 
purpose of defining which keys (and conditions) will be accessible via
key-based login.  (hostbased login makes sense in some cases, especially
clusters where all the compute nodes share authentication.)

> *#scp -r /root/.ssh master:/root/.ssh*
> *later I try connect to master and I can without put key!*

you should probably run "ssh -v" to see exactly what is happening.
this shows information about which keys (or other authentication
mechanisms) are being tried or used.

one final comment: the most common problem in setting up keys is 
getting permissions wrong.  it can be too-open permissions on the 
local private key, but more often it's directory or file permissions
on the target machine.  you won't see the latter in "ssh -v" - 
you need to look at the remote ssh log (usually /var/log/secure).
(the main win of ssh-copy-id is to get the permissions right...)

regards, mark hahn.



More information about the Beowulf mailing list