Why haven't the RSH tools been removed from the current Beta distribution?
-Chuck
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
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
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:
- Users who can't or won't change?
-or-
- 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
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
On Thu, 4 Sep 2003, Chuck Wolber wrote: [...]
- 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).
On Thu, 4 Sep 2003, Chuck Wolber wrote:
- 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.
- 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
On Fri, 5 Sep 2003, Rik van Riel wrote:
On Thu, 4 Sep 2003, Chuck Wolber wrote:
- 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
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:
- 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@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
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/