sftp fails when run from cron

[James Moe]

sftp OpenSSH_7.6p1, OpenSSL 1.1.0h-fips 27 Mar 2018

linux 4.12.14-lp150.12.16-default x86_64

I created bash script to download database files once a week. It uses
sftp as the agent. The script runs correctly when started from a command
line. It fails when run from cron.
Authentication with the remote server is set to use a private/public
key and does not require an explicit password.
Why does the authentication fail when run from cron?

----[ command ]----
/usr/bin/sftp -vv -P 1022 -p -o GSSAPIAuthentication=no \
-i /home/xxx/.ssh/jumpline \
-b /home/xxx/bin/sftp-sma-download-batch \
***@sohnen-moe.com
----[ end ]----

---[ sucessful login ]---
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
** the logs were the same for the two instances up to this point **

debug2: key: /home/xxx/.ssh/liferoot (0x559aaf939430), explicit, agent
debug2: key: /home/xxx/.ssh/sma-stn14l (0x559aaf93dc70), explicit, agent
debug2: key: /home/xxx/.ssh/jumpline (0x559aaf93e150), explicit, agent
debug2: key: /home/xxx/.ssh/jumpline (0x559aaf939380), explicit
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA
SHA256:bkf3ucSsyW2bRzbyqlyJUzvxUXkpsp9bDuun31jgbYA /home/xxx/.ssh/liferoot
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: RSA
SHA256:jVooz7igeVgCpPG5laGISQ6XKSYN5aKgtbovdquUMB8 /home/xxx/.ssh/sma-stn14l
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: RSA
SHA256:B1iu57Rkn5emB//MUP4YEipr4oRRmqZeBHMQWf0U+Mk /home/xxx/.ssh/jumpline
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp
SHA256:B1iu57Rkn5emB//MUP4YEipr4oRRmqZeBHMQWf0U+Mk

debug1: Authentication succeeded (publickey).
Authenticated to sohnen-moe.com ([216.222.193.110]:1022).
** blah blah blah ***
---[ end ]---


---[ failed login ]---
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
** the logs were the same for the two instances up to this point **

debug2: key: /home/xxx/.ssh/jumpline (0x55b73dc16da0), explicit
debug2: key: /home/xxx/.ssh/jumpline (0x55b73dc16a70), explicit
debug2: key: /home/xxx/.ssh/sma-stn14l (0x55b73dc13fc0), explicit
debug2: key: /home/xxx/.ssh/liferoot (0x55b73dc11fb0), explicit
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA
SHA256:B1iu57Rkn5emB//MUP4YEipr4oRRmqZeBHMQWf0U+Mk /home/xxx/.ssh/jumpline
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp
SHA256:B1iu57Rkn5emB//MUP4YEipr4oRRmqZeBHMQWf0U+Mk
debug1: Offering public key: RSA
SHA256:B1iu57Rkn5emB//MUP4YEipr4oRRmqZeBHMQWf0U+Mk /home/xxx/.ssh/jumpline
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp
SHA256:B1iu57Rkn5emB//MUP4YEipr4oRRmqZeBHMQWf0U+Mk
debug1: Offering public key: RSA
SHA256:jVooz7igeVgCpPG5laGISQ6XKSYN5aKgtbovdquUMB8 /home/xxx/.ssh/sma-stn14l
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: RSA
SHA256:bkf3ucSsyW2bRzbyqlyJUzvxUXkpsp9bDuun31jgbYA /home/xxx/.ssh/liferoot
debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
***@sohnen-moe.com: Permission denied (publickey).
Connection closed
** Splat! **
---[ end ]---

[Darren Tucker]

Post by James Moe
sftp OpenSSH_7.6p1, OpenSSL 1.1.0h-fips 27 Mar 2018

Note that OpenSSH 7.6p1 does not support OpenSSL 1.1 so this must be a
vendor modified version, which might or might not make a difference.

[...]

Post by James Moe
debug2: key: /home/xxx/.ssh/jumpline (0x559aaf93e150), explicit, agent

some of your keys are in an ssh-agent, including the "jumpline" one
that the server later accepts.

[...]

Post by James Moe
debug2: key: /home/xxx/.ssh/jumpline (0x55b73dc16da0), explicit

this time the key is not available in an agent.

I'd guess that the reason it doesn't work is that the key is encrypted
and neither the agent nor a tty to ask for the decryption passphrase
is available. Try repeating your command line test after unsetting
SSH_AUTH_SOCK (which will prevent ssh from knowing how to talk to the
agent).

[James Moe]

Post by Darren Tucker
I'd guess that the reason it doesn't work is that the key is encrypted
and neither the agent nor a tty to ask for the decryption passphrase
is available. Try repeating your command line test after unsetting
SSH_AUTH_SOCK

Okay. That reproduced the issue.
Is there a recommended way to provide the decryption passphrase?


$ export SSH_AUTH_SOCK=""
$ bin/sftp-sma-download
command: /usr/bin/sftp -P 1022 -p -o GSSAPIAuthentication=no -i
/home/xxx/.ssh/jumpline -b /home/xxx/bin/sftp-sma-download-batch
***@sohnen-moe.com
***@sohnen-moe.com: Permission denied (publickey).
Connection closed
SFTP did not go well [255]

$ export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"
$ bin/sftp-sma-download
command: /usr/bin/sftp -P 1022 -p -o GSSAPIAuthentication=no -i
/home/xxx/.ssh/jumpline -b /home/xxx/bin/sftp-sma-download-batch
***@sohnen-moe.com
sftp> #
sftp> cd /home/YYY/sma/db
etc...

[Darren Tucker]

Post by James Moe

Post by Darren Tucker
I'd guess that the reason it doesn't work is that the key is encrypted
and neither the agent nor a tty to ask for the decryption passphrase
is available. Try repeating your command line test after unsetting
SSH_AUTH_SOCK

Okay. That reproduced the issue.
Is there a recommended way to provide the decryption passphrase?

it's possible but tricky by writing a custom SSH_ASKPASS program, but
that doesn't buy you much over having the key unencrypted (ie both the
key and the passphrase needed to decrypt it have to readable by your
user).

Other than that, the options are:

- starting an ssh-agent specifically for you cron job, loading the key
and arranging for you cron job to have SSH_AUTH_SOCK pointing to that
agent's socket. The down side is you'll need human intervention after
a restart.

- use a key without a passphrase and set a key restriction on the
server (from=[ip address], see sshd(8)) to make sure it can only be
used from where it's intended (not perfect, but it's better than
nothing).

- set up HostBasedAuthentication instead (you'll also need to enable
EnableSSHKeysign in ssh_config on the client).

[James Moe]

Post by Darren Tucker

Post by James Moe
Is there a recommended way to provide the decryption passphrase?

it's possible but tricky by writing a custom SSH_ASKPASS program, but
that doesn't buy you much over having the key unencrypted (ie both the
key and the passphrase needed to decrypt it have to readable by your
user).

I decided it is no burden to manually run the script.

[Nico Kadel-Garcia]

Post by James Moe

Post by Darren Tucker

Post by James Moe
Is there a recommended way to provide the decryption passphrase?

it's possible but tricky by writing a custom SSH_ASKPASS program, but
that doesn't buy you much over having the key unencrypted (ie both the
key and the passphrase needed to decrypt it have to readable by your
user).

I decided it is no burden to manually run the script.

There is an old, and stable, tool called "keypass". It's a perl script
used to activate an ssh-agent and load a copy of its generated
environment variables into a file that can be "sourced", typicall
$HOME/.keypass/$HOSTNAME.sh I've found it quite useful to pre-load an
ssh-agent for later use by a particular application, especially if I
wanted to have to reload the ssh-agent for cron or other automated
operation.