Yes, this is starting to fill out the details. So is the plan: 1. ssh into your server 2. run the program to get a URL 3. close the ssh connection 4. Open a

Yes, this is starting to fill out the details. So is the plan: 1. ssh into your server 2. run the program to get a URL 3. close the ssh connection 4. Open a browser SSH connection and use the url? In which case, 1. hmm, what is the benefit 2. how do you prevent the hosting webserver from seeing the url parameter? Assuming you want the hosting system to not be able to interfere in the session. If you are OK with such interference, you can make an easier key distribution than this. Or is the idea: 1. Setup your own webserver 2. authenticated to the webserver with some other protocol 3. the webserver grabs the url (it's hosted on the same server as the terminal server?) and then redirects to a page with the URL that you can use for the session In which case, err, why encourage people to use this third party server if that server can read the url? Also, there are again more secure ways of handling this that don't expose your terminal key as a URL parameter Remember URL parameters get leaked in referer and it's generally not recommended to store secrets in them if you can avoid it, which I believe in this use case you can, again assuming I have the workflows right. What this needs is a simple diagram showing the terminal server, the webserver, and the user's browser, defining the trust relationships between these, and explaining the flow of information among these components during key establishment and rotation.