Comment 16 for bug 982316

I'm experiencing the same problem, as storage I'm using a SSH server, and my configuration is set up in ~/.ssh/config, so I've only set the "Server" and "Folder" fields in the "Backup" app.

Tracing this back to the code (looking at the deja-dup_22.0-0ubuntu2 source) gives me common/BackendFile.vala:

[...]
    else {
      when = _("Backup will begin when a network connection becomes available.");
      return yield Network.get().can_reach (file.get_uri ());
    }
[...]

Looking deeper into it, in common/Network.vala there's "public async bool can_reach(string url)" that will use the GIO GNetworkMonitor can_reach_async() method:

[...]
  public async bool can_reach(string url)
  {
    var mon = NetworkMonitor.get_default();
    try {
      var socket = NetworkAddress.parse_uri(url, 0);
      return yield mon.can_reach_async(socket);
[...]

The function is documented here: http://developer.gnome.org/gio/2.32/GNetworkMonitor.html#g-network-monitor-can-reach-async

The socket is determined by parse_uri: http://valadoc.org/#!api=gio-2.0/GLib.NetworkAddress.parse_uri

I'm not sure if there's an easy solution to this problem, especially since it's not enough to just parse the SSH config and check for the "right" hostname, as one could use ProxyCommand to do further indirections (I coincidentally do this, because I have to connect to different IPs depending on whether or not I'm inside or outside the private network where the backup machine is located).

Host mybackupserver
    ProxyCommand some-script-to-open-a-ssh-connection

See the ssh_config(5) manpage for more information.

I guess the easiest way to fix this would be to special-case SSH URIs and just use the "ssh" command to try to make a connection, and use that for the can_reach method - this will also take care of ProxyCommand and friends, and should be more to the point.