Jenkins acts as an SSH server, starting 1.446. This exposes a subset of Jenkins CLI commands (those that do not need any intelligence on the client side.) Plugins may also add additional capabilities through SSH server.
By default, Jenkins will listen on a random available port, so as not to break existing deployments. But this is most likely not very useful, so the administrator is encouraged to change this from the system configuration page by assigning a fixed port. This configuration UI will also allow you to disable this feature.
On secured Jenkins, you register your public keys to Jenkins. See "working with credentials" in Jenkins CLI for more details, and this is how you log in. On unsecured Jenkins, there's no authentication performed.
Use the "who-am-i" command to verify who you are logging in as:
Both provide access to a set of commands that lets you interact with Jenkins from a command line, but they have a few differences:
A part of the SSH protocol involves in verifying that you are talking to the real Jenkins server, instead of a fake inserted by an attacker (otherwise known as the man-in-the-middle attack.) Instance Identity is used as the server key.
Combined with HTTPS, this provides a trusted path to establish a secure connection from a client over an untrusted network.
Programs who wish to discover the SSH endpoint of Jenkins can do so by doing GET access on the Jenkins top page and look for the "X-SSH-Endpoint" HTTP header in the response. This header has the value formatted as HOST:PORT that indicates where the SSH server is listening. This header is present even if the request itself fails (for example, due to access denied.)
The host portion of the header is inferred automatically from the configured root URL, but administrators can override this value by setting the org.jenkinsci.main.modules.sshd.SSHD.hostName system property. This is convenient if you run your Jenkins behind a reverse proxy and you need to route the SSH traffic differently.
Skip to end of metadata Go to start of metadata