8

I would like to use rsync within a python script. I'm calling it using the subprocess module, and authenticating using public keys stored at the authorized_key file on the remote machine.

The only problem is that when I use rsync using a wrong remote user name, I get prompted for password, which obviously halts the backup script forever.

Can I force rsync to exit with error if it can't authenticate, rather than prompting for password?

Udi

Adam Matan
  • 13,194
  • 19
  • 55
  • 75

5 Answers5

10

Assuming you use rsync with an SSH remote shell (and not - for example - with an rsync server), then you can get rsync to run SSH in a way that will never ask for a password. For example, once can use this call:

rsync -e 'ssh -o "NumberOfPasswordPrompts 0"' source user@target:/path

This will force rsync to use SSH with 0 possible password tries - if its can't gain access using some other authentication method (like public key or GSSAPI) then it will fail with an error. Do note that rsync will not like you when that happens and will complain loudly to STDERR and break with exit code 255.

Guss
  • 2,670
  • 5
  • 34
  • 59
5

Here are the command line options for ssh that I use to keep it quiet.

ssh -o stricthostkeychecking=no -o userknownhostsfile=/dev/null -o batchmode=yes -o passwordauthentication=no

You only need the hostkey stuff if you do not maintain your known_hosts file and are worried about getting MitM warnings. Rather than specifying the authentication types as suggested by James F, I had to explicitly restrict password authentication. I use this to hit hundreds of hosts with a few different OS versions, though, so it may just be an incompatibility.

Chad Huneycutt
  • 2,116
  • 1
  • 16
  • 14
  • 1
    Please do NOT use these settings. See section 11.5 of Oreilly's "SSH, The Secure Shell: The Definitive Guide, Second Edition". According to the book: "Unfortunately, effectively skipping server authentication disables a vital part of SSH security: resistance to server host spoofing and man-in-the-middle attacks! This situation also makes it impractical to replace server keys periodically, as should be done, or to revoke a key in case it is known to be compromised (i.e., tell clients to no longer trust it)." – Mick Feb 18 '13 at 16:19
  • 2
    @Mick: the trouble with criticisms like these is that they're entirely inappropriate in some contexts. For example, I work in an environment where the target of rsync operations is generally a host of embedded systems in a private network buried deep inside a lab. There is no connectivity to the outside world at all, and the build system needs to be able to push updated code down onto the targets. This is an entirely legitimate use of ssh and rsync, and the obvious solution is to turn off host checking. To make an absolute rule about it makes no sense at all. – Stabledog Oct 10 '13 at 18:51
  • @Stabledog - My advice is the correct advice for the vast majority of use cases. However, I concede that when you don't believe a bad actor can reasonably obtain access to your network to perform a MiTM attack, you can choose a weak security configuration. The security configuration required for a lab environment (as you mentioned) will obviously differ from a production environment because the risk is naturally reduced. – Mick Oct 10 '13 at 21:21
  • 1
    Fair enough. Here's the philosophical concern, as well as the practical, though: ssh is valued for much more than its ability to be *secure*, and in fact... in most of the settings I've seen it used, security is the least important concern. It's just the swiss-army-knife of choice for remote connections of all types. So there's this disconnect between the "security purists" scoldings, and the way that real people use it all the time in daily, practical ways. I don't believe that we're all just casual fools and the purists are "right". Its a question of knowing when to care. – Stabledog Oct 11 '13 at 03:21
1

re: James's suggestion (not giving it tty), for subprocess, try putting stdin=None as a parameter to Popen.

Adam Brand
  • 6,127
  • 2
  • 30
  • 40
0

Depending on how you are launching rsync, not giving it a TTY or PTY might help.

Many programs check if they have a controlling TTY before deciding to prompt the user for input. The default behaviour of system() and similar calls is to provide a tty to sub-programs, but you can disable this.

It also may be possible to disable password authentication entirely at the remote side if you are in control of both systems and want to get away from password authentication for the security benefits while solving this issue.

If you're doing rsync over SSH, you can add the following to your ssh_config file for the host in question, or via the -o command line switch:

PreferredAuthentications publickey

On a quick test (of just ssh, not rsync) that caused SSH to exit immediately when my public key wasn't accepted without prompting me for a password.

James F
  • 6,689
  • 1
  • 26
  • 24
0

First get the rsync to work from the shell, the command should look like.

If that fails debug the ssh command by itself. When that all works then see what happens for the python script

This is not a bad tutorial

James
  • 2,232
  • 1
  • 13
  • 19