Here’s a quick lowdown on how the OpenSSH CLI tools (scp and sftp) work so that you can better appreciate the issue. When you want to copy over files to or from the remote host, you can use scp which automatically initiates a SSH connection to the remote host. Every time you run a scp command it establishes a new connection to the remote. So if you have multiple scp commands you’d be entering the same password several times. This is why you wouldn’t want to use scp in any scripts you want to run unattended. There’s also the fact that if you have multiple accounts on several machines on the network, you’d have trouble memorizing unique, strong passwords for each. To overcome this problem, you need to switch OpenSSH’s default authentication mechanism to a key-based system.

Key to success

By default OpenSSH only uses keys to authenticate a server’s identity the first time a client encounters a new remote machine: When you respond by typing “yes”, the remote host is added to the list of known hosts. So in addition to the server authenticating the client by asking for a password, the client also authenticates the server using a key. Similarly, you too can get yourself a set of keys to prove your identity. OpenSSH uses a pair of keys to prove your identity and create a secure connection to a remote server. The private key is for-your-eyes-only and is used by your OpenSSH client to prove your identity to servers. Then there’s the public key which you’re supposed to keep under all your accounts on all the remote machines you want to SSH into. To create a key, on your client enter: Remember not to leave the passphrase empty and make note of the location where the keys are stored. The “id_rsa” file is readable only by your account, and its contents are encrypted with the passphrase you supplied during generation. The next step is to copy the public key to the remote server. Assuming you wish to login into user “admin” on the remote machine called “atlantis.remote.com”, you can move the keys with a single command: After you’ve provided the passphrase for your private key, the public key will be automatically placed in the correct location on the remote server, which by default is the “~/.ssh/authorized_keys” file. When you now ssh into the remote machine, you’ll be prompted for your passphrase. The only advantage of using keys is that instead of authenticating you with a password that’s transmitted unencrypted, the remote server and your client establish your identity based on the keys. Also you can now ssh into several remote boxes using the same passphrase, as long as these remote machines have your public key. So you don’t have to remember multiple passwords. But you still can’t run scripts without being interrupted for passphrases.

SSH-agent to the rescue

OpenSSH bundles a tool called ssh-agent, that keeps your private keys in memory. Once an agent is running, instead of prompting you for passphrases, the SSH clients will interact with the agent.
You can start the agent with “ssh-agent /bin/bash“, assuming you are using the bash shell. Any commands which require access to your OpenSSH private keys will be intercepted and answered by the agent. When the agent runs, you need to equip it with your keys. This is done by invoking the “ssh-add” program that by default loads the keys from the default identity file (~/.ssh/id_rsa). Now when you log into the remote computer with “ssh admin@atlantis.remote.com“, you’ll be allowed without entering the passphrase! Similarly, scp and sftp will also be able to connect to the remote hosts without ever asking you for a passphrase. So you can now schedule and run scripts that manipulate files on a remote machine automatically. Also now that you are using keys, it’s a good idea to disable authentication via passwords. To do this, edit the remote server’s config file (/etc/ssh/.sshd_config) and change the “PasswordAuthentication” parameter from “yes” to “no”. From now on, if anyone tries to connect to your SSH service who doesn’t have a public key on the server, they will be denied access without even seeing the login prompt. Image credit: Karunakar Rayker