How do I give a SFTP recipient a public key
I have an FTPS (SSL) server that works. I am thinking of making an SFTP (SSH) server. I have read a lot about the recipient needing a public key. I have not found much information on exactly how to get that public key to the recipient. Is it through an email, a CA Authority, or is it automatically given when they attempt to connect the SFTP server. Do they need a new one each time they connect?
Just the opposite.
1) Server side contains the public key.
2) You deliver a private key to anyone wishing to access your SSH/SFTP service.
How you deliver private keys, also the related passphrase to use the private key, depends on how many keys you have to deliver.
If this is an occasional activity, I just drop these into a hashed directory (which is not indexed anywhere), so something like...
https://davidfavor.com/your-key-j40r7VtwaGl7Pgz1Hz2dNuSTqKwWrOqA then place the private key + passphrase in this directory, then delete this once it's downloaded.
If you have 1000s of accounts to manage, I'd setup an HTTPS WordPress site with a simple file download plugin, to provide secure downloads of these.
Note: Email isn't secure. I never send anything like this via email.
Keys are only generated once. They may be rekeyed at any time, which means you reset the passphrase, then deliver a new passphrase to the user.
Said differently, keys live forever, so no requirement to generate a key for each connection.
1) Server side contains the public key.
2) You deliver a private key to anyone wishing to access your SSH/SFTP service.
How you deliver private keys, also the related passphrase to use the private key, depends on how many keys you have to deliver.
If this is an occasional activity, I just drop these into a hashed directory (which is not indexed anywhere), so something like...
https://davidfavor.com/your-key-j40r7VtwaGl7Pgz1Hz2dNuSTqKwWrOqA then place the private key + passphrase in this directory, then delete this once it's downloaded.
If you have 1000s of accounts to manage, I'd setup an HTTPS WordPress site with a simple file download plugin, to provide secure downloads of these.
Note: Email isn't secure. I never send anything like this via email.
Keys are only generated once. They may be rekeyed at any time, which means you reset the passphrase, then deliver a new passphrase to the user.
Said differently, keys live forever, so no requirement to generate a key for each connection.
@David:
1) Correct.
2) In this case you can stick to FTPS.
The keys must be created from the user on his/her machine. The private key must never be in someone else control.
EDIT:
When someone else has control over your private key, for whatever reason or only for a short time, then the security of public/private key encryption is no longer given. Thus you can stick to FTPS as here your server SSL certificate is used.
The main difference between FTPS and SFTP is the direction of trust:
When using SSH the server can trust that only the owner of the private key can read the data. This trust would be broken.
In comparison, by using FTPS, the user trusts that he gets the data from the correct server.
Another important difference is how the trust is confirmed:
Using a SSH public key means that you (the server user/admin) needs to verify the public key by e.g. getting the fingerprint sent via secure channel.
Using SSL means that the client user trusts a CA.
1) Correct.
2) In this case you can stick to FTPS.
The keys must be created from the user on his/her machine. The private key must never be in someone else control.
EDIT:
When someone else has control over your private key, for whatever reason or only for a short time, then the security of public/private key encryption is no longer given. Thus you can stick to FTPS as here your server SSL certificate is used.
The main difference between FTPS and SFTP is the direction of trust:
When using SSH the server can trust that only the owner of the private key can read the data. This trust would be broken.
In comparison, by using FTPS, the user trusts that he gets the data from the correct server.
Another important difference is how the trust is confirmed:
Using a SSH public key means that you (the server user/admin) needs to verify the public key by e.g. getting the fingerprint sent via secure channel.
Using SSL means that the client user trusts a CA.
ste5an brings up a good point.
This can be approached either way.
1) The above discussion is how I handle the case where I generate all keys for users, then provide them the key.
I almost always do this, to ensure a rock solid key (long bit length key).
2) The other approach, which ste5an covers, provides better security, as the user generates the keypair, then provides the server site with the public key.
The downside of this is every user must be technical enough to figure out how to generate a keypair.
This is dirt simple for Unix + Linux + OSX users.
Not near so simple for Windows users.
3) The approach you take really depends on how many keys your talking about, along with the technical expertise of your users.
Having users provide you with only a public key is far more secure + requires no work on the server side at all, except adding the public key to some ~$user/.ssh/authorized_key
This can be approached either way.
1) The above discussion is how I handle the case where I generate all keys for users, then provide them the key.
I almost always do this, to ensure a rock solid key (long bit length key).
2) The other approach, which ste5an covers, provides better security, as the user generates the keypair, then provides the server site with the public key.
The downside of this is every user must be technical enough to figure out how to generate a keypair.
This is dirt simple for Unix + Linux + OSX users.
Not near so simple for Windows users.
3) The approach you take really depends on how many keys your talking about, along with the technical expertise of your users.
Having users provide you with only a public key is far more secure + requires no work on the server side at all, except adding the public key to some ~$user/.ssh/authorized_key
ASKER
We have about 20 companies we deal with. They don't all have IT departments. I may decide I do not want to help others receive and apply a key. Can I stick with FTPS? It is an improvement over our old FTP server. This is not very high security information, and want to make it easy for others. I don't think our parent company uses SFTP.
That brings up the question. How do they apply and store the key?
That brings up the question. How do they apply and store the key?
Ugh... 20 companies...
If I were faced with this, I'd...
1) Create 4096 bit RSA keypairs.
2) Provide them the private key.
3) Because... the thought of dealing with a bunch of random people at 20x companies... of... how to say this... varying technical expertise...
Wow... If you try to... instruct these people about generating their own keypairs, you'll likely require staff (expensive + time consuming) to try to help each random person get their key generated.
If I were faced with this, I'd...
1) Create 4096 bit RSA keypairs.
2) Provide them the private key.
3) Because... the thought of dealing with a bunch of random people at 20x companies... of... how to say this... varying technical expertise...
Wow... If you try to... instruct these people about generating their own keypairs, you'll likely require staff (expensive + time consuming) to try to help each random person get their key generated.
It occurs to me an easy way to do this...
1) Have someone visit some link which runs ssh-keygen.
2) Then the link shows the keypair + random keyphrase you generate.
3) Then add the public key to whatever ~$user/.ssh/authorized_key
4) Then if no login occurs for this keypair over some time period... say a month... delete the public key from the authorized_keys file, to keep this file purged of unused keys.
5) Be sure to wrap this page in reCAPTCHA V3, then use fail2ban to block any Bots... so they don't thrash your keygen machine.
6) If you run this page behind HTTPS, then deposit the keypair + passphrase in a hashed directory, this keeps the code very simple.
7) Also as a perk, whenever someone loses their key or likes a new password, they can just regenerate a new one.
1) Have someone visit some link which runs ssh-keygen.
2) Then the link shows the keypair + random keyphrase you generate.
3) Then add the public key to whatever ~$user/.ssh/authorized_key
4) Then if no login occurs for this keypair over some time period... say a month... delete the public key from the authorized_keys file, to keep this file purged of unused keys.
5) Be sure to wrap this page in reCAPTCHA V3, then use fail2ban to block any Bots... so they don't thrash your keygen machine.
6) If you run this page behind HTTPS, then deposit the keypair + passphrase in a hashed directory, this keeps the code very simple.
7) Also as a perk, whenever someone loses their key or likes a new password, they can just regenerate a new one.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
So, after reading your comments and reading even more articles I am confused about where the private key goes and the public key goes. Some articles are vague, some say server, and some say client. So does the server share the public key and the client present a private key or the other way around?
ASKER
David, your link appears broken.
ASKER
The user's Public & Private Keys are a pair of keys used to authenticate a client when it connects to an SFTP server. The user's private key is kept secret and stored locally on the user's PC while the user's public key is uploaded and registered on the SFTP server the user connects to.
Host (The Public key I read) key validation ensures the FTP server that a client is connecting to is verified as the correct one. When the client connects to the server, the server’s public key is returned and the client may be prompted to accept the host key (if connecting for the first time). Once accepted, this key will be stored within the client, which will then be used to check if the Host key matches each time it connects to the SFTP server.
Before any client authentication takes place, the client may get prompted by the SFTP server to validate the host key when establishing connection with it. Once server validation is complete the client will encrypt a signature using the loaded private key and sends it to the server. The server then verifies this signature against the stored user public key. Once verification is successful, the SFTP will grant access to the connecting client.
I see part of the confusion is there are four keys. Both the server and client have a public and private key.
SFTP Authentication - 2BrightSparks
www.2brightsparks.com › resources › articles › sftp-authe...Host (The Public key I read) key validation ensures the FTP server that a client is connecting to is verified as the correct one. When the client connects to the server, the server’s public key is returned and the client may be prompted to accept the host key (if connecting for the first time). Once accepted, this key will be stored within the client, which will then be used to check if the Host key matches each time it connects to the SFTP server.
Before any client authentication takes place, the client may get prompted by the SFTP server to validate the host key when establishing connection with it. Once server validation is complete the client will encrypt a signature using the loaded private key and sends it to the server. The server then verifies this signature against the stored user public key. Once verification is successful, the SFTP will grant access to the connecting client.
I see part of the confusion is there are four keys. Both the server and client have a public and private key.
ASKER
In short, since I just worked so hard to make the FTPS server, and it doesn't require the generation of a key by the client, I think I will stay with my FTPS server. It has to be better than the plain FTP server I was using.
Any major objections?
Any major objections?
Yes, FTPS is a vastly superior alternative to FTP.
No, SFTP does NOT require generation of a key by the client. They can simply authenticate with a password.
Are your users that connect to your FTPS server authenticating with a password?
No, SFTP does NOT require generation of a key by the client. They can simply authenticate with a password.
Are your users that connect to your FTPS server authenticating with a password?
ASKER
We are only a team of four for a mid-size company. we all wear many hats. 2 programmer's (1 is a manager), a tech, and me), Your network and hyperconverged VM system need a lot of mission critical updates. We get new projects everyday. I imagine this is or has been true for most of you. I would like perfection, but am losing time on high value projects. I hope you understand.
ASKER
Yes, FTPS requires a password. I was not aware that SFTP does NOT require generation of a key by the client. They can simply authenticate with a password. I like that idea. is it easy?
Yes, it is very easy to set up SFTP with password authentication.
If your FTPS users authenticate with password, then having your SFTP users authenticate with password is just as easy and secure.
SFTP offers the benefit of being easier for the client and server to manage from the standpoint of firewalls.
If your FTPS users authenticate with password, then having your SFTP users authenticate with password is just as easy and secure.
SFTP offers the benefit of being easier for the client and server to manage from the standpoint of firewalls.
https://davidfavor.com/your-key-j40r7VtwaGl7Pgz1Hz2dNuSTqKwWrOqA provides an example of a possible link.
I use hashed links, which are always HTTPS + never appear in a sitemap, so I don't have to manage user/pass access for these links.
Each time I create a keypair, I provide users with 3x items in a hashed link.
1) Private Key file
2) Public Key file
3) Passphrase in form of $string.passphrase, so a person can easily access this too.
How you approach this will be determined by your local security policy.
I use hashed links, which are always HTTPS + never appear in a sitemap, so I don't have to manage user/pass access for these links.
Each time I create a keypair, I provide users with 3x items in a hashed link.
1) Private Key file
2) Public Key file
3) Passphrase in form of $string.passphrase, so a person can easily access this too.
How you approach this will be determined by your local security policy.
ASKER
Yeah, the firewall was a bear. Think I can just search for SFTP users authenticate with password
Note: SSH/SFTP can be accessed via keyfile or password.
Aside: Getting this working is only one step. Next step will be to integrate an ACL system which allows an SSH/SFTP user to read/write files owned by other tech, like Apache or some other server.
Handling ACL setup can be complex.
If files will be shared between users + other tech like Apache, open another question about how to handle multi user ACL management.
Aside: Getting this working is only one step. Next step will be to integrate an ACL system which allows an SSH/SFTP user to read/write files owned by other tech, like Apache or some other server.
Handling ACL setup can be complex.
If files will be shared between users + other tech like Apache, open another question about how to handle multi user ACL management.
ASKER
What OS are you running the server on?
ASKER
2016
What does "2016" mean? Are you saying you are using Windows Server 2016?
If you are using Windows, there are numerous products that make it trivially easy to host an FTPS and SFTP server.
Robo-FTP Server https://www.robo-ftp.com/robo-ftp-server), for example, supports FTPS and SFTP. You can have that up and running in under five minutes. The same username/password combination would work for both protocols, so the client can choose which one they prefer.
If you are using Windows, there are numerous products that make it trivially easy to host an FTPS and SFTP server.
Robo-FTP Server https://www.robo-ftp.com/robo-ftp-server), for example, supports FTPS and SFTP. You can have that up and running in under five minutes. The same username/password combination would work for both protocols, so the client can choose which one they prefer.
ASKER
Does the standard include password SFTP?
Yes, it includes password authentication for both SFTP and FTPS. It also includes key authentication for SFTP and certificate authentication for FTPS, if you want to use them.
ASKER
Is there a way to have an SFTP user login with just a username and password without bothering them with making/accepting keys without having to buy software?
Users can log in using whatever SFTP client they want. There are free clients available and also paid clients.
If you are using password authentication then users will not need to create keys.
If you are using password authentication then users will not need to create keys.
ASKER
we went with FTPS
https://www.ssh.com/ssh/keygen/#ssh-keys-and-public-key-authentication