When migrating between versions of SFTP Gateway, you might consider a cut-over where SFTP users continue to connect to the same DNS hostname.
When doing so, you need to make sure the server host keys on the new server match the old. Otherwise, SFTP users will encounter a security warning stating the server host keys have changed.
Newer versions of SFTP Gateway v3 include the server host keys in the backup and restore process. When migrating from SFTP Gateway v2 to v3, the Python backup script also exports the server host keys.
But in some production environments, it is critical that the server host keys on v3 match those on v2. This article covers the manual process of making sure the server host keys on v2 make it to v3.
Back up the server host keys on v2
For v2, the server host keys are in this location:
To back up your keys, run these commands:
sudo su cd /etc/ssh/ mkdir backup-keys cp -a ssh_host* backup-keys/ tar czvpf backup-keys.tar.gz backup-keys
These commands do the following:
- Creates a folder called backup-keys/
- Copies all the public and private keys into this folder
- Bundles this folder into a single file
You should end up with a file:
Move this to your home directory:
mv backup-keys.tar.gz /home/azureuser/
Then, you can use your SFTP client to pull the
backup-keys.tar.gz file off the 2.0 server, and onto your workstation.
Move the server host keys to v3
On the 3.0 server, use an SFTP client to upload the
backup-keys.tar.gz file to your home directory:
SSH into the server, and elevate your permissions with this command:
Then run these commands:
mv backup-keys.tar.gz /opt/sftpgw/ cd /opt/sftpgw/ mkdir backup-v3 cp -a ssh_host* backup-v3/ tar xzvpf backup-keys.tar.gz cp -a backup-keys/* .
There's a lot happening, so here's what's going on:
- The server host keys on v3 are located in
- First back up the original v3 keys
- Then, extract the v2 keys
Rename the v2 server host keys
The v2 key names have a suffix of
_key, which you will need to change for v3.
mv ssh_host_ed25519_key ssh_host_ed25519 mv ssh_host_ed25519_key.pub ssh_host_ed25519.pub mv ssh_host_rsa_key ssh_host_rsa mv ssh_host_rsa_key.pub ssh_host_rsa.pub
ecdsa key on v3 expects the size as part of the key name, so you need to rename the v2 key appropriately:
mv ssh_host_ecdsa_key ssh_host_ecdsa_256 mv ssh_host_ecdsa_key.pub ssh_host_ecdsa_256.pub
Finally, change the ownership of the server host keys so that they are owned by the
sftpgw Linux user. This is important for the next section.
chown sftpgw:sftpgw ssh_host_ecdsa_256 chown sftpgw:sftpgw ssh_host_ecdsa_256.pub chown sftpgw:sftpgw ssh_host_ed25519 chown sftpgw:sftpgw ssh_host_ed25519.pub chown sftpgw:sftpgw ssh_host_rsa chown sftpgw:sftpgw ssh_host_rsa.pub
Get the v2 server host keys into the database
The v3 server automatically generates its own set of server host keys. Although you can see these files in
/opt/sftpgw/, the source of truth is stored in the database.
In this section, you are going to run a script to clear out the default server host keys generated by v3.
Create a bash script file:
cd /opt/sftpgw/ touch clear-v3-server-host-keys.sh chmod +x clear-v3-server-host-keys.sh
vim and add the following code:
"BEGIN; \ DELETE \ FROM properties \ WHERE key <> 'bannerText'; \ END;" sudo chsh -s /bin/bash postgressudo chsh -s /bin/bash postgres sudo -i -u postgres psql -d sftpgw -c
Finally, run the bash script:
You should see the output
COMMIT after the script has successfully cleared out the v3 server host keys.
Finally, restart Java:
service sftpgw-admin-api restart
When Java restarts, SFTP Gateway will realize that there are no server host keys in the database. So it will incorporate the server host key files in
/opt/sftpgw/, and import these into the database.