Re: [Sshpass-devel] sshpass needs a config file

[Bruce K. <bk...@us...>]

On 07/26/13 20:14, Shachar Shemesh wrote:
>> I only do it if it is welcome.  If it won't get applied, I won't bother.
>> As the author, you probably have an idea about whether the whole idea
>> would be accepted or not.
>>
>> I will guess now that it would be.  Thanks!  Cheers - Bruce
> I'm sorry, this simply is not how open source works.

It all depends upon the actors.  There is an effort difference of
close to a factor of four between hacking together enough that
it meets my needs and polishing it enough to be documented and
generally usable.

What you say about stashing passwords is mostly true.
However, whenever I have had need to ssh to an internet-accessible
domain, they have always used public keys.  In fact, I usually
do not even have password access.  Where this tool is useful
to me is on a private network behind a very secure firewall.
I need to ssh into many nodes that have pre-configured read-only
home directories.

Why not just have all nodes use the same password?  Excellent
question.  I do wish I had a cogent answer.  I guess because
I am accessing machines that were configured by different groups
and each had better (or different) ideas about what password to
use.  Whatever.  I'm here now.  My first idea was to have a
bash config script that filled an associative array with all
the passwords I needed.  That is probably the easiest.

> If you believe in this patch, preferably because you need it yourself,
> then you write it.

I tried to be sufficiently clear.  Maybe I was not.
I was not expecting anyone else to step up and do anything.
Sorry I was not clearer.

> This might mean that it might get accepted, or it might mean it will not.
> It might even mean there is a fundamental problem with the concept.

I was trying to guard against the 4X effort for something that
had no chance whatever.

> If you want to be taken seriously, though, you show effort by writing
> the patch.

It is not like I've not made patches.  I have a chunk of GCC,
I've hacked core utils, I've done many things.  I also strive
to avoid wasting my time on futile efforts, though I've done
that, too.

> ... it is better to start your email with something along
> the lines of "here is a new feature I was thinking of implementing,
> and I'd love to get feedback on whether this is even needed or useful".

That was the intent.  I am sorry it wasn't clear enough.

> Specifically regarding your suggestion: I do not like it much.
> I have security as my background, and I cringe whenever passwords
> are stored in plain text. Your idea involves plain text passwords

Indeed.  It really is not intended for secure access.  It is for
insecure access via secure mechanisms.

> laying around in the clear for much longer than the other alternatives.
> Then again, ssh-pass has been a compromise from the get-go, and as you
> have stated, there are tradeoffs either way. As such, if you write it,
> and if there is no technical reason not to, I'll *probably* include it.
> After all, with the proper warnings in the man page, a user is always
> free not to use this feature.

The caveat would be along the lines of:

   Don't use this feature unless you are using it only for access
   behind a secure firewall.

> Having said that, I think there are things we can do to make this idea
> better, without compromising the usability. In fact, with a little bit
> of work, we can make this into a feature that can be the recommended
> method of doing things. One thing we might do is to tie the passwords
> in to the ssh public key infrastructure.

That is, of course, why I was suggesting SSH-like syntax and
using a file in ~/.ssh -- which, to work, must be secured properly.

> Most valid uses of ssh-pass
> are for cases where the user only controls the client side, and the
> server, for whatever reason, does not allow public key authentication.

Like "compute nodes" that have no local storage and read-only
home directories?

>  If we offer a "remember this password" feature for ssh-pass, and
>  particularly, encrypt the password files with the user's private key
>  (through the ssh-agent or otherwise), then we might get a feature
>  that gives you the usability you want, while actually being MORE
>  secure than the other ssh-pass password passing options.

That would be nice.  Beyond my scope of expertise, but this suggestion
is certainly very welcome.

=================

To a completely different topic, but related to passwords across a network.

You said:
> I have security as my background, ...
I do not.

So I have a toy for providing passwords that *does not* involve
storing them and yet does not require complex memorization gymnastics
to retrieve them either.  The concept is that you start with a
hash seed stored away that is difficult to gain access to.
The hashed text is augmented by an unlikely permutation of
a domain name to produce the actual hash.  That permutation
is only stored in the brain of the user.  The hash bits are
converted to plain text via base64 encoding and trimmed to length.
That's your password (modulo tweaks for certain requirements).
The result is that it is easier to have different passwords
for every domain than it is to use the same one for many sites.

In essence, an attacker has two ways to gain access:

1. obtain the password from a particular domain.  The only thing
   a user can do is make sure other domains have other passwords.

2. obtain the hash seed file ("something the user has"), obtain
   the domain name transform ("something the user knows"),
   know that the target uses this obscure little thing I
   cooked up, and, finally, know which domains the user has
   access to (more stuff known by the user).

I think that is reasonably secure.  I've presented it to the FSF
for blessing, but they want some feedback from security types,
which I'm not.  And it is dragging a bit.

In case you (all) might be interested and willing to play and comment:
  http://autogen.sourceforge.net/data/gnu-pw-mgr-0.5.tar.xz
The tarball includes a man page and texi docs.

Thank you for your feedback, Shachar!

Regards, Bruce