New SFTP backend uses outdated paramiko, breaks connection to server even with --use-scp

I am getting the same message despite as far as I can tell the remote server does not use ECDSA authentication, at least the keys in known_hosts are both ssh-rsa after I sftp there by hand.

I think that I found the probable cause: the "real" ssh uses the .ssh dicrectory that is located under the "home" which is determined from getpwuid(get[e?]uid()). On the other hand, paramico apparently consults the $HOME/.ssh/known_hosts. And if you changed $HOME (which I did in the cronjob script) paramico does not find the known_hosts file.

By the way
duplicity:
  Installed: 0.6.18-0ubuntu3
python-paramiko:
  Installed: 1.7.7.1-2

Anyway copying the .ssh folder fron ~root/ to the directory that is set as $HOME for duplicity fixed the problem.

Created this upstream (and sorry for being so chatty):
https://github.com/paramiko/paramiko/issues/66

I am seeing the same behavior on a Ubuntu 12.04 client (duplicity 0.6.18-0ubuntu3 & python-paramiko 1.7.7.1-2) when attempting to connect to Ubuntu 12.04 server (openssh-server 1:5.9p1-5ubuntu1):
BackendException: ssh connection to 141.215.10.33:22 failed: Unknown server 141.215.10.33

But it works fine when connecting to a Debian 6 server (openssh-server 1:5.5p1-6+squeeze1)

Status changed to 'Confirmed' because the bug affects multiple users.

@Tom: One cause of the "Unknown server" error is the SSH host key not being in known_hosts.

If you ssh to the same destination host, from the same user account that duplicity uses, does it prompt you to accept the host key?

If you do so, does that resolve the error from Duplicity?

@gcc Yes my backup servers are in my known_hosts with the same user.

This definitely seems to be version related:
- duplicity 0.6.18-0ubuntu3 12.04 client can successfully backup to Debian 6 server
- duplicity 0.6.18-0ubuntu3 12.04 client fails on backup to Ubuntu 12.04 server
- downgrade to duplicity 0.6.15-0ubuntu2 from 11.10 on 12.04 client can now successfully backup to 12.04 server

And ssh keys work fine:
ssh <USER>@<DEBIAN 6 SERVER> ls -d /home/duplicity/kanpai_backup
/home/duplicity/kanpai_backup

ssh <USER>@<UBUNTU 12.04 SERVER> ls -d /home/duplicity/kanpai_backup
/home/duplicity/kanpai_backup

This bug does not affect me on Arch Linux with duplicity 0.6.19, but is an issue with Ubuntu 12.04 and 0.6.18

Building .0.6.19 from source fixes this issue on Ubuntu

Happy to know a fix has been released. I found the following which also seems to fix the problem in the interrim:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655278

Installed 0.6.19 package from Quantal in Presice, and it fixed this problem for me (it can now connect to other Precise servers via ssh).

Michael, does this will be released in a future Precise's upgrade?

I just upgraded my system and it still uses 0.6.18 version.

Thanks in advance.

I'm not going to update duplicity to 0.6.19 in 12.04. I could apply a small patch, but it would have to be rather targetted, and I'm not sure how easy the backport is.

Ken or Ed, do you know how easy it is to backport the .ssh/known_hosts fix?

In the meantime, you can workaround it like in comment #2.

Would it be possible to have 0.6.19 in backports? I have been successfully running 0.6.19-0ubuntu1 from quantal on 12.04 for some time now.

I'm having a similar problem, but I don't even have a .ssh folder in my root directory. My .ssh folder is already in my client home directory. I can log in to the target server via ssh without a password from the same user account on the client. I tried --use-scp without success.

My client is Ubuntu 12.04, and the server is a FreeNAS 9.1.0 box.

I tried --ssh-askpass, entered the password for the account on the server, and got the following error:

BackendException: ssh connection to 192.168.1.238:22 failed: Unknown server 192.168.1.238

Still happens in Ubuntu 12.04 amd64 :

- duplicity 0.6.18-0ubuntu3.5
- python-paramiko 1.7.7.1-2ubuntu1

Workaround is to use rsync:// backend instead, which is (if available) better than ssh/scp anyway.

"rsync:// should be able to resume transfer in the middle of the file, so if you are backing up large files over semi-reliable network, I would prefer that."
- Aleksandar Ivanisevic (http://serverfault.com/a/92621)