authorized_keys2 directory idea
Pekka Savola
In a mail about two weeks ago, I brought up an idea:
---
How SSH makes this easier is that you only have to sync the
authorized_keys2 database to root account's .ssh/ every time new admin
comes in/leaves the house. This can even be automatized rather easily. A
more modular hack would be using authorized_keys2 _directory_, and the
keys in there would all be counted as authorized. Thus only one file
copy/removal would do the job, no need for sync; this would be profitable
in environments where all admins don't have access to all systems.
---
Root would not be the only one to profit from this; you would only need to
copy the pubkey file in the right dir (with a descriptive name if you
like!), and authorization would work without file editing. Also, if you
need to refresh just one key, you could just scp that one over, no need
to edit the file either.
The more I think of this, this sounds more and more like a nice feature to
have :-). It'd probably be better be like .ssh/authorized_keys.d/ or the
like, I suppose.
What do you think -- would this be useful? Bloat? Could it be considered
to be merged if it was implemented?
I made some preliminary checking, and I don't think this would add too
much new code; look up all files in the directory, disqualify those with
odd characters in them (e.g. allow [0-9a-zA-Z_.@-]) , insert the rest to
current key check method one by one until a matching key is found.
Btw, I noticed when comparing auth-rsa.c/auth2.c that auth2.c does not
print debug message:
--- openssh-cvs/auth2.c Sat Jun 2 11:14:21 2001
+++ openssh.fix/auth2.c Sat Jun 2 11:13:40 2001
@@ -26,6 +28,8 @@
if (!f) {
/* Restore the privileged uid. */
restore_uid();
+ packet_send_debug("Could not open %.900s for reading.", file);
+ packet_send_debug("If your home is on an NFS volume, it may need to be world-readable.");
return 0;
}
if (options.strict_modes) {
was this left out by design, or a leftover in auth-rsa.c ?
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Markus Friedl
> Root would not be the only one to profit from this; you would only need to
> copy the pubkey file in the right dir (with a descriptive name if you
> like!), and authorization would work without file editing. Also, if you
> need to refresh just one key, you could just scp that one over, no need
> to edit the file either.
i don't understand why editing a file is hard.
i think keeping a file in sync is simpler than
syncing directories, especially deleting files.
> What do you think -- would this be useful? Bloat? Could it be considered
> to be merged if it was implemented?
i don't think it's useful. ssh.com switched to a-key-per-file,
but openssh and the traditional ssh use a-key-per-line
and i don't want to support 2 different ways of doing things.
> Btw, I noticed when comparing auth-rsa.c/auth2.c that auth2.c does not
> print debug message:
> --- openssh-cvs/auth2.c Sat Jun 2 11:14:21 2001
> +++ openssh.fix/auth2.c Sat Jun 2 11:13:40 2001
> @@ -26,6 +28,8 @@
> if (!f) {
> /* Restore the privileged uid. */
> restore_uid();
> + packet_send_debug("Could not open %.900s for reading.", file);
> + packet_send_debug("If your home is on an NFS volume, it may need to be world-readable.");
> return 0;
> }
> if (options.strict_modes) {
>
> was this left out by design, or a leftover in auth-rsa.c ?
they should be merged, and in the future, i don't
want to see debug messages before a user is authenticated.
Jim Knoble
--b5gNqxB1S1yM7hjW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Circa 2001-Jun-03 11:46:04 +0200 dixit Markus Friedl:
: i don't understand why editing a file is hard.
Editing a file is hard for many inexperienced users. Especially a file
that contains very long lines filled with what appears to meaningless
random letters and numbers.
Using a directory format has the potential to make it significantly
easier for users to install public keys onto a remote system. Instead
of having to use a complicated set of shell commands such as:
cat ~/.ssh/identity.pub |ssh remote-host 'cat >>~/.ssh/authorized_keys2'
(remember that ssh-copy-id only works for rsa1 keys), you can simply do:
scp -p ~/.ssh/identity.pub remote-host:.ssh/authorized_keys2.d/local-host
Once they understand scp, inexperienced users can easily manage their
own public keys. That's a big win for everyone.
: i think keeping a file in sync is simpler than syncing directories,
: especially deleting files.
Heard of rsync? All you need is:
rsync -av --delete master-key-repository/* \
user@remote-host:.ssh/authorized_keys2.d/
Alternatively:
ssh remote-host 'cd .ssh/authorized_keys2.d; cvs update'
The file-based format could even stay there without a problem: Simple
read ~/.ssh/authorized_keys2 first, then look for
~/.ssh/authorized_keys2.d/* and read them. Existing practice doesn't
have to change.
[Pekka Savola wrote:]=20
: > What do you think -- would this be useful? Bloat? Could it be conside=
red
: > to be merged if it was implemented?
:=20
: i don't think it's useful. ssh.com switched to a-key-per-file,=20
: but openssh and the traditional ssh use a-key-per-line
Myself, i think it's a fantastic idea. Both experienced and
inexperienced users stand to benefit.
--=20
jim knoble | jmkn...@jmknoble.cx | http://www.jmknoble.cx/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
--b5gNqxB1S1yM7hjW
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Linux)
Comment: finger jmkn...@pobox.com for GnuPG public key
iEYEARECAAYFAjsar50ACgkQKJ/qqBOBFJFyPQCdFtkxkE7jEZUk54SRZkr7EACm
XgsAmgM+/xNuBYNqY3VIn7mC3NOlHiaN
=QGNY
-----END PGP SIGNATURE-----
--b5gNqxB1S1yM7hjW--
Rob Hagopian
and where they came from by having a directory format... could we at least
put the patch in contrib?
-Rob
On Sun, 3 Jun 2001, Markus Friedl wrote:
> On Sat, Jun 02, 2001 at 11:54:24AM +0300, Pekka Savola wrote:
> > Root would not be the only one to profit from this; you would only need to
> > copy the pubkey file in the right dir (with a descriptive name if you
> > like!), and authorization would work without file editing. Also, if you
> > need to refresh just one key, you could just scp that one over, no need
> > to edit the file either.
>
> i don't understand why editing a file is hard.
> i think keeping a file in sync is simpler than
> syncing directories, especially deleting files.
>
> > What do you think -- would this be useful? Bloat? Could it be considered
> > to be merged if it was implemented?
>
> i don't think it's useful. ssh.com switched to a-key-per-file,
> but openssh and the traditional ssh use a-key-per-line
>
Pekka Savola
> On Sat, Jun 02, 2001 at 11:54:24AM +0300, Pekka Savola wrote:
> > Root would not be the only one to profit from this; you would only need to
> > copy the pubkey file in the right dir (with a descriptive name if you
> > like!), and authorization would work without file editing. Also, if you
> > need to refresh just one key, you could just scp that one over, no need
> > to edit the file either.
>
> i don't understand why editing a file is hard.
> i think keeping a file in sync is simpler than
> syncing directories, especially deleting files.
Yes, keeping a file 100% in sync is way easier. But in real situations,
you're often faced by the fact that e.g. 60-90% of the keys are the same,
and the rest vary. Then syncing is a bit more difficult. Editing is also
a bigger (ie: interactive) process when it has to be done on many hosts.
A problem is backup files if you edit keys with an editor, ie. ones ending
to e.g. ~ or # (depending on the editor). Then if you just delete the
base key, the results might be unexpected. To counter this, filenames
would be scanned and only those that contain only legal characters would
pass.
> > What do you think -- would this be useful? Bloat? Could it be considered
> > to be merged if it was implemented?
>
> i don't think it's useful. ssh.com switched to a-key-per-file,
> but openssh and the traditional ssh use a-key-per-line
I wasn't aware ssh.com is doing something like this too. So it might be
something to be done sooner or later, though.
Pekka Savola
> Circa 2001-Jun-03 11:46:04 +0200 dixit Markus Friedl:
>
> : i don't understand why editing a file is hard.
>
> Editing a file is hard for many inexperienced users. Especially a file
> that contains very long lines filled with what appears to meaningless
> random letters and numbers.
>
> Using a directory format has the potential to make it significantly
> easier for users to install public keys onto a remote system. Instead
> of having to use a complicated set of shell commands such as:
>
> cat ~/.ssh/identity.pub |ssh remote-host 'cat >>~/.ssh/authorized_keys2'
And there is another complication here (which often goes wrong with novice
users): the file's permissions usually go wrong due to common non-strict
umask when the file is being created.
Garance A Drosihn
>My $0.02 is that I like it, and I find it easier to keep
>track of the keys and where they came from by having a
>directory format... could we at least put the patch in
>contrib?
I'll add another $0.02 to say that I think it is useful to
allow for a directory of public keys instead of a single
file.
If done, I might also suggest that ssh ignore all files in
that directory except for those which end in '.pub', just
to make it clear that the file should be the "public key"
and not the private one.
--
Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu
Theo de Raadt
OpenSSH is security software. A lot of you keep asking for more and
more features, and the code keeps growing and growing and growing.
Assuming that the number of lines per bug is a constant, how long
before one of these features which noone uses becomes a hole?
I think it is ridiculous how some people keep demanding change.
Sorry, but I firmly believe that change for the sake of "I like it" is
stupid.
> My $0.02 is that I like it, and I find it easier to keep track of the keys
> and where they came from by having a directory format... could we at least
> put the patch in contrib?
> -Rob
>
> On Sun, 3 Jun 2001, Markus Friedl wrote:
>
> > On Sat, Jun 02, 2001 at 11:54:24AM +0300, Pekka Savola wrote:
> > > Root would not be the only one to profit from this; you would only need to
> > > copy the pubkey file in the right dir (with a descriptive name if you
> > > like!), and authorization would work without file editing. Also, if you
> > > need to refresh just one key, you could just scp that one over, no need
> > > to edit the file either.
> >
> > i don't understand why editing a file is hard.
> > i think keeping a file in sync is simpler than
> > syncing directories, especially deleting files.
> >
> > > What do you think -- would this be useful? Bloat? Could it be considered
> > > to be merged if it was implemented?
> >
> > i don't think it's useful. ssh.com switched to a-key-per-file,
> > but openssh and the traditional ssh use a-key-per-line
> >
Rob Hagopian
always a bad thing, I prefer not having a separate .ssh2 directory. But a
lot of other unix utils have moved to file based rather than line based
config methods for the simple reason that a lot of people working with
these systems find it easier to manage them this way... Do you object to
/proc, pam, and SysV rc scripts as well?
And I still think that if people support it, it surely belongs in contrib
for people to use at their own risk... what else is that for?
-Rob
Theo de Raadt
You don't know your history.
mou...@etoh.eviladmin.org
On Mon, 4 Jun 2001, Rob Hagopian wrote:
> OpenSSH changed from the ssh.com directory method... not that that's
> always a bad thing, I prefer not having a separate .ssh2 directory. But a
> lot of other unix utils have moved to file based rather than line based
No.. We did not. ssh.com decided not to use their old single file
authorized_keys. As for which we should follow. I personally don't care.
It's no harder to me to manage it as a single file or as multiple little
files. And the arguments I've seen really does not improve the odds of us
changing it.
> config methods for the simple reason that a lot of people working with
> these systems find it easier to manage them this way... Do you object to
> /proc, pam, and SysV rc scripts as well?
>
I have a massive objection to /proc and a less extent pam.. But that is
here nor there. =)
> And I still think that if people support it, it surely belongs in contrib
> for people to use at their own risk... what else is that for?
> -Rob
>
I doubt Theo ever has had problems with contrib/ code. It's core
software that we are refering to.
- Ben
Rob Hagopian
> On Mon, 4 Jun 2001, Rob Hagopian wrote:
>
> > OpenSSH changed from the ssh.com directory method... not that that's
> > always a bad thing, I prefer not having a separate .ssh2 directory. But a
> > lot of other unix utils have moved to file based rather than line based
>
> No.. We did not. ssh.com decided not to use their old single file
> authorized_keys. As for which we should follow. I personally don't care.
> It's no harder to me to manage it as a single file or as multiple little
> files. And the arguments I've seen really does not improve the odds of us
> changing it.
But ssh.com v2 was around before OpenSSH... they fixed a lot of things
from v1 to v2, I liked that one and was disappointed to see openssh revert
back...
> > And I still think that if people support it, it surely belongs in contrib
> > for people to use at their own risk... what else is that for?
> > -Rob
> >
>
> I doubt Theo ever has had problems with contrib/ code. It's core
> software that we are refering to.
My suggestion was only to put it into /contrib... is that OK then?
-Rob
Theo de Raadt
>
> > On Mon, 4 Jun 2001, Rob Hagopian wrote:
> >
> > > OpenSSH changed from the ssh.com directory method... not that that's
> > > always a bad thing, I prefer not having a separate .ssh2 directory. But a
> > > lot of other unix utils have moved to file based rather than line based
> >
> > No.. We did not. ssh.com decided not to use their old single file
> > authorized_keys. As for which we should follow. I personally don't care.
> > It's no harder to me to manage it as a single file or as multiple little
> > files. And the arguments I've seen really does not improve the odds of us
> > changing it.
>
> But ssh.com v2 was around before OpenSSH... they fixed a lot of things
> from v1 to v2, I liked that one and was disappointed to see openssh revert
> back...
We did not revert back. And just because they made a decision does
not make it the right choice automatically.
Theo de Raadt
Oh, that's a great idea. And after a while, we'll have hundreds of
incompatible versions for Markus to debug when you guys send in
incomplete bug reports.
Theo de Raadt
I want you all to think about this carefully.
We make our software completely free so that you guys can tweak it.
All you want.
But in our own distribution, it's kind of scary when lots of tweaks
happen. It can impact developer effort VERY SIGNIFICANTLY when people
run local modifications.
A Linux vendor shipped with ssh with modifications that broke interop
with various older ones. It took effort to figure out what was going
on. It took effort to convince them to alert their user base. It
wasted time. I firmly believe that contrib directories do too.
For years I have been saying that "buttons are bad"...
Rob Hagopian
specific; I think we're a far cry from hundreds. If people want the
feature and a patch is circulated, people may apply it and never even
mention it. Patches accepted for contrib could be forced to add a tag to
the version line (similar to apache modules) so a developer knows exactly
what they're up against if someone reports bugs. (I could even forsee a
flag in config to reject connections to/from patched ssh distributions for
the really paranoid...) Would that aliviate some of your concern?
-Rob
On Sun, 3 Jun 2001, Theo de Raadt wrote:
Markus Friedl
> OpenSSH changed from the ssh.com directory method...
wrong.
> not that that's
> always a bad thing, I prefer not having a separate .ssh2 directory.
they switched, not we.
> But a
> lot of other unix utils have moved to file based rather than line based
> config methods for the simple reason that a lot of people working with
> these systems find it easier to manage them this way... Do you object to
> /proc, pam, and SysV rc scripts as well?
yes :)
> And I still think that if people support it, it surely belongs in contrib
> for people to use at their own risk... what else is that for?
you have to maintain things in contrib as well, and if
we ship hundreds of contrib patches it's hard to say
this and that is openssh's behaviour.
-m
Markus Friedl
> On Sun, 3 Jun 2001 mou...@etoh.eviladmin.org wrote:
>
> >
> > > OpenSSH changed from the ssh.com directory method... not that that's
> > > always a bad thing, I prefer not having a separate .ssh2 directory. But a
> > > lot of other unix utils have moved to file based rather than line based
> >
> > authorized_keys. As for which we should follow. I personally don't care.
> > It's no harder to me to manage it as a single file or as multiple little
> > files. And the arguments I've seen really does not improve the odds of us
> > changing it.
>
> But ssh.com v2 was around before OpenSSH... they fixed a lot of things
> from v1 to v2, I liked that one and was disappointed to see openssh revert
> back...
i did not revert from their version.
openssh is based on 1.2.12 and we improved 1.2.12.
i never touched ssh.com's v2, because it's not free software.
many people refused to switch to ssh.com's v2, not only because of
the restrictive licence, but because all the configuration changed.
remember, most of the ssh users are still v1 users.
i'm not going to do this. and i won't support 10 different
ways of specifying keys. this is openssh and not perl.
moreover, i don't see much benefit for directories over files.
> My suggestion was only to put it into /contrib... is that OK then?
depends on the size of the patch. but if we have it in contrib,
then ppl will start to expect this from core-openssh.
-m
Jason Stone
Hash: SHA1
> Incompatibility sucks.
>
> OpenSSH is security software. A lot of you keep asking for more and
> more features, and the code keeps growing and growing and growing.
> Assuming that the number of lines per bug is a constant, how long
> before one of these features which noone uses becomes a hole?
>
> I think it is ridiculous how some people keep demanding change.
>
> Sorry, but I firmly believe that change for the sake of "I like it" is
> stupid.
I agree. However, taking such a stand brings with it a risk of
psuedo-forking. You say you won't take this patch because the feature is
unnecesary bloat. The patch writer says okay, and just rolls it in
himself on all his boxes. He also posts it on his website, and all the
other people who liked the idea download it and roll it into their local
installations.
Now bug reports start coming in, and incompatibilities start creeping in,
and if neither the bug reporter nor the developers realize that the
version in question has such an "un-authorized" patch, confusion will
result.
How many patches are already in this state? SecurID? SRP? Some sftp
chroot thing? Others? Again, I don't disagree with your statement, but
the resultant risk should also be considered.
-Jason
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg
iD8DBQE7G0V2swXMWWtptckRAvbrAJ4lST/reVBwdWFnUzWkPy/MiImmZACgxys3
BcDSNhpiXsSlSvjBx6TjS7M=
=BdQE
-----END PGP SIGNATURE-----
Theo de Raadt
> psuedo-forking. You say you won't take this patch because the feature is
> unnecesary bloat. The patch writer says okay, and just rolls it in
> himself on all his boxes. He also posts it on his website, and all the
> other people who liked the idea download it and roll it into their local
> installations.
By all means. It's free software. Go make a version that is
incompatible with all the various SSH books. Hang yourself.
Fact is, Silverman's book clearly describes how OpenSSH works now.
You want us to change it. Get real. This isn't even a smart
conversation, a smart idea, it's just stupid and wasting time.
> Now bug reports start coming in, and incompatibilities start creeping in,
> and if neither the bug reporter nor the developers realize that the
> version in question has such an "un-authorized" patch, confusion will
> result.
Yes, and Markus will simply ignore those people.
> How many patches are already in this state? SecurID? SRP? Some sftp
> chroot thing? Others? Again, I don't disagree with your statement, but
> the resultant risk should also be considered.
What you have stated is precisely what we are trying to avoid. That
is why you will not get me supporting all these "buttons".
I think we should not distribute them. If someone finds one, and uses
it, they are on their own. If they report a problem and are using
some tweak, I think Markus and us other main OpenSSH developers should
ignore those requests, and instead forward them to people like you.
Then you will get a taste of how retarded variations like that are.
Rob Hagopian
> On Mon, Jun 04, 2001 at 12:34:18AM -0400, Rob Hagopian wrote:
> > But ssh.com v2 was around before OpenSSH... they fixed a lot of things
> > from v1 to v2, I liked that one and was disappointed to see openssh revert
> > back...
>
> i did not revert from their version.
>
> openssh is based on 1.2.12 and we improved 1.2.12.
>
> i never touched ssh.com's v2, because it's not free software.
>
> many people refused to switch to ssh.com's v2, not only because of
> the restrictive licence, but because all the configuration changed.
>
> remember, most of the ssh users are still v1 users.
>
> i'm not going to do this. and i won't support 10 different
> ways of specifying keys. this is openssh and not perl.
>
> moreover, i don't see much benefit for directories over files.
Indeed, you never did touch the code base, but you still had to add a
number of features/changes to the code to support v2. Even if you did an
entirely clean room implementation (something I happen to think is a good
idea) I'd still maintain that the ssh v2 ability to store keys as files
came (long) before openssh v2 support.
Why even cater to those people? Even the FreeBSD security notices
specificly mention that ssh v1 has inherent security problems. I don't
even see why it's turned on by default for a distribution that
superficially appears so security concious.
> > My suggestion was only to put it into /contrib... is that OK then?
>
> depends on the size of the patch. but if we have it in contrib,
> then ppl will start to expect this from core-openssh.
I won't claim that that's completely untrue, I notice a lot of emails from
people who want stuff from the portable code base to migrate back into
core. But I don't think it's fair, or even wise, to reject what three
users want (with the only objections coming from committers who don't want
it in the core code base) to leave it out of contrib...
And a number of files in contrib are actually required to build all the
packages for at least redhat. Since portable openssh distributes binaries
of these packages aren't those basicly required to work?
Finally, if you don't want it in the code dists, what about a webpage with
contrib patches? That would even give you an indication of popularity of
these patches. Shutting out contributed code like this can only hurt the
project in the long run...
-Rob
mou...@etoh.eviladmin.org
On Mon, 4 Jun 2001, Rob Hagopian wrote:
> On Mon, 4 Jun 2001, Markus Friedl wrote:
>
[..]
> Why even cater to those people? Even the FreeBSD security notices
> specificly mention that ssh v1 has inherent security problems. I don't
> even see why it's turned on by default for a distribution that
> superficially appears so security concious.
>
Lets do a small reality check. OpenSSH has had a complete v2 compatibity
for how long now? 8 months? No.. 6 months? no.. 5 months? no.. Try
about a month.
Lets do another reality check. How many people are still using v1?
Still over 5x the user base of v2.
THIS IS TOTALLY STUPID. <sigh> v2 is default for all transactions as of
v2.9. Which means OpenSSH will only step down if (a) the users tells the
software to, (b) the v2 keys don't exist, and (c) If the remote side can
not speak v2. IMNSHO this is the correct behavior for at least another
year. Maybe by that time we can look at the v2 and v1 stats and consider
disabling v1.
Migration paths are required evils. Thus is the reason Markus has taken
painful amount writing all that compatibility code for v1. And thus is
the reason why ssh.com is a pain in the ass.
> > > My suggestion was only to put it into /contrib... is that OK then?
> >
> > depends on the size of the patch. but if we have it in contrib,
> > then ppl will start to expect this from core-openssh.
>
> I won't claim that that's completely untrue, I notice a lot of emails from
> people who want stuff from the portable code base to migrate back into
> core. But I don't think it's fair, or even wise, to reject what three
What portable code? OpenSSH portable should implement no 'new' features
outside what is required to get <Insert OS Name> to compile and run.
We attempt to bring in 'universal' changes back to the OpenBSD tree when
we feel it is right, but I see no reason why (Example) IRIX's overly
complex authetication code needs to be put into the clean OpenBSD tree.
> users want (with the only objections coming from committers who don't want
> it in the core code base) to leave it out of contrib...
>
I'll step up and state "No I do not feel that it's any easier to
track a single file vs multiple little files. Therefor I do not wish
to see such code added to the core tree."
If that makes any difference. I'm mainly on the Portable side of the
development (even if extremely busy and quietly lately).
> And a number of files in contrib are actually required to build all the
> packages for at least redhat. Since portable openssh distributes binaries
> of these packages aren't those basicly required to work?
>
You are trying to extend logic that is not correct. All but a few cases
in contrib/, the files are there to support the portable version
directly. You directly need contrib/redhat/ or else you have
authentication issues if you wish to use pam. This is nothing like "I
wan't feature XYZ, but no one wants to commit it therefor I demand it be
in contrib/."
> Finally, if you don't want it in the code dists, what about a webpage with
> contrib patches? That would even give you an indication of popularity of
> these patches. Shutting out contributed code like this can only hurt the
> project in the long run...
> -Rob
Requiring people like myself who help keep the OpenSSH portable tree alive
to maintain all those code snipets will hurt the project even more.
Because in the end it's the OpenBSD and OpenSSH Portable group stuck with
dragging this contrib code forward to each new release. Not the original
author who has long since left the mailinglist and potentially their job
and no longer cares about the patch they submitted.
I look at contrib/ diff files as yet another thing a user will bitch about
if it does not apply cleaningly. A 'feature' they would have never even
dreamed of had the *.diff file not existed. And one more headache to have
to worry about during crunch time in the release process.
Hell, at time I've almost removed contrib/chroot.diff because it was not
kept up.
Anyways, I've had enough of this.=) I have real work that needs to be
done.
- Ben
Gert Doering
On Mon, Jun 04, 2001 at 01:23:15AM -0700, Jason Stone wrote:
> > OpenSSH is security software. A lot of you keep asking for more and
> > more features, and the code keeps growing and growing and growing.
> > Assuming that the number of lines per bug is a constant, how long
> > before one of these features which noone uses becomes a hole?
> >
> > I think it is ridiculous how some people keep demanding change.
> >
> > Sorry, but I firmly believe that change for the sake of "I like it" is
> > stupid.
>
> I agree. However, taking such a stand brings with it a risk of
> psuedo-forking. You say you won't take this patch because the feature is
> unnecesary bloat. The patch writer says okay, and just rolls it in
> himself on all his boxes. He also posts it on his website, and all the
> other people who liked the idea download it and roll it into their local
> installations.
I second this - it's likely to happen sooner than later. There are a
number of things floating around that people *do* want to see, and one
day, somebody will start "FlexSSH". I don't think this is a good thing.
Which doesn't mean every single thinkable feature should go into the
OpenSSH code. But I don't think well-localized ones that touch only
a very few places are such a bad thing.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany ge...@greenie.muc.de
fax: +49-89-35655025 gert.d...@physik.tu-muenchen.de
Rob Hagopian
> Lets do a small reality check. OpenSSH has had a complete v2 compatibity
> for how long now? 8 months? No.. 6 months? no.. 5 months? no.. Try
> about a month.
>
> Lets do another reality check. How many people are still using v1?
> Still over 5x the user base of v2.
>
>
> THIS IS TOTALLY STUPID. <sigh> v2 is default for all transactions as of
> v2.9. Which means OpenSSH will only step down if (a) the users tells the
> software to, (b) the v2 keys don't exist, and (c) If the remote side can
> not speak v2. IMNSHO this is the correct behavior for at least another
> year. Maybe by that time we can look at the v2 and v1 stats and consider
> disabling v1.
>
> Migration paths are required evils. Thus is the reason Markus has taken
> painful amount writing all that compatibility code for v1. And thus is
> the reason why ssh.com is a pain in the ass.
So now security decisions are made via stats user stats and not on the
security merits? That's in direct contradiction to your reasoning for
excluding this patch.
> > I won't claim that that's completely untrue, I notice a lot of emails from
> > people who want stuff from the portable code base to migrate back into
> > core. But I don't think it's fair, or even wise, to reject what three
>
> What portable code? OpenSSH portable should implement no 'new' features
> outside what is required to get <Insert OS Name> to compile and run.
>
> We attempt to bring in 'universal' changes back to the OpenBSD tree when
> we feel it is right, but I see no reason why (Example) IRIX's overly
> complex authetication code needs to be put into the clean OpenBSD tree.
True, portable shouldn't add universal features, and that's another good
reason not to put it in main portable diffs. I understand Theo's arguments
for not putting it in the main code base as well considering the extensive
auditing that OpenBSD gets. I don't understand the objections to contrib,
unless there's a desire to eventually cause a fork.
> I'll step up and state "No I do not feel that it's any easier to
> track a single file vs multiple little files. Therefor I do not wish
> to see such code added to the core tree."
OK, that's 3:2, with the only objections coming from the developers
themselves. Way to listen to the users... isn't this exactly what happened
with gcc?
> > And a number of files in contrib are actually required to build all the
> > packages for at least redhat. Since portable openssh distributes binaries
> > of these packages aren't those basicly required to work?
> >
>
> You are trying to extend logic that is not correct. All but a few cases
> in contrib/, the files are there to support the portable version
> directly. You directly need contrib/redhat/ or else you have
> authentication issues if you wish to use pam. This is nothing like "I
> wan't feature XYZ, but no one wants to commit it therefor I demand it be
> in contrib/."
So you can't use gnome-ask-pass under openbsd? And my assertion has been
all along that there aren't enough patches (chroot.diff) in contrib that
this should be a big deal anyways.
> > Finally, if you don't want it in the code dists, what about a webpage with
> > contrib patches? That would even give you an indication of popularity of
> > these patches. Shutting out contributed code like this can only hurt the
> > project in the long run...
> > -Rob
>
> Requiring people like myself who help keep the OpenSSH portable tree alive
> to maintain all those code snipets will hurt the project even more.
> Because in the end it's the OpenBSD and OpenSSH Portable group stuck with
> dragging this contrib code forward to each new release. Not the original
> author who has long since left the mailinglist and potentially their job
> and no longer cares about the patch they submitted.
Excuse me? I NEVER said you should maintain the code snippet, only that
you should distribute it. Everything in every contrib is almost by
definition AYOR...
> I look at contrib/ diff files as yet another thing a user will bitch about
> if it does not apply cleaningly. A 'feature' they would have never even
> dreamed of had the *.diff file not existed. And one more headache to have
> to worry about during crunch time in the release process.
That certainly doesn't apply to this patch, ssh.com has this feature. In
fact, by excluding it you also exclude the possibilty that openssh could
be a drop in replacement for ssh.com (keeping existing keys) which would
reduce headaches for people rolling the software out. (Note that I don't
necessarily support that idea as I suspect the changes would be quite
extensive.)
> Hell, at time I've almost removed contrib/chroot.diff because it was not
> kept up.
So why didn't you? If it doesn't have a hope of working in the current
version why not remove it until someone fixes it? I never said you should
keep known broken code in the tree.
> Anyways, I've had enough of this.=) I have real work that needs to be
> done.
So do it and let users deal with contrib patches... I already described a
version system (like apaches) that would make it clear to developers when
they are working on/debugging contrib patched versions. There should be
zero effort on your part to include this. Certainly less than it's taken
to make a stand against extending the software.
-Rob
Markus Friedl
> I agree. However, taking such a stand brings with it a risk of
> psuedo-forking.
no, forking is not a reason for accepting every patch.
right now openssh is already a little bit too fat,
since i did accept to many patches in the past :)
so, perhaps, we should only add patches if the remove lines from
openssh and make everything _simpler_.
remember, this is a security program:
"complexity is the enemy"
-m
Markus Friedl
> OpenSSH changed from the ssh.com directory method... not that that's
> always a bad thing, I prefer not having a separate .ssh2 directory. But a
> lot of other unix utils have moved to file based rather than line based
> these systems find it easier to manage them this way... Do you object to
> /proc, pam, and SysV rc scripts as well?
so how do i use
sort
uniq
sed
if i use multiple files instead of a single file?
in a single file i can put the entries in a certain order.
there might be some uses for a-key-per-file, however,
they do not justify a change in the way openssh
is configured.
Markus Friedl
> Yes, keeping a file 100% in sync is way easier. But in real situations,
> you're often faced by the fact that e.g. 60-90% of the keys are the same,
> and the rest vary. Then syncing is a bit more difficult. Editing is also
> a bigger (ie: interactive) process when it has to be done on many hosts.
>
> A problem is backup files if you edit keys with an editor, ie. ones ending
> to e.g. ~ or # (depending on the editor). Then if you just delete the
> base key, the results might be unexpected. To counter this, filenames
> would be scanned and only those that contain only legal characters would
> pass.
yes, you name one of problems that appear with one-key-per-file.
it's also simpler to monitor a single file for changes.
it's easier to introduce races if you use multiple files.
but the main reason is:
there won't be 2 different ways for doing the same thing and
we won't drop the old scheme
so we will not use a-key-per-file
> > > What do you think -- would this be useful? Bloat? Could it be considered
> > > to be merged if it was implemented?
> >
> > i don't think it's useful. ssh.com switched to a-key-per-file,
> > but openssh and the traditional ssh use a-key-per-line
>
> I wasn't aware ssh.com is doing something like this too. So it might be
> something to be done sooner or later, though.
no, i don't think that we should try to clone their implementaion.
Markus Friedl
> Indeed, you never did touch the code base, but you still had to add a
> number of features/changes to the code to support v2.
the protocol is documented in an ietf draft.
> I'd still maintain that the ssh v2 ability to store keys as files
> came (long) before openssh v2 support.
of course. more software has been written before openssh v2.
> Why even cater to those people? Even the FreeBSD security notices
> specificly mention that ssh v1 has inherent security problems.
you mix talk about protocol and implementation.
> I don't
> even see why it's turned on by default for a distribution that
> superficially appears so security concious.
so, what's the problem with protocol v1?
even if it had inherent security problems, it's not inherent
in the way the public keys are stored.
> Finally, if you don't want it in the code dists, what about a webpage with
> contrib patches? That would even give you an indication of popularity of
> these patches. Shutting out contributed code like this can only hurt the
> project in the long run...
i'm not shutting out contributed code.
Markus Friedl
> So now security decisions are made via stats user stats and not on the
> security merits? That's in direct contradiction to your reasoning for
> excluding this patch.
what's wrong with protocol v1? does it matter to you?
Pekka Savola
>
> since i did accept to many patches in the past :)
>
> so, perhaps, we should only add patches if the remove lines from
> openssh and make everything _simpler_.
>
> remember, this is a security program:
>
> "complexity is the enemy"
Too much simplicity will also hinder usability, unfortunately. Some like
programs simpler than others; many think OpenBSD takes KISS paradigm
sometimes too far -- others like it that way. The extent of features
optimally included depends on the application. I consider ssh one of
those that needs more than the average. Just my humble IMO of course.
It would be nice if it was possible to get the main ssh/sshd thinner, and
put more functionality in completely non-privileged "modules". That way
security-critical code hopefully could be minimized and cleaned, while
keeping the usability and most features in.
Rob Hagopian
It's pretty sick, but: cat keys/* | sort | uniq | sed | split -l 1
But of course you lose filenames... you might be able to pull them out of
the comment field... but the point isn't to make it more difficult...
How do you see the time a key was added to your single file? Can you track
individual key changes through utils like tripwire? How about making some
keys immutable but allowing others to be updated? Can I make a symlink to
a common public key that root updates?
I'm not saying that there aren't advantages to a single file, although I'd
be a lot less likely to use sort/uniq/sed than I would be to make a key
immutable, but there are some advantages to separate files too.
As I think about it, I think that taking both and merging them gives even
more flexibility. If you allow multiple files, each with one *or more*
keys in it, you don't change the existing key lookup code except to
include more files in the searching (authorized_keys2 and
authorized_dir2/* or such).
A cursory look at the code looks to add about 10 lines of code to add that
functionality.
-Rob
On Mon, 4 Jun 2001, Markus Friedl wrote:
Markus Friedl
> I second this - it's likely to happen sooner than later. There are a
> number of things floating around that people *do* want to see, and one
> day, somebody will start "FlexSSH". I don't think this is a good thing.
>
> Which doesn't mean every single thinkable feature should go into the
> OpenSSH code. But I don't think well-localized ones that touch only
> a very few places are such a bad thing.
openssh is already to big, more than 40K lines, so i
see no reason for integrating every possible feature.
Markus Friedl
> On Mon, 4 Jun 2001, Markus Friedl wrote:
> >
> > since i did accept to many patches in the past :)
> >
> > so, perhaps, we should only add patches if the remove lines from
> > openssh and make everything _simpler_.
> >
> > remember, this is a security program:
> >
> > "complexity is the enemy"
>
> Too much simplicity will also hinder usability, unfortunately. Some like
maybe, but there is no 'simplicity' in OpenSSH, it's fat and
keeps getting fatter.
> programs simpler than others; many think OpenBSD takes KISS paradigm
> sometimes too far -- others like it that way.
"OpenBSD takes KISS paradigm sometimes too far"?
i really don't think that, OpenBSD is far away from plan9's simplicity.
Markus Friedl
> How do you see the time a key was added to your single file?
rcs
> Can you track
> individual key changes through utils like tripwire? How about making some
> keys immutable but allowing others to be updated?
this is not ssh's business. all entries should be immutable
to anybody but the user. the user should be able to edit all.
Rob Hagopian
"If you are running sshd, disable the use of the SSH1 protocol in
OpenSSH. SSH1 contains inherent protocol deficiencies and is not
recommended for use in high-security environments. Note that some
third-party SSH clients are not capable of using the SSH2 protocol,
however the OpenSSH client (version 2.1 and later) included in FreeBSD
is SSH2-capable."
No, it doesn't matter to me, although all of our higher security boxes
have ssh1 turned off.
It does worry me that openssh still has a significant amount of ssh.com
v1.2.xx code in it. I'm sure it's been audited a number of times, but
problems have still cropped up in it recently...
-Rob
On Mon, 4 Jun 2001, Markus Friedl wrote:
Pekka Savola
> > sometimes too far -- others like it that way.
>
> "OpenBSD takes KISS paradigm sometimes too far"?
>
> i really don't think that, OpenBSD is far away from plan9's simplicity.
See what it has amounted to: plan9 is not being used at all (at all so
that it counts anyway) and OpenBSD is mainly used by people who want their
code clean, or are rather security-conscious (basically).
So I don't think striving to make everything much simpler than it
currently is, is going to really work in general.
Rob Hagopian
> On Mon, Jun 04, 2001 at 04:11:54PM -0400, Rob Hagopian wrote:
> > How do you see the time a key was added to your single file?
>
> rcs
Fine, but with cvs I could check out individual key files, I can't do that
with cvs and a single file.
> > Can you track
> > individual key changes through utils like tripwire? How about making some
> > keys immutable but allowing others to be updated?
>
> this is not ssh's business. all entries should be immutable
> to anybody but the user. the user should be able to edit all.
Really... that's awfully heavy handed to lay down security policy like
that... In fact, I have a number of keys that I don't want the user to be
able to modify at all as we've had problems with that in the past. Not to
mention that immutable with a higher security level can not be changed at
all without a reboot.
And you didn't address sym links... (and if they are set up correctly by
the user I don't believe there are security issues)
The general point is that every OS I can think of has additional
capabilities that can be applied to individual files that can not be
applied to multiple lines within a file. Counter, as you noted, is that
programs to do bulk modifications (sort and uniq [most of sed's stuff can
be done in a loop on all keys]) don't work as well with multiple files. I
still don't see why we can't have both, esp in contrib.
Life is not simple, there is never one best solution for everyone. Where
possible and reasonable I don't see why openssh can't be made more
flexible. I strongly feel that this (what I envision as a 20 line patch
with low security implications) is one of those times.
-Rob
Theo de Raadt
Can you please start your own ssh derivitive project?
> I'm surprised you're advocating the use of sed on authorized_keys files!
>
> It's pretty sick, but: cat keys/* | sort | uniq | sed | split -l 1
> But of course you lose filenames... you might be able to pull them out of
> the comment field... but the point isn't to make it more difficult...
>
> How do you see the time a key was added to your single file? Can you track
> individual key changes through utils like tripwire? How about making some
> keys immutable but allowing others to be updated? Can I make a symlink to
> a common public key that root updates?
>
> I'm not saying that there aren't advantages to a single file, although I'd
> be a lot less likely to use sort/uniq/sed than I would be to make a key
> immutable, but there are some advantages to separate files too.
>
> As I think about it, I think that taking both and merging them gives even
> more flexibility. If you allow multiple files, each with one *or more*
> keys in it, you don't change the existing key lookup code except to
> include more files in the searching (authorized_keys2 and
> authorized_dir2/* or such).
>
> A cursory look at the code looks to add about 10 lines of code to add that
> functionality.
> -Rob
>
> On Mon, 4 Jun 2001, Markus Friedl wrote:
>
Theo de Raadt
> optimally included depends on the application. I consider ssh one of
> those that needs more than the average. Just my humble IMO of course.
>
> It would be nice if it was possible to get the main ssh/sshd thinner, and
> put more functionality in completely non-privileged "modules". That way
> security-critical code hopefully could be minimized and cleaned, while
> keeping the usability and most features in.
If any of you put in 1% of the work Markus has put in, we would listen to
you.
Am I being harsh?
Yes. Am I being realistic? Yes.
Theo de Raadt
> v1.2.xx code in it. I'm sure it's been audited a number of times, but
> problems have still cropped up in it recently...
We look forward to your patches. In the meantime, we are very tired
of your lengthy chit-chats, so send in fixes, or SHUT UP.
I can't believe how patient we are with people who yammer on and on and
on.
Markus Friedl
> It does worry me that openssh still has a significant amount of ssh.com
> v1.2.xx code in it. I'm sure it's been audited a number of times, but
> problems have still cropped up in it recently...
this is FUD.
the PROTOCOL contains some minor defects. this has NOTHING
to do with the 1.2.12 code.
-m
Corinna Vinschen
> If any of you put in 1% of the work Markus has put in, we would listen to
> you.
>
> Am I being harsh?
>
> Yes. Am I being realistic? Yes.
Just the same as in many projects. Many demands, no help.
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vins...@redhat.com
Damien Miller
> Why even cater to those people? Even the FreeBSD security notices
> specificly mention that ssh v1 has inherent security problems. I don't
> even see why it's turned on by default for a distribution that
> superficially appears so security concious.
Please spare us the pejorative tone.
Security software has to be _usable_ for it to be adopted, by offering
SSH protocol 1 support (which is no longer the default anyway) OpenSSH
has done more to migrate users off the legacy protocol than anyone
else.
If you _really_ want key-per-file, why not write a small tool that
can generate authorized_key{,2} from a key-per-file directory?
-d
--
| Damien Miller <d...@mindrot.org> \ ``E-mail attachments are the poor man's
| http://www.mindrot.org / distributed filesystem'' - Dan Geer
Damien Miller
> I'm surprised you're advocating the use of sed on authorized_keys files!
>
> It's pretty sick, but: cat keys/* | sort | uniq | sed | split -l 1
> But of course you lose filenames... you might be able to pull them out of
> the comment field... but the point isn't to make it more difficult...
Not much, it probably took you all of 10 seconds to write the previous
paragraph. It would take even less if you make is a script.
> How do you see the time a key was added to your single file? Can you track
> individual key changes through utils like tripwire? How about making some
> keys immutable but allowing others to be updated? Can I make a symlink to
> a common public key that root updates?
If you have special needs, patch your own source. Most of what you ask for
could be accomplished by teaching key_read() to ignore everything after
the '#' character (It may already) - you could dump whatever other
information you require in there.
Pekka Savola
> If you _really_ want key-per-file, why not write a small tool that
> can generate authorized_key{,2} from a key-per-file directory?
This is a very good idea, and IMO solves most of the problems brought up
here. It's still a bit cumbersome to do that daily for 1000 users but
that's kind of a corner-case and can be, to some extent, be worked around
(e.g. do it in shell initscripts, not cron).
Personally, I write code to the community as much as myself, and if it
isn't going to used widely, I'm not going to do it. This kind of tool
enables the best of the both worlds: if someone patches OpenSSH, no need
to run it; and it works with original OpenSSH too if someone wants the
functionality. And the main code base can be kept smaller if that is the
desire.
An external non-privileged module run from cron if I may ;-)
I had hoped the thread started by me hadn't degenerated into this kind
of "deep discussion". Oh well.
Gert Doering
On Tue, Jun 05, 2001 at 12:21:50AM +0200, Corinna Vinschen wrote:
> On Mon, Jun 04, 2001 at 03:40:58PM -0600, Theo de Raadt wrote:
> > If any of you put in 1% of the work Markus has put in, we would listen to
> > you.
> >
> > Am I being harsh?
> >
> > Yes. Am I being realistic? Yes.
>
> Just the same as in many projects. Many demands, no help.
While I originally wanted to stay out of this discussion, I just want to
point out that many of the people actually discussing here *have*
contributed - by testing "foreign" architectures and providing patches
(or at least input), or by offering patches that haven't been included.
So that's not really fair. The help *is* there, but it is rejected (in
case of the features being discussed).
James Ralston
I'm not really concerned with the authorized_keys{,2} entries. Where
I think the feature would be a win is with known_hosts{,2}. My
known_hosts file currently has 50+ entries, and it's a royal PITA to
maintain them.
The easiest way I've found to reliably keep files in sync across
different machines is rsync-over-ssh. That works great if the
granularity of change you're dealing with is a file, because rsync is
flexible enough to express conditions like:
1. Only add files that do not exist on the target.
2. Don't overwrite newer files on the target.
3. Delete files that exist on the target but not on the source.
But when the granularity of change is the *content* of an individual
file, this won't work. All I can tell using rsync is that the files
differ. To tell what those differences are, I have to scp the remote
file to the local system, diff it, figure out how to reconcile the
differences, modify the local version of the remote file, and then scp
it back to the remote system.
Now repeat this about a dozen times or so. It's a big waste of time,
and it's not fun.
And yes, this task would be simpler if I could always push my changes
out immediately after I make them. But that's not always possible
(due to firewalls and depending on whether I'm at work, home, or on
the road). And it's not always desirable either: my known_hosts files
are not strictly identical across all of the machines I access. (I
could, however, express "push-only-if-older-version-exists-on-target"
using rsync.)
On Sun, 3 Jun 2001, Markus Friedl wrote:
> i don't understand why editing a file is hard. i think keeping a
> file in sync is simpler than syncing directories, especially
> deleting files.
It might be simpler for you, but that doesn't mean it's simpler for
everyone.
On Sun, 3 Jun 2001, Theo de Raadt wrote:
> OpenSSH is security software. A lot of you keep asking for more and
> more features, and the code keeps growing and growing and growing.
> Assuming that the number of lines per bug is a constant, how long
> before one of these features which noone uses becomes a hole?
You have a good point: it would be unwise to carelessly add additional
features to OpenSSH.
However, good software grows or dies, and OpenSSH is no exception.
Carelessly *refusing* to add additional features to OpenSSH will
damage the project every bit as much (if not more so) than carelessly
adding additional features, because the former will antagonize more
people (including supporters and contributors, both current and
potential) than the latter.
And in terms of this feature, the complexity added is minimal.
Processing the subdirectory shouldn't require special pains, because
it exists in the user's ~/.ssh directory. If attacker can create
files or directories in the user's ~/.ssh directory, it's already Game
Over.
The effort required by the OpenSSH developers is also negligible,
because Pekka offered to write the patch. (Or at least that was my
interpretation; Pekka, please correct me if I'm placing words in your
mouth.)
I realize opinions may have been somewhat polarized by the resulting
almost-flamefest, but I think Pekka's original suggestion had merit.
Markus et. al., please [re]consider it.
--
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
Theo de Raadt
Sorry.
Gert Doering
On Fri, Jun 08, 2001 at 05:36:12PM -0400, James Ralston wrote:
> My $0.02: I'd like to see this feature.
>
> I'm not really concerned with the authorized_keys{,2} entries. Where
> I think the feature would be a win is with known_hosts{,2}. My
> known_hosts file currently has 50+ entries, and it's a royal PITA to
> maintain them.
Now for known_hosts, I tend to disagree - I don't see any compelling
reason to exclude hosts from that list. So what we do is just "collect
all host keys on one central machine, and distribute the complete file
from there".
With the keys, it's not that easy, as not everybody has access everywhere.