As far as I can tell, the choice between the first three does not have one as mandatory in any case that I can imagine.

If I prefer to manage the host keys of my agents outside of Jenkins configuration files but in the account that runs my Jenkins controller, then I choose option 1. Personally, I prefer to manage my Jenkins configuration inside the files maintained by Jenkins, so I did not choose option 1.

Options 2 and 3 are minor variants of each other. If I choose option 3, then I will be prompted on first connection of the agent to approve the host key that is detected by Jenkins. That is a reasonable approach if I am confident at that time that the agent being connected is the expected agent.

I personally chose option 2 because I prefer to provide the host key while I am configuring the agent rather than waiting until the first connection of the agent. That places some additional burden on me because it requires that I insert the host key of the agent myself. I find that easier, but not significantly different for security purposes. When I'm entering data in the agent configuration, I'm only seconds away from connecting the agent.

Hello Mark

Interesting your explanation and has sense at a first glance - if it can be added (after to be polished and approved by the authors of this plugin) would be very valuable - if some Figures can be added to represent each scenario would be really valuable for new comers. I use the option #3 - it because after to watched many tutorials on Youtube - that approach worked how expected - just that my main concern is if is wise copy and paste the "private" key - I would suggest refer the absolute path to the private key. It in case if a remote user with his credentials get access to Jenkins via web and arrives to that configuration, he only is able to see the path but not the content.

Of course if the authors can add more scenarios(s) if exists with Figures - would be really valuable.

I know that I ask for many things - but security is not game.

Thanks for your understanding to all

4 - it is insecure as you said so the recommendation is to not use it.
3 - IMHO is odd you have to configure the agent wait for it to connect and verify the public key is correct.
2 - This is the option that allows Jenkins to manage the public key, so Jenkins has the control.
1 - In this case the public key is in the filesystem in the home of the user used by Jenkins to run (~/.ssh/known_hosts), it is in the folder ~/.ssh that should have 0600 permissions (it is mandatory on all SSH implementations)

In any case, there is a security risk of exposing sensible data, Why? because you are using the public key of the host that it is shared by the SSH service every time you try to connect so it is public, the private key of the host is in the agent in the folder /etc/ssh and is managed in that system.

I watched many tutorials in YouTube for this topic:

4 - Agree - for LAN simple testing for agents has sense this approach
3 - Only was possible for me establish a successful connection for this approach - to be honest I like this approach, but I am not agree in copy/paste the private key content within the Jenkins GUI - other user would see that content - I think is better create a text field and refer the path for that private key - even better if is customized about the file name, for example ~/.ssh/id_rsa_jenkins_agent - so if other user arrives to there only can see the path, but never the content
2 - I think the problem was not possible define the custom public key - such as: ~/.ssh/id_rsa_jenkins_agent.pub
1 - I don't remember the problem I had in this approach

again, the validation of host is made with the host public key, starts with ssh-rsa for rsa keys and is in the /etc/ssh/*.pub files, the one that is copied in `~/.ssh/known_hosts`. If you are using private keys (e.g. ----BEGIN RSA PRIVATE KEY----) the feature should not work.

https://github.com/jenkinsci/ssh-slaves-plugin/blob/master/doc/CONFIGURE.md#host-key-verification-strategy

manueljordan there is no need to insert the private key of the remote host into Jenkins and there is no Jenkins input field that will accept the private key of the remote host. The Jenkins input field in the ssh agents dialog accepts the public key of the remote host. The remote file containing the private key of the remote host is almost always permission protected on the remote host so that it can only be read by the super user on the remote host.

I've definitely used methods 2 and 3 in my Jenkins instance.

Hello developers

Seems we had a confusion, perhaps my English grammar is not well - but about the private key is about of the own client, not about the server/host.

It is about the same one based in the following figure:

• https://github.com/jenkinsci/ssh-slaves-plugin/blob/master/doc/images/ssh-credentials-manage-detail.png

The video and blog tutorial is about:

 * https://www.coachdevops.com/2021/06/jenkins-build-agent-setup-how-to-setup.html

The explicit figure from that tutorial (practically the same than the first link) is

• https://1.bp.blogspot.com/-QZ670DvumD8/W8uaM3e-sWI/AAAAAAAAAi0/k-rbHMYt9Eouwv_TD_wzpHhWA31YoqUTwCLcBGAs/s1600/Screen%2BShot%2B2018-10-20%2Bat%2B4.11.41%2BPM.png

So, that is the part that I referred when I used the copy/paste terms about the private key - and should be better use a text field to only refer the private key file - in case other developer arrives to there.

Just two points

One

Then about the Manually provided key Verification Strategy approach , about the /etc/ssh/<key_name>.pub file mentioned - that file is of the agent side right? - but which one? there are in Ubuntu 3 public key files for rsa, ecdsa and ed25519 - friendly I suggest indicate explicitly what is the file mentioned through The SSH key expected for this connection. - it about the content shown in the following figure: https://github.com/jenkinsci/ssh-slaves-plugin/blob/master/doc/images/hkvs-manual-key.png. I think it is important to avoid confusions. It is confuse in some way 

Two

I use the Manually trusted key Verification Strategy approach (using the private key of the controller side), I have a consult here - in this section is mentioned the Computer.CONFIGURE file - that file where is located? it was confuse for me until now - at a first glance what is the relation of that file with SSH?
 
BTW to avoid more confusions - for me about the terms:

• Controller -> client
• Agent -> server (because I paste there the public key of the client/controller to accomplish the SSH connection)

The Controller needs do a connection to the Agent, right?

Thanks for your understanding