2:59 a.m.
Why haven't the RSH tools been removed from the current Beta distribution?
-Chuck
--
Quantum Linux Laboratories - ACCELERATING Business with Open Technology
* Education | -=^ Ad Astra Per Aspera ^=-
* Integration | http://www.quantumlinux.com
* Support | chuckw(a)quantumlinux.com
2:08 p.m.
On Thu, 2003-09-04 at 01:59, Chuck Wolber wrote:
Why haven't the RSH tools been removed from the current Beta
distribution?
Because that would be a bad move...
Lots of software assumes that those utilities are available. For
example, the Informix database cluster utilities automatically invoke
rsh.
Dax Kelson
Guru Labs
2:39 p.m.
> Why haven't the RSH tools been removed from the current
Beta
> distribution?
Because that would be a bad move...
Lots of software assumes that those utilities are available. For
example, the Informix database cluster utilities automatically invoke
rsh.
Indeed. I meant the post more as a troll to see what sort of issues would
be raised. So far I haven't seen anything that, at least at first glance,
couldn't be done with ssh and a symbolic link. Is the issue:
1) Users who can't or won't change?
-or-
2) SSH is simply not transparent enough to masquerade as rsh?
-Chuck
--
Quantum Linux Laboratories - ACCELERATING Business with Open Technology
* Education | -=^ Ad Astra Per Aspera ^=-
* Integration | http://www.quantumlinux.com
* Support | chuckw(a)quantumlinux.com
2:41 p.m.
On Thu, 2003-09-04 at 14:39, Chuck Wolber wrote:
Indeed. I meant the post more as a troll to see what sort of issues
would
be raised. So far I haven't seen anything that, at least at first glance,
couldn't be done with ssh and a symbolic link. Is the issue:
1) Users who can't or won't change?
-or-
2) SSH is simply not transparent enough to masquerade as rsh?
I doubt this is the case in 99% of cases.
I think you've hit the nail on the head with #1, I hear a lot of large
enterprise shops tell me "the documented standard says rsh || the
application vendor told me i had to have rsh", and all the technical
documentation in the world can't change their minds. I usually make them
aware of the security implications of plaintext transmissions, and let
them play with their toys.
~spot
2:48 p.m.
I think you've hit the nail on the head with #1, I hear a lot of
large
enterprise shops tell me "the documented standard says rsh || the
application vendor told me i had to have rsh", and all the technical
documentation in the world can't change their minds. I usually make them
aware of the security implications of plaintext transmissions, and let
them play with their toys.
To add to your comment, if you actually do convince them that trading keys
between machines and using rsh->ssh, you're the first one them blame when
something goes wrong. Quite frankly that sucks.
What is RedHat's customer experience when they have done stuff like
"masquerade" one app as another? IOW: Add a little code so that ssh is
aware of $0 and acts accordingly. At least that could start forcing the
migration path.
-Chuck
--
Quantum Linux Laboratories - ACCELERATING Business with Open Technology
* Education | -=^ Ad Astra Per Aspera ^=-
* Integration | http://www.quantumlinux.com
* Support | chuckw(a)quantumlinux.com
1:11 a.m.
On Thu, 4 Sep 2003, Chuck Wolber wrote:
[...]
2) SSH is simply not transparent enough to masquerade as rsh?
FYI,
Note that RhostAuthentication has recently been removed from OpenSSH CVS,
thus after that, SSH cannot be used as a direct rsh substitute (you have
to use HostbasedAuthentication or the like).
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
9:27 a.m.
On Thu, 4 Sep 2003, Chuck Wolber wrote:
1) Users who can't or won't change?
Think high performance computing clusters. It's faster
to start a remote job using rsh than using ssh.
Sure, you could argue that it's only a few %, but when
you're talking about really large clusters a few % means
a pile of computer equipment as expensive as a house ;)
Not something people want to waste.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
9:53 a.m.
> 1) Users who can't or won't change?
Think high performance computing clusters. It's faster to start a
remote job using rsh than using ssh.
Sure, you could argue that it's only a few %, but when you're talking
about really large clusters a few % means a pile of computer equipment
as expensive as a house ;)
I agree 100%. There's a difference though, between someone who operates a
250 kilodollar cluster and someone who follows "the manufacturers
instructions". It's probably a mute point though. Looks like there's ample
reason to keep RSH in. I'll just pack this thread away and unearth it
again in about 5 years...
-Chuck
--
Quantum Linux Laboratories - ACCELERATING Business with Open Technology
* Education | -=^ Ad Astra Per Aspera ^=-
* Integration | http://www.quantumlinux.com
* Support | chuckw(a)quantumlinux.com
9:58 a.m.
On Fri, 5 Sep 2003, Rik van Riel wrote:
On Thu, 4 Sep 2003, Chuck Wolber wrote:
> 1) Users who can't or won't change?
Think high performance computing clusters. It's faster
to start a remote job using rsh than using ssh.
One thing that might help there is if OpenSSH had a null cipher like
commercial SSH.com SSH does. You'd still get secure authentication (using
public key exchange), but then use no encryption for the data transfer once
connected. There are patches floating around for OpenSSH for this,
though they're not very current (or weren't last time I looked)....
For another large-environment advantage of rprotocols, they work with krb5,
while ssh requires patching for GSSAPI support.
later,
chris
10:18 a.m.
I think openssh-3.7p1 may have some form of SSHv2 Kerberos support in
it. It will either be a form that interoperates with ssh.com's krb
support or a version similar to the GSSAPI versions.
On Fri, 2003-09-05 at 08:58, Chris Ricker wrote:
On Fri, 5 Sep 2003, Rik van Riel wrote:
> On Thu, 4 Sep 2003, Chuck Wolber wrote:
>
> > 1) Users who can't or won't change?
>
> Think high performance computing clusters. It's faster
> to start a remote job using rsh than using ssh.
One thing that might help there is if OpenSSH had a null cipher like
commercial SSH.com SSH does. You'd still get secure authentication (using
public key exchange), but then use no encryption for the data transfer once
connected. There are patches floating around for OpenSSH for this,
though they're not very current (or weren't last time I looked)....
For another large-environment advantage of rprotocols, they work with krb5,
while ssh requires patching for GSSAPI support.
later,
chris
--
Rhl-devel-list mailing list
Rhl-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/rhl-devel-list
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #)
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
5:31 p.m.
One thing that might help there is if OpenSSH had a null cipher like
commercial SSH.com SSH does. You'd still get secure authentication (using
public key exchange), but then use no encryption for the data transfer once
connected. There are patches floating around for OpenSSH for this,
though they're not very current (or weren't last time I looked)....
Oh, my number one ssh pet peeve. What exactly is technically speaking
the problem with getting this in ? I never could figure out why this
wasn't just an option from the start. It's such a waste of CPU to rsync
30 GB over ssh on a local network.
Thomas
Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
Can we, like, have a dude conversation ?
I'm begging here !
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/
7537
days inactive
7538
days old
11 comments
9 participants
participants (9)
-
Bill Nottingham -
Chris Ricker -
Chuck Wolber -
Dax Kelson -
Pekka Savola -
Rik van Riel -
Stephen Smoogen -
Thomas Vander Stichele -
Tom Callaway