Rob Owens wrote: > I think the main issue here is that LTSP 5 requires the use of ssh, and > it requires some relatively relaxed security settings -- in particular, > it requires that you allow password authentication. > > Jordan, I don't understand why you're so hell-bent on preventing an easy > fix for this. That's all these guys are trying to do. > Rob, to be honest I'm not sure why I'm so hellbent on this either. ;) I guess I just am. In my eyes, the "easy fix" is only easy for the admins who want it. If you really want a unique configuration, then whip it up. There's no need to spend time modifying what WORKS (LTSP) when all you really need to do is configure your services according to your specific needs, yourself.
> How's this for a fix: have LTSP use ssh on an alternate port (and > alternate pid, alternate config file, etc) *by default*. That way it > does not interfere with the way admins configure their "administrative > purposes" ssh daemon. There's no good reason that I can see that LTSP > needs to use port 22. > Well, I say there's no good reason NOT to run LTSP's sshd on port 22. I'm guessing that LTSP uses port 22 because port 22 is sshd's default port. People know it is. I don't know about you, but I'm happy that I get sshd on port 22 for my LTSP servers - that means I don't have to spend time configuring ssh to ALSO listen on port 22, or every time I ssh into a server to use the -p switch. Stick with the defaults whenever you can, because it avoids unnecessary complexity with the system as a whole. If you're so set on providing an "alternate" ssh daemon, just for administrators (which I think is really unnecessary to begin with since you can have any router portforward an alternate port to LTSP's 22), then by all means, set it up. All you have to do is create a secondary configuration file, edit it to your liking, and launch the daemon with -f /path/to/config. In all of my years administrating Linux/*nix servers, I've never heard of such a solution such as what's been proposed. It just doesn't make sense on a fundamental level. There are too many other options that make more sense and require very little effort on the part of the administrator. Besides, why bother the LTSP maintainers with this when their plates are already more than full? I really hope I don't come across as being a jerk here. I know there are a lot of admins out there that just aren't informed as to their options. I'm simply trying to provide them with what I think is the best solution, without modifying how LTSP already works. Cheers, Jordan/Lns > > Jordan Erickson wrote: > >> David Burgess wrote: >> >>>> Seriously, this conversation is getting kind of silly. I seriously see >>>> no need to launch a completely separate sshd just for administrators on >>>> a different port. There are plenty of network-layer utils available to >>>> secure a port from the outside world. There is no need to make >>>> LTSP/Edubuntu setups more complex for this purpose. If you need access >>>> to ssh from any IP on the net to your internal LTSP server, set it up - >>>> but I really don't think this is a common enough scenario to warrant a >>>> default secondary sshd for everyone. You're gonna get tons of admins >>>> asking "why do I have an open port 2222? Why the hell is ssh running on >>>> 2222??" >>>> >>>> >>> I have such a setup, and I agree that a second ssh should not run by >>> default. Indeed, most modern distros run with no server listening on >>> any port by default. Nevertheless I would advocate for making things a >>> little easier to get a second ssh running for those who need it. >>> >>> >> No offense, but this is what learning how openssh-server works is all >> about. >> >> >>> I, for one, need it, and it took me quite some time searching and then >>> some hand-holding from the list to get it going. Perhaps a new >>> optional package could be made available for this purpose. For >>> example, right now on ubuntu if I want to install and run an ssh >>> server I just use my package manager to install the openssh-server >>> package. Why not have an openssh-alternate-server or ltsp-ssh-server >>> package that is not a dependency of ltsp-server, openssh-server, or >>> any other package, but could be listed as "Recommends" or "Suggests" >>> by those packages. It would run be default on an alternate port and >>> could perhaps even ask the user, during configuration, which port and >>> interface to listen on. >>> >>> >> Creating and having to maintain a completely separate package for simply >> running an alternate configuration is absurd. Again, no offense, but >> seriously. Here, I'll even show you how to get sshd to listen on 2 ports: >> >> >> /etc/ssh/sshd_config: >> >> Port 22 >> Port 2222 >> >> You don't need 2 packages to have sshd listen on 2 different ports. >> Think about these things: >> >> - Any flaws/exploits in openssh-server will affect BOTH instances, which >> means it doesn't matter who you whitelist. Exploiting a flaw doesn't >> require credentials. >> - Running on an alternate, non-standard port for obscurity will foil >> only the most naive hackers/portscanners. Take a look at any >> sophisticated port scanner and it will connect to the port to see which >> service is running on it. Only the n00biest of n00bie hackers will >> assume that a non-standard open port is something non-important. What >> will attract their attention is that *there is an open port*. All you >> have to do is poke at it and it'll gladly give you enough information to >> figure out what's running on it. >> - Creating a new package and maintaining it for simply offering a >> default alternate configuration wouldn't fly with any sane maintainer. >> >> >> >>> Personally, I run my client-side ssh server on port 22 and my >>> internet-accessible ssh server on an alternate port. This way I don't >>> have to make yet another customisation to lts.conf and remote login >>> attempts from unknown users are virtually non-existant. >>> >>> If one was to create a package for a second server and minimise setup >>> headaches for the user, one would have to choose between a) altering >>> lts.conf so the clients would connect to the second server on an >>> alternate port, b) altering sshd_config so the primary ssh server >>> listens on an alternate port, or c) prompting the user to make one of >>> the above changes. I'm not really aware of the etiquette/implications >>> of a package messing with the config files of another package. >>> >>> I really do think that creating a package, or through some other >>> means, streamlining for the user the process of setting up a second >>> ssh server would be a big step toward making ltsp simpler to >>> administer, at least for the administrator that needs remote access. >>> >> What you're talking about really has nothing to do with LTSP, it has to >> do with openssh-server. And actually, it doesn't really even have much >> to do with that. You're talking about running a service on 2 ports at >> the same time, with alternate configurations on each. There's nothing >> holding you back from using the same daemon to run 2 different >> instances, and calling 2 different configuration files even, if you're >> really stuck on doing that. One "stock" for LTSP, and another to do >> whatever else you want. That's what the -f flag is for in sshd - to run >> an alternate config. >> >> >> Cheers, >> Jordan/Lns >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _____________________________________________________________________ >> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: >> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss >> For additional LTSP help, try #ltsp channel on irc.freenode.net >> > ******************************************************** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. If you are not the addressee, any disclosure, reproduction, > copying, distribution, or other dissemination or use of this transmission in > error please notify the sender immediately and then delete this e-mail. > E-mail transmission cannot be guaranteed to be secure or error free as > information could be intercepted, corrupted lost, destroyed, arrive late or > incomplete, or contain viruses. > The sender therefore does not accept liability for any errors or omissions > in the contents of this message which arise as a result of e-mail > transmission. If verification is required please request a hard copy > version. > > ******************************************************** > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _____________________________________________________________________ > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > For additional LTSP help, try #ltsp channel on irc.freenode.net > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
