k3sup
k3sup copied to clipboard
alexellis
[Feature] Host key validation
[Feature] Host key validation
Expected Behaviour
Most solutions which consume SSH will always, strictly validate SSH Host keys, to make sure that the host being connected to by the client is as expected.
I suspect that most of the time, people type in "yes" without looking at the host key, and without verifying it.
After accepting the Host key, it gets stored in ~/.ssh/known_hosts on its own line. Whenever the user reconnects, that known host value will be used to validate that the Host key has not changed. If it has changed, then the ssh client will refuse to connect, since the host may have been tampered with, or the connection may have been intercepted.
Current Behaviour
k3sup ignores hosts keys, since it's designed to be used headless, without any prompting. Forcing strict acceptance of host keys will require user interaction and break the user-experience.
Possible Solution
As a middle-ground, k3sup could accept the host key, and maintain its own known_hosts file, or make use of the the system-level file.
A downside to this is that k3sup is often used with VMs, for learning, with RPis, and with labs, where the IP and host key will rarely match between requests. k3sup also is designed to connect to each agent host only once, which defeats the purpose of the host key validation.
This is not a simple issue, however I hope that security-types will be reassured that the potential issue is being logged, and that suggestions are welcome.
It may be a stupid question but I'll ask anyway: did you evaluate the idea of using certificates instead of private/public key?
@scanepa it really comes down to what users are doing, rather than what we think is the best practice in the industry. How much of an infrastructure and on boarding burden is there, if all users are forced to use SSH certificates?
Would you mind answering the above, and giving a proposal of how you'd see things working?
Forcing all users to get SSH certificates requires a certification authority for sure, some tool/human to sign keys and distribute user certificates, the installation on the destination host of the trusted CA keys, plus some steps that I'm quite sure now I'm forgetting. I'm assuming the creation of the CA can be automated, but all other steps not, especially in the case of baremetal manually deployed systems.
So, after taking some time to think again I'm convinced this is to much work just to be able to login without issues on a AWS VM which changed IP in between sessions. My question was really stupid after all.
I'm not keen on using language like "stupid" on this project. Let's try and keep things objective.
Having the host key accepted on first connection is a bad default, but generally accepted. We could do that and validate on the second connection. This would become more necessary if users connected more than once to a machine with k3sup - i.e. an "apply" or upgrade/remove feature.
Sorry but I meant no offence, I just forgot you and all people reading this cannot see my smiling and embarrassed expression when I realised my idea is most likely adding more burden than needed.
The best way to measure pros and cons could be a POC so let's see what I can setup with the hardware or VM I have around