Package: duplicity
Version: 0.6.18-3
Severity: normal
Dear Maintainer,
Due to the usage of Paramiko as a default backend for scp/ssh backups,
it's not possible to use ECDSA keys to connect to the backuphost.
Synology and Ubuntu (since 12.04) are only 2 examples where such keys
are used by default these days. So when in your .ssh/known_hosts a
non-dsa or non-rsa key is, it fails to perform backups with a not very
helpfull error message.
As you can see, regular ssh just works fine and as expected
# ssh -v -p22 duplicity@adomainOpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11
Feb 2013
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to adomain [192.168.118.90] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.8p1-hpn13v11
debug1: match: OpenSSH_5.8p1-hpn13v11 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug1: Host 'adomain' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:4
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to adomain ([192.168.118.90]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_PAPER = en_GB.UTF-8
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_MEASUREMENT = en_GB.UTF-8
debug1: Sending env LC_CTYPE = en_US.UTF-8
debug1: Sending env LC_TIME = en_GB.UTF-8
BusyBox ( built-in shell (ash)
Enter 'help' for a list of built-in commands.
>
---------------------
Now with duplicity with a lot of verbosity I get this:
duplicity cleanup --force --no-print-statistics --ssh-options
'-o=IdentityFile=/root/.ssh/id_rsa' --extra-clean --archive-dir
/tmp/fooopen scp://duplicity@adomain//tmp/ -v9
Using archive dir: /tmp/fooopen/de254bb460815c673d7e6e55b3aac793
Using backup name: de254bb460815c673d7e6e55b3aac793
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.ftpsbackend Succeeded
Import of duplicity.backends.sshbackend Succeeded
Import of duplicity.backends.botobackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.cloudfilesbackend Succeeded
Import of duplicity.backends.ftpbackend Succeeded
Import of duplicity.backends.giobackend Failed: No module named gio
Import of duplicity.backends.u1backend Succeeded
ssh: starting thread (client mode): 0x2b81fd0L
ssh: Connected (version 2.0, client OpenSSH_5.8p1-hpn13v11)
ssh: kex algos:['ecdh-sha2-nistp256', 'ecdh-sha2-nistp384',
'ecdh-sha2-nistp521', 'diffie-hellman-group-exchange-sha256',
'diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1',
'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss',
'ecdsa-sha2-nistp256'] client encrypt:['aes128-ctr', 'aes192-ctr',
'aes256-ctr', 'arcfour256', 'arcfour128', 'aes128-cbc', '3des-cbc',
'blowfish-cbc', 'cast128-cbc', 'aes192-cbc', 'aes256-cbc', 'arcfour',
'rijndael-...@lysator.liu.se'] server encrypt:['aes128-ctr',
'aes192-ctr', 'aes256-ctr', 'arcfour256', 'arcfour128', 'aes128-cbc',
'3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'aes192-cbc', 'aes256-cbc',
'arcfour', 'rijndael-...@lysator.liu.se'] client mac:['hmac-md5',
'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160',
'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server
mac:['hmac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160',
'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client
compress:['none', 'z...@openssh.com'] server compress:['none',
'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False
ssh: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
ssh: using kex diffie-hellman-group1-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: Rejecting ssh-rsa host key for adomain:
xxxxxxxxxxxxxxxxxxxxxxxxxxxa5dc3
Using temporary directory /tmp/duplicity-OHoJKF-tempdir
Backend error detail: Traceback (most recent call last):
File "/usr/bin/duplicity", line 1404, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1397, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1248, in main
action = commandline.ProcessCommandLine(sys.argv[1:])
File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line
999, in ProcessCommandLine
globals.backend = backend.get_backend(args[0])
File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line
158, in get_backend
return _backends[pu.scheme](pu)
File
"/usr/lib/python2.7/dist-packages/duplicity/backends/sshbackend.py",
line 140, in __init__
raise BackendException("ssh connection to %s:%d failed: %s" %
(parsed_url.hostname,portnumber,e))
BackendException: ssh connection to adomain:22 failed: Unknown server
adomain
BackendException: ssh connection to adomain:22 failed: Unknown server
adomain
ssh: EOF in transport thread
-----------------------------
A work-around could be to specify ssh to only use RSA-keys for those
backup hosts and to get rid of all ECDSA keys. Getting rid of ECDSA
known hosts is necessary because otherwise SSH itself complains about
changed remote host identification (strangely enough it expects the same
fingerprint for a different scheme). I don't have a Debian stable at
hand to check if this is actually a regression, I'd think so, but would
need to be confirmed.
Ciao,
Kwadronaut
-- System Information:
Debian Release: 7.0
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages duplicity depends on:
ii libc6 2.13-38
ii librsync1 0.9.7-9
ii python 2.7.3-4
ii python-gnupginterface 0.3.2-9.1
Versions of packages duplicity recommends:
ii python-paramiko 1.7.7.1-3.1
ii rsync 3.0.9-4
Versions of packages duplicity suggests:
pn lftp <none>
pn ncftp <none>
pn python-boto <none>
pn python-cloudfiles <none>
pn python-gdata <none>
ii python-pexpect 2.4-1
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
