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
On Mon, Mar 12, 2012 at 17:54, Jones, Brian P CTR
SPAWARSYSCEN-PACIFIC, 63600 [off-list ref] 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.
On Mon, Mar 12, 2012 at 8:53 PM, Shawn Pearce [off-list ref] wrote:
On Mon, Mar 12, 2012 at 17:54, Jones, Brian P CTR
SPAWARSYSCEN-PACIFIC, 63600 [off-list ref] wrote:
quoted
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.
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