Difference between pages "Kerberos With Funtoo" and "Git Guide"

(Difference between pages)
(Deployment scenatio #2: Your Funtoo box as a slave Kerberos KDC)
 
(Git config example)
 
Line 1: Line 1:
= Concepts =
+
[[File:git-logo.png]]
  
== The big picture ==
+
__TOC__
  
Kerberos is an authentication protocol originally developed at the Massachusetts Institute of Technology (part of [http://en.wikipedia.org/wiki/Project_Athena Project Athena]) and named after the three-headed guard dog who guarded the gates of Hades in the Greek mythology. ''Kerberos'' is also an historical wink to as it was first used at the MIT to guard access to the services provided the Project Athena. Kerberos was design is based on the [http://en.wikipedia.org/wiki/Needham-Schroeder_protocol Needham and Schroeder's protocol] (Xerox Research Center - 1978) and went through several revisions:
+
== Introduction ==
  
* '''1983(?)-1987''': Kerberos v1 to Kerberos v3 (never released outside the MIT)
+
<tt>Git</tt> is a distributed version control system that lets you manage from small to very large projects. You can see a <tt>Subversion</tt> comparison in the official [https://git.wiki.kernel.org/index.php/GitSvnComparison <tt>Git</tt> wiki].
* '''1987''': Design of Kerberos v4 and deployment at the MIT
+
* '''1989''': First public release of a the Kerberos v4 reference implementation
+
* '''1990''': Design of Kerberos v5
+
* '''1991''': Kerberos v5 is adopted by the [http://en.wikipedia.org/wiki/Distributed_Computing_Environment OSF/DCE]
+
* '''1992''': First large-scale deployments of Kerberos v4 outside the MIT (universities)
+
* '''1993''': Publication of the first Request For Comment that documents Kerberos v5 ([http://tools.ietf.org/html/rfc1510 RFC1510] superseded in 2005 by  http://tools.ietf.org/html/rfc4120 RFC4120]). Kerberos v4 is not documented in a RFC but had been the subject to various articles and publications.
+
* '''1996''': Publication by the MIT of the first version of the Kerberos v5 reference implementation
+
* '''2006''': Kerberos 4 reached its end of life as the DES encryption protocol it was relying on had been considered weak and insecure.  
+
  
Kerberos has now a long history behind (20+ years) and is widely used worldwide as it brings an elegant, robust and reliable answer to the classic longstanding challenge of having to authenticate and check the access credentials of something in a, by nature, insecure environment:
+
This howto will guide you through the setup process of git [http://www.github.com Github] and the usage of SSH keys to work with <tt>git</tt>. Github is a web based service to store public and private <tt>git</tt> repositories. Funtoo's portage tree and overlays are git based and stored at [https://github.com/funtoo github].
  
----
+
== Setup ==
  
''The Internet is an insecure place. Many of the protocols used in the Internet do not provide any security. Tools to "sniff" passwords off of the network are in common use by malicious hackers. Thus, applications which send an unencrypted password over the network are extremely vulnerable. Worse yet, other client/server applications rely on the client program to be "honest" about the identity of the user who is using it. Other applications rely on the client to restrict its activities to those which it is allowed to do, with no other enforcement by the server.'' -- [http://web.mit.edu/kerberos/www Massachusetts Institute of Technology].
+
=== Recommended packages ===
  
----
+
Before you start configuring <tt>git</tt> we recommend that you have installed <tt>[[keychain]]</tt> on your system to manage the SSH keys. So just type <tt>emerge -avt keychain</tt> as root.
  
Kerberos is a '''publicly documented''' network protocol that have the following benefits:
+
=== Backing up existing keys ===
  
* '''Centralized authentication''' : In the old days, networks were composed of passive terminals which were directly connected on a central time-shared  computer through a wire (implicit trust relationship). However, with the advent of personal (and now ''mobile'') computing and packet-switched networks machines can't be as considered as being as "safe" especially because the machine as not well-locked (it is not rare that a user has administrative rights and can do whatever he wants starting by installing a service that could impersonates its real identity). Worse, having a user accessing the network from several (and unsafe) devices tends to be very common and tends to complicate the task of the system administrators especially because each machine security requires to be taken care of. Kerberos has been designed from the ground up to be a centralized architecture: a single machine (known as the ''Kerberos Key Distribution Center'' or ''KDC'') holds the responsibilities of authenticating the others machines and to emit the appropriate access credentials.
+
For security reasons you will backup your existing keys in <tt>~/.ssh</tt>. It can be possible that your .ssh directory is empty, so this will just result in an error message.
* '''Security''': Kerberos relies on electronic tickets exchanges (protected from tempering by strong cryptography mechanisms) instead of sending passwords over the network, even in strong encrypted form. As Kerberos relies on asymmetric strong cryptography/digital signing,  a KDC can, per definition, be considered as a trusted third-party when a machine of the network wants to check the access credentials given to another machine of the network.
+
* '''Single sign-on (SSO)''': Kerberos tickets do not need, necessarily,  to be reissued each time a client machine want to access something. Tickets have a lifetime and thus can be reused by a client machine as long as they are not expired. Moreover, the information is '''centralized''' on the Kerberos controller and not scattered on various machines of the networks.
+
*'''Open standard''': Kerberos relies an on a set of open and publicly well documented standards.
+
*'''Cross-Platforms''': Kerberos has implementation on various platforms and operating systems. Note that Microsoft Windows has been known to have authentication issues with the MIT Kerberos reference implementation (see [http://support.microsoft.com/kb/870987/en-us?fr=1 KB870987 amongst others).  
+
  
Despite those advantages, having a centralized architecture has a drawback: if the heart of system (i.e. the Kerberos KDC) is compromised, the whole network security is compromised as well. Hence, it is always a good idea to:
+
<pre>
* Dedicate a machine to the sole usage of being a KDC
+
~ $ cd ~/.ssh
* Installs on the KDC the only minimal set of software components required to run a Kerberos server
+
~/.ssh $ install -d backup-keys
* Use SSH to open a remote administrative session (A Kerberos server can also be remotely administrated from a client machine)
+
~/.ssh $ cp * backup-keys/.
* Forbids the access to the KDC to anyone but the system/network administrators.
+
</pre>
+
Enough of those teasing paragraphs! It is time to give a first big picture of Kerberos. The best is to think about the following analogy and imagine yourself going to watch a film in a cinema:
+
# At the entrance you buy a ticket which grant the right of seeing a particular film.
+
# A cinema agent then checks your ticket authenticity/validity, tears it in two parts and indicates you the right place to go (in case of control it is easy to check if your ticket matches its other half kept by the agent) if your ticket is valid.
+
# Once you go go out of the cinema room, your ticket is considered expired preventing you to see the same film again without paying another ticket (your ticket has a a limited validity period).
+
  
Transposed to Kerberos:
+
=== Generating a SSH key ===
  
[[File:Kerberos_operations.png]]
+
Now you need to generate a new key for using with your Github account:
  
A client '''(C)''' wants to access a printing service located on a printing server '''(PS)''' :
+
<pre>
# '''C''' first contacts the Authentication Server '''(AS)'''. '''AS''' then checks the identity of '''C''' and if the authentication is successful issues a Ticket Granting Ticket '''(TGT)'''. The TGT could sent by the AS as a crypted information chuck which has to be decrypted first (via a password or a private cyphering key for example). 
+
~/.ssh $ ssh-keygen -t rsa -C your@account.com
# With the '''TGT''' in hands, ('''C''' then contacts the Ticket Granting Server '''(TGS)''' to request a grant to the printing service. '''TGS''' will check the presented '''TGT''', do additional checks (e.g. if the C is allowed to use the printing service) and will issue a ticket '''(T)''' to the requested service is everything is fine.
+
</pre>
# With '''T''' in hands, '''C''' will then contact '''PS'''. If the ticket is still valid, '''PS''' will grant to '''C''' the access to its printing service.
+
  
== Concepts definitions ==
+
Where you replace <tt>your@account.com</tt> with your e-mail account that you like to use on Github. You can use multiple SSH keys but not with the same e-mail address. If you use multiple accounts, we recommend to use your <tt>user</tt> and your <tt>hostname</tt>, for example user: <tt>funtoo</tt> on host: <tt>funtoo</tt>: <tt>ssh-keygen -t rsa -C funtoo@funtoo</tt>.
  
It is important to grab some addition concepts before diving further on the subject because you will manipulate them directly. Some of the definitions below directly comes from various places:
+
This will ask you where to save the file with a default name <tt>id_rsa</tt>. If a file exists it will not ask us to overwrite it, so save it for example as <tt>github-ssh-key</tt> or <tt>user@hostname</tt>, where you replace user with your username and hostname with your hostname. It will ask you for a password. For that <tt>git</tt>-key we stay with a password-less key, so you can easily interact with github. Anyway if you feel more comfortable with a password add it here.
  
* '''Authentication Server (AS)''': A server that issues a ticket to a client for accessing a particular service on the Kerberos realm.
+
You can see a extended explanation of this process in [[Keychain#Generating_a_Key_Pair|generating a key pair]] at <tt>Keychain</tt> wiki entry.
* '''Key Distribution Center (KDC):''' The combination of an AS and a TGS. The KDC is also known as the ''Kerberos server''. The KDC also have a database in which it stores its informations. For high availability reasons, a domain can have several KDC (one ''master'' KDC which is replicated in ''several'' slaves).
+
* '''Principal:''' ''something'' that can be given access credentials. In most cases a security principal designates a user or a computer but it can also denotes a service. A principal is an assembly of several components that forms  '''a unique identity''' on a given Kerberos realm. Those components are expressed under the form ''primary/instance@REALM'' where:
+
** '''Primary''': Identifies who the principal is (e.g. the username for a user, the service name in the case of a service)
+
** '''Instance''': Gives information that qualifies the primary. For example, in case of a host, the instance is the host FQDN. In the case of a user the instance is optional but can be used to denote, for example the role of a user if that later can endorse several ones within the Kerberos realm (e.g. jdoe/admin@FUNTOO.ORG or jdoe/user@FUNTOO.ORG).
+
** '''Realm''': See below.
+
* '''Kerberos Realm:''' A Kerberos realm is an logical partition of a network served by a single master KDC. A Keberos realm has its own principals Several Realms can co-exists, can be organized in a hierarchic manner and can establish trust relationships in between (Windows system administrators will talk about a ''Windows domain'', both notions are very close especially because the vast majority of Windows domains in the world now relies on Kerberos and not on NTLM). By convention a Kerberos realm:
+
** is expressed in capital letters
+
** is mapped on the Internet domain (eg. the DNS domain funtoo.org will give the Kerberos realm FUNTOO.ORG)
+
* '''Ticket:''' a temporary set of electronic credentials that verify the identity of a client for a particular service.
+
* '''Ticket-Granting Ticket (TGT):''' A special Kerberos ticket that permits the client to obtain additional Kerberos tickets within the same Kerberos realm. This ticket is issued in a encrypted form by the TGS using a shared secret (like a password hash for example) between the TGS and the client.
+
* '''Ticket Granting Server (TGS):''' A server that handles the request coming from a client for a TGT delivery.
+
  
= Kerberize your Funtoo =
+
=== Loading the new SSH key ===
  
== Packages related to Kerberbos in Funtoo ==
+
You have now two options to load the new ssh key for <tt>git</tt>: manually or automatically. In both cases we will use <tt>keychain</tt> to do it.
  
As of writing (april 2011), Funtoo has 3 packages related to Kerberos:
+
==== Manually ====
  
* '''app-crypt/mit-krb5''': the heart of the system (Kerberos 5 servers and utilities)
+
<pre>
* '''app-crypt/mit-krb5-appl''': ''Kerberized'' client-server applications like rcp, telnet, ftp, rsh, login
+
~/.ssh $ keychain --inherit --eval --agents ssh your-ssh-key-name
* '''sys-auth/pam_krb5''': PAM modules to integrate your machine in a Kerberos realm
+
</pre>
  
== Pre-requisites ==
+
Where <tt>your-ssh-key-name</tt> is the SSH key you generated above.
  
Kerberos requires the following to function properly:
+
==== Automatically ====
  
* All of the machines on a Kerberos a realm (including those acting as KDC) '''are required to have their time synchronized''' (Kerberos tickets are timestamped) else "strange" authentication failures will appear. A simple way to ensure this requirement is satisfied would be to deploy NTP (beyond the scope of this article, it assumed here that all of your machines already have their time synchronized with NTP).  
+
To load the keys automatically we need to edit your <tt>.bash_profile</tt> that will start a background process with the indicated ssh keys. So edit that file with your editor of choose:
* A functional direct and reverse DNS resolution (please do not use /etc/hosts replicated on each one of your machines, this is a poor practice).
+
*  Kerberos connectivity installed on '''all machines who will use Kerberos or who will act as Kerberos KDCs'''. For Funtoo and Gentoo machines this lies in the package '''app-crypt/mit-krb5'''.  
+
  
Once '''app-crypt/mit-krb5''' has been emerged, do in /etc and copy the sample configuration file '''krb5.conf.sample''' to be '''krb5.conf''' and use your favorite text editor to edit. By default this file has the following contents (notice it is divided in several sections whose names are in brackets):
 
 
<pre>
 
<pre>
[libdefaults]
+
~/.ssh $ cd ..
        default_realm = ATHENA.MIT.EDU
+
~ $ vim .bash_profile
 +
</pre>
  
[realms]
+
or
# use "kdc = ..." if realm admins haven't put SRV records into DNS
+
        ATHENA.MIT.EDU = {
+
                admin_server = KERBEROS.MIT.EDU
+
                default_domain = MIT.EDU
+
                v4_instance_convert = {
+
                        mit = mit.edu
+
                        lithium = lithium.lcs.mit.edu
+
                }
+
        }
+
        ANDREW.CMU.EDU = {
+
                admin_server = vice28.fs.andrew.cmu.edu
+
        }
+
  
[domain_realm]
+
<pre>
        .mit.edu = ATHENA.MIT.EDU
+
~/.ssh $ cd ..
        mit.edu = ATHENA.MIT.EDU
+
~ $ nano -w .bash_profile
        .media.mit.edu = MEDIA-LAB.MIT.EDU
+
</pre>
        media.mit.edu = MEDIA-LAB.MIT.EDU
+
        .ucsc.edu = CATS.UCSC.EDU
+
  
[logging]
+
And add at the bottom of the file a new line with the following content:
#      kdc = CONSOLE
+
 
 +
<pre>
 +
eval `keychain --eval --agents ssh your-ssh-key-name`
 
</pre>
 
</pre>
  
Where:
+
Where <tt>your-ssh-key-name</tt> is the SSH key you generated above. <tt>your-ssh-key-name</tt> could also be a list of keys like <tt>key1 key2 ... keyn</tt>, what would mean that keychain loads all this keys to one ssh-agent and not starting several subprocesses for it.
  
* '''libdefaults''': sets the default values for various parameters (default Kerberos realm to use, ticket lifetime, if tickets are forwardable or not, etc) used by the Kerberos library on the host (client machines, note that the Kerberos KDC is also a client to itself). Most notable parameters in this section are:
+
Exit with <tt>CTRL + X</tt> and save with yes for <tt>nano</tt> or <tt>Esc</tt> and <tt>:wq!</tt> for <tt>vim</tt>.
** '''default_realm''':  default Kerberos realm for the client.
+
** '''clockskew''': maximum allowable amount of clockskew in seconds that the library will tolerate before assuming that a Kerberos message is invalid
+
** '''forwardable''': if set,  initial tickets by default will be forwardable (initial tickets are NOT forwardable by default)
+
** '''proxiable''': if set,  initial tickets by default will be proxiable (initial tickets are NOT proxiable by default)
+
* '''realms''': tells where to find the Kerberos servers for a particular realm plus some other realm related information (e.g. which hosts endorses the role of being KDC for the realm) and information related to deal with Kerberos v4 databases. Parameters are set by Kerberos realms and most notable one  are:
+
*** '''kdc''':
+
*** '''admin_server''':
+
* '''domain_realm''': maps subdomains and domain names to Kerberos realm names.
+
* '''logging''': tells how to perform the logging
+
  
{{fancynote|Various other sections and option are detailed in the krb5.conf(5) manual page.}}
+
Now you need to reload the profile to load the key:
  
 +
<pre>
 +
~ $ source .bash_profile
  
 +
* keychain 2.7.1 ~ http://www.funtoo.org
 +
* Starting ssh-agent...
 +
* Adding 1 ssh key(s): /home/username/.ssh/your-ssh-key-name
 +
* ssh-add: Identities added: /home/username/.ssh/your-ssh-key-name
  
{{fancynote|* Kerberos realms are '''case sensitive''' (hence '''BLAHBLAH.ORG''' is not the same realm as '''BlahBlah.org''').
+
~ $
* By convention a Kerberos realm is mapped on a DNS domain }}
+
</pre>
  
= Deployment scenatio #1: Your Funtoo box as a client of a Kerberos KDC =
+
== Configuring Github ==
  
= Deployment scenatio #2: Your Funtoo box as a Kerberos KDC =
+
For using [http://www.github.com Github] we need some basic configuration:
 +
 
 +
<pre>
 +
~ $ git config --global user.name "Real Name"
 +
~ $ git config --global user.email "your@account.com"
 +
</pre>
 +
 
 +
Where <tt>Real Name</tt> will be the name displayed on commits and <tt>your@account.com</tt> the e-mail account (or user@hostname) you used to generate a SSH key for.
 +
 
 +
Next you need to add the SSH public key to Github so they can recognize your SSH key. This has to be done by their website. Login with your user or create a new one and navigate to: <tt>Account Setting > Click SSH Public Key > Click Add another public key</tt>. Add a title and the output of <tt>your-ssh-key-name.pub</tt> that you can be seen with <tt>cat ~/.ssh/our-ssh-key-name.pub</tt> and save it.
 +
 
 +
[[Image:github_guide-account_settings.jpg |frame|center|Select Account Settings]]
 +
[[Image:github_guide-add_ssh_key.jpg  |frame|center|Click on Add another public key]]
 +
[[Image:github_guide-save_key.jpg |frame|center|Save the key]]
 +
 
 +
If you have now added you first github repository you can start working with it.
 +
 
 +
=== Checking if all worked ===
 +
 
 +
Now you can check if all worked. Just run:
 +
 
 +
<pre>
 +
~ $ ssh git@github.com -i ~/.ssh/github-ssh-key
 +
The authenticity of host 'github.com (207.97.227.239)' can't be established.
 +
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
 +
Are you sure you want to continue connecting (yes/no)? yes
 +
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts.
 +
PTY allocation request failed on channel 0
 +
Hi <YOUR GITHUB USERNAME>! You've successfully authenticated, but GitHub does not provide shell access.
 +
Connection to github.com closed.
 +
</pre>
 +
 
 +
== Needed commands for git ==
 +
 
 +
<tt>clone</tt>, <tt>pull</tt>, <tt>commit</tt>, <tt>push</tt>
 +
 
 +
== Git config example ==
 +
 
 +
As a nice feature we want to help you set up git so you have a nicer view, for that we edit and/or create two files.
 +
 
 +
First edit/create the the file ~/.gitconfig
 +
 
 +
<pre>
 +
[user]
 +
    name = <Your Name>
 +
    email = <Your email for github>
 +
[github]
 +
    user = <Your github username>
 +
[color]
 +
    diff = auto
 +
    status = auto
 +
    branch = auto
 +
    grep = auto
 +
    interactive = auto
 +
    showbranch = auto
 +
[core]
 +
    editor = <Your prefered editor>
 +
[commit]
 +
    template = ~/.gitmessage.txt
 +
</pre>
 +
 
 +
Then create the following file ~/.gitmessage.txt
 +
 
 +
<pre>
 +
subject line
 +
 
 +
config description
 +
 
 +
[ticket: X]
 +
</pre>
  
= Deployment scenatio #3: Your Funtoo box as a slave Kerberos KDC =
+
If you now do a commit, you don't need to enter the complete base frame everytime on your own. Git will open your editor set in .gitconfig and show you the .gitmessage.txt where you could replace the first 5 lines with a description about what you did and why, but please never edit the lines after [ticket: X] in the upcomming window. :)

Latest revision as of 19:13, May 25, 2012

Git-logo.png

Introduction

Git is a distributed version control system that lets you manage from small to very large projects. You can see a Subversion comparison in the official Git wiki.

This howto will guide you through the setup process of git Github and the usage of SSH keys to work with git. Github is a web based service to store public and private git repositories. Funtoo's portage tree and overlays are git based and stored at github.

Setup

Recommended packages

Before you start configuring git we recommend that you have installed keychain on your system to manage the SSH keys. So just type emerge -avt keychain as root.

Backing up existing keys

For security reasons you will backup your existing keys in ~/.ssh. It can be possible that your .ssh directory is empty, so this will just result in an error message.

~ $ cd ~/.ssh
~/.ssh $ install -d backup-keys
~/.ssh $ cp * backup-keys/.

Generating a SSH key

Now you need to generate a new key for using with your Github account:

~/.ssh $ ssh-keygen -t rsa -C your@account.com

Where you replace your@account.com with your e-mail account that you like to use on Github. You can use multiple SSH keys but not with the same e-mail address. If you use multiple accounts, we recommend to use your user and your hostname, for example user: funtoo on host: funtoo: ssh-keygen -t rsa -C funtoo@funtoo.

This will ask you where to save the file with a default name id_rsa. If a file exists it will not ask us to overwrite it, so save it for example as github-ssh-key or user@hostname, where you replace user with your username and hostname with your hostname. It will ask you for a password. For that git-key we stay with a password-less key, so you can easily interact with github. Anyway if you feel more comfortable with a password add it here.

You can see a extended explanation of this process in generating a key pair at Keychain wiki entry.

Loading the new SSH key

You have now two options to load the new ssh key for git: manually or automatically. In both cases we will use keychain to do it.

Manually

~/.ssh $ keychain --inherit --eval --agents ssh your-ssh-key-name

Where your-ssh-key-name is the SSH key you generated above.

Automatically

To load the keys automatically we need to edit your .bash_profile that will start a background process with the indicated ssh keys. So edit that file with your editor of choose:

~/.ssh $ cd ..
~ $ vim .bash_profile

or

~/.ssh $ cd ..
~ $ nano -w .bash_profile

And add at the bottom of the file a new line with the following content:

eval `keychain --eval --agents ssh your-ssh-key-name`

Where your-ssh-key-name is the SSH key you generated above. your-ssh-key-name could also be a list of keys like key1 key2 ... keyn, what would mean that keychain loads all this keys to one ssh-agent and not starting several subprocesses for it.

Exit with CTRL + X and save with yes for nano or Esc and :wq! for vim.

Now you need to reload the profile to load the key:

~ $ source .bash_profile

* keychain 2.7.1 ~ http://www.funtoo.org
* Starting ssh-agent...
* Adding 1 ssh key(s): /home/username/.ssh/your-ssh-key-name
* ssh-add: Identities added: /home/username/.ssh/your-ssh-key-name

~ $

Configuring Github

For using Github we need some basic configuration:

~ $ git config --global user.name "Real Name"
~ $ git config --global user.email "your@account.com"

Where Real Name will be the name displayed on commits and your@account.com the e-mail account (or user@hostname) you used to generate a SSH key for.

Next you need to add the SSH public key to Github so they can recognize your SSH key. This has to be done by their website. Login with your user or create a new one and navigate to: Account Setting > Click SSH Public Key > Click Add another public key. Add a title and the output of your-ssh-key-name.pub that you can be seen with cat ~/.ssh/our-ssh-key-name.pub and save it.

Select Account Settings
Click on Add another public key
Save the key

If you have now added you first github repository you can start working with it.

Checking if all worked

Now you can check if all worked. Just run:

~ $ ssh git@github.com -i ~/.ssh/github-ssh-key
The authenticity of host 'github.com (207.97.227.239)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts.
PTY allocation request failed on channel 0
Hi <YOUR GITHUB USERNAME>! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

Needed commands for git

clone, pull, commit, push

Git config example

As a nice feature we want to help you set up git so you have a nicer view, for that we edit and/or create two files.

First edit/create the the file ~/.gitconfig

[user]
    name = <Your Name>
    email = <Your email for github>
[github]
    user = <Your github username>
[color]
    diff = auto
    status = auto
    branch = auto
    grep = auto
    interactive = auto
    showbranch = auto
[core]
    editor = <Your prefered editor>
[commit]
    template = ~/.gitmessage.txt

Then create the following file ~/.gitmessage.txt

subject line

config description

[ticket: X]

If you now do a commit, you don't need to enter the complete base frame everytime on your own. Git will open your editor set in .gitconfig and show you the .gitmessage.txt where you could replace the first 5 lines with a description about what you did and why, but please never edit the lines after [ticket: X] in the upcomming window. :)