I have create private/publich key pair by ssh-keygen command line.
I have already paste the content of ~/.ssh/id_ed25519.pub to github account
I have already manually start ssh-agent and add the private key by followinng command lines:
3.1 $ eval "$(ssh-agent -s)"
3.2 $ ssh-add ~/.ssh/id_ed25519
so I can use git clone and other git command lines without user/passworld
after reboot the linux system, I found no ssh-agent process but I can still use git command line to interact with github aacount. WHY? I see lot of article saying that you must start ssh-agent ervery time or automatically start ssh-agent. confusing...
would you please help to explan the reason.
the OS of my linux server is Centos stream 9.
If you don't have a passphrase on your private key, ssh-agent is not necessary. –
1615903
Feb 14, 2017 at 6:36
Related
I'm reading these docs on sharing SSH keys with a dev container, but I can't get it to work.
My setup is as follows:
Windows 10 with Docker Desktop 4.2.0 using the WSL2 backend
A WSL2 distro running Ubuntu 20.04
In WSL2, I have ssh-agent running and aware of my key:
λ ssh-add -l
4096 SHA256:wDqVYQshQBCG/Sri/bsgjEaUFboQDUO/9FJqhFMncdk /home/taschan/.ssh/id_rsa (RSA)
The docs say
the extension will automatically forward your local SSH agent if one is running
But if I do ssh-add -l in the devcontainer, it responds with Could not open a connection to your authentication agent.; and of course starting one (with eval "$(ssh-agent -s)") only starts one that doesn't know of my private key.
What am I missing?
I had basically the same issue. Running Windows 11 with WSL2 and my VSCode Devcontainer wouldn't show any ssh keys (running ssh-add -l inside the container showed an empty list) despite having Git configured on my host machine with working ssh keys.
For me, there were 3 separate instances of ssh-agent on my machine:
WSL2
Git Bash
Windows host 🠆 This is the one VSCode is forwarding to the devcontainer
My existing ssh keys were set up inside Git Bash (as per Github's instructions) so running ssh-add -l only ever showed my ssh keys from inside a Git Bash terminal, nowhere else.
However, as explained in the previous answer, digging through the Devcontainer startup logs shows that VSCode is forwarding only the host machine's ssh-agent, it doesn't look at the WSL2 or Git Bash ones.
Solution: I suggest following the below Microsoft docs page. You need to enable an "Optional Feature" in Windows, then run a few commands in PowerShell (as admin) to activate the ssh-agent service. With this set up, the ssh-agent/ssh-add commands will work from a regular CMD terminal too.
You can use these with the usual keygen commands etc to generate and add new keys on the host (I just ssh-add'ed the same keys generated by Git Bash originally). The added keys should immediately be detected by ssh-add -l inside the container.
https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement
I tried many things but did not work. Finally after devcontainer is created , I note down the container name and copy the id_rsa and id_rsa.pub key inside container using docker cp command.
syntax:
docker cp <sourcefile> container_id:/dir
Copy both private and public key:
docker cp /root/.ssh/id_ed25519 eloquent_ritchie:/root/.ssh/
docker cp /root/.ssh/id_ed25519.pub eloquent_ritchie:/root/.ssh/
change the permission of private key so that you can do git operations
docker exec eloquent_ritchie chmod 600 /root/.ssh/id_ed25519
eloquent_ritchie is sample container name. Your container name will differ. Use your container name
Then I was able to do Git operations inside devcontainer.
If you rebuild your container again you need to copy the file to devcontainer again.
I also had quite a lot of trouble to get this to work. The following steps might help troubleshooting:
Check that ssh-agent is running on your host and the key is added
Run ssh-agent -l on Windows and expect to see the name of your key
Check that VSCode forwards the socket
Search ssh-agent in the startup log. I had the message
ssh-agent: SSH_AUTH_SOCK in container (/tmp/vscode-ssh-auth-a56c4b60c939c778f2998dee2a6bbe12285db2ad.sock) forwarded to local host (\\.\pipe\openssh-ssh-agent).
So it seems that VSCode is directly forwarding the Windows SSH agent here (and not an SSH agent running in your WSL).
Summary:
As I'm integrating CI to the development workflow, I'm also trying to move the executions of Bitrise workflows to our local iOS Mac Computer which is setup as a Jenkins slave.
The projects that I'm trying to build therefore needs to be built on this iOS Computer.
Problem:
I'm trying to establish an ssh connection to an integration user (a GitHub account that has access to my repositories) and I have created a key and added it to the GitHub user as well as to the .bitrise.secrets.yml file.
But when the initial step, the activate-ssh-key step is executed, it results with an error that I can't add the SSH key to the ssh-agent with empty passphrase. (Is this somehow configurable? Can I just evade this?)
Here is the output log:
https://pastebin.com/FCHhZNDb
Step in bitrise.yml:
- activate-ssh-key#4.0.2: {getenv "SSH_RSA_PRIVATE_KEY"}
.bitrise.secrets.yml:
envs:
- SSH_RSA_PRIVATE_KEY: ssh-rsa *KEY*
|------------------------------------|
I have also tried putting the ssh key directly in the .ssh directory which did not work.
Any help is really appreciated! :)
TL;DR
Trying to connect bitrise cli with github via ssh, doesn't work.
The SSH key you used seem to be protected with a passphrase. You should generate one that does not require a passphrase to be specified, and register that for the repository.
How to generate such an SSH key: https://devcenter.bitrise.io/faq/how-to-generate-ssh-keypair/
ssh-keygen -t rsa -b 4096 -P '' -f ./bitrise-ssh -m PEM
Alternatively you can replace the Activate SSH Key step with a script one and activate the SSH key any way you like.
Or if you prefer to not to use SSH keys you could switch to using https:// git clone urls (instead of the SSH / git# one) and replace the Activate SSH Key step with the Authenticate with GitHub OAuth one (https://www.bitrise.io/integrations/steps/authenticate-with-github-oauth).
I need to pull a github repository on my cloud server using a script from web. I created a php script to access a shell script file.
There are 4 commands that I use when I do a pull:
sudo su
eval $(ssh-agent)
ssh-add
git pull repository master
The problem is when the script does the ssh-add I have to type a password, how can I type a password in a shell script?
I would use keychain instead of ssh-agent and ssh-add -- keychain will start an ssh-agent if necessary, or use the existing ssh-agent. So with keychain, you only type in your passphrase at the start of your session when keychain is starting an ssh-agent.
I use keychain from my .bash_profile like:
eval `keychain --eval id_rsa`
Here is my setup:
Jenkins is running on my linux machine as 'jenkins' user.
I have generated a ssh key-pair as described in Linux - Setup Git, for the 'jenkins' user.
When I sudo su jenkins and try ssh -vT git#github.com, I am always asked my passphrase, but I am always eventually authenicated. (the verbose option shows which key is used, among others).
I could clone my repo from GitHub using jenkins:
Thusly:
jenkins#alpm:~/jobs/test git/workspace$ git pull
Enter passphrase for key '/var/lib/jenkins/.ssh/id*_rsa':
Already up-to-date.
Up to this point I have followed the instructions to the letter. The problem is that the Jenkins job fails with the following error:
status code 128:
stdout:
stderr: Permission denied (publickey).
fatal: The remote end hung up unexpectedly
This is same error as I get when I typo the passphrase (but of course, Jenkins does not ask me for the passphrase). The following pages:
GitHub - SSH Issues
Using SSH Agent Forwarding
indicate to me that ssh-agent could help remember the passphrase, which it does when I am using my own user, but not the jenkins id. Note that while running as my normal user yields:
echo "$SSH_AUTH_SOCK"
/tmp/keyring-nQlwf9/ssh
While running the same command as my 'jenkins' yields nothing (not even permission denied)
My understanding of the problem is that the passphrase is not remembered.
Do you have any idea?
Shall I start a ssh-agent or key ring manager for the jenkins user? How?
Or is ssh forwarding suitable when forwarding to the same machine?
Any brighter idea?
ps: I never sudo gitted, I always used jenkins or my user account (as mentioned in this SO post - Ubuntu/GitHub SSH Key Issue)
Since nobody wrote the answer from the comments for several months, I will quickly do so.
There are 2 possible problems/solutions:
id_rsa created with wrong user
Create id_rsa as the jenkins user (see hudson cannot fetch from git repository)
Leave passphrase empty
To summarise what must be done on the Jenkins server:
# 1. Create the folder containing the SSH keys if necessary
if [ ! -e ~jenkins/.ssh ]; then mkdir ~jenkins/.ssh; fi
cd ~jenkins/.ssh/
# 2. Create the SSH pair of keys
# The comment will help to identify the SSH key on target systems
ssh-keygen -C "jenkins" -f ~jenkins/.ssh/id_rsa -P ""
# 3. Assign the proper access rights
chown -R jenkins ~jenkins/.ssh/
chmod 700 ~jenkins/.ssh
chmod 600 ~jenkins/.ssh/*
Remember:
Please keep the default "id_rsa" name when generating the keys, as other such as "id_rsa_jenkins" won't work, even if correctly set up.
Do not use a passphrase for your key
Check that the public key (id_rsa.pub) has been uploaded on the git server (GitHub, Bitbucket, etc). Once done, test your SSH key by running: ssh -vvv git#github.com (change address according to your git server)
I got around this problem by simply leaving the passphrase empty when creating the keys.
I would add that if you created the keys by hand, they might still be owned by you and not readable by jenkins, try:
sudo chown jenkins -R /var/lib/jenkins/.ssh/*
To check are the following:
if the right public key (id_rsa.pub) is uploaded to the git-server.
jenkins user will access to github -> to CHECK if the right private key (id_rsa) is copied to /var/lib/jenkins/.ssh/
if the known_hosts file is created inside ~/.ssh folder. Try ssh -vvv git#github.com to see debug logs. If thing goes well, github.com will be added to known_hosts.
if the permission of id_rsa is set to 755 (chmod 755 id_rsa)
After all checks -> try ssh -vvv git#github.com
Dont try to do config in jenkins until ssh works!
If you are running jenkins as a service in windows, you need to verify the user running the service. If you created the keys using the user "MACHINENAME\user", change the service so the user running it can match
For Mac users, the issue can be solved by removing the existing keys and creating new Private and Public Keys by following these steps:
1.Remove all Public and Private keys located at /Users/Username/.ssh
2.Remove all the credentials saved under the Credentials tab in Jenkins.
3.Remove the existing Public SSH keys defined in the Github Repository Settings.
4.Create new SSH keys (private and public: id_rsa and id_rsa.pub) by following the steps from https://confluence.atlassian.com/bitbucketserver/creating-ssh-keys-776639788.html#CreatingSSHkeys-CreatinganSSHkeyonLinux&MacOSX
5.Set the newly created public SSH key (id_rsa.pub) in Github or an equivalent Repository Settings.
6.In Jenkins,create new credentials by adding the private SSH key(id_rsa) for your Github username.
7.The Error should be removed now.
keys need to generated from jenkins user.
sudo su jenkins
ssh-keygen
once the key is generated, it should be added as ssh key in bitbucket or github.
I'm trying to deploy a project using Capistrano. My development machine is running Windows 7; the server I'm deploying onto is Linux.
In the deploy.rb script, the following is set:
ssh_options[:forward_agent] = true
The Capistrano script starts off by running a git command locally, at which point I'm prompted for the passphrase for my SSH key:
* executing `deploy:update_code'
executing locally: "git ls-remote git#github.com:pathto/gitproject.git develop"
Enter passphrase for key '/c/Users/Sam/.ssh/id_rsa':
command finished in 6999ms
(I've removed the real git path from the above as you can probably see.)
I enter my passphrase and this works fine. However, Capistrano then tries to do something similar on the remote machine (renamed to staging-server.com in the below) and I get an error -- see the final line of this extract:
[staging-server.com] executing command
[staging-server.com] sh -c 'git clone git#github.com:pathto/gitproject.git /home/perstest/releases/20120412074500 && cd
/home/perstest/releases/20120412074500 && git checkout -b deploy 50eaf06d06d66fd20c3e55038276f420d8c308a8 && (echo 50eaf06d06d66fd20c3e55038
276f420d8c308a8 > /home/perstest/releases/20120412074500/REVISION)'
** [staging-server.com :: out] Initialized empty Git repository in /home/perstest/releases/20120412074500/.git/
** [staging-server.com :: err] Error reading response length from authentication socket.
If I comment out the forward_agent line in deploy.rb, this install succeeds, presumably using the key from the deployment server itself.
My SSH key seems to be working - after all, the initial git command works, I can use it in git push/pull and ssh -T git#github.com reports what it should (as recommended on github:help).
I assumed that my machine was not serving keys when asked for them by the remote server. After an awful lot of Googling, I found the recommendations at http://hustoknow.blogspot.co.uk/2011/06/ssh-agent-and-agent-forwarding-on.html, which explain how to get ssh-agent running on startup. I was doing all this from the command-prompt, so I then switched to git-bash and set up my .bash_profile for that to include the script I've linked to.
After adding this, I was prompted for my passphrase when first launching git bash and I could then connect to github using the SSH key (without having to re-enter passphrase). Furthermore, ssh-add -L reported that there was indeed a key available. So everything seems to be set up correctly!
However, I still get the "Error reading response length from authentication socket." error.
Any ideas? This works for my colleague (same deploy.rb file) whose development machine is Linux.
This is a bug from net-ssh as described here