Sure. and that would be fine for all the people who aren’t malicious.
> On Apr 11, 2017, at 7:53 PM, Tom <tomas.kuchta.li...@gmail.com> wrote: > > That is what contracts, firewalls, monitoring and compliance tools are > for. > If you do not trust users to start a process or use network ports - > disable their login and physical access to computers. > There are so many avenues which can be exploited beside ssh or any > myriad of other server processes. > Tomas > On Tue, 2017-04-11 at 18:41 -0500, Cryptomonkeys.org > <http://cryptomonkeys.org/> wrote: >> On Apr 10, 2017, at 2:17 PM, Jim Garrison <j...@jhmg.net> wrote: >>> >>> On 4/10/2017 8:22 AM, Paul Heinlein wrote: >>>> I've got a CentOS 7 VM running off in the cloud. It exposes SSH >>>> on >>>> port 22 to the world. I've thought about moving it to an >>>> alternate >>>> port, and may someday do so, but in the meantime I've tried to >>>> keep up >>>> with best practices for sshd configuration. >>>> >>>> I recently changed the KexAlgorithms setting, removing all >>>> key-exchange algorithms based on NIST curves. (Google variants of >>>> "ed25519 nist ssh ecdh" for my reasoning.) Anyway, the new >>>> setting: >>>> >>>> KexAlgorithms curve25519-sha...@libssh.org,diffie-hellman-group >>>> -exchange-sha256 >>>> >>>> All of my machines (MacOS 10.12, CentOS 6, CentOS 7) can work >>>> with >>>> this setting, so I don't have to worry about infinite backward >>>> compatibility. >>>> >>>> One interesting and unintended result of this change is that many >>>> SSH >>>> scanners will fail while trying to negotiate a key exchange. The >>>> log >>>> entries are short and sweet: >>>> >>>> sshd[18200]: fatal: Unable to negotiate a key exchange method >>>> [preauth] >>>> >>>> The number of scanners that even get through to the stage of >>>> 'Invalid >>>> user' has dropped from a couple hundred per day to less than a >>>> dozen. >>>> >>>> Everyone's situation is different, of course, and this alteration >>>> may >>>> not work in your environment -- but you may find it worthwhile >>>> raising >>>> the bar on the KexAlgorithm, Ciphers, and MACs in your >>>> sshd_config, >>>> especially if your SSH daemon is exposed to the world at large. >>>> >>> >>> I've been running sshd on a non-standard port above 5000 for about >>> 7 >>> years, on various hosting services, both real hardware and more >>> recently >>> virtual machines. I think in 7 years I've seen only **two** >>> attempted >>> connections and I think those were from someone just doing a >>> portscan, >>> as the log messages were one-offs and not repeated. >>> >>> There has never been any effort from anybody to actually connect. >>> >> Any thoughts on the consequences of arbitrary users being able to run >> their own sshd on port numbers >1024? Would that mean that if >> somebody got access to your machine, they could replace the listening >> sshd with their own? >> >> -- >> Louis Kowolowski >> lou...@cryptomonkeys.com >> Cryptomonkeys: >> http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/> >> <http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/>> >> >> >> >> _______________________________________________ >> PLUG mailing list >> PLUG@lists.pdxlinux.org <mailto:PLUG@lists.pdxlinux.org> >> http://lists.pdxlinux.org/mailman/listinfo/plug >> <http://lists.pdxlinux.org/mailman/listinfo/plug> > _______________________________________________ > PLUG mailing list > PLUG@lists.pdxlinux.org <mailto:PLUG@lists.pdxlinux.org> > http://lists.pdxlinux.org/mailman/listinfo/plug > <http://lists.pdxlinux.org/mailman/listinfo/plug> -- Louis Kowolowski lou...@cryptomonkeys.com Cryptomonkeys: http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/> _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug