|
Home > Archive > Red Hat Security > January 2004 > Portable openssh.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Gladiator 2004-01-23, 7:50 pm |
| I hope someone can help me to understand one thing. 
What´s the difference between openssh from RedHat and from www.openssh.org?
I have installed a portable openssh 3.5p1-1.rpm on RedHat 7.3 and it was a
year ago.
Now I want to update the latest openssh with openssh-3.1p1-14.i386.rpm från
RedHat Network.
If you look at the version number it lower then the one I have installed, am
I upgrading or downgrading?
Whats the difference? Could anyone tell me or give a tips on a websites that
have this information for a newbie like me.
I did install the openssh-3.1p1-14.i386.rpm anyway on my server and it did
install new sshd_config.rpmnew.
But I restarted sshd without changing the sshd_config and I got following
errors on these options:
UsePrivilegeSeparation
KerberosAuthentication
KerberosOrLocalPasswd
KerberosTicketCleanup
Is my server more secure after the upgrade?
Billy
| |
|
| Gladiator wrote:
quote:
> If you look at the version number it lower then the one I have installed,
> am I upgrading or downgrading?
> Whats the difference? Could anyone tell me or give a tips on a websites
> that have this information for a newbie like me.
.... as a rule, the release of [third party] software from a distro
vendor will always be a little bit behind the third party software
vendor.
for example, suse offers gaim v.60, but i can get v.70 directly
from the gaim folks.
in the case of openssh, i'll bet you can update your system with
the latest [security] patches from red hat.
as far as the version numbers you provided: 3.7.1 is the current
release. you say you installed openssh 3.5p1-1.rpm last year
and that the latest at red hat is openssh-3.1p1-14.i386.rpm - yes,
that is for red hat 7.3. 3.5.p1 is for red hat 9. it stands to
reason that a software version for an older release of a distro
will be behind (lower #), as there will be dependencies on the
complete distro package.
..
--
/// Michael J. Tobler: motorcyclist, surfer, skydiver, \\\
\\\ and author: "Inside Linux", "C++ HowTo", "C++ Unleashed" ///
\\\ http://pages.sbcglobal.net/mtobler/mjt_linux_page.html ///
Children are natural mimic who act like their parents despite
every effort to teach them good manners.
| |
| Nico Kadel-Garcia 2004-01-23, 7:50 pm |
| Gladiator wrote:
quote:
> I hope someone can help me to understand one thing.
> What´s the difference between openssh from RedHat and from www.openssh.org?
> I have installed a portable openssh 3.5p1-1.rpm on RedHat 7.3 and it was a
> year ago.
> Now I want to update the latest openssh with openssh-3.1p1-14.i386.rpm från
> RedHat Network.
Redirected to comp.security.ssh.
OpenSSH does their development work on OpenBSD. All releases happen
first for that platform, and by working on a single platform, it eases
development *A LOT*. The most release is openssh-3.7.1
Another group does the cross-platform changes and patches as a set of
add-ons. These are the openssh-*.p* releases, currently openssh-3.7.1p1.
Many of the new OpenBSD releases have new features that have not been
robustly tested out under RedHat or other Linux releases, or that
significantly change its behavior. A classic case of this was 3.4p1,
which added the "privilege separation" which seriously broke OpenSSH on
a lot of platforms when left enabled, and broke compilation on other
systems.
RedHat, as a policy, seems to backport critical security and performance
patches from all sorts of software, such as OpenSSH, into their
published RPM updates rather than making wild leaps of the entire
package just to get the 10-line security patch. This has kept OpenSSH on
RedHat far, far more reliable and stable than the bleeding edge
openssh-*.p* releases.
quote:
> If you look at the version number it lower then the one I have installed, am
> I upgrading or downgrading?
> Whats the difference? Could anyone tell me or give a tips on a websites that
> have this information for a newbie like me.
www.redhat.com, and there are usually notes in the SRPM's and their
..spec files about patches that have been rolled in.
quote:
> I did install the openssh-3.1p1-14.i386.rpm anyway on my server and it did
> install new sshd_config.rpmnew.
> But I restarted sshd without changing the sshd_config and I got following
> errors on these options:
> UsePrivilegeSeparation
> KerberosAuthentication
> KerberosOrLocalPasswd
> KerberosTicketCleanup
You'll need to roll in appropriate options from your new
sshd_config.rpmnew into your current sshd_config. That sort of change is
why they try not to jump complete software revisions: if you'd jumped to
3.7.1p1, it would be even worse.
quote:
> Is my server more secure after the upgrade?
Probably. Are you using Kerberos? Do you want privilege separation? Turn
them on if you want or need them.
| |
| Bill Unruh 2004-01-23, 7:50 pm |
| "Gladiator" <billy@30plusplus.com> writes:
]I hope someone can help me to understand one thing.
]What´s the difference between openssh from RedHat and from www.openssh.org?
]I have installed a portable openssh 3.5p1-1.rpm on RedHat 7.3 and it was a
]year ago.
So you went out and got an ssh from the openssh site and installed it?
]Now I want to update the latest openssh with openssh-3.1p1-14.i386.rpm från
]RedHat Network.
And now want to use the RedHat openssh?
1
]If you look at the version number it lower then the one I have installed, am
]I upgrading or downgrading?
downgrading.
However you may have more security patches in the Redhat one.
Why did you install the version from 3.5 in the first place?
If you want to stay with 3.5, you could try downloading the openssh-3.5p1-11.src.rpm
from the Redhat security page, and recompiling that
rpm --rebuild openssh-3.5p1-11.src.rpm
Not guarenteed to work, but there is a chance.
]Whats the difference? Could anyone tell me or give a tips on a websites that
]have this information for a newbie like me.
Go to the openssh web site and look at the complete revision history of openssh to find out what
changes were made between 3.1 and 3.5. Then look at the Redhat patches to see what changes they
made. You obviously felt a year ago that you wanted something from 3.5 that the
standard Redhat issue for 7.3 did not saupply. What was that?
]I did install the openssh-3.1p1-14.i386.rpm anyway on my server and it did
]install new sshd_config.rpmnew.
]But I restarted sshd without changing the sshd_config and I got following
]errors on these options:
]UsePrivilegeSeparation
]KerberosAuthentication
]KerberosOrLocalPasswd
]KerberosTicketCleanup
Yes, there were changes in openssh from 3.1 to 3.5.
]Is my server more secure after the upgrade?
Who knows. You do not have the upgrades made from 3.1 to 3.5 You do have security bug fixes
installed by Redhat to 3.1
]Billy
| |
| Volker Birk 2004-01-23, 7:50 pm |
| In comp.os.linux.security Gladiator <billy@30plusplus.com> wrote:quote:
> What´s the difference between openssh from RedHat and from www.openssh.org?
The difference is that Redhed packages OpenSSH into an RPM.
quote:
> If you look at the version number it lower then the one I have installed, am
> I upgrading or downgrading?
Downgrading. By definition ;-)
quote:
> Is my server more secure after the upgrade?
Who knows?
VB.
--
X-Pie Software GmbH
Postfach 1540, 88334 Bad Waldsee
Phone +49-7524-996806 Fax +49-7524-996807
mailto:vb@x-pie.de http://www.x-pie.de
| |
| Nico Kadel-Garcia 2004-01-23, 7:50 pm |
| Volker Birk wrote:
quote:
> In comp.os.linux.security Gladiator <billy@30plusplus.com> wrote:
>
>
>
> The difference is that Redhed packages OpenSSH into an RPM.
>
>
>
>
> Downgrading. By definition ;-)
>
>
>
>
> Who knows?
My ghod, it *IS* Peter Breuer! It must be. No one else gives such
useless, snippy answers with so little content.
Read back to my reply. I explained how and why RedHat rolls back
security patches to older versions of software in older OS releases to
keep from breaking old setups with new features or configuration
changes. OpenSSH is a perfect example, because old and new sshd_config
setups *will not* work with other versions of the software. And there's
nothing quite like upgrading sshd over an SSH session and blowing away
your daemon because of configuration mismatch. *Fortunately*, the RedHat
init scripts seem to only kill the master daemon, not the client session
you're connected over, but if you lose that client session you're dead
meat and have to login at the console.
| |
| Volker Birk 2004-01-23, 7:50 pm |
| In comp.os.linux.security Nico Kadel-Garcia <nkadel@comcast.net> wrote:quote:
> My ghod, it *IS* Peter Breuer! It must be. No one else gives such
> useless, snippy answers with so little content.
Funny - WTF is "Peter Breuer"? *Asking Google* Shell I post with
my GnuPG signature for you? ;-)
quote:
> Read back to my reply. I explained how and why RedHat rolls back
> security patches to older versions of software in older OS releases to
> keep from breaking old setups with new features or configuration
> changes.
Because they're not translating the config files into the new syntax
if that is needed?
quote:
> OpenSSH is a perfect example, because old and new sshd_config
> setups *will not* work with other versions of the software. And there's
> nothing quite like upgrading sshd over an SSH session and blowing away
> your daemon because of configuration mismatch. *Fortunately*, the RedHat
> init scripts seem to only kill the master daemon, not the client session
> you're connected over, but if you lose that client session you're dead
> meat and have to login at the console.
Updating the deamon with which you're connected leads into the problem
to not remove your access to the box, of course.
What exactly was your point? BTW, if you don't want to read my postings,
why not adding me to your killfile?
VB.
--
X-Pie Software GmbH
Postfach 1540, 88334 Bad Waldsee
Phone +49-7524-996806 Fax +49-7524-996807
mailto:vb@x-pie.de http://www.x-pie.de
| |
| Nico Kadel-Garcia 2004-01-23, 7:50 pm |
| Volker Birk wrote:quote:
> In comp.os.linux.security Nico Kadel-Garcia <nkadel@comcast.net> wrote:
>
>
>
> Funny - WTF is "Peter Breuer"? *Asking Google* Shell I post with
> my GnuPG signature for you? ;-)
He's a guy who snaps off one-liner answers to newbie questions claiming
lots of knowledge, which translate to "RTFM" or "no one would ever need
to do that". He's not nice, and not helpful. You've actually shown far
more comprehension of the material elsewhere, so I'll take the Peter
Breuer claim back.
Please note, since we're posting in comp.os.linux.security: all a PGP
key proves is that you have the same key as someone who used it
elsewhere. It's next to useless for proving you're *NOT* someone else,
unless someone you trust signs each key and thus vouches for the
person's identity. But lots of people have signed PGP keys for aliases.
quote:
>
>
> Because they're not translating the config files into the new syntax
> if that is needed?
Because this process is extremely difficult to do reliably for an
automated procedure. Examples include sites that use alternative SSH
ports, and thus you'd have to find and auto-edit all of their
configuration files.
Bind and apache and NTP are almost as bad with local subtleties embedded
into the configurations that really need hand-holding to update.
Configuration testing these things is *work*.
quote:
>
>
> Updating the deamon with which you're connected leads into the problem
> to not remove your access to the box, of course.
Yup. I've literally faced this problem with machines across the coast,
doing security patches of tools like libc, glibc, kernels, SSH and
OpenSSH, etc.
quote:
> What exactly was your point? BTW, if you don't want to read my postings,
> why not adding me to your killfile?
As long as someone at least has *something* useful to say, which you
seem to (I took back the Peter Breuer shot!), I'd rather not. I prefer
to confront or correct errors than leave them unnoticed: it's why I
submit software patches....
| |
| Volker Birk 2004-01-23, 7:50 pm |
| In comp.os.linux.security Nico Kadel-Garcia <nkadel@comcast.net> wrote:quote:
> Please note, since we're posting in comp.os.linux.security: all a PGP
> key proves is that you have the same key as someone who used it
> elsewhere.
I'm looking forward to our next keysigning party ;-)
quote:
> Because this process is extremely difficult to do reliably for an
> automated procedure.
Sorry, no. With updating, normally you can assume that the features of
the old version is a subset of the features of the new version. So a
formal translation is not a big problem. But it would be good practice
to ask the user what she/he wants - keeping the old config file,
replacing this by a new one or rewriting the old config file to the
syntax of the new format. If you cannot assume that, you are warned
by the documentation and can decide from case to case.
Writing a compiler for config file formats with different versions
should be not complicated at all.
quote:
> Examples include sites that use alternative SSH
> ports, and thus you'd have to find and auto-edit all of their
> configuration files.
Not for updating. And that was the topic.
VB.
--
X-Pie Software GmbH
Postfach 1540, 88334 Bad Waldsee
Phone +49-7524-996806 Fax +49-7524-996807
mailto:vb@x-pie.de http://www.x-pie.de
| |
| Nico Kadel-Garcia 2004-01-23, 7:50 pm |
| Volker Birk wrote:
quote:
> In comp.os.linux.security Nico Kadel-Garcia <nkadel@comcast.net> wrote:
>
>
>
> I'm looking forward to our next keysigning party ;-)
>
>
>
>
> Sorry, no. With updating, normally you can assume that the features of
> the old version is a subset of the features of the new version. So a
> formal translation is not a big problem. But it would be good practice
> to ask the user what she/he wants - keeping the old config file,
> replacing this by a new one or rewriting the old config file to the
> syntax of the new format. If you cannot assume that, you are warned
> by the documentation and can decide from case to case.
Volker, I'm afraid this reasonable assumption is too often mistaken.
Examples include Apache, XFree86, and OpenSSL, which have compatibility
hooks in them for older configurations but are a bit of an adventure to
upgrade between completely different versions in the same OS
distribution. And it's often difficult to include "read the
documentation" in an automated update procedure. It's often simply safer
to backport security patches to the older version and release that, and
expect users to update the entire OS if they want to go to a new version
of such powerful tools.
quote:
> Writing a compiler for config file formats with different versions
> should be not complicated at all.
Heh. Heh-heh-heh-heh. Hah. Hah-hah-ha-ha-ha-BWA-HA-HA-HA-HA-HA!!!!!
Tee-hee. I'm sorry, that was really, really, funny. Please believe me
that in many cases, you'd have to replicate much of the configuration
file parsing capability of the software itself and replicate it in the
installation tools, indeed in the software management structure itself.
For any of us who've done a lot of shell scripting in any language, I
submit the example of "How do you handle 'comment' symbols inside of
quoted strings?"
quote:
>
>
> Not for updating. And that was the topic.
Well, actually, he was downgrading. That's even *harder*, since you'd
have to predict the format of future configuration files and revert them
appropriately....
| |
| Volker Birk 2004-01-23, 7:50 pm |
| In comp.os.linux.security Nico Kadel-Garcia <nkadel@comcast.net> wrote:
[software updates]quote:
> It's often simply safer
> to backport security patches to the older version and release that, and
> expect users to update the entire OS if they want to go to a new version
> of such powerful tools.
Hm... sorry, I cannot see that but with versions which are completely
different.
quote:
> Heh. Heh-heh-heh-heh. Hah. Hah-hah-ha-ha-ha-BWA-HA-HA-HA-HA-HA!!!!!
Hm... you're a blitheful guy, aren't you?
quote:
> For any of us who've done a lot of shell scripting in any language, I
> submit the example of "How do you handle 'comment' symbols inside of
> quoted strings?"
We're talking about config files, you'll remember. And we're talking
about a compiler, not "How do you handle 'comment' symbols inside of
uoted strings in shell scripts".
quote:
> Well, actually, he was downgrading. That's even *harder*, since you'd
> have to predict the format of future configuration files and revert them
> appropriately....
That is not computable.
VB.
--
X-Pie Software GmbH
Postfach 1540, 88334 Bad Waldsee
Phone +49-7524-996806 Fax +49-7524-996807
mailto:vb@x-pie.de http://www.x-pie.de
| |
| Nico Kadel-Garcia 2004-01-23, 7:50 pm |
| Volker Birk wrote:
quote:
> In comp.os.linux.security Nico Kadel-Garcia <nkadel@comcast.net> wrote:
quote:
>
>
> We're talking about config files, you'll remember. And we're talking
> about a compiler, not "How do you handle 'comment' symbols inside of
> uoted strings in shell scripts".
A compiler will run into the same issues. Configuration files take a
huge variety of formats, and unfortunately there are just not enough
standards in use to make a straightforward compiler of any sort. 3
examples might include:
local.ca A bind zone file for local zone configuration, in bind
parsable zone format.
named.conf The bind master configuration file, which is an entirely
different format.
sshd_config A very shell script like format
httpd.conf A very SGML like format
/etc/profile Straightforward Bourne-shell like format
/etc/cshrc C-cshell format
Etc., etc. It's not fair to wave your hands and say "we'll just use a
universal compiler to re-configure all configuration files on the fly".
They have to *read* the configuration files, and then *output* them in
the designated and wildly varying formats.
quote:
>
>
> That is not computable.
Yup. I've had to write add-on installation wrappers to do things like
that: it got pretty painful, and I had to explain that there would
always be a requirement for reversion tools to be published with new
software releases until we could discard all requirements for the old
software. That caused quite a bit of screaming, especially when I tried
to get the reversion tools into the Q/A process.....
| |
| Volker Birk 2004-01-23, 7:50 pm |
| In comp.os.linux.security Nico Kadel-Garcia <nkadel@comcast.net> wrote:quote:
> Etc., etc. It's not fair to wave your hands and say "we'll just use a
> universal compiler to re-configure all configuration files on the fly".
I never said that. And we're talking about one single package.
VB.
--
X-Pie Software GmbH
Postfach 1540, 88334 Bad Waldsee
Phone +49-7524-996806 Fax +49-7524-996807
mailto:vb@x-pie.de http://www.x-pie.de
| |
| all mail refused 2004-01-23, 7:50 pm |
| In article <Ka2dnTRfnYh5Sh2iU-KYhA@comcast.com>, Nico Kadel-Garcia wrote:
quote:
> local.ca A bind zone file ...
> named.conf The bind master ... different format.
> sshd_config A very shell script like format
> httpd.conf A very SGML like format
> /etc/profile Straightforward Bourne-shell like format
> /etc/cshrc C-cshell format
Also PAM. I recently wrote a pam.conf re-writer to go with the installation
of one particular s/w package. And that was only pam.conf, not pam.d/,
and only for Solaris. Even this needed doing twice after I realised that the
step of copying one line with certain transformations could apply to a block
of several lines. It's more work than writing PERL code for 5 OS versions.
I think the only way to installs where _complicated_ config files are
concerned (e.g. sudo) is to save the old config file (always a good move)
and write the new default one that matches the new s/w and let the admin
carry over any of his old settings into this.
--
I was less than impressed when one of my staff last year suggested
tunneling ftp through ssh. -- Evpuneq Erivf
|
|
|
|
|