[JENKINS-71483] Paragraph character in password not working

[jenkins-infra-bot]

I would like to connect a new agent to our Jenkins Master. It uses the paragraph character § in the password and the authentication fails (wrong password). Unfortunately, I am not allowed to change the password. 

 

When I connect manually via ssh from a Linux machine, it asks for the password and accepts it. Without those special characters, the connection would also work from Jenkins. So I assume it's a bug in the plugin. 

Unfortunately, it's not possible to use a SSH key instead of a password with this plugin. Would have been a viable alternative.

---

Originally reported by vogtmh, imported from: Paragraph character in password not working

• assignee: ifernandezcalvo
• status: Open
• priority: Minor
• component(s): ssh-slaves-plugin
• resolution: Unresolved
• votes: 0
• watchers: 3
• imported: 20251212-090250

Raw content of original issue

I would like to connect a new agent to our Jenkins Master. It uses the paragraph character § in the password and the authentication fails (wrong password). Unfortunately, I am not allowed to change the password. 

 

When I connect manually via ssh from a Linux machine, it asks for the password and accepts it. Without those special characters, the connection would also work from Jenkins. So I assume it's a bug in the plugin. 

Unfortunately, it's not possible to use a SSH key instead of a password with this plugin. Would have been a viable alternative.

• environment: Jenkins 2.401.1, SSH Build Agents 2.877.v365f5eb_a_b_eec

3 attachments

• image-2023-06-19-17-50-11-771.png

  

• image-2023-06-19-17-50-55-293.png

  

• image-2023-06-19-18-01-29-087.png

  

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  Can you further explain your statement:
  
  Unfortunately, it's not possible to use a SSH key instead of a password with this plugin. Would have been a viable alternative.
  
  I only use SSH private keys with the Jenkins agents that I connect with SSH.  I have agents running Alma Linux 8, CentOS 7, Debian 10, Debian 11, Debian 12, FreeBSD 13, Rocky Linux 9, openSUSE 15.4, Ubuntu 20.04, Ubuntu 22.04, Windows 10, and Windows 11.
  
  I don't know how to connect a Jenkins agent using ssh with a password.
  
  Maybe you mean that the SSH private key is protected by a passphrase and that passphrase includes the paragraph character?
  

Can you further explain your statement:

Unfortunately, it's not possible to use a SSH key instead of a password with this plugin. Would have been a viable alternative.

I only use SSH private keys with the Jenkins agents that I connect with SSH. I have agents running Alma Linux 8, CentOS 7, Debian 10, Debian 11, Debian 12, FreeBSD 13, Rocky Linux 9, openSUSE 15.4, Ubuntu 20.04, Ubuntu 22.04, Windows 10, and Windows 11.

I don't know how to connect a Jenkins agent using ssh with a password.

Maybe you mean that the SSH private key is protected by a passphrase and that passphrase includes the paragraph character?

[jenkins-infra-bot]

vogtmh:

• Original comment link
• Raw content of original comment:

  The SSH Build Agents plugin only accepts credentials based on username/password. SSH keys are not supported. 
  
  As far as I understood, only the Cloudbees SSH agent plugin - which is not available on the Open Source Jenkins - supports SSH keys.
  
  Here's a screenshot of my node configuration:
  
  
  

The SSH Build Agents plugin only accepts credentials based on username/password. SSH keys are not supported. 

As far as I understood, only the Cloudbees SSH agent plugin - which is not available on the Open Source Jenkins - supports SSH keys.

Here's a screenshot of my node configuration:

[jenkins-infra-bot]

ifernandezcalvo:

• Original comment link
• Raw content of original comment:

  The plugin accepts SSH keys as credentials. You have to have installed the SSH Credentials plugin.
  
  https://github.com/jenkinsci/ssh-slaves-plugin/blob/main/doc/CONFIGURE.md#integration-with-ssh-credentials-plugin
  

The plugin accepts SSH keys as credentials. You have to have installed the SSH Credentials plugin.

https://github.com/jenkinsci/ssh-slaves-plugin/blob/main/doc/CONFIGURE.md#integration-with-ssh-credentials-plugin

