The SSH keys are user-specific.
Nobody on server B can access server A because of this key in any way.
With your setup, the root user (and nobody else) on server A can both "push" and "pull" files:
From A to B:
serverA> scp /some/file.txt serverB:/some/dir
From B to A:
serverA> scp serverB:/some/file.txt /some/dir
If the key was copied to the authorized_keys file of a non-root user on server B (for example "userB"), you should be aware of two things:
- You must always specify the target username when accessing server B:
scp /some/file.txt userB@serverB:/some/directory
sftp userB@serverB
If you don't specify the username, the default is the same username as you're using on server A (i.e. root). If you don't know the correct username on server B, ask the administrator of server B: there is no way you can find it out on your own except by blindly trying all possible usernames.
- On server B, you can only access the directories userB has access to. You don't automatically have root access on server B just because you are root on server A.
If you want to allow a non-root user on server A to do the copying, you don't need to create new keys: you can just copy the /root/.ssh/id_* files to the ~/.ssh directory of that user and chown the key files to that user. Of course, if you have set a passphrase to that key, you must then allow the user to know the passphrase.
(A good security principle: always use the lowest privilege level that is adequate for the job. If there is a malfunction or an attack, this limits the amount of damage that can be caused.)
Make sure that the private key file is never readable by anyone other than its owner. Otherwise the SSH tools will regard the key as "unsafe" and won't use it.
MK
MK
