• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • ssh-slaves-plugin
    • None
    • Jenkins 2.401.1, SSH Build Agents 2.877.v365f5eb_a_b_eec

      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.

          [JENKINS-71483] Paragraph character in password not working

          Maximilian added a 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  

          Maximilian added a 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  

          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.

          Ivan Fernandez Calvo added a 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.

          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.

          Ivan Fernandez Calvo added a 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.

          Maximilian added a 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 "§".

          Maximilian added a 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 "§".

          Ivan Fernandez Calvo added a comment - - edited

          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

          Ivan Fernandez Calvo added a comment - - edited 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

          Maximilian added a comment - - edited

          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. 

          Maximilian added a comment - - edited 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. 

          Maximilian added a 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. 

          Maximilian added a 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.

          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.

          Ivan Fernandez Calvo added a 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.

          Maximilian added a 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. 

          Maximilian added a 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. 

          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

          Ivan Fernandez Calvo added a 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

            ifernandezcalvo Ivan Fernandez Calvo
            vogtmh Maximilian
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: