I’m trying to backup into a Mac. In the Mac’s sharing control panel, I’ve enabled remote login, which enables SSH and SFTP.
In the client I’m trying to back up, on the destination screen, I set:
The storage type as SFTP (SSH)
The server address (192.168.1.8) and port (22)
The path (/Volumes/Drobo/)
The login and PW
From terminal, I can SSH into the destination machine using the same server, login, and PW. So I believe they are correct.
When I click the Test connection button, I get a pop up saying no certificate was specified and asking me to approve the host key. I click yes. That tells me it is at least reaching out to the other machine.
I then get a pop up saying “Failed to connect: No suitable authentication method found to complete authentication (publickey,keyboard-interactive).”
Duplicati expects to use a password but the Mac only provides the option for public key or interactive.
Interactive is a separate authentication method that Duplicati doesn’t understand.
You can change to using a public private keyset or you can change the SSH config to allow password, although unfortunately I can’t remember how. I can find some info on it in a couple of hours when I’m at my machine.
hmm, I was trying to replicate, but when I enable remote login on my Mac Duplicati connects without any problems.
What MacOS version are you running? Maybe they changed something?
My SSH server returns Permission denied (publickey,password,keyboard-interactive) if I force it to show me the authentication methods allowed, so for some reason mine starts with password as well as the two other methods.
On the mac I’m connecting from, I’m using the latest-- 10.12.x
On the mac I’m connecting to (running the SSH server), I using 10.11.6
Looking at the console log on the ssh server, i see:
2/20/18 10:12:59.759 PM sshd: unknown [pam][3378]: in od_record_create(): failed: 13
2/20/18 10:12:59.759 PM sshd: unknown [pam][3378]: in od_record_create_cstring(): failed: 13
2/20/18 10:13:05.478 PM sshd: unknown [pam][3378]: in od_record_create(): failed: 13
2/20/18 10:13:05.478 PM sshd: unknown [pam][3378]: in od_record_create_cstring(): failed: 13
2/20/18 10:13:05.478 PM sshd: unknown [pam][3378]: in pam_sm_authenticate(): OpenDirectory - Unable to get user record.
2/20/18 10:13:05.479 PM sshd[3376]: error: PAM: unknown user for illegal user XXXX from 192.168.1.24 via 192.168.1.8
2/20/18 10:13:05.510 PM sshd: unknown [pam][3379]: in od_record_create(): failed: 13
2/20/18 10:13:05.510 PM sshd: unknown [pam][3379]: in od_record_create_cstring(): failed: 13
2/20/18 10:13:06.470 PM sshd: unknown [pam][3379]: in od_record_create(): failed: 13
2/20/18 10:13:06.470 PM sshd: unknown [pam][3379]: in od_record_create_cstring(): failed: 13
2/20/18 10:13:06.470 PM sshd: unknown [pam][3379]: in pam_sm_authenticate(): OpenDirectory - Unable to get user record.
2/20/18 10:13:06.471 PM sshd[3376]: error: PAM: unknown user for illegal user XXXX from 192.168.1.24 via 192.168.1.8
2/20/18 10:13:06.487 PM sshd: unknown [pam][3380]: in od_record_create(): failed: 13
2/20/18 10:13:06.488 PM sshd: unknown [pam][3380]: in od_record_create_cstring(): failed: 13
Where “user XXXX” is the user name that I am using on the machine I’m connecting from. It is not the user name that I entered into the Duplicati web screen. Why is that?
In your experiment, are you running as the same user on both machines? Try running as a different user…
It doesn’t know. It only knows what name you’re trying to log in with, but most SSH clients will just use your current username if you just call ssh 192.168.1.2 without specifying the user as user@192.168.1.2
But Duplicati will specify that name since you provide the destination name when you set up the backup, so it won’t matter which user Duplicati is running as
No need to be sorry, it’s new to everyone at some point
Ahh… You’re right. I bet it happened when I was using terminal to check that I could SSH into that machine. First time, i forgot the -l switch. Ok. Mystery solved.
So, back to the original problem… The destination mac is running OS X 10.11.x. Maybe that doesn’t allow for what I’m attempting to do? You don’t by chance have access to one do you?
Any other logs i can dump to help debug this?
Worst case, i’m going to try the public/private key tonite. Other than adding the public key to Duplicate, anything else I need to do? Do I need to enter the username and password? Any documentation showing this?
I only have this one on 10.13.3, but I think it’s just a different default value. The OpenSSH server definitely should support it, Apple got it straight from BSD
If you try updating /private/etc/ssh/sshd_config to have PasswordAuthentication yes then it should work.
After you setup ssh-keys on source and destination you just need to add the ssh-keyfile under advanced options. If it’s a password protected key the key password just goes into the regular password field
Yup, remove the hashtag and change it to “yes”, then restarting the sshd service should let it kick in.
By the way, you can always check what methods are allowed with -o PreferredAuthentications=none. It’s not pretty, but it will give you an error telling you the methods
Opening up a Mac for SSH does weaken the security of your system (password security) especially if you also make it available when away from your local network. Opening up ssh for sftp) is more vulnerable than the alternative, I think: you can run an S3-compatible Minio (also open source) setup on the Mac you want to backup to. Don’t know which one is faster, though.
Yes, good point. Opening up SSH will always be less secure on any system.
If it’s public outside your network I’d also strongly recommend public/private keysets and personally I never expose regular password authentication SSH over the internet.
Uh, this look very cool! I might wanna play around with it for my home setup
I’ve got a working setup (4 Minio servers behind an nginx on macOS) and the LaunchDaemon settings have been posted here. Note that — just as Duplicati — Minio is beta. Both nginx and minio can be installed easily through homebrew.
I played a bit with 4 servers in docker (split over 2 physical disks) yesterday. It seems very stable when intentionally damaging storage on one or two of the servers. it even works when I connect directly to the instance with missing data and download the data.
The only thing that I’m a little concerned about is the fact that I couldn’t find any way to heal broken data other than to call the minio client command against the server manually. And it’s output is not very script friendly, so I’d have to go through a bunch of trouble to script automatically checking and healing of the cluster and reporting problems
Well, I haven’t had much of a need to get stuff back (apart from a little testing I did that worked well). The setup runs fine for the rest. A 200GB low-volatility set incoming over fast internet takes about 20-30 minutes for a daily update for one client and about 12 minutes for another. My Minio setup resides on a Mirror RAID system and is serviced by a single server. It does not use TLS. The TLS is done by the nginx in front of it which then connects over the loopback device to minio. I don’t need anything more complicated.
The only issue I am having is that re clients may go to sleep during a running backup. It would be nice if there was a way to stop that from happening.
