Andreas Ntaflos <[email protected]> writes:
> The scenario is this: We have a Jenkins build server (build01) and an
> APT repo server (apt01, using Freight [1]). Jenkins does what it does
> and in the end creates DEB packages. Those DEB packages should land on
> the APT repo server and the APT repo should be updated with the new
> packages. This works as expected using SSH public key authentication.
> On the shell it looks like this:
> jenkins@build01:~$ scp *.deb jenkins@apt01:/path/to/packages
> jenkins@build01:~$ ssh jenkins@apt01 "/usr/local/bin/update-apt-repo"
> After that the APT repo server has the new packages, signed and ready
> for installation.
What we do for a similar case is that we put the two commands in a script,
and then create a keytab on the build server that will be used for
authentication to upload the commands. You can just use the
host/build01.example.com host key, but we usually create a special
principal for the Jenkins build service (we'd call it service/jenkins), or
if you want each build server to have a unique keytab (not a bad idea),
create a keytab like jenkins/build01.example.com.
Then, use wallet to create that keytab on the build server, and then have
your Jenkins server end its tasks by running:
k5start -qUf /path/to/keytab/file -- /path/to/upload/script
This will run the script with a Kerberos ticket cache. ssh will then be
able to use GSS-API authentication using that Kerberos ticket cache, and
once you add a .k5login file in the home directory of the jenkins user on
apt01 containing the principal you use on the build server, everything
should just work with Kerberos and no ssh public keys.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
