Step 4.7 Using Public Key Authentication for Automated File Transfers

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 to connect to as user sshuser2 .

Action 4 7 2 Generate a key pair

  • First, a key pair needs to be generated for sshuser on . 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:

[]$ 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/
 The key fingerprint is:
  • 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 or file, depending on which type of key pair you created:

    []$ cd .ssh
     []$ 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
     -rw-r--r-- 1 sshuser sshuser 2880 Feb 21 08:50 known_hosts
     []$ cat
  • The public key of sshuser now needs to be copied over to 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:

    []$ scp's password: ******* 100% ***************************** 239 00:00
  • Once sshuser's public key is copied to , open an SSH session to 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 as root, and then become sshuser2 using the su command:

    []$ ssh's password: *******
     Last login: Mon Feb 24 11:19:15 2003 from
  • Once you log in as sshuser2 , change to the .ssh directory in sshuser2's home directory. You should see a file named authorized_keys .

    []$ cd .ssh
     []$ 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
  • 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).

    []$ ls ~/
     []$ cat ~/ >> authorized_keys
     []$ cat authorized_keys ssh-rsa
  • 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 as user sshuser to 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 as sshuser to as sshuser2. If everything is configured properly, you should not be prompted for a passphrase and should log in automatically.

[]$ ssh
 Last login: Mon Feb 24 12:25:16 2003 from

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 as sshuser2 from as sshuser , also with no passphrase:

[]$ scp 100% ***************************** 151 00:00

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=",*,!" ssh-rsa AAAAB3NzaC1yc2Eaaaa253gAAIEAuG8ugce5+/

    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/" ssh-rsa AAAAB3NzaC1yc2Eaaaa253gAAIEAuG8ugce5+/
  • 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+/
  • 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="",permitopen="" ssh-rsa AAAAB3NzaC1yc2Eaaaa253gAAIE
  • 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

OpenSSH. A Survival Guide for Secure Shell Handling, Version 1.0
OpenSSH: A Survival Guide for Secure Shell Handling (Version 1.0)
ISBN: 0972427384
EAN: 2147483647
Year: 2002
Pages: 90 © 2008-2020.
If you may any questions please contact us: