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.
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.
at this point when I log into my CentOS machine, I get this:
groostav#mymachine:~$ ssh root#my.company.com
root#my.company.com's password:
Last login: Mon Aug 20 13:52:47 2018 from s12345.vs.shawcable.net
-bash: brew: command not found
-bash-4.2#
I've gotten to this state by very carelessly trying to get a nice git prompt --evidently I even managed to get some mac osx code on my bash configuration path somehow. I've also blown up my old prompt which was in the form user#host:pwd #, which I would prefer.
I've been greping around but I cant find where the problem configuration is. Both the /etc/bashrc and ~/.bashrc files look fine (the former seems like a default, and the latter has a number of commented-out lines in it).
Where is this brew command and how did it get there!?
How did my prompt get reverted from the usual form to this basic form?
for bonus points, anybody know a very simple git prompt configuration? I'm remoting into this machine from linux machines and WSL, so fancy colors and unicode are a bad idea.
Many thanks!
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 am on a Windows7 machine and I'm trying to get graphic view on the centOS machine to be displayed on my current screen. When typing xclock, gedit... in terminal, I am getting the following error
-bash: xclock: command not found
and This the result of # vi /etc/ssh/sshd_config command
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
#tewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
Also Xming is running on server:0.0 and I turned X11 forwarding on on putty
So what's the problem ?
sudo yum install xorg-x11-apps
Should cover it!
Do you have an .Xauthority file in your home directory?
I've recently found the answer for my issue, which might be similar to yours. I've seen quite a few open questions about this topic without resolution. You may have a few more things to work through, but SELinux settings ended up being my final hurdle. This among many other steps are covered here: ssh X11 forwarding won't work
That aside, you may need to change the Xming settings to match the default DisplayOffset of 10 for Centos. And after any changes to sshd_config, you'll need to restart the service via
/etc/init.d/sshd restart
I would like to emphasize that my situation is a non-critical operation within a (hopefully!) securely-managed intranet. I would NOT suggest turning off SELinux at work, or at home if you're hoping to open ports or configure VPN for your home network. Please consider: http://securityblog.org/2006/05/21/software-not-working-disable-selinux/
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!