0

I want to encrypt and authenticate port 8078 on a server running Jenkins using SSH keys (I'll pass our the public or private key as needed), and keep 8078 from being accessed by anything but SSH. I have just a few developers using the machine for now.

Questions: A/ Do I need a firewall to complete this to block 8078 from non SSH access? B/ Will the decrypted request through port 22, when redirected to port 8078, be seen by a firewall? B/ What IP/port will the firewall see when the SSH server redirects the unecrypted request on port 22 to port 8078? C/ Is this a good long term solution to both encryption and authentication to a non web server application? D/ Would a VPN solution be better for this purpose?

Dennis
  • 163
  • 1
  • 6

1 Answers1

1

A) Once an SSH server listens on 8078 on the server, no other application can, Jenkins included. B) I get confused: SSH does not redirect unencrypted requests. C) I assume you want to do the following:

  1. Configure Jenkins to run on Port 8078, unencrypted, but on the localhost IP 127.0.0.1. No firewall needed, as no one from outside can connect that IP. Only if Jenkins cannot be configured to bind to 127.0.0.1, you need a firewall.
  2. Create a special user account with a custom shell that acts as a telnet client to 127.0.0.1:8078. You can do so with a very simple bash script. Authorize all public keys to use that account.
  3. Connect to SSH at port 22 as usual with the special user. The connection will open the special telnet shell.

Script would look like this:

#! /bin/bash
telnet localhost 8078

Save in /usr/local/bin/jenkins-ssh and

chmod a+x /usr/local/bin/jenkins-ssh
useradd jenkins-ssh
passwd jenkins-ssh (or don't, use pubkey only)
chsh jenkins-ssh -s /usr/local/bin/jenkins-ssh

D) A VPN solution would be superior in that it can be used for more than one service. But you'd have to bind the service to an internal IP which may become available only after starting the VPN service, thus complicating startup sequence.

korkman
  • 1,657
  • 2
  • 13
  • 26
  • Internal IP? Is that a localhost IP 127.0.0.X, or one on the local network? Otherwise I really like your suggestions, thank you. – Dennis Oct 31 '11 at 13:23
  • VPNs like openvpn (which is quite good and versatile) work with non-public subnets like 192.168.x.x or 10.x.x.x. You'd configure your VPN server to serve a subnet like 10.11.12.0/24 and have 10.11.12.1 assigned to the server. Jenkins would then bind to 10.11.12.1. When you login with VPN client, you get another IP, like 10.11.12.5, and any connection to 10.11.12.1 would route through the VPN tunnel. – korkman Nov 01 '11 at 23:09
  • And then there's IPSec which can indeed encrypt traffic between public IPs, but that's hard to configure and maintain. Plus it doesn't play nice with todays common NAT gateways (read: DSL routers). Don't touch it. – korkman Nov 01 '11 at 23:15