I'm using git over ssh on a remote machine that is running Windows 10. When I try to do a git pull, I get the error message in the title after entering my credentials.
Fixed by installing the latest version of git credential manager on chocolatey (not sure if this is necessary) and switching my git credential store to dpapi.
See https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md#dpapi-protected-files for instructions on how to do so.
This could be illustrated by GitCredentialManager/git-credential-manager issue 325
The error you're seeing is related to the way that Windows handles "logon sessions" and "credential sets".
GCM Core uses the Windows Credential Manager (wincred.h) to store credentials safely on Windows.
We interact with wincred via the Windows APIs: CredRead, CredWrite, CredDelete, and CredEnumerate.
The error being returned in your case here is ERROR_NO_SUCH_LOGON_SESSION (0x520) which means:
The logon session does not exist or there is no credential set associated with this logon session.
Network logon sessions do not have an associated credential set.
The key part here is in bold.
When you connect via SSH, the sshd daemon/Windows service is running as the NT AUTHORITY\NETWORK SERVICE account (most likely/by default), which creates network logon sessions when an SSH client connects.
From some searching online, one workaround posted is to change the account that sshd runs as to be your real user, which would then have an associated credential set. Your milage may vary here depending on setup.
If you try to use the built-in cmdkey command for interacting credentials stores in the Windows Credential Manager, you'll see similar errors or messages like "saved for this login only".
Upgrading to the latest version of GCM comes with:
With the latest GCM Core release (v2.0.567) there is support on Windows to use a different credential store other than the Windows Credential Manager that shouldn't have the same remote-session limitations.
You can read more about the different options here: https://aka.ms/gcmcore-credstores
The specific store that may help this SSH scenario is the DPAPI-protected file store.
Credentials are protected using Windows DPAPI encryption (based on your current user account) and are written to files on disk (configurable; defaults to %USERPROFILE%\.gcm\dpapi_store).
Related
I'm using WSL in an exclusively windows environment because of a number of tools that are only really available for Linux. I often connect to DBs programmatically and would like to be able to do that without specifying my login information. For example in Python through Windows I could do this:
import pymssql
con = pymssql.connect(server, port)
And that connection would go through without my having to specify any credentials because my AD account has access to the server, and pymssql will use windows auth when no credentials are specified.
In python running on WSL however that doesn't work, and so to make the same connection I would have to additionally pass the user and password parameters.
Is there any way to make WSL inherit windows authentication when running Linux processes?
I got you Fam!
Here is the solution : http://michaeljw.com/blog/post/keyring-r-python-windows/
Here is the Sauce:
Use the Windows Credential Manager to store the creds you want to use
https://support.microsoft.com/en-us/windows/accessing-credential-manager-1b5c916a-6a16-889f-8581-fc16e8165ac0
Here is the command for accessing the credential manager in Python:
keyring.get_password(u"[Domain or URI]", u"[username]")
As long as the user is in the cred manager, you should be able to use that command to variablize creds. You will probably have to play with it a bit to get it right, but it will work. Be sure to read the linked articles.
Enjoy
I developed an Intranet application which needs to realize a "git push" from a local repository (on the disk of the web server) to a remote repository.
I launch the git process from the web server, it runs under the IIS pool identity which is a domain account member of the administrators group of the web server machine.
Git needs the user credentials to perform the push action. I integrated a custom version of git-credential-winstore. This program uses the Windows Credential Manager to store generic credentials for a web site. But when the call to the credential's write occurs, I get the error :
Failed to write credential: A specified logon session does not exist. It may already have been terminated
I checked the policy "Network access: Do not allow storage of passwords and credentials for network authentication", it is disabled.
What goes wrong here ?
Pool account needs to gain access to its user profile.
So we need to connect one time to a Windows Session to create user profile (I think it's necessary). Next in the Advanced Settings of the dedicated Application Pool, set "Load User Profile" = true.
Note about credentials : Windows credential target must be changed to manage different users in the same Windows vault. I change "git:https://remote-host" by "git_USERID:https://remote-host".
I set this property to enabled and it works now, maybe it will work for you also:
We use a VisualSVN Server (Windows) server at work. It uses a https:// connection with a SSL certificate. On our Windows (7 and 8) workstation machines we use TortoiseSVN to connect. On Windows I couldn't get a connection to this SVN server (at first) using a regular SVN username and password, got SVN auth error:
Error during context: An error occurred during authentication
On Windows we got it working
So we figured out we need to supply a (Windows) credential to this domain name. Like suggested on this website:
http://tigris-scm.10930.n7.nabble.com/Issue-with-basic-authentication-td95075.html
On Windows we opened Control Panel > Credential Manager and added a new Windows credential to a network address (website): URL of our SVN server and a (domain) username (which is the SVN username) and my password.
Now this worked on our Windows workstations, we can connect to the SVN server with a supplied (Windows) credentials (supplied in Windows Credential Manager).
On Mac (not yet)
In Cornerstone we get a similar error:
Error running context: The requested authentication type(s) are not supported
Now we need this to work on our (Maverick) Mac's in Cornerstone (Mac SVN client). I've searched the net and found various articles, even on Zennaware's (Cornerstone) own support site explaining how to add the certificate to the SVN connection within Cornerstone:
http://zennaware.com/cornerstone/helpbook/pages/getting-started/client-certificates.html
But the above on Mac is 'step 2' ... I need a way to (like on Windows) to first create the credentials (step 1).
Now I know it must be done in Mac's KeyChain Access program. In this KeyChain Access program I tried to generate a certificate using the Certificate Assistant. But I'm unable to generate certificate for an internet address (our svn server) and provide my own username and password for this SVN server.
I've played around with OpenSSL on the command-line to somehow 'save' the SSL certificate from our SVN server (for import into KeyChain Access program), but I can't provide my username and password.
Cornerstone SVN Mac client needs a certificate (from KeyChain Access) with a public and private key. Like you see in their screenshots on their support site.
On Mac; how do I (generate?) the certificate or credentials (like on Windows Credential Manager) for a specific SVN server address and providing my own SVN username and password?
It's completely unrelated to client-side certificates / HTTPS at all.
On Windows machines that are in the same AD domain as VisualSVN Server, you can authenticate without any additional actions (via Integrated Windows Authentication / Single Sign-On).
If you are not in the same AD domain as VisualSVN Server or you need to authenticate under another AD user account, you must use Windows Credential Manager to specify user account's credentials. (lol, it looks like that my support instruction helped on the mailing list).
No certificate setup is required on OSX machines. The instruction on Zennaware's website is irrelevant to VisualSVN Server. You have to either join the OSX machine to your AD domain and login under the AD domain user account or enter domain credentials to some OSX password store (unfortunately I'm not really familiar with OSX so no step-by-step instruction here).
The other way to login from OSX machine is to enable Basic Windows authentication on VisualSVN Server and enter user account's credentials when you attempt to access a repository hosted on VisualSVN Server.
BTW, make sure to run the latest available Subversion client on OSX.
We already had a secured VPN using OpenVPN, so we don't want to use Git with SSH to avoid double encryption.
I successfully set up Bonobo Git Server on IIS 7 on Windows 2008 RC2 and created an repository. But when I tried to clone that repository from my laptop using Git GUI, it kept asking me username and password repetitively although I gave it the correct username and password created on Bonobo Server.
When I intentionally gave it incorrect credentials, it threw an expected authentication error.
Do you have any advice for me so I can connect to Git Server? Is it due to the lack of SSH keys?
As far as I can see, Bonobo offers three different authentication mechanisms: Forms, Basic, and Windows authentication. None of these involve SSH, so no, you are not using SSH and you don’t need SSH keys to make this work. SSH is just one mechanism that is commonly used for Git servers (simply because they run on Linux machines, and SSH access is very common there).
Bonobo uses the forms authentication by default. I believe you cannot preset the login information anywhere so you don’t have to enter it over and over again. You can do that with basic authentication though by changing the remote URL to include the credentials (e.g. http://user:password#bonobo-server/project.git). Of course, this will put the credentials in clear text into the repository’s configuration file, and also send the password in clear text over the network. The VPN connection will prevent someone outside of the VPN connection reading out that password, but inside of the VPN connection it is sent as clear text, so keep that in mind.
The more secure way would be Windows authentication. It uses your Windows login to authenticate at the server, and you won’t need to store your password somewhere. To Windows, it’s the “natural” authentication system, just like SSH is to Linux.
I was successful with poke's suggestion in his comment, which is utilizing a shared folder pointing to a remote bare repository.
Since version 5.50 the Bitvise SSH Server allows connected client to authenticate to Windows user account without providing this user's Windows password. See here: https://www.bitvise.com/ssh-server-version-history
I've checked it myself - it does indeed.
My question is of pure curiosity: what kind of sorcery is this? Is there any WinAPI that allows such thing or is this some kind of clever hack? I always thought it is impossible to impersonate as other user without a password (as even when configuring Windows service or scheduled task to "run as user" it is neccessary to provide one).
IIRC, the SSH server in Cygwin does the same thing.
If you have the appropriate privileges you can create an access token with ZwCreateToken, no password required. Such a token has some limitations. For example, you can't access network resources without a password and some encrypted material isn't accessible.
There's an explanation and some sample code here.
Since version 5.50, Bitvise SSH Server comes with a Windows authentication package. An authentication package can enhance the Windows logon process in custom ways. When the SSH server needs to log you in, but does not have a password (e.g. because you logged in with a public key), it calls the authentication package to construct a logon token which closely resembles the logon token that would have been created by Windows. As arx has noted, a session created this way does not contain your authentication credentials, so side effects are that you can't access things like network resources and EFS.