So I was following this tutorial to map a remote system as a network drive using sshfs. The issue is the remote system requires Kerberos authentication. So typically I have to do kinit before doing ssh user#remote but doing so before connecting through the network drive doesn't work for me. Is there any way to authenticate with Kerberos before I connect?
As far as I can see, you cannot use Kerberos with sshfs-win, because in normal mode it always waits for at least one password prompt, while in passwordless mode (sshfs.k) it always forces the authentication mechanism to 'publickey' when invoking the actual sshfs client, so there's no way to enable 'gssapi-with-mic' auth even if you do so via ~/.ssh/config.
For now I would suggest accessing the server via WinSCP; it supports Kerberos via Windows SSPI.
(On non-AD-member systems, use cmdkey /add:*.example.com /user:foo#EXAMPLE.COM /pass to store your Kerberos password in Windows Credential storage. This will allow any SSPI-based program to get tickets for the specified servers, including PuTTY, WinSCP, and even Win32-OpenSSH.)
Related
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).
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
Is there a Windows C++ API to execute a command as a different user ? I am trying to mount a CIFS share from a service which is running as sys admin and I am currently logged in as a Kiosk user so when I try to mount the share using "net use .." I get access denied.
With CreateProcessWithLogin, you can execute a command with an arbitrary user provided you have valid credentials. Alternatively, can can use a combination of LogonUser and CreateProcessAsUser / CreateProcessWithToken.
Rather than requiring credentials including a password stored as plaintext (not recommended from a security POV), you could also grant required permissions to the kiosk user so that the current user context is sufficient for accessing the data and/or mapping the network drive.
If that is not an option, your application could have a manually configured persistent network drive as a prerequisite. The credentials would then be managed by Windows.
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.