Re: cygport improvements: upload, fish, src_prep_fini_hook

[Andrew Schulman <schulman dot andrew at epa dot gov>]

> > > > - Look if ssh-agent is running (SSH_AGENT_PID non-empty?)
> > > > - If not, start ssh-agent and ssh-add.  This asks for the passphrase,
> > > >   if any.
> > > > - run sftp
> > > > - If the script started ssh-agent, run eval $(ssh-agent -k)
> 
> I just played with this a bit and it turned out that you must be careful
> in terms of the login shell the user is using.  If you run this in a
> bash script, while the user's login shell is tcsh, it's essential to
> start ssh-agent with the -s flag:
> 
>   eval $(ssh-agent -c)
>   [...]
>   eval $(ssh-agent -k -c)
> 
> Otherwise ssh-agent will generate tcsh-compatible setenv/unsetenv
> commands :}

Ack, thanks.

> > > Another case is if the user sets SSH_KEY to use a specific key, and they already
> > > have an ssh-agent running, but it doesn't include that key.  Then the key will
> > > have to be added and then removed again afterward, or maybe a different
> > > ssh-agent started.  I'll have to think about that.
> > 
> > SSH_KEY?  This env var is not supported by ssh.  If that's an lftp
> > thingy you can ignore it using the above method.
> 
> On second thought, yes, the user might want to use an ssh key which
> is not usually maintained by ssh-agent.  Would it make sense to allow
> storing the key in ~/.cygport.conf?

Yes, SSH_KEY is a variable that I added just to the cygport upload command,
to allow people to specify a different key they might want to use for
uploading.  It can be specified in the shell environment or in
~/.cygport.conf.

> Testing if the key is already maintained by ssh-agent is easy:
> 
>   $ ssh-add -l
>   2048 88:75:95:cf:de:12:e0:15:45:f2:a6:8e:89:08:93:2c /path/to/private-key
> 
> Checking the path might be sufficient, but if you want to be really sure,
> you could check against the fingerprint value instead:
> 
>   $ ssh-keygen -l -f /path/to/private-key
>   2048 88:75:95:cf:de:12:e0:15:45:f2:a6:8e:89:08:93:2c <some string>

Yes, comparing hashes is better (though a bit scrapy).

Thanks,
Andrew