Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-45651

X-SSH-Endpoint is not provided on top page when 401/403 are returned

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Minor Minor
    • core, ldap-plugin, ssh-plugin
    • None
    • Jenkins 2.60.1 on RedHat Enterprise Linux 5

      Quite contrary to what is written on https://wiki.jenkins.io/display/JENKINS/Jenkins+SSH, X-SSH-Endpoint header is not provided on the top page when the response is 403.

      $ curl -I http://localhost:8440/jenkins/
HTTP/1.1 403 Forbidden
Date: Wed, 19 Jul 2017 13:43:33 GMT
X-Content-Type-Options: nosniff
Set-Cookie: JSESSIONID.32f49371=15lrqwbgqu5jvm4xkf7ulfomu;Path=/jenkins;HttpOnly
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html;charset=UTF-8
X-Hudson: 1.395
X-Jenkins: 2.60.1
X-Jenkins-Session: 567160ff
X-Hudson-CLI-Port: 37318
X-Jenkins-CLI-Port: 37318
X-Jenkins-CLI2-Port: 37318
X-You-Are-Authenticated-As: anonymous
X-You-Are-In-Group-Disabled: JENKINS-39402: use -Dhudson.security.AccessDeniedException2.REPORT_GROUP_HEADERS=true or use /whoAmI to diagnose
X-Required-Permission: hudson.model.Hudson.Read
X-Permission-Implied-By: hudson.security.Permission.GenericRead
X-Permission-Implied-By: hudson.model.Hudson.Administer
Content-Length: 829
Server: Jetty(9.2.z-SNAPSHOT)

      One needs to get response 200 (i.e. access login URL) to get the endpoint. Note that CLI ports ARE returned always, only SSH endpoint is missing.

      $ curl -I http://localhost:8440/jenkins/login
HTTP/1.1 200 OK
Date: Wed, 19 Jul 2017 13:43:41 GMT
X-Content-Type-Options: nosniff
Set-Cookie: JSESSIONID.32f49371=6balu16gxdidrwpc4t258io;Path=/jenkins;HttpOnly
Expires: 0
Cache-Control: no-cache,no-store,must-revalidate
X-Hudson-Theme: default
Content-Type: text/html;charset=UTF-8
X-Hudson: 1.395
X-Jenkins: 2.60.1
X-Jenkins-Session: 567160ff
X-Hudson-CLI-Port: 37318
X-Jenkins-CLI-Port: 37318
X-Jenkins-CLI2-Port: 37318
X-Frame-Options: sameorigin
X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlwNEtMd78Uf5V2p+hCgcHOazeDpoo9lKZL7YlqgzpuQeJvHfhMZ+fRCTCoIns/swiE5tG0WttqRL4z7tgA+xF8+KzKFuUtONhar+4kGDIhrJks+MuyePpEpzXplHtcB9OFUymfwTXrOBXExswjdGodqupyG9IBG1Xlx51oRHRXHEci3QgF1f/7+KfsZM3oCTOpyQxNasE5dki4nA33PvvAeZGHwxvdJ0nmLcbAVk8aSCzjuDbJZ+GnjJC+CsLR34AYWHNbxOo8rn9PCiIJid43UX/36HmYweWlUdRsnBfXtHL02/NV6OngWvWAowmFmVz9YzLj5+C4Q9QshZmvhbFwIDAQAB
X-SSH-Endpoint: server:55999
Content-Length: 7304
Server: Jetty(9.2.z-SNAPSHOT)

        1. jenkins-global-security.png
          jenkins-global-security.png
          470 kB

          [JENKINS-45651] X-SSH-Endpoint is not provided on top page when 401/403 are returned

          Daniel Beck added a comment -

          Right, the expectation is that login is always available.

          https://github.com/jenkinsci/jenkins/blob/862de8612966f0acb64e6cf1205f2bc967679547/cli/src/main/java/hudson/cli/SSHCLI.java#L64

          If it works for the root URL, then probably only because anonymous Overall/Read is enabled.

          Daniel Beck added a comment - Right, the expectation is that login is always available. https://github.com/jenkinsci/jenkins/blob/862de8612966f0acb64e6cf1205f2bc967679547/cli/src/main/java/hudson/cli/SSHCLI.java#L64 If it works for the root URL, then probably only because anonymous Overall/Read is enabled.

          Sorin Sbarnea added a comment -

          So what should we do now as we know what happens?

          From my point of view I find the use of HTTP headers to document the port a bit questionable. The industry standard for this is based on DNS SRV entries

          dig _jssh._tcp.subdomain.example.com SRV

          See that I didn't use the default `ssh` name because that's already used by ssh protocol and many ssh clients are already supporting it.  Because Jenkins SSH is not really ssh, it may deserve its own service name, like  "jssh". 

          Sorin Sbarnea added a comment - So what should we do now as we know what happens? From my point of view I find the use of HTTP headers to document the port a bit questionable. The industry standard for this is based on  DNS SRV entries dig _jssh._tcp.subdomain.example.com SRV See that I didn't use the default `ssh` name because that's already used by ssh protocol and many ssh clients are already supporting it.  Because Jenkins SSH is not really ssh, it may deserve its own service name, like  "jssh". 

          Daniel Beck added a comment -

          So what should we do now as we know what happens?

          Look into whether the SSO plugin does something sane. It might not be. Not the easiest thing to do given Jenkins' authentication process complexity.

          Daniel Beck added a comment - So what should we do now as we know what happens? Look into whether the SSO plugin does something sane. It might not be. Not the easiest thing to do given Jenkins' authentication process complexity.

          Sorin Sbarnea added a comment -

          I tried to look for all the places where X-SSH-Endpoint  is used and found only 3 places and none of them look like something interesting https://github.com/search?utf8=%E2%9C%93&q=org%3Ajenkinsci+X-SSH-Endpoint&type=Code

          This makes me think that this issue has nothing to do with the plugin and that's a core limitation/bug that prevents the SSHD plugin from adding a header, the response being send back before reaching the plugin code.

          The only headers that seem to be working in this case are those like X-Jenkins-CLI2-Port which are added inside jenkins code, not by a plugin.

           

          Sorin Sbarnea added a comment - I tried to look for all the places where X-SSH-Endpoint  is used and found only 3 places and none of them look like something interesting https://github.com/search?utf8=%E2%9C%93&q=org%3Ajenkinsci+X-SSH-Endpoint&type=Code This makes me think that this issue has nothing to do with the plugin and that's a core limitation/bug that prevents the SSHD plugin from adding a header, the response being send back before reaching the plugin code. The only headers that seem to be working in this case are those like X-Jenkins-CLI2-Port  which are added inside jenkins code, not by a plugin.  

          Daniel Beck added a comment -

          It's implemented as a page decorator, which only works for successfully served pages. Hence the problem with your auth plugin not having a 200 response for /login.

          Daniel Beck added a comment - It's implemented as a page decorator, which only works for successfully served pages. Hence the problem with your auth plugin not having a 200 response for /login.

          Sorin Sbarnea added a comment -

          We are talking here about the ldap-plugin not some esoteric one and TBH I am not even sure that getting a 401 response from `/login` page is wrong. In fact that even more HTTP compliant than returning a 200 answer. 

          Somehow I have the impression that's another bug that feels between the jenkins core and its plugin. Everyone agrees thats a bug but nobody agrees which code is to blame/fix: core, ldap-plugin or sshd-plugin? ... based on the status of the ticket one could even assume that is "Not A Defect".

          Sorin Sbarnea added a comment - We are talking here about the ldap-plugin not some esoteric one and TBH I am not even sure that getting a 401 response from `/login` page is wrong. In fact that even more HTTP compliant than returning a 200 answer.  Somehow I have the impression that's another bug that feels between the jenkins core and its plugin. Everyone agrees thats a bug but nobody agrees which code is to blame/fix: core, ldap-plugin or sshd-plugin? ... based on the status of the ticket one could even assume that is "Not A Defect".

          Daniel Beck added a comment - - edited

          Weird, ci.jenkins.io also uses LDAP and returns 200 for /login (which could in theory be due to Overall/Read being granted, but local tests with internal user DB and without anon Overall/Read also return 200). Are you sure the reverse proxy isn't messing with that?

          Daniel Beck added a comment - - edited Weird, ci.jenkins.io also uses LDAP and returns 200 for /login (which could in theory be due to Overall/Read being granted, but local tests with internal user DB and without anon Overall/Read also return 200). Are you sure the reverse proxy isn't messing with that?

          Ruben Stein added a comment - - edited

          When I updated one of our machines to 2.60.2 or 2.60.3 my puppet client's CLI authentication through SSH key does not work anymore.

          root@testmaster:/var/lib/jenkins# java -jar /usr/share/jenkins/jenkins-cli.jar -s https://testmaster:8443/login -i /etc/puppet/ssl_cli/testmaster-nonuser -ssh -user testmaster-nonuser help

          returns code 255 and:

          Sep 07, 2017 5:01:13 PM hudson.cli.SSHCLI sshConnection
          WARNING: No header 'X-SSH-Endpoint' returned by Jenkins

          Regarding  a workaround I read adding that header via reverse proxy config. What to do about this if there is no reverse proxy in place? Is this really fixed like this?

          Edit: I am using the matrix-auth plugin together with active-directory to authenticate against an AD server.

          Ruben Stein added a comment - - edited When I updated one of our machines to 2.60.2 or 2.60.3 my puppet client's CLI authentication through SSH key does not work anymore. root@testmaster:/var/lib/jenkins# java -jar /usr/share/jenkins/jenkins-cli.jar -s https://testmaster:8443/login -i /etc/puppet/ssl_cli/testmaster-nonuser -ssh -user testmaster-nonuser help returns code 255 and: Sep 07, 2017 5:01:13 PM hudson.cli.SSHCLI sshConnection WARNING: No header 'X-SSH-Endpoint' returned by Jenkins Regarding  a workaround I read adding that header via reverse proxy config. What to do about this if there is no reverse proxy in place? Is this really fixed like this? Edit: I am using the matrix-auth plugin together with active-directory to authenticate against an AD server.

          Jayesh Jadhav added a comment -

          rst Can you please give me the link to the workaround you have mentioned , I am facing a similar issue .

          Jayesh Jadhav added a comment - rst Can you please give me the link to the workaround you have mentioned , I am facing a similar issue .

          Ruben Stein added a comment -

          Hey Jayesh,

          in one of the older comments (Sorin Sbarnea - 2017-08-24 15:27 comment-311573) it is mentioned that the header was manually added via an nginx in front of jenkins. He mentions that after this the cli was able to connect properly.

          Ruben Stein added a comment - Hey Jayesh, in one of the older comments (Sorin Sbarnea - 2017-08-24 15:27 comment-311573 ) it is mentioned that the header was manually added via an nginx in front of jenkins. He mentions that after this the cli was able to connect properly.

            Unassigned Unassigned
            raspy Krzysztof Malinowski
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: