For Git Bash
If you are running msysgit (I am assuming you are) and are looking to run Git Bash (I recommend it over TortoiseGit, but I lean to the CLI more than GUI now), you need to figure out what your home directory is for Git Bash by starting it then type pwd
(On Windows 7, it will be something like C:\Users\phsr
I think). While you're in Git Bash, you should mkdir .ssh
.
After you have the home directory, and a .ssh
folder under that, you want to open PuTTYgen and open the key (.ppk file) you have previously created. Once your key is open, you want to select Conversions -> Export OpenSSH key
and save it to HOME\.ssh\id_rsa
. After you have the key at that location, Git Bash will recognize the key and use it.
Note: Comments indicate that this doesn't work in all cases. You may need to copy the OpenSSH key to Program Files\Git\.ssh\id_rsa
(or Program Files (x86)\Git\.ssh\id_rsa
).
For TortoiseGit
When using TortoiseGit, you need to set the SSH key via pacey's directions. You need to do that for every repository you are using TortoiseGit with.
It's the end of 2018 and I've run into the same question as you. After some digging, I can offer a write-up for posteriority.
tl; dr:
- "Infinite renewal" not possible and probably never will be
- SSSD will renew tickets if you log in using passwords
- SSSD will renew all tickets, at some point in the future
First off, you can't have "indefinitely". Kerberos tickets have a maximum renewable lifetime which is a KDC server setting, and nothing will let you renew one ticket past this time. The only thing you could do is store the users credentials and request a fresh new ticket on their behalf.
That being said, you shouldn't have to. Chances are that you are running the "System Security Services Daemon", or SSSD. If you do, you can use the builtin renewal options krb5_renew_interval
and krb5_renewable_lifetime
to renew users tickets automatically:
[domain/yourdomain.example.com]
krb5_renewable_lifetime = 90d
krb5_renew_interval = 500
You can look into man 5 sssd-krb5
for details. With these settings SSSD will ask for renewable tickets (maximum lifetime 90 days) whenever you log in* and every 500 seconds go through a list of tickets* and renew the existing tickets that are renewable.
After 90 days have passed since the original ticket, the renewal will fail and the ticket is lost. However, if you log in* in the mean time, you will get a fresh ticket from SSSD - even when you enter your password into your machines lock screen.
*) So far, so wonderful. Unfortunately, a few gotchas apply.
At the time when I am writing this, SSSD can only renew tickets that it itself requested. These are all the logins that go through the pam_sss
PAM module, for example (but not limited to):
- Typing
su $USER
on your terminal
- Logging in to your system through a graphical shell
- Unlocking the screen through a graphical shell
- Logging in through SSH using the
PasswordAuthentication
method.
Now what is notably missing from this list is:
- Running
kinit
- Logging in through SSH using the
PubkeyAuthentication
method.
- Logging in through SSH using the
GSSAPIAuthentication
method.
- Logging in through SSH, while the
GSSAPIDelegateCredentials
option is on.
Now that makes things quite awkward, and for the time being it essentially means that eitheryou force users to enter a password or that you write a ticket renewal daemon yourself. I have not found another way to make this work in the present, please anybody comment if you found a way.
This might become quite a bit easier, however.
SSSD now provides a "kerberos cache manager", a KCM that's called sssd-kcm. Basically, it's a small server that will store tickets there (KCM:
when you run klist
) instead of the Kernel keyring (KEYRING:
when you run klist
) or a file in /tmp (FILE:
when you run klist
).
At some point in the future, SSSD will hopefully be able to renew all tickets (not just the ones it requested itself) when sssd-kcm
implements ticket renewal. This has not happened yet, and is tracked in issue 1723 on the SSSD bug tracker.
If you're running a Red Hat based system (RHEL, CentOS, Fedora), then SSHD also needs to learn to respect the selected cache creation mechanism. This is tracked in issue 1639376 on the Red Hat bugtracker.
Best Answer
A
~
tilde occurring as the first character of an argument in Unix/Linux shell/bash is the same as the$HOME
environment variable. Windows equivalent is%USERPROFILE%
.You can use any user variable starting with string expanded to. Try your own from an open
cmd
window:set | find /I "%USERNAME%"
and the output looks likeHence, you could use something like the following code snippet