[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