Sorry for a long post
I have a VS Code Remote Development setup using containers. I have multiple user accounts for the same git server. I am using key-based authentication to interact with git-server. I am using Ubuntu 18.04 LTS in my host machine and Debian Buster in containers.
Git Server - git.server.com
Git urls
- git#git.server.com:repo1.git
- git#git.server.com:repo2.git
Repo1 is used by User1 account
Repo2 is used by User2 account
ssh-key for User1 - ~/.ssh/id_ed25519_user1
ssh-key for User2 - ~/.ssh/id_ed25519_user2
I have created an ssh config in ~/.ssh/config
Host user1.git.server.com
HostName git.server.com
User git
IdentityFile /home/user/.ssh/id_ed25519_user1
IdentitiesOnly yes
Host user2.git.server.com
HostName git.server.com
User git
IdentityFile /home/user/.ssh/id_ed25519_user2
IdentitiesOnly yes
From a terminal in host machine I can authenticate to server
as user1:
ssh git#user1.git.server.com
as user2:
ssh git#user2.git.server.com
I can launch multiple vs code instances and inside the vs code terminal (without opening the folder in remote container), I can use the above commands to authenticate.
Things get interesting once we use "Reopen in Containers".
I don't have the .ssh/config folder mounted inside containers so the above commands fail to execute by giving error:
Could not resolve hostname user1.git.server.com: Name or service not known
or
Could not resolve hostname user2.git.server.com: Name or service not known
I don't want to mount my ./ssh folder to containers for obvious reasons. Also mount=type=ssh is also not possible as this is not building a container but working with container as a dev environment.
Next thing I notice is that ssh-agent forwarding is working.
ssh-add -l
If I execute the above command in terminal in host, terminal in vs code (when folder is opened locally) and terminal in vs code (when folder is opened in remote container) all returns same output (the fingerprint for keys of identities for user1 and user2).
So I start a new ssh-agent in host terminal before launching the code.
~/repo1$ eval `ssh-agent -s`
~/repo1$ ssh-add ~/.ssh/id_ed25519_user1
~/repo1$ code .
and in another terminal
~/repo2$ eval `ssh-agent -s`
~/repo2$ ssh-add ~/id_ed25519_user2
~/repo2$ code .
In respective host terminal and vs code terminal (without opening folder in remote container) I get the desired result. I can use:
ssh git#git.server.com
So I don't need a ssh-config file anymore.
But this does not work when the folder is opened in Remote Container. VS Code only connects to the first ssh-agent started. That is (in this case) the repo1 opened in VS Code Remote Container works perfectly with all git support but repo2 opened in VS Code Remote Container does not work.
How can I direct VS Code to use which ssh-agent to forward to container when switching to remote container?
Workaround
The workaround which I am using currently is use the default ssh-agent (Ubuntu starts an ssh-agent at the time of logging in). This agent already contains both the identities. Verify by running
ssh-add -l
Launch multiple vs code instances as usual and switch to Remote Container.
When I want to perform a git operation I do the following in host terminal:
For repo1 (user1) operations
$ ssh-add -D
$ ssh-add ~/.ssh/id_ed25519_user1
For repo2 (user2) operations
$ ssh-add -D
$ ssh-add ~/.ssh/id_ed25519_user2
Is there any other suggested way? Is there any settings that can be added to devcontainer.json to achieve the proper forwarding of ssh-agent?
Thank you for your patience.
Related
I usually connect to remote computers through VS Code SSH. The settings (IP of the remote computer and public and private key pairs are properly set). The strange thing that is happening is that I can open any folder in the remote computer, but not the folder where the project is located (for example, I can also open the parent folder of the project).
It was working properly for years and now it has this type of problem.
Here, I report the output terminal:
[21:03:16.164] "remote.SSH.serverInstallPath": {}
[21:03:16.168] SSH Resolver called for host: PC000
[21:03:16.168] Setting up SSH remote "PC000"
[21:03:16.173] Using commit id "6261075646f044b98968d5000324gdhsdsjdd3b" and quality "stable" for server
[21:03:16.177] Install and start server if needed
[21:03:16.182] Checking ssh with "ssh -V"
[21:03:16.261] > OpenSSH_for_Wind
[21:03:16.262] > ows_8.1p1, LibreSSL 3.0.2
[21:03:16.273] Running script with connection command: ssh -T -D 64484 "PC000" bash
[21:03:16.275] Terminal shell path: C:\Windows\System32\cmd.exe
And after a while, it returns the timeout error.
I am putting the passphrase which it is requesting, then it is not able to connect to the folder.
Do anyone have some ideas?
I tried to open other folders with VS Code SSH connection and they are propery opened. I browsed with the command window to to the folder of the project and everything seem fine.
Did you try this option? "remote.SSH.useLocalServer": false, for more details, you can have a look the discussion here
Setting the terminal.integrated.inheritEnv option to true solved the problem
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).
I have connected to a remote Ubuntu host from Windows using VS Code and using it for remote development. Often times I open different code repositories in VS Code but every time I have to open a different folder despite having the connection established the VS Code ask for password.
It seems that once we are commented to a remote host then successive opening of different folder from same host should not prompt for password.
Is there any setting I am missing or should do to resolve this or save password.
I'm assuming you're connecting to an ssh remote.
There are two ways to authenticate an ssh connection, via password and via public/private key. When using the latter you don't need to enter the password each time.
To use the public/private keys here's what you have to do:
You first need a pair (public/private) of ssh keys. On windows you can use ssh-keygen to generate them for you and put them in the default ssh config folder ( ~/.ssh/)
You then have to configure the remote server to allow your ssh key, you can do this in two ways:
with the ssh-copy-id command if available (I think on windows it's not there, but you can try)
by manually add your public key (~/.ssh/id_rsa.pub) to the.ssh/authorized_keys file on the host machine
Here's a link to know more about passwordless logins via ssh: https://www.redhat.com/sysadmin/passwordless-ssh
Open git bash on Windows
cd .ssh
ssh-copy-id -i id_ed25519.pub your-username#your-server
Anybody has any problems deploying with Laravel's envoy when using private Github repos?
When manually cloning my repo from the production server, the ssh key seems to be accessible but when using Envoy, I always get a "Permission denied (publickey) error.
Thanks
It is probably because the ssh key on your remote server requires a password.
If you change the Envoy.blade.php to perform some other task you should be able to establish whether you are connecting to your remote correctly.
#servers(['web' => 'user#domain.com'])
#task('deploy')
cd /path/to/site
git status
#endtask
Should return something like:
[user#domain.com]: On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
If you are connecting using a Mac or Linux you probably don't have to enter your password because your terminal is using ssh-agent which silently handles your authentication.
Wikipedia article on ssh-agent
When connecting over ssh, ssh-agent isn't running and the script is being prompted for a password which is where it is failing.
To get around this you could to generate a new key on the remote machine that doesn't use a password.
If you want to restrict the ssh key to a single repository on GitHub have a look at deploy keys
You need to pass the -A (as per the man page it - Enables forwarding of the authentication agent connection. This can also be specified on a per-host basis in a configuration file) in you ssh string.
You will also need add your ssh key for agent forwarding (on the machine which can access the git remote which I assume be your localhost)
ssh-add -K ~/.ssh/your_private_key
Something like this
#servers(['web' => '-A user#domain.com'])
#task('deploy')
cd /path/to/site
git status
#endtask
Git remote commands should now work.
I'm having an hard time trying to configure Capistrano 3.1 to deploy an app hosted on Github.
I'm following Capistrano Documentation and I have successfully completed the first step (SSH keys from workstation to servers) and on the second one (From our servers to the repository host) I'm able to successfully run ssh -A deploy#one-of-my-servers.com 'git ls-remote git#github.com:my_user/my_repo.git':
18f38afz261df35d462f7f4e2ca847d22f148a06 HEAD
18f38afz261df35d462f7f4e2ca847d22f148a06 refs/heads/master
however, ssh deploy#one-of-my-servers.com 'git ls-remote git#github.com:my_user/my_repo.git' fails:
Permission denied (publickey).
Capistrano docs suggests
If you get the error "host key verification failed." log in into your server and run as the deploy user the command ssh git#github.com to add github.com to the list of known hosts.
SO, I tried so but I get
ssh git#github.com
Warning: Permanently added the RSA host key for IP address '192.30.252.131' to the list of known hosts.
Permission denied (publickey).
And I'm basically not able to successfully access the Github repo.
SSH documentation states:
-A Enables forwarding of the authentication agent connection. This
can also be specified on a per-host basis in a configuration
file.
How can I specified on a per-host basis in a configuration file?
My local machine runs Mac OSX Mavericks.
The VPS runs Ubuntu 12.04
Thanks.
Do you have your ssh key added to the list of agent identites ?
You can check with ssh-add -L , you should see the key your are using to connect to github :
$ ssh-add -L
ssh-rsa AAAAB3N.....0VmSiRvTzBrbU0ww== /Users/youruser/.ssh/id_rsa
If you don't see the ssh key you use for github or a message like
The agent has no identities.
Then you should add your key with :
ssh-add ~/.ssh/id_rsa
(replace with the path to the key you use for github)
See the ssh-add doc for more info
Add following lines to .ssh/config file on your local computer
Host Server_Address
ForwardAgent yes
Check your local key whether listed in ssh-add list or not with
ssh-add -L
If not add key to SSH Agent
ssh-add -K
Connect to Remote Server
ssh -v username#Server_Address
Check SSH Agent forwarding is enabled by running following command. It should list a socket file
echo "$SSH_AUTH_SOCK"
Run connection test against GitHub
ssh -T git#github.com
Run ls remote test against targeted git repository
git ls-remote --heads git#github.com:account/repo.git
Finally logout and run following from your local machine
cap production git:check
Add the following to ~/.ssh/config
Host one-of-my-servers.com
ForwardAgent yes
Yet another cause: If the target host's fingerprint doesn't match with your ~/.ssh/known_hosts, SSH automatically disables Agent Forwarding.
The solution is:
$ ssh -A -o UserKnownHostsFile=/dev/null my-target-host