Bug#776528: BackendException: ssh connection to user@hostname:22 failed: No authentication methods available
On Sun, 01 Feb 2015 20:47:04 +1300, Francois Marier writes: Here's the exact command line I have problems with, with only the GPG passphrase removed: $ PASSPHRASE= duplicity cleanup --ssh-options=-oIdentityFile=/home/francois/backup/identity -oUserKnownHostsFile=/home/francois/backup/known_hosts --verbosity 1 --force sftp://user@hostname/duplicity BackendException: ssh connection to user@hostname:22 failed: No authentication methods available hmm. i still can't reproduce it, neither with stable's duplicity (and paramiko), nor with sid's :-(( i created a testuser of your name, same directory structure (as far as keys are concerned), new unpassphrased rsa key, but no luck. the only difference that i see in -v9 is that my target ssh server is older, 6.0 from stable versus your 6.6.1. here's my paramiko log, pretty much the same as yours: ssh: starting thread (client mode): 0xc522550L ssh: Connected (version 2.0, client OpenSSH_6.0p1) ssh: kex algos:[u'ecdh-sha2-nistp256', u'ecdh-sha2-nistp384', u'ecdh-sha2-nistp521', u'diffie-hellman-group-exchange-sha256', u'diffie-hellman-group-exchange-sha1', u'diffie-hellman-group14-sha1', u'diffie-hellman-group1-sha1'] server key:[u'ssh-rsa', u'ssh-dss'] client encrypt:[u'aes128-ctr', u'aes192-ctr', u'aes256-ctr', u'arcfour256', u'arcfour128', u'aes128-cbc', u'3des-cbc', u'blowfish-cbc', u'cast128-cbc', u'aes192-cbc', u'aes256-cbc', u'arcfour', u'rijndael-...@lysator.liu.se'] server encrypt:[u'aes128-ctr', u'aes192-ctr', u'aes256-ctr', u'arcfour256', u'arcfour128', u'aes128-cbc', u'3des-cbc', u'blowfish-cbc', u'cast128-cbc', u'aes192-cbc', u'aes256-cbc', u'arcfour', u'rijndael-...@lysator.liu.se'] client mac:[u'hmac-md5', u'hmac-sha1', u'umac...@openssh.com', u'hmac-sha2-256', u'hmac-sha2-256-96', u'hmac-sha2-512', u'hmac-sha2-512-96', u'hmac-ripemd160', u'hmac-ripemd...@openssh.com', u'hmac-sha1-96', u'hmac-md5-96'] server mac:[u'hmac-md5', u'hmac-sha1', u'umac...@openssh.com', u'hmac-sha2-256', u'hmac-sha2-256-96', u'hmac-sha2-512', u'hmac-sha2-512-96', u'hmac-ripemd160', u'hmac-ripemd...@openssh.com', u'hmac-sha1-96', u'hmac-md5-96'] client compress:[u'none', u'z...@openssh.com'] server compress:[u'none', u'z...@openssh.com'] client lang:[u''] server lang:[u''] kex follows?False ssh: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr ssh: using kex diffie-hellman-group14-sha1; server key type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none ssh: Switch to new keys ... ssh: Trying key 79efd8a14d23dff17696585ccb2009c9 from /home/francois/backup/identity ssh: userauth is OK at this point my suspicion is that there's something wrong in paramiko, but i can't explain why it works for you if and only if you specify the (totally ignored!) knownhosts ssh option as a separate item. regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ REAL*8 RESPONSE(8) DATA /RESPONSE/ 8HYOU EVER,8H DONE IT,8H IN FORT,8HRAN IV?$ -- Peter da Silva about the joys of string handling signature.asc Description: Digital Signature
Bug#776528: BackendException: ssh connection to user@hostname:22 failed: No authentication methods available
On Sat, 31 Jan 2015 17:48:50 +1300, Francois Marier writes: On 2015-01-29 at 23:56:35, Francois Marier wrote: If I change the above to: duplicity cleanup --ssh-options=-oIdentityFile=id_rsa --force scp://user@ho stname/backup then it works fine. weird. both of the above work fine for me here, but i'm on the stable version of paramiko which is much older. (similar setup to yours, password-less rsa key, extra known_hosts file) So it seems like 0.7 stopped supporting multiple options inside the --ssh-options option, which the manpage claims is supported: i really don't think that's it, as the commandline parsing code hasn't changed in any relevant fashion between 0.6.24 and 0.7. i just diffed it and it's almost exclusively whitespace-only changes. three things to consider: first, paramiko (the default ssh backend) doesn't use anything from --ssh-options except -i idfile or -oIdentityFile=idfile. so handing it a userknownhost directive doesn't do anything. is the --ssh-options line you submitted *exactly* what fails? if not, please send me that. i suspect that the parsing of the identityfile bit might stumble over your actual data, as the given --ssh-options line works fine here. does it work with two separate --ssh-options (knowing that the knownhostsfile bit has no effect)? does the order of the --ssh-options make any difference? second, could you please rerun your failing command with -v9 and send me the parts of the output that are tagged ssh:? third, does changing the access protocol to sftp:// change anything? (i don't suspect so, but it might be worth a try...) regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ Give a fool a tool and he has a weapon. signature.asc Description: Digital Signature
Bug#776528: BackendException: ssh connection to user@hostname:22 failed: No authentication methods available
On 2015-01-31 at 17:58:53, Alexander Zangerl wrote: is the --ssh-options line you submitted *exactly* what fails? if not, please send me that. i suspect that the parsing of the identityfile bit might stumble over your actual data, as the given --ssh-options line works fine here. Here's the exact command line I have problems with, with only the GPG passphrase removed: $ PASSPHRASE= duplicity cleanup --ssh-options=-oIdentityFile=/home/francois/backup/identity -oUserKnownHostsFile=/home/francois/backup/known_hosts --verbosity 1 --force sftp://user@hostname/duplicity BackendException: ssh connection to user@hostname:22 failed: No authentication methods available does it work with two separate --ssh-options (knowing that the knownhostsfile bit has no effect)? does the order of the --ssh-options make any difference? Yes, it does work if I split the ssh-options into two: $ PASSPHRASE= duplicity cleanup --ssh-options=-oIdentityFile=/home/francois/backup/identity --ssh-options=-oUserKnownHostsFile=/home/francois/backup/known_hosts --verbosity 1 --force sftp://user@hostname/duplicity second, could you please rerun your failing command with -v9 and send me the parts of the output that are tagged ssh:? Here's the broken one with --verbosity 9 (the ssh lines only): ssh: starting thread (client mode): 0xe1b396d0L ssh: Connected (version 2.0, client OpenSSH_6.6.1p1) ssh: kex algos:[u'curve25519-sha...@libssh.org', u'ecdh-sha2-nistp256', u'ecdh-sha2-nistp384', u'ecdh-sha2-nistp521', u'diffie-hellman-group-exchange-sha256', u'diffie-hellman-group-exchange-sha1', u'diffie-hellman-group14-sha1', u'diffie-hellman-group1-sha1'] server key:[u'ssh-rsa', u'ssh-dss'] client encrypt:[u'aes128-ctr', u'aes192-ctr', u'aes256-ctr', u'arcfour256', u'arcfour128', u'aes128-...@openssh.com', u'aes256-...@openssh.com', u'chacha20-poly1...@openssh.com', u'aes128-cbc', u'3des-cbc', u'blowfish-cbc', u'cast128-cbc', u'aes192-cbc', u'aes256-cbc', u'arcfour', u'rijndael-...@lysator.liu.se'] server encrypt:[u'aes128-ctr', u'aes192-ctr', u'aes256-ctr', u'arcfour256', u'arcfour128', u'aes128-...@openssh.com', u'aes256-...@openssh.com', u'chacha20-poly1...@openssh.com', u'aes128-cbc', u'3des-cbc', u'blowfish-cbc', u'cast128-cbc', u'aes192-cbc', u'aes256-cbc', u'arcfour', u'rijndael-...@lysator.liu.se'] client mac:[u'hmac-md5-...@openssh.com', u'hmac-sha1-...@openssh.com', u'umac-64-...@openssh.com', u'umac-128-...@openssh.com', u'hmac-sha2-256-...@openssh.com', u'hmac-sha2-512-...@openssh.com', u'hmac-ripemd160-...@openssh.com', u'hmac-sha1-96-...@openssh.com', u'hmac-md5-96-...@openssh.com', u'hmac-md5', u'hmac-sha1', u'umac...@openssh.com', u'umac-...@openssh.com', u'hmac-sha2-256', u'hmac-sha2-512', u'hmac-ripemd160', u'hmac-ripemd...@openssh.com', u'hmac-sha1-96', u'hmac-md5-96'] server mac:[u'hmac-md5-...@openssh.com', u'hmac-sha1-...@openssh.com', u'umac-64-...@openssh.com', u'umac-128-...@openssh.com', u'hmac-sha2-256-...@openssh.com', u'hmac-sha2-512-...@openssh.com', u'hmac-ripemd160-...@openssh.com', u'hmac-sha1-96-...@openssh.com', u'hmac-md5-96-...@openssh.com', u'hmac-md5', u'hmac-sha1', u'umac...@openssh.com', u'umac-...@openssh.com', u'hmac-sha2-256', u'hmac-sha2-512', u'hmac-ripemd160', u'hmac-ripemd...@openssh.com', u'hmac-sha1-96', u'hmac-md5-96'] client compress:[u'none', u'z...@openssh.com'] server compress:[u'none', u'z...@openssh.com'] client lang:[u''] server lang:[u''] kex follows?False ssh: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr ssh: using kex diffie-hellman-group14-sha1; server key type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none ssh: Switch to new keys ... Using temporary directory /tmp/duplicity-2EqPPt-tempdir Backend error detail: Traceback (most recent call last): File /usr/bin/duplicity, line 1507, in module with_tempdir(main) File /usr/bin/duplicity, line 1501, in with_tempdir fn() File /usr/bin/duplicity, line 1334, in main action = commandline.ProcessCommandLine(sys.argv[1:]) File /usr/lib/python2.7/dist-packages/duplicity/commandline.py, line 1047, in ProcessCommandLine globals.backend = backend.get_backend(args[0]) File /usr/lib/python2.7/dist-packages/duplicity/backend.py, line 221, in get_backend obj = get_backend_object(url_string) File /usr/lib/python2.7/dist-packages/duplicity/backend.py, line 207, in get_backend_object return factory(pu) File /usr/lib/python2.7/dist-packages/duplicity/backends/ssh_paramiko_backend.py, line 217, in __init__ self.config['port'], e)) BackendException: ssh connection to user@hostname:22 failed: No authentication methods available BackendException: ssh connection to user@hostname:22 failed: No authentication methods available ssh: EOF in transport thread third, does changing the access protocol to sftp:// change anything? (i don't suspect so, but it might be worth a
Bug#776528: BackendException: ssh connection to user@hostname:22 failed: No authentication methods available
On 2015-01-29 at 23:56:35, Francois Marier wrote: duplicity cleanup --ssh-options=-oIdentityFile=id_rsa -oUserKnownHostsFile=known_hosts --force scp://user@hostname/backup If I change the above to: duplicity cleanup --ssh-options=-oIdentityFile=id_rsa --force scp://user@hostname/backup then it works fine. So it seems like 0.7 stopped supporting multiple options inside the --ssh-options option, which the manpage claims is supported: --ssh-options options Allows you to pass options to the ssh backend. Can be specified multiple times or as a space separated options list. The options list should be of the form -oOpt1='parm1' -oOpt2='parm2' where the option string is quoted and the only spaces allowed are between options. The option string will be passed verbatim to both scp and sftp, whose command line syntax differs slightly hence the options should therefore be given in the long option format described in ssh_config(5). example of a list: duplicity --ssh-options=-oProtocol=2 -oIdentityFile='/my/backup/id' /home/me scp://user@host/some_dir Francois -- Francois Marier identi.ca/fmarier http://fmarier.org twitter.com/fmarier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776528: BackendException: ssh connection to user@hostname:22 failed: No authentication methods available
On 2015-01-29 at 20:23:21, Alexander Zangerl wrote: On Tue, 27 Jan 2015 15:10:34 +1300, Francois Marier writes: After upgrading from duplicity 0.6.24-2 to 0.7.01-1, my backups to an ssh host stopped working. i can't reproduce that; i've just used 0.7.01 sftp and scp backups without major problems, using sftp://me@somehost/location as well as scp://me@somehost/location. This is what fails for me: duplicity cleanup --ssh-options=-oIdentityFile=id_rsa -oUserKnownHostsFile=known_hosts --force scp://user@hostname/backup Now, if I try to run any of the duplicity commands, I get the following: BackendException: ssh connection to user@hostname:22 failed: No authenticatio n methods available looks like you need to set up ssh-agent and key auth, or use --ssh-askpass or provide the password to duplicity via FTP_PASSWORD. i've tested all three options and they work fine. I'm using a password-less key (as per the above command-line) so it's not a password or ssh-agent problem. it looks as if the strictness of the auth handling changed somewhere between 0.6.24 and 0.7.01, but the changelog doesn't show anything pertinent. There's also the possibility that it doesn't have anything to do with authentication. paramiko has a tendency to return misleading or unhelpful messages, unfortunately. Francois -- Francois Marier identi.ca/fmarier http://fmarier.org twitter.com/fmarier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776528: BackendException: ssh connection to user@hostname:22 failed: No authentication methods available
tags 776528 + unreproducible moreinfo severity 776528 normal thanks On Tue, 27 Jan 2015 15:10:34 +1300, Francois Marier writes: After upgrading from duplicity 0.6.24-2 to 0.7.01-1, my backups to an ssh host stopped working. i can't reproduce that; i've just used 0.7.01 sftp and scp backups without major problems, using sftp://me@somehost/location as well as scp://me@somehost/location. Now, if I try to run any of the duplicity commands, I get the following: BackendException: ssh connection to user@hostname:22 failed: No authenticatio n methods available looks like you need to set up ssh-agent and key auth, or use --ssh-askpass or provide the password to duplicity via FTP_PASSWORD. i've tested all three options and they work fine. it looks as if the strictness of the auth handling changed somewhere between 0.6.24 and 0.7.01, but the changelog doesn't show anything pertinent. i believe the old version fell back to interactive asking without insisting on --ssh-askpass if no suitable ssh-agent was a/v. regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don't even do that much. -- Matt Blaze signature.asc Description: Digital Signature
Bug#776528: BackendException: ssh connection to user@hostname:22 failed: No authentication methods available
Package: duplicity Version: 0.7.01-1 Severity: grave Justification: renders package unusable After upgrading from duplicity 0.6.24-2 to 0.7.01-1, my backups to an ssh host stopped working. Now, if I try to run any of the duplicity commands, I get the following: BackendException: ssh connection to user@hostname:22 failed: No authentication methods available My ssh config didn't change in the meantime and I have verified that I can still ssh manually to that box. Downgrading to 0.6.24-2 solves the problem. Francois -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages duplicity depends on: ii libc62.19-13 ii librsync10.9.7-10 ii python 2.7.8-2 ii python-lockfile 1:0.8-2 Versions of packages duplicity recommends: ii python-oauthlib 0.6.3-1 ii python-paramiko 1.15.1-1 ii python-urllib3 1.9.1-3 ii rsync3.1.1-2+b1 Versions of packages duplicity suggests: pn lftpnone ii ncftp 2:3.2.5-1.1 ii python-boto 2.34.0-2 pn python-cloudfiles none pn python-gdatanone pn python-swiftclient none pn tahoe-lafs none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
