On Fri, 17 Aug 2001, Matthew Collins wrote: > If you insist on using ssh for your authentication/crypto layer a > more useful approach is probably to use strict host key checking on > both ends to do your host authentication and have the syslog backend I'd rather not do host checking...it implies that there is a mapping of all users from one host to the other, whereas what you really want is to provide a single key mapping to a single user. You have the same number of keys to deal with either way. > This has the advantage of integrating seamlessly into environments > which have already constructed large scale host key list generation > mechanisms without requiring manual intervention on the password file, > etc. One isn't required to touch the password file at all to use ssh. I was only recommending it as an additional measure. I would also recommend it if you were using an SSL solution; it's meant as an additional safety measure in the case of software failure. > Perhaps something like allowing RSA based shosts authentication for > a "syslog" user which doesnt have a usable shell, but rather spawns > the "write" part of your syslog replacement. That's exactly what I was proposing, except not using shosts but using user-based keys (a given user can have an unbounded number of keys). I don't see how this doesn't scale well to automatic generation. In any scheme, you need to at the very least - generate a key - put the private on the logging client - put the public key in a list on the host The simple ssh solution isn't any more difficult than that. > Personally, the approach we've used is tcp based syslog for reliability > over encryption with stunnel. I know folks who have done it using > zebedee and other tunneling software as well. How do you sort out the logs between two hosts? Do you run a separate stunnel on each port? Or do all of your logs just get concatenated? Or has stunnel now incorporated some way of switching commands based on key verification? Or are you not doing any authentication? -Peff --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Fri Aug 17 2001 - 22:11:36 PDT