access(): the pattern for refs is too strict for filenames

a filename also becomes a "ref" if you use VREF/NAME.

For some reason[1], it seems some people use crazy filenames like foo(0)
or bar%20baz, and these things blow up on that test.

--

[1] viz., the lack of someone with good taste, like me, leading their
project ;-)
sshkeys-lint: accept ecdsa keys also

thanks to Richard Salts
(minor) perms would not print the correct message sometimes...

i.e., if getperms had an error.  (The same error for setperms would
print the correct message)
fix typo in ssh-authkeys
(minor) access: usage message was confusing
(minor) change ?? to syntax error
allow non-gitolite keys to have options/command, etc

Apparently, ssh-keygen can take fingerprints of entire authkeys files
also.  This is totally undocumented.

Since 'man ssh-keygen' only says: "Show fingerprint of specified public
key file." and makes no mention of authorized_keys files, I had assumed
that it treated a file containing this

    command="/usr/bin/backup" ssh-rsa .....

(i.e., a non-gitolite key that nevertheless contains a command) as just
a special type of pubkey file.  This meant, to me, that the presence or
absence of a newline should not matter, because *without* the 'command='
it certainly doesn't.

But what's actually happening is that it is treating this as an
authorized_keys file, and in *that* mode, it requires a newline.

I still don't see why it should require a newline as a *terminator*;
having it as a *separator* should be sufficient, but it's pointless to
argue about that when the feature itself is undocumented.

Wizmaster (code at wizmaster at fr) had to dig into the openssh source
code to figure this out and explain it to me.