Hi All,
Need some help regarding file transfer between server.
Suppose we have system-A and system-B. To transfer file from system-A to system-B we usually share the
public keys of system-A to system-B and do scp/sftp to transfer a file.
Is it possible that public key of system-B can be shared to system-A, so that the system-A can establish connectivity to system-B via scp/sftp or using jdbc(java).? Is this even possible?
Thanks in advance.
Yes, it is possible and yes, such a public key is valid for scp-, sftp- and ssh-connections. I don't know if jdbc can use the same key, however.
scp, ssh and sftp all share the same protocol (SSL, secure socket layer) and the keys you exchange are the keys for the protocol, not the application on top of it, therefore the keys are valid for all (or none) of them.
A "key" is exactly what it name suggests: on a system (let us call it "server") in the home of a specific user (call it "serveruser") we put a key of the user "clientuser" from "client". From now on an incoming connection from "clientuser@client" to "serveruser@server" is authenticated via the key instead of a password.
Two things to keep in mind: first, authentication is a directed thing: if "clientuser@client" is allowed access as "serveruser@server" that does NOT mean "serveruser@server" is allowed access as "clientuser@client". It is possible to set that up but these are two different keys placed in two different places where "source" and "target" are reversed. Each of these keys allow for a one-way authentication. (If i give you the keys to my house it does not mean i could enter yours too - you would also have to give me your keys for that.)
Second: all these protocols work in a client-server model. That means for i.e. the ssh connection to work the ssh-daemon has to run on the server side. What the "server" and what the "client" is is determined by the sort of connection, not the system! Trying to log on from system A to system B means A is client, B is server. Trying to log on from B to A reverses these roles, so in the first connection B has to have the daemon running, in the second one it has to be A.
I hope this helps.
bakunin
Thank you Bakunin.
Few clarifications...
But in such a case, when we share a public key from server/system B to server/system A, this generally indicates that user from server B is transferring files to server A and not vice-versa.
Can user from server A connect to server B using this public key. If so then how will the authentication will happen between servers.
We usually use scp -i <pvt_key> <obsolute_path_of_dummy file> user@host or sftp user@host to connect a server. Then is there no need to mention the private key in scp to connect from server A connect to server B?
Also what would be the scp/sftp syntax.
Thank you
No! It means that the authentication is done in this direction.
Consider it this way: if you give someone the key to your house he has access to it. That could mean he takes away something or brings something, but this difference is not depending on him receiving your key or not. He could do both these things without the key too, he just would have to ring your bell (and wait till you answer it) if he lacks the key.
If userA@systemA (notice that "userA" on one system and "userA" on another system are two different accounts, they just happen to share the same name) has his key on systemB this user is allowed to log on (without password). What he does after this logon is not determined by the key at all. He could put files (that is: transfer to the server) or get files (that is: copy files from that server).
This is also possible with classical ftp or sftp: there is the put / mput command to move files to the system and get / mget command to move/copy files from the system.
In scp this would look like:
scp user@system:/path/to/remotefile /path/to/localfile
This will transfer a remote file from "system" using the account "user" to the local system. The other way would be:
scp /path/to/localfile user@system:/path/to/remotefile
This would transfer a local file using the account "user" to the remote system "system". The difference between having put the key of your local user on "system" will be: without the key you need to authenticate, with the key you don't.
I hope this helps.
bakunin