openssh unix dev - Aug 2016 - Feature request for ssh-add

Ajay Ramjatan asks if it would be ok to have:

A config file that contains list of DSA/RSA/ED25519 entries to be
added, when run by default.

Currently According to the man page:
"
Alternative file names can be given on the command line. If any file
requires a passphrase, ssh-add asks for the passphrase from the user.
"

Instead of specifying each key file, a single file such as .config
would contain:
AgentDefaultKey ~/.ssh/client1_rsa.private ~/.ssh/client2_ed25519
~/.ssh/client3_ed25519.

On Wed 2016-08-10 11:29:37 -0400, Loganaden Velvindron
wrote:
> Ajay Ramjatan asks if it would be ok to have:
>
> A config file that contains list of DSA/RSA/ED25519 entries to be
> added, when run by default.
>
> Currently According to the man page:
> "
> Alternative file names can be given on the command line. If any file
> requires a passphrase, ssh-add asks for the passphrase from the user.
> "
>
> Instead of specifying each key file, a single file such as .config
> would contain:
> AgentDefaultKey ~/.ssh/client1_rsa.private ~/.ssh/client2_ed25519
> ~/.ssh/client3_ed25519.
Is the goal to modify ssh-add to read this list, or to make it so that
ssh-agent tries to load these keys when it is initialized?

If we're talking about ssh-add, wouldn't it be just as easy to write a
brief shell script or alias to have the same effect?

To express my own tastes: I like the cleanliness of ssh-add's current
interface, and wouldn't want to introduce a new config file to have to
worry about parsing, dealing with errors, etc.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160810/dab2638e/attachment.bin>

On Thu, Aug 11, 2016 at 1:29 AM, Loganaden Velvindron
<loganaden at gmail.com> wrote:
[...]
> Instead of specifying each key file, a single file such as .config
> would contain:
> AgentDefaultKey ~/.ssh/client1_rsa.private ~/.ssh/client2_ed25519
> ~/.ssh/client3_ed25519.
You can do that with a trivial shell wrapper:

function ssh-add() { if [ -z "$@" ];then /usr/bin/ssh-add `cat
~/.ssh/keylist`; else /usr/bin/ssh-add $@; fi ; }

then list your keys in ~/.ssh/keylist.  ssh-add does not currently
read a config file and I don't think it should.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On Aug 10, 2016, at 17:24, Darren Tucker <dtucker at zip.com.au>
wrote:
> 
> On Thu, Aug 11, 2016 at 1:29 AM, Loganaden Velvindron
> <loganaden at gmail.com> wrote:
> [...]
>> Instead of specifying each key file, a single file such as .config
>> would contain:
>> AgentDefaultKey ~/.ssh/client1_rsa.private ~/.ssh/client2_ed25519
>> ~/.ssh/client3_ed25519.
> 
> You can do that with a trivial shell wrapper:
> 
> function ssh-add() { if [ -z "$@" ];then /usr/bin/ssh-add `cat
> ~/.ssh/keylist`; else /usr/bin/ssh-add $@; fi ; }
This may not do exactly what you mean, depending on the user's shell; there
are idiosyncrasies surrounding "$@", among other things.

This would be more likely to work correctly:

ssh-add() {
  if [ $# -eq 0 ]; then
    /usr/bin/ssh-add `cat "$HOME/.ssh/keylist"`
  else
    /usr/bin/ssh-add "$@"
  fi
}

Basically, "$@" (with double quotes) expands to "$1"
"$2" ... "$n". Some shells don't like more than one
argument after a -z test.  Some shells also expand "$@" to
"" (an empty string) if no arguments are provided, while others (e.g.,
bash) expand it to nothing (not even an empty string). Using the quoted form
after the ssh-add command ensures that arguments containing whitespace are
preserved.  Likewise, not all shells like a tilde ('~') for $HOME, and
quoting it ensures that home directories containing whitespace work correctly.

Handling whitespace in the names of key files in ~/.ssh/keyfiles is left as an
exercise for the reader, as is handling alternate locations of ssh-add. :)

Otherwise, I concur as well; this should not be first-class functionality of
ssh-add.

-- 
jim knoble