Can't start SSH Agent with Git Bash on Windows 10 - windows

I have executed the following command in Git Bash, and it returns the following error.
$ eval $(ssh-agent -s)
1 [main] ssh-agent 1564 child_info_fork::abort: \??\C:\Program Files\Git\usr\bin\msys-
crypto-1.1.dll: Loaded to different address: parent(0x8A0000) != child(0x910000)
fork: Resource temporarily available
I have also tried restarting my system, that doesn't do any good.
Any Ideas what this issue is all about, or how to fix it, if possible?
Thanks in advance! 😉👍

Make sure first in a CMD session to:
upgrade to the latest Git for Windows
the PATH correctly set to Git, for testing.
That is:
set GH=C:\path\to\git
set PATH=C:\windows\system32;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\
set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%GH%\mingw64\libexec\git-core;%PATH%
Then, in that same CMD session, type git bash and try again

Related

Why can I not use the command history in minikube ssh

I have a minikube K8s 1 node cluster on my Windows 10 pc. I can SSH into this cluster using minikube ssh.
The problem that I am experiencing is that I can't use the arrow keys to bring back the previous command. I did some looking around and diagnostics:
set -o | grep history gave history on
echo $HISTFILE gave /home/docker/.bash_history. This is indeed in the home folder of the user and the file was present after exiting and executing minikube ssh again
echo $HISTSIZE and echo $HISTFILESIZE both gave 500
echo $SHELL gave /bin/bash
All these things tell me that command history should be enabled, but it doesn't seem to be the case.
I tried using both Powershell and cmd to run minikube ssh, both with and without Windows Terminal.
Both PowerShell and cmd themselves have a working command history, but once SSHing using minikube, the history in the bash shell doesn't work.
Does anyone know how to get the command history to work after executing minikube shh?
Edit:
I have tried minikube ssh --native-ssh=false, but this didn't change anything.
It seems to be a problem with the SSH client you are using. You can try with the --native-ssh=false option:
minikube ssh --native-ssh=false
You can also try with different alternatives or with something like the ssh version that comes with Cygwin.
There is already an unsolved issue related to this. (Feel free to update)
✌️

How can I run git commands on Windows with SSH verbose mode?

This is the Windows version of How can I run git push/pull commands with SSH verbose mode?
There are times where you just need to debug git's usage of SSH.
OpenSSH has a -v flag for verbose output, but how do you get git to use it?
How can I run git commands on Windows with SSH verbose mode?
If your PATH is correctly set:
you don't need OpenSSH-Win64 (ssh is already included in Git)
you don't need to specify the full path for SSH
You need:
set GH=C:\path\to\git
set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%PATH%
Then
set GIT_SSH_COMMAND=ssh -vvv
You can force git to provide verbose ssh output with the "GIT_SSH_COMMAND" environment variable.
For example, to get verbose output from OpenSSH-For-Windows for a git clone command, just open a command prompt and enter
set GIT_SSH_COMMAND="C:\Program Files\OpenSSH-Win64\ssh.exe" -vvv
git clone <repo_ssh_url>
Note the location of the quotation marks.

Docker unable to start an interactive shell if the image has an entry script

My custom-made image ends with
ENTRYPOINT [ "/bin/bash", "-c", "/home/tool/entry_script.sh" ]
This is absolutely needed because at runtime, the first thing the user must do is to update an already cloned github project, and users will often forget to do it.
But then, when i try to launch using
docker run -it --rm my_image /bin/bash
i can see that the ENTRYPOINT script is being executed, but then the container exit.
I expect to have /bin/bash being executed and the shell to remain in interactive mode, due to -it flags.
What am I doing wrong?
UPDATE: I add my entry script
#!/bin/bash
echo "UPDATING GIT REPO";
cd /home/tool/cloned_github_tools_root
git pull
git submodule init
git submodule update
echo "Entrypoint ended";
Actually I've not kind of errors at runtime
When you set and entry point in a docker container. It is the only thing it will run. It's the one and only process that matters (PID 1). Once your entry_point.sh script finishes running and returns and exit code, docker thinks the container has done what it needed to do and exits, since the only process inside it exits.
If you want to launch a shell inside the container, you can modify your entry point script like so:
#!/bin/bash
echo "UPDATING GIT REPO";
cd /home/tool/cloned_github_tools_root
git pull
git submodule init
git submodule update
echo "Entrypoint ended";
/bin/bash "$#"
This starts a shell after the repo update has been done. The container will now exit when the user quits the shell.
The -i and -t flags will make sure the session gives you an stdin/stdout and will allocate a psuedo-tty for you, but they will not automatically run bash for you. Some containers don't even have bash in them.
I think the original question and answer are pretty good (thank you!). However I had the same exact problem but the provided solution did not work for me. I ended up wasting a lot of time figuring out what I was doing wrong. Hence I came up with a solution that should work all the time, if this could save time for others. In my docker entry point I'm sourcing a shell script file from Intel compiler and the received parameters $# are somewhat changed by the 'source' command. Then when ending the script with /bin/bash "$#" the original parameters are gone. Here is my updated version that would be safer for all use cases:
#!/bin/bash
# Save original parameters
allparams=("$#")
echo "UPDATING GIT REPO";
cd /home/tool/cloned_github_tools_root
git pull
git submodule init
git submodule update
echo "Entrypoint ended";
# Forward initial parameters
/bin/bash "${allparams[#]}"

I changed /etc/passwd to git-shell and changed it back, but now shell not working

I was following the instruction on how to set up a git server here, and I removed the ssh access from the git user by setting /etc/passwd file to /usr/bin/git-shell.
Later I found out that I still want to ssh as git, so I reset it back to /bin/sh. I could ssh back, but the shell prompt looked all strange today. Previously, the prompt was
git#xyz.com $
but now it's just
$
Tab Autocomplete is gone. History is also gone. I am not sure what files got removed when I switched to git-shell. How do I recover from this?
chsh git -s /bin/bash should fix it (I prefer to use the chsh program instead of editing /etc/passwd by hand to change an account's login shell)
Maybe it was not /bin/sh before, try setting it as
/bin/bash

sbt (Scala) via SSH results in command not found, but works if I do it myself

So I'm trying to do something that involves running sbt over an SSH command, and this is what I'm trying:
ssh my_username#<server ip> "cd <project folder>; sbt 'run-main Foo' "
When I do that however, I get an error message: bash: sbt: command not found
Then I go SSH into the server myself, cd to the project folder, and run sbt 'run-main Foo' and everything works nicely. I have checked to make sure sbt is on the $PATH variable on the remote server via ssh my_username#<server ip> "echo $PATH" and it shows the correct value.
I feel like this is a simple fix, but cannot figure it out... help?
Thanks!
-kstruct
When you log in, bash is run as an interactive shell. When you run commands directly through ssh, bash is run as a non-interactive shell, and therefore different initialization files are sourced (see the bash manual pages for which exactly). There are a number of ways to fix this, e.g.:
Use the full path to sbt when calling it directly through ssh
Edit .bashrc and add the missing directories to the PATH environment variable
Note that your test ssh my_username#<server ip> "echo $PATH" actually prints PATH on your client, not your server, because of the double quotes. Use ssh my_username#<server ip> 'echo $PATH' or ssh my_username#<server ip> env to print PATH from the server's environment. When checking using env, you will see that PS1 is only set in interactive shells.

Resources