1GITCREDENTIALS(7) Git Manual GITCREDENTIALS(7)
2
6 gitcredentials - Providing usernames and passwords to Git
7
9 git config credential.https://example.com.username myusername
10 git config credential.helper "$helper $options"
11
13 Git will sometimes need credentials from the user in order to perform
14 operations; for example, it may need to ask for a username and password
15 in order to access a remote repository over HTTP. This manual describes
16 the mechanisms Git uses to request these credentials, as well as some
17 features to avoid inputting these credentials repeatedly.
18
20 Without any credential helpers defined, Git will try the following
21 strategies to ask the user for usernames and passwords:
22 1. If the GIT_ASKPASS environment variable is set, the program
24 specified by the variable is invoked. A suitable prompt is provided
25 to the program on the command line, and the user’s input is read
26 from its standard output.
27 2. Otherwise, if the core.askPass configuration variable is set, its
29 value is used as above.
30 3. Otherwise, if the SSH_ASKPASS environment variable is set, its
32 value is used as above.
33 4. Otherwise, the user is prompted on the terminal.
35
37 It can be cumbersome to input the same credentials over and over. Git
38 provides two methods to reduce this annoyance:
39 1. Static configuration of usernames for a given authentication
41 context.
42 2. Credential helpers to cache or store passwords, or to interact with
44 a system password wallet or keychain.
45 The first is simple and appropriate if you do not have secure storage
47 available for a password. It is generally configured by adding this to
48 your config:
49 [credential "https://example.com"]
51 username = me
52 Credential helpers, on the other hand, are external programs from which
54 Git can request both usernames and passwords; they typically interface
55 with secure storage provided by the OS or other programs.
56 To use a helper, you must first select one to use. Git currently
58 includes the following helpers:
59 cache
61 Cache credentials in memory for a short period of time. See git-
62 credential-cache(1) for details.
63 store
65 Store credentials indefinitely on disk. See git-credential-store(1)
66 for details.
67 You may also have third-party helpers installed; search for
69 credential-* in the output of git help -a, and consult the
70 documentation of individual helpers. Once you have selected a helper,
71 you can tell Git to use it by putting its name into the
72 credential.helper variable.
73 1. Find a helper.
75 $ git help -a | grep credential-
77 credential-foo
78 2. Read its description.
80 $ git help credential-foo
82 3. Tell Git to use it.
84 $ git config --global credential.helper foo
86
88 Git considers each credential to have a context defined by a URL. This
89 context is used to look up context-specific configuration, and is
90 passed to any helpers, which may use it as an index into secure
91 storage.
92 For instance, imagine we are accessing https://example.com/foo.git.
94 When Git looks into a config file to see if a section matches this
95 context, it will consider the two a match if the context is a
96 more-specific subset of the pattern in the config file. For example, if
97 you have this in your config file:
98 [credential "https://example.com"]
100 username = foo
101 then we will match: both protocols are the same, both hosts are the
103 same, and the "pattern" URL does not care about the path component at
104 all. However, this context would not match:
105 [credential "https://kernel.org"]
107 username = foo
108 because the hostnames differ. Nor would it match foo.example.com; Git
110 compares hostnames exactly, without considering whether two hosts are
111 part of the same domain. Likewise, a config entry for
112 http://example.com would not match: Git compares the protocols exactly.
113 However, you may use wildcards in the domain name and other pattern
114 matching techniques as with the http.<URL>.* options.
115 If the "pattern" URL does include a path component, then this too must
117 match exactly: the context https://example.com/bar/baz.git will match a
118 config entry for https://example.com/bar/baz.git (in addition to
119 matching the config entry for https://example.com) but will not match a
120 config entry for https://example.com/bar.
121
123 Options for a credential context can be configured either in
124 credential.* (which applies to all credentials), or credential.<URL>.*,
125 where <URL> matches the context as described above.
126 The following options are available in either location:
128 helper
130 The name of an external credential helper, and any associated
131 options. If the helper name is not an absolute path, then the
132 string git credential- is prepended. The resulting string is
133 executed by the shell (so, for example, setting this to foo
134 --option=bar will execute git credential-foo --option=bar via the
135 shell. See the manual of specific helpers for examples of their
136 use.
137 If there are multiple instances of the credential.helper
139 configuration variable, each helper will be tried in turn, and may
140 provide a username, password, or nothing. Once Git has acquired
141 both a username and a password, no more helpers will be tried.
142 If credential.helper is configured to the empty string, this resets
144 the helper list to empty (so you may override a helper set by a
145 lower-priority config file by configuring the empty-string helper,
146 followed by whatever set of helpers you would like).
147 username
149 A default username, if one is not provided in the URL.
150 useHttpPath
152 By default, Git does not consider the "path" component of an http
153 URL to be worth matching via external helpers. This means that a
154 credential stored for https://example.com/foo.git will also be used
155 for https://example.com/bar.git. If you do want to distinguish
156 these cases, set this option to true.
157
159 You can write your own custom helpers to interface with any system in
160 which you keep credentials.
161 Credential helpers are programs executed by Git to fetch or save
163 credentials from and to long-term storage (where "long-term" is simply
164 longer than a single Git process; e.g., credentials may be stored
165 in-memory for a few minutes, or indefinitely on disk).
166 Each helper is specified by a single string in the configuration
168 variable credential.helper (and others, see git-config(1)). The string
169 is transformed by Git into a command to be executed using these rules:
170 1. If the helper string begins with "!", it is considered a shell
172 snippet, and everything after the "!" becomes the command.
173 2. Otherwise, if the helper string begins with an absolute path, the
175 verbatim helper string becomes the command.
176 3. Otherwise, the string "git credential-" is prepended to the helper
178 string, and the result becomes the command.
179 The resulting command then has an "operation" argument appended to it
181 (see below for details), and the result is executed by the shell.
182 Here are some example specifications:
184 # run "git credential-foo"
186 [credential]
187 helper = foo
188 # same as above, but pass an argument to the helper
190 [credential]
191 helper = "foo --bar=baz"
192 # the arguments are parsed by the shell, so use shell
194 # quoting if necessary
195 [credential]
196 helper = "foo --bar='whitespace arg'"
197 # you can also use an absolute path, which will not use the git wrapper
199 [credential]
200 helper = "/path/to/my/helper --with-arguments"
201 # or you can specify your own shell snippet
203 [credential "https://example.com"]
204 username = your_user
205 helper = "!f() { test \"$1\" = get && echo \"password=$(cat $HOME/.secret)\"; }; f"
206 Generally speaking, rule (3) above is the simplest for users to
208 specify. Authors of credential helpers should make an effort to assist
209 their users by naming their program "git-credential-$NAME", and putting
210 it in the $PATH or $GIT_EXEC_PATH during installation, which will allow
211 a user to enable it with git config credential.helper $NAME.
212 When a helper is executed, it will have one "operation" argument
214 appended to its command line, which is one of:
215 get
217 Return a matching credential, if any exists.
218 store
220 Store the credential, if applicable to the helper.
221 erase
223 Remove a matching credential, if any, from the helper’s storage.
224 The details of the credential will be provided on the helper’s stdin
226 stream. The exact format is the same as the input/output format of the
227 git credential plumbing command (see the section INPUT/OUTPUT FORMAT in
228 git-credential(1) for a detailed specification).
229 For a get operation, the helper should produce a list of attributes on
231 stdout in the same format (see git-credential(1) for common
232 attributes). A helper is free to produce a subset, or even no values at
233 all if it has nothing useful to provide. Any provided attributes will
234 overwrite those already known about by Git’s credential subsystem.
235 While it is possible to override all attributes, well behaving helpers
237 should refrain from doing so for any attribute other than username and
238 password.
239 If a helper outputs a quit attribute with a value of true or 1, no
241 further helpers will be consulted, nor will the user be prompted (if no
242 credential has been provided, the operation will then fail).
243 Similarly, no more helpers will be consulted once both username and
245 password had been provided.
246 For a store or erase operation, the helper’s output is ignored.
248 If a helper fails to perform the requested operation or needs to notify
250 the user of a potential issue, it may write to stderr.
251 If it does not support the requested operation (e.g., a read-only
253 store), it should silently ignore the request.
254 If a helper receives any other operation, it should silently ignore the
256 request. This leaves room for future operations to be added (older
257 helpers will just ignore the new requests).
258
260 Part of the git(1) suite
261Git 2.36.1 2022-05-05 GITCREDENTIALS(7)