In order to transfer files from one server to another you can use Unix tools such as rsync with key pairs. Setting up the connection is rather easy once you know how to do it.
How keys work in public key cryptography
Public key cryptography relies on the use of a key pair that consists of a private and a public key. These two text strings can be compared against one another using a cryptographic algorithm. If the verification succeeds, access is granted.
Think of the public key as the lock on a door. It is technically available to everyone, but can only be opened with the corresponding private key.
In public key cryptography, your private key is like the master key of an apartment house in the real world: it can open all the locks on any door anywhere (for one and only private key, it is possible to generate many public keys).
Public key cryptography relies on an analogy to a lock and a key in the real world; animation by — Vala Afshar (@ValaAfshar) via Twitter
In order for the origin host (ec-instance-01) to be able to connect to the target host (ec-instance-02), you need to follow these steps:
- create a key pair in the .ssh directory on the origin host (the one that will be initiating the connection); the private key of this key pair should never leave this host!
- append only(!) the public key from this pair to the authorized_keys file of your user on the destination host.
Here is how to do this in more detail.
Step 1. Check sshd config on each of the hosts
In /etc/ssh/sshd_config, you may find these lines:
# RSAAuthentication yes # PubkeyAuthentication yes
They indicate the defaults. Leave them alone, unless you want to deactivate RSA authentication. (Should you want to deactivate RSA authentication, make sure you don’t lock yourself out of your instance!)
Step 2. Create a new key pair on the server that will initiate the remote connection
Do NOT use the same key pair that is being used for administrative access to either one of the two instances! Generate a new key pair. By creating a new key pair for your active user on the source host (ec-instance-01), you will ensure that the private key can remain in place and will not need to be transferred over the network.
Here is the basic syntax of the command to generate a key pair:
ssh-keygen -t 'ecdsa|rsa|ed25519' -f /path/to/file
The -t flag specifies the type of key (pick one!); the -f option specifies the file name. Both ECDSA (Elliptic Curve Digital Signature Algorithm) and ED25519 use signatures based on elliptic curve cryptography and are much safer than RSA. ED25519 is immune to a broken random number generator, but newer than ECDSA and less widely supported.
The default location is $HOME/.ssh of the active user. The key size is specified with the -b parameter.
To generate a host ECDSA key pair in 256 bit inside of the directory you just created, use this command:
ssh-keygen -t ecdsa -f $HOME/.ssh/ecdsa_key_file Enter passphrase (empty for no passphrase):
Unless you use a passphrase, the mere possession of the private key will grant any user access to that key and with it the access to remote servers that have the public key installed; if you do use a passphrase for the private key you will need to enter it whenever you use they key to initiate a connection otherwise it won’t work.
When done, you will find two files in the directory you specified
ls -l $HOME/.ssh/ -rw------- 1 root root 556 Dec 21 09:29 ecdsa_key_file -rw-r--r-- 1 root root 180 Dec 21 09:29 ecdsa_key_file.pub
The file ecdsa_key_file contains your top-secret private key (.pem). The file ecdsa_key_file.pub contains your public key. The recommended privileges on the private key are 600 (- rw- — —).
Step 3. Verify placement and permissions on the private key on the host that will be initiating the connection
Make sure that your private key is located in the appropriate directory on the origin host (the host that will be initiating the connection).
The private key belongs either in /home/user1/.ssh/ (this is where most ssh-capable tools will look for it by default) or in a subdirectory within this path.
If you need to adjust permissions on the private key file and its parent directory, use:
chmod 700 ~/.ssh chmod 600 ~/.ssh/ecdsa_key_file
Step 4. Place the public key on the target host (the “lock in the door”)
Append the public key onto the authorized_keys file on the target instance (ec-instance-02) that is found inside the .ssh directory in the home directory of the user that will run the process.
Should there be no such file, create it:
touch .ssh/authorized_keys
and save the key inside: one key per line, followed by space, followed by an optional comment on the location of the corresponding private key.
After creating the authorized_keys file, make sure you also adjust access privileges on it:
chmod 700 .ssh chmod 600 .ssh/authorized_keys
It should be owned by the user and the user’s primary group:
chown username:username .ssh/authorized_keys
The result will look somewhat like this:
[root@ip-10-0-0-243 .ssh]# ls -lat total 12 drwx------ 2 fedora fedora 46 Nov 4 04:25 . -rw------- 1 fedora fedora 526 Nov 4 06:06 authorized_keys
(For more on access restrictions, see this post on Unix/Linux privileges and alternative access methods.)
Step 5. Unblock access through any firewalls and open up AWS security groups
Unblock access through firewalls (if any) and open up AWS security groups of both hosts for each of their respective IP addresses (the “external” ones on each relevant interface that should be able to establish a connection).
You should be good to go now.
Step 6. Connect
To connect from the source host to the destination host, use this command at the prompt of the source host:
ssh -v -i "/path/to/your/private_key_file" remote-user@re.mo.te.ip
This command will generate verbose output (-v). As a result, you may see a couple of errors even though the connection may succeed. Read the output carefully and troubleshoot if necessary.
Step 7. Troubleshoot
On AWS, you may see this warning:
Address 123.345.678.123 maps to ec2-123-456-789-123.compute-1.amazonaws.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
This warning reflects the way EC2 has been designed. Each network interface of an EC2 instance operates two IP addresses: one private internal IP (this IP is being addressed by internal server processes on the “inside” of the instance) and one on the outside (this one can be either a private or a public IP and is accessible from the network). This is simply “as designed” and–in and by itself–nothing to worry about unless you spot an unfamiliar IP. In any case, verify if the IPs match your AWS resources. If they do, proceed. If they don’t, abort.
The success report should include:
debug1: Offering public key: /root/.ssh/ec2migration.keypair/ecdsa_key_file debug1: Server accepts key: pkalg ecdsa-sha2-nistp256 blen 104 debug1: read PEM private key done: type ECDSA debug1: Authentication succeeded (publickey).
Once the connection is established, you can perform any operation you perform locally. To exit the session, use
exit
Once you know that ssh works between the two hosts, it is time to set up rsync (for file backups and the like). For details on how to do this, read: How to rsync Files and Directories between Remote Hosts in the Cloud.
Leave a Reply