Does anyone know if git is being used in a military CAC enabled environment? This means that the DoD CAC card is required to authenticate when hitting the git transfer protocol. This is a requirement before I can propose using git. I understand that git is able to use https as well as ssh or over port 9418. Is there any documentation on setting up CAC enabled git protocols? Brian P. Jones Senior Software Engineer
threads / discuss / 29929
CAC enabled authentication with git transfer protocols
Subject: CAC enabled authentication with git transfer protocols
Shawn PearceRe: CAC enabled authentication with git transfer protocols
On Mon, Mar 12, 2012 at 17:54, Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600 <brian.p.jones4.ctr@navy.mil> wrote:
> Does anyone know if git is being used in a military CAC enabled environment? This means that the DoD CAC card is required to authenticate when hitting the git transfer protocol. This is a requirement before I can propose using git. I understand that git is able to use https as well as ssh or over port 9418. Is there any documentation on setting up CAC enabled git protocols?
The git:// protocol on port 9418 has no authentication. It won't meet your requirements.
For Git over ssh://, Git just relies on the SSH client and server binaries installed on the system. You would have to find out if these binaries meet your requirements. If they do, you may just be able to use SSH.
Git 1.7.9 and later on https:// can use a credential helper binary to obtain the user's "password" string. A credential helper is an external program Git calls to help it authenticate over HTTP using either HTTP basic or HTTP digest authentication. It may be possible to write a git-credential-dodcac binary that does the magic required. Install this binary in the user's $PATH, have them enable it with a `git config --global credential.helper dodcac` configuration setting, and away they go.
If a DoD CAC is like a one time password scheme, it may be possible to have the user's "password" over HTTP actually be $password:$onetimepad or some such format, and then use a custom authentication system on the server to decode this string and verify it.
Internally at $DAYJOB we use a custom git-credential-$DAYJOB binary to acquire a unique token that identifies the caller and pass this to the server over HTTPS. The HTTP server in turn verifies this string with the authentication system. Its not really their password, its just a mutually agreed upon blob that was passed around between the client workstation and the server.
Chris KeesRe: CAC enabled authentication with git transfer protocols
On Mon, Mar 12, 2012 at 8:53 PM, Shawn Pearce <spearce@spearce.org> wrote:
Show 13 quoted lines
> On Mon, Mar 12, 2012 at 17:54, Jones, Brian P CTR > SPAWARSYSCEN-PACIFIC, 63600 <brian.p.jones4.ctr@navy.mil> wrote: >> Does anyone know if git is being used in a military CAC enabled environment? This means that the DoD CAC card is required to authenticate when hitting the git transfer protocol. This is a requirement before I can propose using git. I understand that git is able to use https as well as ssh or over port 9418. Is there any documentation on setting up CAC enabled git protocols? > > The git:// protocol on port 9418 has no authentication. It won't meet > your requirements. > > > For Git over ssh://, Git just relies on the SSH client and server > binaries installed on the system. You would have to find out if these > binaries meet your requirements. If they do, you may just be able to > use SSH. >
It seems like ssh might be the best shot. Kerberised ssh servers and clients can already be set up so that they use a CaC for authentication.
Show 25 quoted lines
> > Git 1.7.9 and later on https:// can use a credential helper binary to > obtain the user's "password" string. A credential helper is an > external program Git calls to help it authenticate over HTTP using > either HTTP basic or HTTP digest authentication. It may be possible to > write a git-credential-dodcac binary that does the magic required. > Install this binary in the user's $PATH, have them enable it with a > `git config --global credential.helper dodcac` configuration setting, > and away they go. > > If a DoD CAC is like a one time password scheme, it may be possible to > have the user's "password" over HTTP actually be $password:$onetimepad > or some such format, and then use a custom authentication system on > the server to decode this string and verify it. > > Internally at $DAYJOB we use a custom git-credential-$DAYJOB binary to > acquire a unique token that identifies the caller and pass this to the > server over HTTPS. The HTTP server in turn verifies this string with > the authentication system. Its not really their password, its just a > mutually agreed upon blob that was passed around between the client > workstation and the server. > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html