[jenkins-infra-bot]

ifernandezcalvo:

• Original comment link
• Raw content of original comment:

  I doubt any special character can break the authentication, the password is stored as it is and is written in the browser and restored in the same way. The only way that that character is incorrectly written in the credentials store is if your Browser locale does not accept that character or does not write the same input.
  

I doubt any special character can break the authentication, the password is stored as it is and is written in the browser and restored in the same way. The only way that that character is incorrectly written in the credentials store is if your Browser locale does not accept that character or does not write the same input.

[jenkins-infra-bot]

vogtmh:

• Original comment link
• Raw content of original comment:

  Jenkins SSH Credentials Plugin is installed, of course. But the SSH Build Agents Plugin does not list our existing SSH credentials from the store. I can only select user/password credentials.
  

Jenkins SSH Credentials Plugin is installed, of course. But the SSH Build Agents Plugin does not list our existing SSH credentials from the store. I can only select user/password credentials.

[jenkins-infra-bot]

vogtmh:

• Original comment link
• Raw content of original comment:

  Update from my side: SSH Build Agents does not have an extra selection for it, but combines both username/password and username/sshkey into one list (a rather long list in my case). I can confirm it works fine using the SSH key instead of a password  
  

Update from my side: SSH Build Agents does not have an extra selection for it, but combines both username/password and username/sshkey into one list (a rather long list in my case). I can confirm it works fine using the SSH key instead of a password  

[jenkins-infra-bot]

ifernandezcalvo:

• Original comment link
• Raw content of original comment:

  This is because they are not in the domain of the agents, it is explained in the documentation. Most of people and I use SSH Keys, so it is a well-tested feature.
  

This is because they are not in the domain of the agents, it is explained in the documentation. Most of people and I use SSH Keys, so it is a well-tested feature.

[jenkins-infra-bot]

ifernandezcalvo:

• Original comment link
• Raw content of original comment:

  As I said, the thing with the character is definitely related to the browser. All the forms in Jenkins use the same way to manage secrets, and the UI for the user and password in the SSH build agents plugin is provided by the credential user and password. The Jenkins Core provides this credential IIRC.
  

As I said, the thing with the character is definitely related to the browser. All the forms in Jenkins use the same way to manage secrets, and the UI for the user and password in the SSH build agents plugin is provided by the credential user and password. The Jenkins Core provides this credential IIRC.

[jenkins-infra-bot]

vogtmh:

• Original comment link
• Raw content of original comment:

  Okay, I tried it on 3 different machines (Win/Mac/Lnx) and browsers (Firefox, Chrome, Safari) now. Some browser are set to German, some are set to English. Obviously, it seems to be a flaw in how Jenkins stores the secrets, because it reproducibly converts each occurrence of "§" to "§".
  

Okay, I tried it on 3 different machines (Win/Mac/Lnx) and browsers (Firefox, Chrome, Safari) now. Some browser are set to German, some are set to English. Obviously, it seems to be a flaw in how Jenkins stores the secrets, because it reproducibly converts each occurrence of "§" to "§".

[jenkins-infra-bot]

ifernandezcalvo:

• Original comment link
• Raw content of original comment:

  I think your Jenkins Controller is not configured with UTF-8 or something like that. The character "§" is 0xC2 0xA7 in UTF-8 that is the characters "§" if you split the character in 2 bytes, it looks like an issue converting a Unicode character to another encoding that is not UTF-8
  
  https://www.compart.com/en/unicode/U+00A7
  

I think your Jenkins Controller is not configured with UTF-8 or something like that. The character "§" is 0xC2 0xA7 in UTF-8 that is the characters "§" if you split the character in 2 bytes, it looks like an issue converting a Unicode character to another encoding that is not UTF-8

https://www.compart.com/en/unicode/U+00A7

[jenkins-infra-bot]

vogtmh:

• Original comment link
• Raw content of original comment:

  You're right. My controller is running on Windows and therefore not using UTF-8. I could not find an easy fix to switch it yet as it seems to ignore all additional parameters. But at least I have a clue now, thanks!
  
  My Linux masters use UTF-8 as their default. 
  

