Aahh... it is, thanks for the correction. It doesn't really change anything in our case though since it's still very easy to spoof a tcp connection when you have access to the local network (which in our case would be very common situation in our threat-models.
I had read about the role based authentication a while ago, but forgotten about it. Can't wait till it's GA!
I actually haven't read the specifics about it. Hopefully you can assign a role using ssh dsa/rsa keys as an authenticator (or other such auth system that doesn't autnenticate in the clear or suffer from MiTM, replay attacks, etc).
Are there lots of other people doing things like this out there? :)
On Tue, 2 Nov 2004, Chris Thompson wrote:
avarni@cj.com writes:
[... much sensible stuff about rsh ...]
The fact that rsh relies on the source IP address for authentication, coupled with the fact that rsh runs over UDP
Gone over the top there! rsh uses TCP to port 514.
No code is running on the filer. I just wrote a very basic client/server type that runs over ssh using no-password dsa keys. The client, running on the DB servers, connect to the server process running on the management server, to communicate the request.
One of the goodies described in the 7.0RC1 documentation is a whole bunch of security controls over which useradmin-defined users can do what (unlike the previous "they are all root except for the name" state). And as said before, ssh/ssl support is bundled in. It will be interesting to see whether that's going to be sufficient to make locally-developed workrounds like yours (and I am sure there are lots of them around) wither away, or not.
Chris Thompson Email: cet1@cam.ac.uk