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!
Related
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.
I followed the guide from https://help.github.com/articles/generating-ssh-keys/ to generate a ssh key used to connect to github from my server.
The problem is if I close the shell and login the server again, I have to repeat below steps to reconnect to github, otherwise the accessing will be denied:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa
How can I setup a permanent connection with github?
Since you are logging on to the command-line (presumably using SSH) all applications that you run, including ssh-agent, stop when you log out.
In my opinion your best bet is to have your CentOS machine start ssh-agent for you each time you log in, then manually use ssh-add to add your key. This can be done by modifying your shell's login script. If you are using bash, this file is called ~/.bash_profile. If you are using another shell, refer to its documentation and choose an appropriate file.
Edit one of these files and add eval "$(ssh-agent -s)" at the end.
Now, each time you log in ssh-agent should automatically start, and you can optionally run ssh-add (since you are using a file that ssh-add looks for by default you don't need to pass the file to the command) to add your key, then do Git stuff.
It sounds like you want to automate the adding of the key as well. This isn't something that I would choose to do since I like adding keys to be explicit, but because you don't have a passphrase on your SSH key you should be able to add ssh-add to the same file we modified above (after we start the agent, of course) and have your key added automatically.
Thanks #Chris
I did the following and it worked:-
Step1:- .bash_profile
Step2:- enter image description here
Step3:-source .bash_profile
Step4:- enter image description here
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
I use to navigate my remote servers with ssh. Sometimes i would like to download a file to open in my computer.
But the only way i know how to do it is to open a new command line window and use scp from local to remote.
is there a way to do this directly from the ssh server?
like a command that know my current ip so can set up everything automatically?
(wonderful would also be to do the upload in such a way...)
There is no easy way to do it - I used ssh & scp many years the way you just described. But, you may configure ssh & scp in such a way that they don't require password each time, which is very comfortable! For this, you need:
generate keys by ssh-keygen - they can be also passphrase (= password) protected
copy the keys to remote machine to ~/.ssh/authorized_keys
And then, each time you start a session, you run ssh-agent and ssh-add. You just enter the password once. And then you can just run scp/ssh many times, from scripts, etc., without the need to enter the password each time!
I don't remember the exact way how to configure all this, but have a look at manpages of all those useful tools! Many things can be automatized by placing them into ~/.bash_profile or ~/.bashrc files.
I found this while trying to answer your question for myself:
https://askubuntu.com/a/13586/137980
Just install zssh and use Ctrl-# to go into file transfer mode.
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.