Jeffrey Hutzelman writes: > So, my preference is for my platform-independent sshd_config to have the > same effect on the next Solaris port we do as it's had on every previous > platform since we started supporting ssh.
The config-file-overrides-SMF but default-config-file-is-empty proposal I made gives you exactly that. I don't think it's necessarily the cleanest solution, as our clear direction in most other places is that SMF is authoritative and the legacy configuration files are not. What's happened to inetd.conf is in line with that broader system-level plan. (No, I can't say I necessarily agree with that plan, but _is_ the plan of record, and having everyone do things a little bit differently is, I think, obviously worse than having consistent mechanisms.) Nicolas Williams writes: > E.g., I often manually run a server in debug mode on port 2222 on my > systems. It might be nice to be able to trivially create a new instance > of the ssh service that sets a debug option, another to set the file > where the debug msgs go, and the port number. If it were only me > running sshd instances in debug mode, who cares, but others have asked > for it to be easy to create additional instances for other purposes. I run two instances on my systems at home. One instance has "ListenAddress ::" and an explicit AllowUsers line for users that I know need to have access from the Internet. The other instance has explicit "ListenAddress 127.0.0.1 ListenAddress 192.168.1.1" on it. That allows access for all users on my internal (RFC 1918) network, and it happens to work because of a dubious bit of Solaris functionality that allows a bind to an address already in use in some cases. I wish I had a way to configure it that didn't require me to run two instances. It seems like a sloppy mechanism to me. I'd much rather be able to class the addresses into "internal" and "external," and then give users privileges to use one or the other or both. I tried futzing with SMF for a while to try to make this work, and I gave up. I ended up creating an /etc/rc3.d/S90ssh-local file that launches the second sshd with the "-f" option. Given the limitations here, having explicit support for multiple instances via SMF would be a much better thing for me. Darren Reed writes: > I really really don't like that recommendation. It sounds like you're railing against SMF itself rather than against my proposal. My proposal was to *KEEP* the text configuration file, *AND* make it authoritative over SMF. The enabling mechanism I suggested was shipping the *default* configuration file with all options commented out so that SMF *could* be used. In other words, I wasn't requiring SMF or changing the normal behavior at all. > Viewing things stored in SMF is not easy and nor is there > a way to present and edit what's stored in SMF with the > same ease as "vi /etc/ssh/sshd_config". We've been over this ground before. See the original Greenline case for details. I completely agree with you about the Good Things that are present in plain text configuration files. I said as much in my dissent on that case. However, the issue's been decided, and I'm uninterested in reopening and rearguing that case. If you want to do so, have at it, but please don't just strike off in a different architectural direction from everyone else. It makes the system poorer, not richer. > In a thread elsewhere, you commented about how web servers > use virtual hosts to do the "multiple instance" thing, rather than > have multiple instances of the software running (complexity > reasons.) I'd warrant that the same applies here: running more > than one instance of sshd isn't likely to be a"typical" task for > anyone (that isn't a ssh developer) as it involves changing > things like port numbers and addresses. As above, I've found reason to do it -- the configuration syntax that sshd provides isn't sufficiently rich to set up the security rules I want. Apache is a very different case, as it provides a *lot* of flexibility. If sshd provided a similar level of flexibility, I likely wouldn't want to have multiple instances, either. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