You're right. My controller is running on Windows and therefore not using UTF-8. I could not find an easy fix to switch it yet as it seems to ignore all additional parameters. But at least I have a clue now, thanks!

My Linux masters use UTF-8 as their default. 

[jenkins-infra-bot]

vogtmh:

• Original comment link
• Raw content of original comment:

  I had no luck with different encodings, then I dumped my credential via the script console: it looks perfectly fine. However, the Credential Binding Plugin and the SSH Build Agents Plugin seem to have a problem to correctly read it. 
  
  I tried other special characters like <>$%& and they all work without any problems. 
  
  SSH Keys in general work fine to connect, but we ran into the problem that Windows SMB shares don't work with those. 
  

I had no luck with different encodings, then I dumped my credential via the script console: it looks perfectly fine. However, the Credential Binding Plugin and the SSH Build Agents Plugin seem to have a problem to correctly read it. 

I tried other special characters like <>$%& and they all work without any problems. 

SSH Keys in general work fine to connect, but we ran into the problem that Windows SMB shares don't work with those. 

[jenkins-infra-bot]

ifernandezcalvo:

• Original comment link
• Raw content of original comment:

  >I had no luck with different encodings, then I dumped my credential via the script console: it looks perfectly fine. However, the Credential Binding Plugin and the SSH Build Agents Plugin seem to have a problem to correctly read it. 
  
  Again in a UTF-8 console, the output will always be correct because the bytes stores are correct. It is a problem of encoding/decoding in your system.  I will make a PoC in Docker if I could not replicate the issue I will close it again. I recommend you to ask in the Jenkins groups https://www.jenkins.io/participate/report-issue/#issue-reporting
  
  >I tried other special characters like <>$%& and they all work without any problems.
  
  These characters have only one byte in UTF-8 https://www.compart.com/en/unicode/U+0024, so it is impossible to interpret them wrong because they are in the 256 common characters of any encoding.
  
  >SSH Keys in general work fine to connect, but we ran into the problem that Windows SMB shares don't work with those. 
  
  I dunno what have to do SSH with SMB are different protocols.
  
  
  
  
  
  

>I had no luck with different encodings, then I dumped my credential via the script console: it looks perfectly fine. However, the Credential Binding Plugin and the SSH Build Agents Plugin seem to have a problem to correctly read it.

Again in a UTF-8 console, the output will always be correct because the bytes stores are correct. It is a problem of encoding/decoding in your system. I will make a PoC in Docker if I could not replicate the issue I will close it again. I recommend you to ask in the Jenkins groups https://www.jenkins.io/participate/report-issue/#issue-reporting

>I tried other special characters like <>$%& and they all work without any problems.

These characters have only one byte in UTF-8 https://www.compart.com/en/unicode/U+0024, so it is impossible to interpret them wrong because they are in the 256 common characters of any encoding.

>SSH Keys in general work fine to connect, but we ran into the problem that Windows SMB shares don't work with those.

I dunno what have to do SSH with SMB are different protocols.

[jenkins-infra-bot]

vogtmh:

• Original comment link
• Raw content of original comment:

  On Windows, you usually logon with a domain user and automatically have permission to some network shares. Windows is basically passing your username and password to authenticate with the remote server - which is not possible when using SSH keys instead. 
  

On Windows, you usually logon with a domain user and automatically have permission to some network shares. Windows is basically passing your username and password to authenticate with the remote server - which is not possible when using SSH keys instead. 

[jenkins-infra-bot]

ifernandezcalvo:

• Original comment link
• Raw content of original comment:

  I can replicate the issue easily in a docker environment, I dunno the RC yet, I have tried some encodings combinations, but all failed. I think it is related to the character has two bytes, so probably more characters have the same issue.
  
  https://github.com/kuisathaverat/jenkins-issues/tree/main/JENKINS-71483
  

I can replicate the issue easily in a docker environment, I dunno the RC yet, I have tried some encodings combinations, but all failed. I think it is related to the character has two bytes, so probably more characters have the same issue.

JENKINS-71483" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/kuisathaverat/jenkins-issues/tree/main/JENKINS-71483