Whoever it was who suggested that you make sure to create a passwordless ~/.ssh/identity was smart to think of that. (I had neglected to mention that part of it :)). But if this script is only going to be launched when you're logged in already (i.e., if you'll be launching it manually) then it will inherit your ssh-agent environment variables, and will have appropriate access. Here's the sequence, cut directly out of /etc/profile.local on the computer I'm using: ## if interactive, set up for SSH if [[ $- == *i* ]] && [ ! "$SSH_AUTH_SOCK" ] && [ -d $HOME/.ssh ] \ && type ssh-agent > /dev/null 2>&1; then # The 'trap' command sets us up to automatically clean up the # freshly-started agent when we exit eval $(ssh-agent) && trap 'eval $(ssh-agent -k)' EXIT echo "Type \`\`ssh-add'' in order to set up your SSH client." fi As for Kevin Donnelly wrote:
Yes, I am always asked, but this may be because ssh-agent is not available or not running or not set up on the webserver.
I should explain that the web server knows nothing about ssh-agent. Your local ssh client uses the private key as part of comminication with the remote server, and the remote server doesn't know whether you just typed in the passphrase for that private key, or whether ssh-agent conveniently kept the private key cached for you, or what. It just reads the bits that your ssh client sends it.
I am reading the man pages at the moment, in between deep gulps of breath!
I find it appalling reading. I only dug into the server config file page after my ssh logins broke after an upgrade. O'Reilly and associates has an entire book just on setting up and using SSH. Looks like a couple of hundred pages; I haven't read it, since I had already gotten my configuration (finally) working without it.
In the meantime, I've got the problem that the ssh login keeps kindly presenting me with a shell prompt, so of course the rest of the script doesn't execute. What's the best way of getting the script to ignore it and go on to run a shell command directly?
The shell prompt will confuse almost any program that expects to read something back from the remote shell. Earlier versions (at least until 7.1, maybe 7.2) of SuSE linux came with an /etc/profile that automatically set the prompt (PS1) even if you weren't logged in interactively. This is a Bad Thing. Here's the hack to fix it, again out of my /etc/profile.local. You should put this into your .bashrc on the remote host: ## Non-interactive shells should not have PS1 and PS2 set indiscriminately! if [[ $- != *i* ]]; then unset PS1 PS2 fi
I've tried sending the login to /dev/null, using && for the next command, putting login and command in brackets, separated by semi-colon, and a few other things in David Tansley's Linux and Unix Shell Programming book, but no luck.
You could also use the very useful program ``expect'' to automate the login process. The main disadvantage of doing this in an expect script is that you'll then end up including a cleartext password in the body of the script. Also note that ssh takes a -i option that allows you to use an alternate identity file. So you could have an identity that you use just for the automated script. Good luck! Write back! --Steve Augart