*#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.
_______________________________________________
Beowulf mailing list, [email protected] sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
