I have a home server which hosts shared files to a set of users. When adding new users I have (in the past) set up user accounts which belong to an 'SFTP only' group that chroots them to the shared directory (using the sshd_config). A personal folder is created for them that only they can write to and it contains an authorized_keys file used for private key authentication. I create the public / private key pair on my server as part of the user creation process and then write the public key to their authorized_keys file (on my server) and email them the private key (alongside a welcome message containing useful instructions and information) so that they can connect.

I realise that by doing this I am defeating the purpose of using keys as both the private key is being sent over email and I as the administrator have a copy (and could impersonate the user). Now while security is not particularly important in this instance I would like to do things properly and would hope that this question and any answers provided will help someone else who does need to improve security in this way.

My ideal solution is is to provide a private key to the user over email (per my previous method) which will expire after 'X' period (likely a few days) at which point the key will become unusable. In this period it is expected that the user replace the public / private key provided with their own which is necessary because of the self-expiring key. In this way I am able to easily set up a user account which someone can access without:

  • Allowing password authentication over SSH (which would also require giving them a password and giving them shell access to change that password)
  • Requesting a public key is provided beforehand (this would both deter users from signing up and make it difficult to automate the process on my end).
  • Continuing with my current practice.

Users would then have an opportunity to get their own private / public key set and replace the contents of the authorized_keys file with their own public key.

I stumbled across this article which explains how temporary access can be provided over ssh with signed public keys. I spent a lot of time looking into this but have not been able to get it to work and don't understand what seems to be a core concept - clients (users) are provided with the certified public key. I don't understand how the login / authorisation process is completed with the public key? Most guides get to that part and just note that the public key is provided to the user to 'log in' and do not elaborate further. Is this something that can only be done with SSH and not SFTP? When authorizing in filezilla for example I am able to provide a private key but not a public one. Further searching appears to indicate that this method (509x ??) will require client side configuration (and is more of an enterprise solution) and so may not be what I am looking for (as this will be too complicated for most of my users).

Is there any simple solution to my question, have I missed a critical step or misunderstood something? Thank you in advance for any help you may be able to provide.

1 Answer 1


Temporary OpenSSH certificates is the solution I'd also recommend for your needs. I did not try that with SFTP myself yet.

Mainly you sign the user's public key with the private key of a SSH-CA adding some more meta-data like validity period.

Then on your SFTP server you store the public key of the SSH-CA and refer to this file with config directive TrustedUserCAKeys. With this public key of the SSH-CA the server validates the OpenSSH certificate of the user during login. No need anymore to distribute authorized keys to the servers and remove them after validity period.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .