Having been warned by Lifeboat for several months about security issues because I kept authentication with password enabled, I finally decided to push that “Disable Password Authentication” button. So far so good, the warning has disappeared and Lifeboat can connect (like I can using the Terminal).
However, I’ve found that SFTP won’t work anymore (I’m using Transmit). The SFTP account is a different one than my main account. When I tried my SFTP account in Transmit, it asked me for a passphrase after it said the password was refused. I tried the saved passphrase in Lifeboat, but I presume the username is kept in the phrase, explaining why it doesn’t work; I thought the “Disable Password Authentication” would only target the admin account…
Now, I have two choices:
1: re-enable password authentication to make things as they were.
2: create a passphrase for the SFTP account and somehow make it recognised by the SFTP software.
Both these choices share the same issue: I don’t know exactly what Lifeboat has done (and I’m not an expert in Linux, that’s why I’m using Lifeboat in the first place).
Ask aditional help from Tim, but here is a starter…
Lifeboat Help
Secure Authentication
Disable SSH Password authentication for additional security. Lifeboat will create a SSH key pair, store the private key, and configure the server to authenticate with the new SSH key. When this is done, Lifeboat will disable password authentication and reconnect using the SSH key.
This tool can be used to automate the process of preventing password-based entry.
I’ve pinged him for you.
On a side note, you can mention users by using the @ symbol followed by their name, like @Arnaud_N . The mention will autocomplete the name as you type to make things easier. This will notify them to view the thread.
Well, as with most third-party vendors, you’re also likely to get a faster response if you contact them directly via whatever means they offer for support.
So I tried @Rick_Araujo 's posted article (which basically tells me what I already tried) and it doesn’t work either. Transmit asks me for a passphrase and the server responds with telling me my passphrase was incorrect and to enter a password which I have no idea about.
Are these certificates dependent on the user name, or rather server-wide?
Each user name will have their own certificate unless you configure the server with the same for all.
I think the only account that you can use (for now until you configure your server with a certificate for your SFTP account) is the Lifeboat account/credentials in Transmit.
Every account on the server will have its own ~/.ssh/authorized_keys file which lists the public keys that are allowed to authenticate with them. The file may not yet exist, which means the account will not accept a login from any key. Since you said you use a separate FTP user, you might need to copy the authorized_keys file from the user that you can log into, into the FTP user. Make sure ownership is changed.
Hi, sorry, I’ve been struggling with my health these last few weeks and had yet another episode. It’s been a real bother mucking up my plans for XDC Anywhere.
Lifeboat does not offer user management features so if you’ve created additional accounts, it’s kind of up to you to ensure all of them are configured. This feature used to require you to set up SSH Keys before simply disabling password authentication, but I was encouraged to make it simpler.
Lifeboat does not warn you about your authentication method, so I’m sorry you felt pressure from somewhere to click the button.
Thanks all for your helpful answers. I’ve now had some time to try them. For now, it still doesn’t work (can’t log in with Transmit).
Ok, I’ve done that. Copied the file from the working user to the ftp user (in a .ssh subfolder) and set the permissions based on how it was for the original account (but for the other user, of course).
The problem lies more in vsftpd, actually.
In /etc/ssl/private, I’m seeing pem files that vsftpd uses. But in my home folder, the file is named authorized_keys. So I’ve spent an hour searching for how to convert an authorized_keys file to pem and haven’t find anything working…
Lifeboat created a pem file on my local computer, but I expect it wouldn’t work on the server, as there should be two different files on both ends, right?
Hi, I’m really sorry to read that. Really hoping you’ll get better as soon as possible.
I’ve yet to learn how
I’m an occasional Unix user, but I’ve to say I don’t fully adhere to its logic.
It showed an “insecure” field, IIRC. I was worried the same (but that’s probably just me)
Well, when the current issue gets resolved (if it gets), I’ll probably be glad something told me to be up to date with security.
For FTP over SSH (SFTP) you don’t need another daemon like vsftpd. Just make sure you have Subsystem sftp internal-sftp in your /etc/ssh/sshd_config file, and any user that can sign into via SSH can get SFTP. If you need to limit your ftp user to SFTP without the shell, you would do something like this:
Match User ftpuser
ForceCommand internal-sftp
ChrootDirectory /path/to/ftp/directory
PermitTunnel no
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
I don’t have any experience with vsftpd though, so if you want to keep using it, I’m probably not too helpful. I’m a little curious why turning off shell password authentication would interfere with vsftpd though.
Oh yes, that worked amazingly well! I’ve not even had to remove vsftpd prior to make it working (though I’ll now do).
I’m now unsure why I “needed” to install vsftpd in the first place. I guess I’ve not read anywhere that SSH provided FTP natively. Assumptions can lead to a big load of side effects.
Thanks everyone, especially Thom, for your answers!
Ah yes; I was certainly confused between FTPS and SFTP (both mean “secured FTP” to me , unless I see both at the same time and then remember there are two different beasts).
. Looks like a good starting point. I’m going to try it and will tell the result here.