I might have a thinking fault: To secure my ssh keys, I would like to keep them on the server inside the HSM. So I wonder how I need to setup ssh on the client to get remote connected to the server?
As the private key is only inside the (server) HSM, the client could only obtain the public key. Is there any trick ( e.g. ssh-agent ) that this scenario could work ?
Second case would be: ONE client has also an NK pro and the public key is registered on the server with HSM. From there all other clients and servers could be reached with the key pair stored in the HSM and ssh-agent running on the server.
I think the second scenario will work, but will need two HW tokens. Also the client’*s HW token could be used to connect to all other machines direct. So what are the use-cases for the second scenario ?
( Maybe somebody could share a usual practice )
The client is always authenticating against the server by signing its request with its own private key. The corresponding public key is stored at servers side in a list of allowed clients. The private key of the client could be secured by another device, but not by the HSM of the server.
The HSM of the server may can store the private root key of the SSH server which is used to decrypt the communication to the server, but not the keys of the client, because of the way SSH is working.
I am not sure, if this is an adequate response to your question. Generally, I guess you already understood the situation here, as far as I understand your descriptions. But maybe I got it wrong.
Do you mean something like reverse
Ok, thanks for the clarification. When I call “ssh” one type of application, I could imagine that I could build another app that keeps the private key in the HSM on the server and open a tunnel on a allowed client, when this client is connected. So even if the client is “infected” , the client would not be able to open the connection from his side - only the server could do that. To prevent chronicle heart-beeps/checks whether a client is available, the app could allow a “available” message as hook-request.
My second option setup seems to be easy: put the clients user public key on the servers client user ssh directory and put the HSM public key for the user on all other direct available second servers. The ssh- agent would only need the key, when you hop from that second servers to third servers ( e.g. behind a firewall ).
Also it could be possible to setup the HSM server as trusted ssh server and allow host2host trust by putting the HSM servers public ssh key to all second servers of the above scenario. Then all users of teh HSM server could connect behind the firewall, when there is also a host2host trust.
So overall it would be like a reverse-ssh that is initiated from the server instead of the client.
Alternative solution to
p11-kit - see Server stuck in POST when Nitrokey HSM is inserted
I am not sure it is possible to configure properly the ssh-agent for the first use case, specifically whether it was foreseen in its design. @nitroalex: ideas?
Did not test this either.