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

You are mixing thing one is the authentication of the agent https://github.com/kuisathaverat/ssh-slaves-plugin/blob/master/doc/CONFIGURE.md#required-settings, in you case with a user private key credential https://github.com/kuisathaverat/ssh-slaves-plugin/blob/master/doc/CONFIGURE.md#integration-with-ssh-credentials-plugin, this authenticate Jenkins to login in your SSH agent; and the agent host key verification https://github.com/kuisathaverat/ssh-slaves-plugin/blob/master/doc/CONFIGURE.md#host-key-verification-strategy that verify that the Agent you are connecting is the host you thing it is by checking host public key. Both things are different parts of the SSH connection protocol, not are related.

Here you have more details about the SSH handshake https://goteleport.com/blog/ssh-handshake-explained/

In any case, if you want help about the SSH agent please use the use google group or discourse community https://community.jenkins.io/ Jira is for report issues, not for get support https://www.jenkins.io/participate/report-issue/ I’ll kindly help you there to configure your SSH agent

Thanks for the links Ivan - I am going to read it. I hope it clarify and improves the idea about how Jenkins works with SSH

Wooh - I didn't know about Discourse for Jenkins - I have always used StackOverflow and SuperUser.

Thank you!

alexandruivan, I believe manueljordan created the ticket as.much to get an answer for himself as to get better guidance in the Host Key Verification strategy documentation as to what would be the preferred optiion for what circumstances for the user, so such questions need not arise.

Not all users will be sufficiently familiar with ssh security, or may get confused enough witj keys , they juat choose xwhatever gets me working", which would be no verification strategy.

Hello

I believe Manuel Jordan created the ticket as.much to get an answer for himself as to get better guidance in the Host Key Verification strategy documentation??

The former is reflected for the latter for other users/developers - I am assuming other developers are going to have the same concern about get the best guidance to know what option select - it according the specific/general scenario they have

Not all users will be sufficiently familiar with ssh security, or may get confused enough witj keys

Is assumed that the developer should learn SSH - like in my case and for any new developer - security is always critical and a risk.

they juat choose xwhatever gets me working", which would be no verification strategy

Agree for a simple LAN or some experiments, but for real development security must be applied any of the 3 other options.

So this request was generated according my concern/clarification/guidance to know when apply wisely the best option of the three first options - I am sure other developers would consider valuable that information