Starting in the upcoming Jenkins 1.446, Jenkins speaks the server-side of the SSH protocol. I think this is exciting, and here is why.
For quite some time now, there is Jenkins CLI, which lets you access Jenkins from command line by using a custom client jar file. There are several dozen commands available (that you can check by visiting http://server/jenkins/cli), ranging from creating a job to shutting down Jenkins. These CLIs are often a lot more scriptable than HTTP interfaces, and so it is often used by other programs to interact with Jenkins.
Jenkins 1.446 exposes a large subset of these commands through SSH, making it even easier to access this functionality. You no longer need any special client jar nor Java VM to talk to Jenkins. All you need is a stock ssh client. As I explained earlier, Jenkins lets you register your SSH public keys, and that is how you authenticate.
As always, the server side of this is extensible. Plugins can define additional commands to be exposed via SSH, which is a great building block for more sophisticated integrations. This is particularly so because SSH is a standard transport protocol for many tools, such as Git, Subversion, and so on. I’m planning to write a few plugins that take advantage of this in the coming days.
Wiki article talks more about the details, including how you can discover the endpoint, how you can verify the server key, and so on.
(And no, this is not about making Jenkins a general-purpose SSH server that you can use to login to the server.)
8 Comments Add yours
Jenkins website http://jenkins-ci.org/ is unreachable. It looks like there is a DNS issue…
This seems like a _very_ bad idea. I’m having a hard time understanding why it’s enabled by default, and access to the CLI is allowed without auth.
Even if you can’t run commands, you can create a new job (and exec commands) or install a plugin from URL (and exec commands). This is screaming for exploitation.
But you can do all those without this addition if your instance isn’t secured…
Understood. I’d still rather see this disabled by default, seems dangerous to pop up a new service – what if users only firewalled :8080 or have placed another form of authentication (.htaccess) in front of the normal web frontend?
This service really shouldn’t be enabled by default (SSH or even CLI). As an option it sounds very powerful but shouldn’t be present on every installation. The appearance of an SSH server can cause problems with security programs and it really is a feature that the user should have to deliberately add as a plugin or enable. We are currently stuck using releases prior to .446 because the Jenkins SSH server is throwing errors on startup.
I can’t understand all the negativity in this comments.
Jenkins comes with everything open by default, and it is the admin’s task to secure it.
This service is actually improving the security strongly, since it is the safest way to automate any communication between an external host and jenkins, using a properly password-protected ssh key pair.
A big thank you for your work in Jenkins, Kohsuke!!