Step 4.7 Using Public Key Authentication for Automated File Transfers

2017-11-03 09:05:01

Problem: Automated scripts and file transfers cannot decrypt password-protected public keys.

It is possible to use public key authentication to automatically transfer files from one machine to another. While this is usually not recommended, it may be desirable for batch scripts. However, this involves setting a blank passphrase which clearly leads to some risks. Therefore this mechanism should only be used for a one-way connection between two specific, non-privileged user IDs on different hosts .

Action 4 7 1 Decide who trusts who

Decide which system trusts which and what user ids are going to be used on each. Minimal privilege (non-root, not-a-real-person) user ids are best for system-to-system trust relationships. In general, the less secure, less vital system should trust the more secure, more critical system.

In the example below, we will set up sshuser on client.example.com to connect to server.example.com as user sshuser2 .

Action 4 7 2 Generate a key pair

First, a key pair needs to be generated for sshuser on server.example.com . Generating a key pair is detailed in step 4.3 of this book. However, when a key pair is generated for an automated transfer, it should be configured so that we are never prompted to decrypt the private key.

To accomplish this, do not enter a passphrase when prompted by the ssh-keygen program - instead just press enter . This can also be accomplished by supplying the “P option with a null passphrase to ssh-keygen (e.g. “P "" ). When you do not enter a passphrase, ssh-keygen understand this to indicate that you do not want the private key encrypted:

[sshuser@client.example.com]$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/sshuser/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/sshuser/.ssh/id_rsa. Your public key has been saved in /home/sshuser/.ssh/id_rsa.pub. The key fingerprint is: 7e:ab:80:12:06:0f:b9:1f:f1:64:b0:0a:00:7c:69:b4 sshuser@client.example.com [sshuser@client.example.com]$

Keep in mind that since the private key is now stored unencrypted, if anyone were able to get the private key file, they would be able to log in on the remote machine without an authentication challenge. This is the reason we use a restricted user account on both machines when creating key pairs with no passphrase.

Action 4 7 3 Copy the public key to the remote system

The key pair for sshuser should now be created and stored in the ~sshuser/.ssh directory, where ~sshuser is sshuser's home directory, in either the id_dsa.pub or id_rsa.pub file, depending on which type of key pair you created:

[sshuser@client.example.com]$ cd .ssh [sshuser@client.example.com]$ ls -l total 7 -rw-r--r-- 1 sshuser sshuser 223 Jan 22 11:00 authorized_keys -rw------- 1 sshuser sshuser 883 Feb 24 12:29 id_rsa -rw-r--r-- 1 sshuser sshuser 239 Feb 24 12:29 id_rsa.pub -rw-r--r-- 1 sshuser sshuser 2880 Feb 21 08:50 known_hosts [sshuser@client.example.com]$ cat id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAvXDPUt60ScgSrCFcYffvMTRVK8+IzOe1JKGDoIwCKlZB1E1GGkGQPHftVnan5oc+hX6C1wg66TFL M/38jtQhWmGpLo00ZbfzmA9qrE72T/G58Vl57chZOmFWMWzXXYuni8v7ThT2pMXTY5csJRqX4pPquM76LGK6Qtpf5vyQH9M= sshuser@client.example.com [sshuser@client.example.com]$

The public key of sshuser now needs to be copied over to server.example.com for sshuser2 to use. This can be done any way that is convenient . Since we are transferring the public key and we don't care who sees the public key, it can be transferred in a clear-text manner, such as by email or FTP:

[sshuser@client.example.com]$ scp id_rsa.pub sshuser2@server.example.com:~ sshuser2@server.example.com's password: ******* id_rsa.pub 100% ***************************** 239 00:00

Once sshuser's public key is copied to server.example.com , open an SSH session to server.example.com and log in as sshuser2 . If you have restricted sshuser2's account such that it is unable to log in, you will have to log in to server.example.com as root, and then become sshuser2 using the su command:

[sshuser@client.example.com]$ ssh sshuser2@server.example.com sshuser2@server.example.com's password: ******* Last login: Mon Feb 24 11:19:15 2003 from client.example.com [sshuser2@server.example.com]$

Once you log in as sshuser2 , change to the .ssh directory in sshuser2's home directory. You should see a file named authorized_keys .

[sshuser2@server.example.com]$ cd .ssh [sshuser2@server.example.com]$ ls -l total 12 -rw-r--r-- 1 sshuser2 staff 227 Feb 24 12:21 authorized_keys -rw-r--r-- 1 sshuser2 staff 223 Dec 9 14:25 known_hosts [sshuser2@server.example.com]$

Append sshuser's public key, which you copied, to the authorized_keys file. Be careful when appending the key to the file as the key should remain as one continuous line (i.e. no carriage -returns or linefeeds).

[sshuser2@server.example.com]$ ls ~/id_rsa.pub /home/sshuser2/id_rsa.pub [sshuser2@server.example.com]$ cat ~/id_rsa.pub >> authorized_keys [sshuser2@server.example.com]$ cat authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEA2Rv612mkhAXokW2tvA/6w34OM2PzYS9xQmY9PQg07qMqp0UbQAuEQEUc7Oga6wY9jBBQWmLx7B3c RuDdOQnASUugqQypuIVqqw4iaEi24qmrI6JTDCwEWZQ+ndODVXDDQeTVEVJLxNvvbwSvcvi3tV+7m26HooFYvoGWb7njJqk= sshuser2@server.example.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAvXDPUt60ScgSrCFcYffvMTRVK8+IzOe1JKGDoIwCKlZB1E1GGkGQPHftVnan5oc+hX6C1wg66TFL M/38jtQhWmGpLo00ZbfzmA9qrE72T/G58Vl57chZOmFWMWzXXYuni8v7ThT2pMXTY5csJRqX4pPquM76LGK6Qtpf5vyQH9M= sshuser@client.example.com

Once sshuser's public key has been appended to the authorized_keys file successfully, you should be able to automatically log in and transfer files from client.example.com as user sshuser to server.example.com as sshuser2 without being prompted for authentication.

Action 4 7 4 Verify that you are able to log in without an authentication prompt

In order to verify that the public key authentication is not prompting for a passphrase, try logging in from server.example.com as sshuser to server.example.com as sshuser2. If everything is configured properly, you should not be prompted for a passphrase and should log in automatically.

[sshuser@client.example.com]$ ssh sshuser2@server.example.com Last login: Mon Feb 24 12:25:16 2003 from client.example.com [sshuser2@server.example.com]$

Action 4 7 5 Verify that a scp transfer works

If you are able to log in to the remote system using OpenSSH without being prompted for a passphrase, you should be able to use scp to copy a file to server.example.com as sshuser2 from client.example.com as sshuser , also with no passphrase:

[sshuser@client.example.com]$ scp test.pl sshuser2@server.example.com:~ test.pl 100% ***************************** 151 00:00 [sshuser@client.example.com]$

Action 4 7 6 Secure the connection

At this point you have created the capability for a user account on a client to log in to a server using public key authentication without being prompted for a passphrase. While this makes using public key authentication more convenient , it also opens up some security risks. Namely, the private key used to log in to the remote server is now sitting unencrypted. If a malicious attacker were able to obtain the unencrypted private key, he would be able to log in as the remote user. Therefore, some further restrictions should be put into place to lock down the use of the unencrypted private key.

OpenSSH provides a number of options that can be used to restrict a key used for authentication. These options are entered in the authorized_keys file on the remote server, immediately preceding the associated key entry. Multiple options can be used to further restrict the use of the key. The options available are described below.

from=" hosts " “ The from option specifies IP addresses or resolvable hostnames that are allowed to use the key for authentication. Wildcards "*" and "?" and negation "!" can also be used to indicate which hosts are allowed to connect. Multiple hosts can be specified in a comma-delimited list. An example of a key using the from option is shown below:

from="192.168.1.10,*.example.com,!client.example.com" ssh-rsa AAAAB3NzaC1yc2Eaaaa253gAAIEAuG8ugce5+/ Cno2FCcyraJN2LK5Gsl+ujV8ad8s1lobhldonA20x6i9eNln8+LP76k2jMuLFtWEmc8MwmvrnIL2ZH2SOC90QpB3KwBuS6suVWT X5AKkXpB5uEKMWQJjHoEFOQx7Kpzmkav83n73naE8u/oyagSIgLVxCIvEhk9XX8= sshuser@example.com

Note

If the OpenSSH daemon is set to fall back to password authentication when public key authentication is not successful, a malicious user may still be able to log in to the system if they know the password for the account! That is because these options only restrict the use of the key, not the use of the account.

command="command" “ The command option specifies a command that is run immediately after the key is used for authentication. After the command executes, the SSH session will be terminated immediately. This option is extremely useful when you want to restrict the use of a key to single commands, such as backups or file copies.

command="/home/backup/backup.sh" ssh-rsa AAAAB3NzaC1yc2Eaaaa253gAAIEAuG8ugce5+/ Cno2FCcyraJN2LK5Gsl+ujV8ad8s1lobhldonA20x6i9eNln8+LP76k2jMuLFtWEmc8MwmvrnIL2ZH2SOC90QpB3KwBuS6suVWT X5AKkXpB5uEKMWQJjHoEFOQx7Kpzmkav83n73naE8u/oyagSIgLVxCIvEhk9XX8= sshuser@example.com

environment="variable=value" “ The environment option specifies a variable that is added to the environment whenever the key is used. If this environment variable is already set, its previous value will be overwritten. This option can be useful for limiting the PATH environment variable in backup scripts to prevent certain attacks. This option can be specified multiple times.

environment="PATH=/bin:/usr/bin",environment="TERM=vt100" ssh-rsa AAAAB3NzaC1yc2Eaaaa253gAAIEAuG8ugce5+/ Cno2FCcyraJN2LK5Gsl+ujV8ad8s1lobhldonA20x6i9eNln8+LP76k2jMuLFtWEmc8MwmvrnIL2ZH2SOC90QpB3KwBuS6suVWT X5AKkXpB5uEKMWQJjHoEFOQx7Kpzmkav83n73naE8u/oyagSIgLVxCIvEhk9XX8= sshuser@example.com

permitopen="host:port" “ The permitopen option restricts local port forwarding to only the hosts and ports specified. Unlike the from option, wildcards and negation cannot be used. Multiple permitopen options can be specified. See step 6.1 for more information on port forwarding.

permitopen="mail.example.com:25",permitopen="mail.example.com:143" ssh-rsa AAAAB3NzaC1yc2Eaaaa253gAAIE AuG8ugce5+/Cno2FCcyraJN2LK5Gsl+ujV8ad8s1lobhldonA20x6i9eNln8+LP76k2jMuLFtWEmc8MwmvrnIL2ZH2SOC90 QpB3KwBuS6suVWTX5AKkXpB5uEKMWQJjHoEFOQx7Kpzmkav83n73naE8u/oyagSIgLVxCIvEhk9XX8= sshuser@example.com

no-port-forwarding “ This option will disallow any port forwarding when the key is used. See step 6.1 for more information on port forwarding.

no-X11-forwarding “ This option will disallow X11 forwarding when the key is used. See step 6.3 for more information on X11 forwarding.

no-agent-forwarding “ This option will disallow agent forwarding when the key is used. Agent forwarding is used in OpenSSH to allow your local OpenSSH daemon to contact an authentication agent (ssh-agent or Pageant) on a remote machine. Authentication agents are discussed in more detail in step 4.5.

no-pty “ This command prevents tty allocation to occur when the key is used. This is useful when you want a key to be used only for non-interactive commands, such as backups.

no-pty,no-agent-forwarding,no-X11-forwarding,no-port-forwarding ssh-rsa AAAAB3NzaC1yc2Eaaaa253gAAIE AuG8ugce5+/Cno2FCcyraJN2LK5Gsl+ujV8ad8s1lobhldonA20x6i9eNln8+LP76k2jMuLFtWEmc8MwmvrnIL2ZH2SOC90 QpB3KwBuS6suVWTX5AKkXpB5uEKMWQJjHoEFOQx7Kpzmkav83n73naE8u/oyagSIgLVxCIvEhk9XX8= sshuser@example.com