On 1 Jul 2002 at 22:38, Greg Morgan wrote: >I believe you need to correct your web site. It says that you changed >the location of ssh_config in the packages. I believe there are two >configuration files with one character different, a d. >ssh.lrp contains /etc/ssh/ssh_config. >sshd.lrp contains /etc/ssh/sshd_config.
Thanks for your comments, Greg. Yes, there are two configuration files. Jacques' packaging has: sshd.lrp containing /etc/ssh/ssh_config /etc/ssh/sshd_config ssh.lrp does not contain any /etc/ssh/*_config files These packages move only the /etc/ssh/ssh_config to ssh.lrp, and leave /etc/ssh/sshd_config in sshd.lrp My thinking was the config file should go with the program. I'm willing to have my thinking corrected, though. (Or is it just that the web page can have a better explanation?) >I was reading http://www.openssh.com/txt/preauth.adv under "1. Versions >affected: >... >OpenSSH 3.4 and later are not affected." > > >If the package you compiled fixes this problem and numerous others, >then is the idea here just to add additional protection by disabling >privileges escalation? Security safeguard on another safeguard may be a >good thing. But if privilege separation is not required in 3.4, is it >necessary to go through this? > >I am just trying to sort the issues out here. Any thoughts. Well, that's two of us trying to sort out the issues. :-) Brief answer: Yes, privilege separation is extra protection (against future attacks). No, its not necessary to go through creating a new user if you disable privilege separation in sshd_config. Long answer: According to http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102495293705094&w2 Privilege separation takes ~24500 lines of code and puts it in a chroot jail, leaving only ~2500 lines of code running as root. I believe the thinking here is that privilege separation doesn't fix this problem specifically; it makes it less likely for there to be privilege escalation in the future. Privilege separation was evidently available in earlier versions of openSSH, the difference is that it is now the default. To answer your question "is it necessary to go through this?" for deployed LEAF boxes, I'd probably be inclined to install the 3.4 OpenSSH, disable privilege separation in sshd_config, and go on. That should be a simple upgrade. The question (for me) is what about new LEAF installations and what about the future? One thing I really like about Bering is that Jacques is trying to stay close to "standard." The options that I see for ssh*.lrp are: - compile as default, create sshd user and group - compile with priviledge separation, but use "nobody" for chroot jail - compile without priviledge separation enabled At this point, a default compile of OpenSSH will use privilege separation with the sshd user. For new LEAF installations/releases, do we want to deviate from the (new) OpenSSH standard, or accomodate it and move on? Either answer is fine with me, as long as there is some sort of informed consensus. >Redhat says they are not vulnerable. >I did the did this in sshd_config file >and was denied service after I applied the Redhat patch. Funny. One of our sites changed his firewall rules to completely block port 22 traffic. He wasn't vulnerable either. :-) Thanks again! Nathan --- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel