Password and private key file for ssh

[inercia]

This PR adds a -P<password> and -i<key> arguments for using alternative authentication methods for ssh.

[ereslibre]

Please, let's focus on the sprint goals. I don't think this is necessary at the moment.

[inercia]

Please, let's focus on the sprint goals. I don't think this is necessary at the moment.

Well, this is necessary for deploying the cluster in my environment. If you have any comments relative to the code please go ahead...

[ereslibre]

How so? Just do a ssh-add of your key to a running ssh agent as documented on the prerequisites: https://github.com/SUSE/caaspctl#prerequisites.

[inercia]

How so? Just do a ssh-add of your key to a running ssh agent as documented on the prerequisites: https://github.com/SUSE/caaspctl#prerequisites.

I'm automating things and that workflow does not match that automation. So do you think there is something wrong with this code?

[ereslibre]

So do you think there is something wrong with this code?

Well, sure:

• It's duplicating the shorthand for port as p.
• It doesn't adapt the README prerequisites to include the new flags.

But most important of all, you don't clearly state why an SSH agent is not enough for your needs. We are trying to keep things as simple as possible and stick to the sprint goals. Having these flags is something we explicitly tried to avoid unless we had a valid story of why they are needed, and so far I haven't read anything like that.

[inercia]

It's duplicating the shorthand for port as p.

It is not, password uses capital -P.

It doesn't adapt the README prerequisites to include the new flags.

My intention was not to ducument this as, as you said, the main workflow is with ssh-add.

But most important of all, you don't clearly state why an SSH agent is not enough for your needs.

I've already told you that I have my automation scripts (that I will not dump in this discussion for sake of brevity) that do not match that workflow.

We are trying to keep things as simple as possible and stick to the sprint goals. Having these flags is something we explicitly tried to avoid unless we had a valid story of why they are needed, and so far I haven't read anything like that.

There are always changes that appear as side-effects of the work in a sprint, things that must be fixed or small improvements that make things easier when developing. It is a developer's dutty to keep focus on his main task, so they don't need to be babysitted.

[ereslibre]

It is not, password uses capital -P.

You changed this after my comment 🚀 (SUSE/caaspctl@c1b4d93 - SUSE/caaspctl@74746dc)

Cannot you do ssh agent forwarding? I still don't see enough evidence to not block this, I'm sorry.

[inercia]

Maybe @flavio could break the tie here.

[NunoFilipeSantos]

@inercia please pick up the tasks that were assigned to you during sprint planning.

[flavio]

It's fine to work on little things that were not planned as part of the sprint as long as the end goals of the sprint are matches.

I like the idea to be able to specify the ssh key via cli, I've run into the lack of this feature at the SUSECON booth and I wanted to file an issue about it.

I don't like the idea to supply a password via the command line. ssh authentication via password is a bad security practice and we should not encourage it. Plus it would add issues on our side like, the password would be visible inside of the history and via ps.

Just remove the code that deals with providing the password from the cli.

[ereslibre]

I like the idea to be able to specify the ssh key via cli, I've run into the lack of this feature at the SUSECON booth and I wanted to file an issue about it.

Just to have more context; why was this required? What use cases would this cover that the use of a ssh-agent cannot cover?

[ereslibre]

I believe this adds extra complexity on our side, e.g. if the private key has a passphrase this change is not enough and ssh.ParsePrivateKey is not going to succeed: ssh.ParsePrivateKeyWithPassphrase is required in that case, and the passphrase needs to be passed somehow to caaspctl. Go has issues open using private keys with passphrases: golang/go#18692

Using an ssh-agent abstracts all this from us: they have to do ssh-add and we don't care if the key has passphrase or not, they add the keys they need to the agent and that's it. I don't see the need to add arguments to point to a specific key or adding passwords or handling this complexity at all.

I'm a -1 to this change altogether.

[flavio]

All right, I didn't know about the limitations of Go when it comes to managing ssh keys. Let's leave everything aside until we get clear feedback from our stakeholders.

@inercia let's close this PR and re-open it if someone asks for one of these features.

In the meantime I've pinged @r0ckarong to understand how much we document about ssh-agent (for example the secret forwarding feature is pretty cool and answers one of the scenarios that was concerning me).