I am writing a bash script on a machine without expect.
The script automates the build of a helm (v2.9.1) chart.
I've got to the part in the script where it runs a
helm package --sign --key 'mykey' --keyring 'path/to/keyring' -d chartdir chart
and because helm prompts for the passphrase of the gpg key I created in order to use provenance files (a requirement), I cannot script around the soliciting of the passphrase, which I would like to prompt for separately as the script is part of a CI/CD build chain.
I have tried using
yes $promptedPassPhrase | helm package --sign...
and I got
xrealloc: cannot allocate 18446744071562067968 bytes (237568 bytes allocated)
I also tried plain old
echo $promptedPassPhrase | helm package --sign...
and I got
Error: inappropriate ioctl for device
I also tried script and got the same response. As I do not have expect on the server, I cannot expect my way round it, so I'm stumped as to how to automate the helm package command and am not going to use a key without a passphrase as it is bad practice.
I don't know how long this has been the case, or exactly which versions this works on, but this doc page says:
If your PGP private key has a passphrase, [...] You can set the HELM_KEY_PASSPHRASE environment variable to that passphrase in case you don't want to be prompted to enter the passphrase.
This works for me on v2.13.1. It looks like it was added in October of 2018, so my guess is that it was first available in v2.12.0-rc.1.
Although this doesn't directly answer the OP's question (since they asked about v2.9.1), it will hopefully help anyone who ends up here because they (like me the first time round) missed that line in the doc.
I have followed the instructions over here (https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/#adding-your-ssh-key-to-the-ssh-agent) but Git still keeps asking for my passphrase. I'm on windows and have already set up ssh and generated the key. I even used the -K argument on the command ssh-add ~/.ssh/id_rsa but it doesn't seem to work. How should I correct this?
I want to use ssh passwordless-login using authentication-key-pairs.
I added
eval `ssh-agent -s`
ssh-add ~/.ssh/my_p_key
to ~/.profile. This doesn't work. If I use the ~/.bashrc it works fine.
Why do I have to set this every time I call a bash instead of every time the user logges in. I could not find any explanation.
Is there no better way to configure this?
The answer below solved my problem and for me it looks like a very legit solution.
Add private key permanently with ssh-add on Ubuntu
The
eval `ssh-agent -s`
sets the environment of the process. If you are using a window manager e.g. on a linux machine then the window manager will likely have a possibility to run a program like e.g. your ssh-agent on startup and passing the environment down to all processes started there, so all your terminal windows/tabs will allow you a passwordless login. The exact location, configuration and behaviour depends on the desktop/wm used.
If you are on a non-window-system, then you might look at the output of the ssh-agent call and paste that into all shells you open, however that may be as complicated as entering your password. The output will likely set something like
SSH_AGENT_PID=4041
SSH_AUTH_SOCK=/tmp/ssh-WZANnlaFiaBt/agent.3966
and you can access pw-less in all places where you set these
Just adding "IdentityFile ~/.ssh/config" to my .ssh/config did not work for me. I had to also add "AddKeysToAgent yes" to that file.
I think this extra line is necessary because gnome-Keyring loads my key but it has a bug that prevents it from being forwarded to the machine I ssh into.
Edit: After upgrading to Ubuntu 20.04, new terminals that I started could not access the ssh-agent. I had to add eval (ssh-agent -c) &>/dev/null to my ~/.config/fish/config.fish file.
my machine setup is as follows:
windows 7, Git for windows,Git Bash, openSSH 1.6 installed via cygwin.
I followed the instructions on https://help.github.com/articles/generating-ssh-keys
But I still have to login in everytime I push something.
I guess my setup is messed up... any help is very much appreciated.
To be able to use key-based authentication (instead of HTTP basic-auth), you have to use the SSH-Protocol. On Github, the URLs look like this:
git#github.com:username/repository.git
Once you use key authentication, you can use the common SSH tools to manage the connections. One of these tools is the SSH agent which will decrypt your private key once after loading and keep it in main memory while it is running. This allows new SSH sessions to use this key without having to bother you with a password-question.
You can add a private key to the current SSH agent session by running
ssh-add /path/to/key
If you want to remove the passphrase and it annoys you then enter:
ssh-keygen -p
enter the old passphrase and when asks for the new one, just leave it empty.
I now got it working kinda...
At first I uninstalled the ssh package from cygwin since git for windows ships with ssh.
like Holger said I had to add the key to the ssh-agent but from the git bash I was not able to add it. It worked like this:
eval 'ssh-agen.exe'
ssh-add ~/.ssh/id_rsa
After this I was able to push without entering a passphrase.
The only problem got left is that I have to add the key after every system reboot...
ANy ideas how to fix this?
These instructions are for Windows 7 and above.
Create a filename named .bashrc in your home directory (so full file path is C:\Users\XYZ\.bashrc where XYZ is your windows user name
In the file add these two lines. Note: change location of private key file if not at ~/.ssh/id_rsa
eval `ssh-agent`
ssh-add ~/.ssh/id_rsa
Open Git Bash application and you should be prompted with asking for your key's password
I wrote a simple script which mails out svn activity logs nightly to our developers. Until now, I've run it on the same machine as the svn repository, so I didn't have to worry about authentication, I could just use svn's file:/// address style.
Now I'm running the script on a home computer, accessing a remote repository, so I had to change to svn+ssh:// paths. With ssh-key nicely set up, I don't ever have to enter passwords for accessing the svn repository under normal circumstances.
However, crontab did not have access to my ssh-keys / ssh-agent. I've read about this problem a few places on the web, and it's also alluded to here, without resolution:
Why ssh fails from crontab but succedes when executed from a command line?
My solution was to add this to the top of the script:
### TOTAL HACK TO MAKE SSH-KEYS WORK ###
eval `ssh-agent -s`
This seems to work under MacOSX 10.6.
My question is, how terrible is this, and is there a better way?
In addition...
If your key have a passhphrase, keychain will ask you once (valid until you reboot the machine or kill the ssh-agent).
keychain is what you need! Just install it and add the follow code in your .bash_profile:
keychain ~/.ssh/id_dsa
So use the code below in your script to load the ssh-agent environment variables:
. ~/.keychain/$HOSTNAME-sh
Note: keychain also generates code to csh and fish shells.
Copied answer from https://serverfault.com/questions/92683/execute-rsync-command-over-ssh-with-an-ssh-agent-via-crontab
When you run ssh-agent -s, it launches a background process that you'll need to kill later. So, the minimum is to change your hack to something like:
eval `ssh-agent -s`
svn stuff
kill $SSH_AGENT_PID
However, I don't understand how this hack is working. Simply running an agent without also running ssh-add will not load any keys. Perhaps MacOS' ssh-agent is behaving differently than its manual page says it does.
I had a similar problem. My script (that relied upon ssh keys) worked when I ran it manually but failed when run with crontab.
Manually defining the appropriate key with
ssh -i /path/to/key
didn't work.
But eventually I found out that the SSH_AUTH_SOCK was empty when the crontab was running SSH. I wasn't exactly sure why, but I just
env | grep SSH
copied the returned value and added this definition to the head of my crontab.
SSH_AUTH_SOCK="/tmp/value-you-get-from-above-command"
I'm out of depth as to what's happening here, but it fixed my problem. The crontab runs smoothly now.
One way to recover the pid and socket of running ssh-agent would be.
SSH_AGENT_PID=`pgrep -U $USER ssh-agent`
for PID in $SSH_AGENT_PID; do
let "FPID = $PID - 1"
FILE=`find /tmp -path "*ssh*" -type s -iname "agent.$FPID"`
export SSH_AGENT_PID="$PID"
export SSH_AUTH_SOCK="$FILE"
done
This of course presumes that you have pgrep installed in the system and there is only one ssh-agent running or in case of multiple ones it will take the one which pgrep finds last.
My solution - based on pra's - slightly improved to kill process even on script failure:
eval `ssh-agent`
function cleanup {
/bin/kill $SSH_AGENT_PID
}
trap cleanup EXIT
ssh-add
svn-stuff
Note that I must call ssh-add on my machine (scientific linux 6).
To set up automated processes without automated password/passphrase hacks,
I use a separate IdentityFile that has no passphrase, and restrict the target machines' authorized_keys entries prefixed with from="automated.machine.com" ... etc..
I created a public-private keyset for the sending machine without a passphrase:
ssh-keygen -f .ssh/id_localAuto
(Hit return when prompted for a passphrase)
I set up a remoteAuto Host entry in .ssh/config:
Host remoteAuto
HostName remote.machine.edu
IdentityFile ~/.ssh/id_localAuto
and the remote.machine.edu:.ssh/authorized_keys with:
...
from="192.168.1.777" ssh-rsa ABCDEFGabcdefg....
...
Then ssh doesn't need the externally authenticated authorization provided by ssh-agent or keychain, so you can use commands like:
scp -p remoteAuto:watchdog ./watchdog_remote
rsync -Ca remoteAuto/stuff/* remote_mirror
svn svn+ssh://remoteAuto/path
svn update
...
Assuming that you already configured SSH settings and that script works fine from terminal, using the keychain is definitely the easiest way to ensure that script works fine in crontab as well.
Since keychain is not included in most of Unix/Linux derivations, here is the step by step procedure.
1. Download the appropriate rpm package depending on your OS version from http://pkgs.repoforge.org/keychain/. Example for CentOS 6:
wget http://pkgs.repoforge.org/keychain/keychain-2.7.0-1.el6.rf.noarch.rpm
2. Install the package:
sudo rpm -Uvh keychain-2.7.0-1.el6.rf.noarch.rpm
3. Generate keychain files for your SSH key, they will be located in ~/.keychain directory. Example for id_rsa:
keychain ~/.ssh/id_rsa
4. Add the following line to your script anywhere before the first command that is using SSH authentication:
source ~/.keychain/$HOSTNAME-sh
I personally tried to avoid to use additional programs for this, but everything else I tried didn't work. And this worked just fine.
Inspired by some of the other answers here (particularly vpk's) I came up with the following crontab entry, which doesn't require an external script:
PATH=/usr/bin:/bin:/usr/sbin:/sbin
* * * * * SSH_AUTH_SOCK=$(lsof -a -p $(pgrep ssh-agent) -U -F n | sed -n 's/^n//p') ssh hostname remote-command-here
Here is a solution that will work if you can't use keychain and if you can't start an ssh-agent from your script (for example, because your key is passphrase-protected).
Run this once:
nohup ssh-agent > .ssh-agent-file &
. ssh-agent-file
ssh-add # you'd enter your passphrase here
In the script you are running from cron:
# start of script
. ${HOME}/.ssh-agent-file
# now your key is available
Of course this allows anyone who can read '~/.ssh-agent-file' and the corresponding socket to use your ssh credentials, so use with caution in any multi-user environment.
Your solution works but it will spawn a new agent process every time as already indicated by some other answer.
I faced similar issues and I found this blogpost useful as well as the shell script by Wayne Walker mentioned in the blog on github.
Good luck!
Not enough reputation to comment on #markshep's answer, just wanted to add a simpler solution. lsof was not listing the socket for me without sudo, but find is enough:
* * * * * SSH_AUTH_SOCK="$(find /tmp/ -type s -path '/tmp/ssh-*/agent.*' -user $(whoami) 2>/dev/null)" ssh-command
The find command searches the /tmp directory for sockets whose full path name matches that of ssh agent socket files and are owned by the current user. It redirects stderr to /dev/null to ignore the many permission denied errors that will usually be produced by running find on directories that it doesn't have access to.
The solution assumes only one socket will be found for that user.
The target and path match might need modification for other distributions/ssh versions/configurations, should be straightforward though.