SSH problems
 

Hi, I'm trying to set up and SSH'd network but I'm beginning to think I've missed/misunderstood something major. Please confirm this for me. As I understand it, SSH creates files which must be locked, one to each machine and one on the master which knows them all. Since they are protected, they can be used for network security?

I have 4 machines, 1 'master', 3 'slaves'. I have run keygen on each slave and accumulated the id_rsa.pub files into an 'authorized_keys' file on master as per instructions. I'm sure this has been done correctly. SSHD is run via systemctl on master and SuSE starts ssh on boot on the others. As it stands the slaves will connect as expected to master, but I can't reverse this, i.e. I can't get master to connect/become a slave.

Do I need to do the same thing in reverse, i.e. make new authorized-keys files for each slave by creating more rsa files on master? Or should what I have done so far (keygen -> upload -> amalgamate -> write protect files) work in both directions?

Simple enough question, but I'm beginning to doubt my sanity! Thanks,

Adrian

I'm not sure what you are trying but in any arrangement using SSH you need OpenSSH-server (sshd) running on the machines you are connecting to and OpenSSH-client (ssh) on the machines you are connecting from.

Then if you are going to use keys with passphrases instead of passwords, you need to generate a key pair for each client+server combination. Use the -C option in "ssh-keygen" to add a comment to the key when generating the key pair so you can keep them straight later. You can use the -f option to give the key pair useful file names. Then once you have the key pairs, copy only the public key to the authorized_keys file on the server in the account you wish to log in to.

Yes, that's exactly what you need to do to enable the "master" as you call it to ssh into a "slave".
And you need to install the openssh-server package on each machine you want to connect to from the master.

Note that you don't have to do the authorized keys stuff manually. The easiest way to do it is through the ssh-copy-id command.

You may not need to do this. For scp (and sftp), you can copy in either direction.
You only need this for ssh'ing both ways.

Thanks for the help. I did as you together suggested. SSHD is installed on each machine. I have an id_rsa file on each machine and their content is also kept in a four line authorized_keys file on the master. This is to be used for commumnication from slaves to master? Then I created a new id_rsa.pub file on the master and sent it to a one-line authorized_keys file on each slave machine. They are all the same. That should take care of communication from master to the slaves?

This seems to work ok (except that 2 of the slaves on ssh-ing to the master still ask for a password, but it may not matter, see following). I can't (using e.g. 'mpirun -host master,slave1,slave 2 -np 3 a.out') connect to more than three machines at any time. I've been through all (as best I can tell) the combinations, 1 with 2, 1 with 3 etc. There's no problem in connecting any one of them to any of the others as long as I don't try to connect more than three of them. If I do it I get a 'public-key' error message (after a pause) but only for one of the machines, not necessarily for the two for which I know there is a password problem. Even more puzzling is that I made the changes you suggested on reciept of your advice and all was well. Now this is happening!

Again, help very gratefully received, Adrian.

It might help to think of SSH in terms of 'server' and 'client'. The 'master'/'slave' paradigm makes sense in MIDI and probably other places, but for ssh it doesn't make much sense.

If I go out to connect to some other box, then I am the client to its server (or service).

If some box connects to me, then I am its server and it is a client.

Something can be both a client and a server at the same time.

Master/slave implies, traditionally, that the slave machine looks to the master for everything; clock, data, whatever. With SSH, this isn't necessarily the case; it's just a remote (but secure/encrypted) shell.

Heck, you don't even have to stay connected to use ssh. You can run a one-off command via ssh on a remote box (I do this all the time for an auto-IP updater I have in place for my home server). Definitely not a master/slave relationship.

This indicates that the keys are not properly set up for this combination.
You can get more useful debugging info by adding -vvv to the ssh command.

Typical reasons for keys not working
- copy - paste errors (which is why I recommend using ssh-copy-id rather than copying manually)
- Permissions: the ssh keys must not have too open permissions, otherwise they are ignored for security reasons. chmod 600 them in case of doubt...

Thanks again for the replies. I have named the machines this way (old habits die hard!) but am happy with the server/client idea. This morning only one machine asks for a password. I -vv'd the remaining password-demander to find that the server accepts the key from the client but may fail because the key is corrupted 'key_parse_private2: missing begin marker'. I guess this means that for this machine I must generate another key pair and cat the id_rsa.pub file to authorized_keys on the server. I'll try it.

Many thanks again, Adrian.

Yeah, try that, and once again, do yourself a favor and, instead of copying the id_rsa.pub content manually, do the following on the client:
It'll ask you for a password and copy the public key.
Then try logging in with