Walker News

How To Setup Non-Interactive SSH Login

When I am sitting in front of a computer, it doesn’t really matter if Putty or WinSCP prompts me to enter password for authentication.

But, how could I handle this interactive authentication process in Windows batch files or Linux shell scripts that scheduled to trigger file transfer between networked hosts on a daily basis?
Apparently, in order for the scheduled shell scripts or batch files to execute in this way, I need these two components:
  • a command line SSH utility such as pscp (for Windows batch file) or scp (for Linux shell scripts).
     
  • a pair of password-less cryptographic keys (i.e. private key that is without passphrase) for non-interactive authentication.
    Additional steps required for “password-less” ssh login if the private key is secured with a passphrase.

The generic concept: How to setup a password-less, non-interactive ssh login?

This is not a detailed guide for a specific ssh suite. Indeed, this is just a generic view of what you should do, in order to get a OpenSSH-compatible suite to work in a non-interactive authentication way. (As of 2005, OpenSSH is the single most popular SSH implementation).
Personally, I like Putty suite for Windows and OpenSSH for Red Hat Linux. The guides of configuring these tools to support non-interactive ssh login can be referred on these earlier posts:

SSH-2 protocol (secure shell version 2) supports at least two authentication methods, i.e. legacy system password authentication and public-key cryptography authentication. For password-less or non-interactive SSH login to work, public-key cryptography authentication is preferable:
  1. Execute ssh key generator to create a pair of keys. For example, the Linux OpenSSH key generator ssh-keygen -t dsa defaulted to create a pair of DSA-based keys called id_dsa (private key) and id_dsa.pub (public key).
     
  2. When the SSH key generator prompts you to enter a passphrase (to secure the private key), leave it empty (i.e. to disable the passphrase).
    The passphrase secures the private key. So, if someone steals the private key has to know the passphrase to unlock the secured private key. The server that trigger automated shell scripts or batch files keeps the private key, and hence should be secured as well. Otherwise, what’s the justification to only secure file transfer but leave the server box to be vulnerable for attack?
  3. Keep the private key in .ssh (a hidden directory) at client side and make sure the private key file access permission is restricted to 600, i.e. only grants read and write access to file owner.
     
  4. Transfer the public key to all target servers (which are expected to receive files) and append the public key file content to authorized_key file that resides in .ssh directory. Again, the authorized_key file access permission must be restricted to 600 mode.

Once all those generic steps are done, the client shell scripts / batch file is then capable to automate file transfer in password-less, non-interactive authentication mode.
Suggestion:

If you’re about to write a Linux shell scripts or Windows batch file to automate file transfer between networked hosts via ssh protocol, try to use scp (in Linux) or pscp (Putty suite for Windows) rather than sftp or psftp, for the benefit of coding simplicity, given the fact that secure copy (SCP / PSCP) command is highly non-interactive and straight-forward.

The scp syntax:
scp source_file user_id@hostname:[path/file]

Some scp examples:

Assume all these scp commands are executed at server WalkerNews-A using walker-a user login ID
scp -i $HOME/.ssh/id_dsa file1 walker-b@WalkerNews-B:newfile1

meant to
  • use the -i option switch to explicitly specify which private key to used for authentication, i.e. $HOME/.ssh/id_dsa. This option is useful when the ssh_config configured with a non-default IdentityFile option or there are multiple private keys kept inside the .ssh directory).
     
  • upload file1 to walker-b home directory at server WalkerNews-B as a new file named “newfile1″
scp file1 file2 log* walker-b@WalkerNews-B:/tmp

meant to upload multiple source files (i.e. file1, file2, log*) to server WalkerNews-B using the walker-b user login ID and save those source files into /tmp directory.
scp walker-b@WalkerNews-B:/tmp/f1 walker-b@WalkerNews-B:/tmp/f2 tmp

meant to download /tmp/f1 and /tmp/f2 from server WalkerNews-B using walker-b user ID to the local tmp directory at walker-a home directory.

Custom Search

  1. Configure Secured Private Key For Password-less SSH Login – Walker News 09-06-08@23:49

    [...] enable non-interactive SSH login, you could generate a pair of password-less cryptographic keys for the sake of simplicity, i.e. creates a private key that is not secured with a passphrase (by [...]

  2. Osher 17-06-11@17:19

    I encountered another issue that is not mentioned in this guide:

    Security requirements implementated in OpenSSH will not accept presented public keys if they can be stolen.
    Specifically – when the ~/ directory or the ~/.ssh/ directory of the requesting user is not secured – i.e. chmod to 700 or less.

    The observed behavior is that the key was not accepted even through everything was in place and all files were accessible (because permissions were even higher then 700…).

    Only by digging in verbose node on the server logs we could see a permissions issue warning, which after hardening permissions first on .ssh folder, and then on home – the silent-login finally worked and scripts started to run well.

  3. hector 28-06-12@03:26

    In my case (debian 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux)
    it is still not working..
    I put the logs in verbose and get this on the server

    sshd[13019]: Failed none for root from xx.xx.xx.xx port 37612 ssh2
    sshd[13019]: Failed publickey for root from xx.xx.xx.xx port 37612 ssh2

    i verified the public keys and they are OK just like the document says.permissions also ok.

2014  •  Privacy Policy