I'm trying to get Remote-SSH working with ssh-agent, from Windows 7 desktop to CentOs 7 server.
I'm using ssh, ssh-add and ssh-agent from the Git for windows package. From the cmd prompt, this is all working fine, I can "ssh-add -l" and see the keys, and I can run "ssh " and it runs with no problems and without asking for password:
C:\Users\gnb>"c:\Program Files\Git\usr\bin\ssh-add.exe" -l
4096 SHA256:zg2IR6OlPwCGP8SzcbriXIQjth5zuDc9rbO6uaNPmcU gnb#VDI028-MEL (RSA)
C:\Users\gnb>ssh vdi ls
Desktop
tsclient
wkspace
C:\Users\gnb>
From within VS-Code, I can't get this to work. Running the exact same ssh-add command from within the VS-Code Terminal does not seem to find the agent:
C:\Users\gnb>"c:\Program Files\Git\usr\bin\ssh-add.exe" -l
Could not open a connection to your authentication agent.
The actual remote functionality in VS-Code more or less works, but keeps stopping to ask for passwords.
What's missing here? Why can the vs-code environment not connect to the ssh-agent?
OK, I've had a few more hours playing around with this and I think I understand what's going on.
It only works from cmd if it is the same cmd window that was used to start the agent. Opening a new cmd window then ssh gets the same msg as starting vs-code from the menu - can't find the agent. It appears that the start-ssh-agent script that comes with git/ssh on Win7 is setting some environment variables or some such that the ssh client needs. This does make sense, Unix ssh-agent acts the same way, but I'm clearly not used to thinking about windows apps in those terms.
It also seems the start-ssg-agent script will set the environment variables to point to an existing agent if one is running, else will create a new agent. So a 2 line batch file
start-ssh-agent
code
will reliably start up VS Code with the ssh-agent. If you name the identity file in the ssh config, vs-code will add they key to the agent when required. Otherwise you need to manually add the key to the agent, or fall back to entering the password all the time.
Suspect the better solution is to be on Win10 and use ssh-agent as a service, which should mean VS-code should find the agent when run from a menu. But I can't test that.
Related
For a node project I will have to work on a remote server and for that I will use filzilla for file transfer and ssh for console.
I use Visual Studio Code, I installed a remote ssh extension,
I did the hostname and user configurations as well as secretkey,
because before that I had another error The process tried to write to a nonexistent pipe ,
which I finally solved but now after I start ssh and log in with the password in cmd from Visual Studio Code, I get this error bash: powershell: command not found.
I tried one day to search the internet for that error.
https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_server_configuration?WT.mc_id=-blog-scottha
https://learn.microsoft.com/en-us/windows/wsl/troubleshooting
I've talked to people who have more experience but within the time limit my advice could be, but I still couldn't solve the error, either it's something from windows or ssh or I don't know.
You are the first time I try to do this in general I used heroku or aws that had some facilities.
I changed host machine in the settings JSON file windows to linux
When you got the option to Select Linux, Windows or Mac did you make sure that you know exactly the type of server you are connecting to. Bcs if you choose the wrong one this error gets thrown.
Is it possible in VSCode to edit files within WSL2 of a remote PC. (This is like a combination of Remote-WSL and Remote-SSH.) I can connect to that remote PC via ssh and RDP.
The path \\wsl$\ does not seem to be available in my remote-ssh connection.
PCA - me, local, VSCode
^
|
ssh and/or RDP
|
V
PCB - remote, WSL2
(I currently have Windows OpenSSH set up on the remote PC, with the default CMD shell. I tried setting the shell to Bash but then the remote extension wouldn't install.)
Update Setting PC-B's ssh server shell to bash.exe does solve all my problems. I'm not sure why it didn't work before. See my answer below for more details.
Answering my own question I was certain I'd tried this before and it had not worked, but now that I try it again it works. Perhaps I just needed a reboot of Windows and WSL2.
Enable Windows SSH server on PC-B and set the shell to be bash.exe
# Powershell as Administrator
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Set-Service -Name sshd -StartupType 'Automatic'
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\WINDOWS\System32\bash.exe" -PropertyType String -Force
If you want authorized_keys-based login to this PC and your account is an Administrator account, you will need to follow the special instructions here: https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement (I have heard of having to manually fix the administrator_authorized_keys file permission at some point too. https://stackoverflow.com/a/64868357/600360 )
Using Remote-SSH connect VSCode from PC-A to PC-B (using Windows credentials) and tell VSCode that it is a linux server (because you're connecting to bash.exe within WSL2).
If you're behind a proxy server, add the proxy to your ~/.wgetrc.
Voila.
These steps taken from THE EASY WAY how to SSH into Bash and WSL2 on Windows 10 from an external machine where you can find more details.
If you want to connect to remote WSL, you probably should set it up to run own sshd instead of relying on hosting Windows to do the tunneling.
If I have got your problem statement right, the flow seems to be outlined in one of VS Code blog posts. Here I'll mention steps I think you will need to get to your target state.
Firstly, disable sshd on remote Windows so it does not occupy port 22. then, install and start sshd inside PCB:
# from PCB command prompt
# something like that, depending on your choice of distro
sudo apt remove openssh-server && sudo apt install openssh-server
# this would again depend on your chosen distro
sudo /etc/init.d/ssh start # after i do this - windows pops up a firewall prompt to allow me create a rule. you might need to add it manually
then you'd need to either enable password logins via ssh or (preferably) generate a key pair and put your public key into /home/your_name/.ssh/authorized_keys on PCB.
Assuming you have OpenSSH for Windows installed (this seems to be the client Remote SSH relies on), on your PCA follow something like so:
# something along these lines on your PCA
PS C:\WINDOWS\system32>ssh-keygen
# note location of .pub file and copy its contents into remote ./ssh/authorized_keys
# add generated private key to ssh-agent service
PS C:\WINDOWS\system32> Start-Service ssh-agent # if this fails - ensure service is installed and enabled
PS C:\WINDOWS\system32> ssh-add path\to\your\private_key # ensure you have dropped all permission except your own user
Watch out for permissions:
ssh keys are considered secret, so neither client nor server would start unless you drop all permissions from your key material. On linux do chmod 600 .ssh/authorized_keys, and for windows ssh-agent follow instructions from this SE answer.
The above may seem a bit daunting but is in fact very standard SSH setup procedure
easy steps
just update your vscode to the latest version
install Remote Development extension pack
allow WSL2 connection in the settings
if my answer helped you upvoted :D
I know it's been a while since the post, but here is a useful answer that uses Remote -- Tunnels extension.
https://stackoverflow.com/a/75389647
It appears that, for now, you need to manually install the CLI in WSL in order for it to work. The downloads can be found here. Since you are on Windows, I would recommend the x64 CLI download. When you extract the tar.gz file, you will get a file named code. I would recommend moving it to your home directory for ease. To open the tunnel, run ./code tunnel (from wherever you put the code file) to force the new CLI. If you use code tunnel it will still use the Windows version.
Source: https://github.com/microsoft/vscode/issues/171196
I am running on Pop!_OS so for most things this is likely an aquivalent of Ubuntu.
KeepassXC is installed and the SSH-Agent is enabled.
There is a keyphrase configured with a key and it works just like a charm when I start keepassxc from the terminal keepassxc log in and then I can see that ssh-add -l lists an additional key. It also vanishes once I close KeePassXC. Perfect!
Now I start keypassXC from the gnome shell, hit the super key, search for keepassXC and log into its vault. Looking at ssh-add -l in the terminal: Nothing. No keys added. 😔
Now I took a look at /usr/share/applications/org.keepassxc.KeePassXC.desktop and changed Terminal=false to true. No, sadly not that easy.
My guess that it has something to do how the gnome shell starts KeePassXC, but can't say for sure what the problem is. Anyone got a clue what that could be or how to take a shot at the problem?
I got the KeepassXC ssh agent working on Ubuntu 16.04.6 with Unity as the window manager.
The issue is that if the SSH_AUTH_SOCK environmental variable is not set before the window manager starts it is not available for programs started in the window manager.
Some distributions have a system for starting programs such as the ssh-agent before the window manager. On my distro I found that /etc/X11/Xsession.d/90x11-common_ssh-agent was starting ssh-agent. See this comment on a user help issue for KeepassXC for more information.
However I also found that GNOME Keyring was starting an ssh agent of its own. I had to disable this in the startup applications. I also checked that no shells startup scripts (ie. .bashrc .bash_profile .profile .config/fish/config.fish were trying to start the ssh-agent, as doing so would replace the one started before the window manager.
An interesting side note, the ttys, that you get to with Ctrl+Alt+F1, Ctrl+AltF2, etc., also do not have the SSH_AUTH_SOCK environmental variable set as they start up before the window manager. If you need it here you can add code to find and set the SSH_AUTH_SOCK. For the fish shell I added the following to ~/.config/fish/config.fish:
# Set SSH_AUTH_SOCK if not set.
if test -z "$SSH_AUTH_SOCK";
set -gx SSH_AUTH_SOCK (find /tmp/ -path "/tmp/ssh-*/agent.*" 2>/dev/null)
end
I also found that in the upcoming 2.6.0 release of KeepassXC (targeted for 3. April 2020), there will be an added settings to allow overriding, or settings the value to use for SSH_AUTH_SOCK. However as this changes each time ssh-agent starts you will either need to keep changing it or set-up a link that would point to the current sock.
here's my situation.
I'm running Cruise Control as a Windows Service and trying to get it to connect to a Mercurial Repository on BitBucket over SSH.
I'm pretty sure that everything's configured OK (PuttyGen, Pagaent, etc). I'm remoting onto the server using the same account that I am using to run the service and if I issue hg pull -b ssh://#bitbucket.org// from a command line everything works. I added -v to the ssh configuration in mercurial.ini and I can see all of the steps that are taken.
If I run CC.NET from a command prompt then it builds fine. In the console window I can see the same logging from the SSH operation.
However, if I run CC.NET as a service (using the same user account that I'm logged in on) the call to BitBucket times out. I can find no way to work out why either. The build log doesn't help and neither do ccnet.log or ccnet.trace in the temp directory. I was expecting one of them to contain the logging from the SSH operation, but they don't.
Can anyone help? Is it that running as a service prevents it from connecting to Pagaent (I've started Pagaent by adding it to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run). When I did the pull from the command line I had to OK a dialog, but only once. Is it waiting on the same dialog now that it's running as a service?
Getting close to my wits end here.
Thanks
I did get it working in the end. The trick was to create the public key without a passphrase. When running as a service the solution has to be completely non-interactive and the passphrase option with pagaent.exe just isn't.
Here are the steps:
Use PutTTygen to generate a secure key WITHOUT a passphrase. If you really do need one then you can add it to the mercurial.ini file, but defeats the point for me as it's in plain sight anyway.
Copy a mercurial.ini to two locations: C:\Windows\System32\config\systemprofile and C:\Windows\SysWOW64\config\systemprofile. Probably only one of these was really necessary, but I didn't have the time to experiment. The first is the home directory for the system user when running 64 bit apps, the SysWOW64 location for 32 bit. Make sure that if you do the same as me then keep both files in sync - or go one further and work out which is the correct location.
Add something like this line under the [ui] key in both files:
ssh = "D:\Program Files\TortoiseHg\TortoisePlink.exe" -ssh -2 -C -batch -v -i "[Path to your ppk file]"
Add the passphrase to the end of the command if one was created in step 1.
Make sure that TortoisePlink.exe is specified, not Plink.exe. They should both be in the same directory.
Download psexec from http://technet.microsoft.com/en-gb/sysinternals/bb842062.aspx
Run d:\PSTools\PsExec.exe -s -i cmd.exe. This will open a command line as the system account in interactive mode.
Now do an hg pull, or hg clone or whatever.
A dialog should pop up with a confirmation message. This is a one time thing and the reason that you have to do the PsExec step. OK the dialog.
Now cc.net should be able to be run as a service under the local system account using SSH!
I was wondering if anyone has tried using teamcity's command line builder to perform ssh remote login.
Right now, I would like to automate some testing on a QNX neutrino OS which is currently unsupported by teamcity. As a work around, I setup a ssh server on the target qnx machine so i could ssh and sftp the executables in.
Firstly, the source are compiled on Windows XP using qnx's compiler (based on g++). Followed by sftp-ing the executables into qnx neutrino.
Next, using ssh, script the login to remotely start the test apps and send the results back to the remote agent for publishing.
The batch script I created works well standalone, however, after hooking it up on the remote agent, it fails to login ssh and hangs indefinitely at the following command:
ssh -l "./.sh"
Notes:
I have added the remote agent's RSA public key in the QNX .ssh/authorized keys file, automatic login is working.
Is there a need to add the teamcity server's RSA public key in too?
Anyone has any idea on this problem?
I had a few weird problems with key-based SSH logins on QNX related to file permissions for the keys in .ssh. and permissions of parent folders (/home/username and /root).
Add
LogLevel DEBUG3
to /etc/openssh/sshd_config, make sure syslog is configured and is logging sshd output, restart sshd and try again - it will most likely complain about something.
Also, ssh -l "./.sh" makes no sense - -l is used to specify the user name, something is off there.