[PLUG] Public SSH server configs

Tom tomas.kuchta.lists at gmail.com
Wed Apr 12 00:53:14 UTC 2017


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 wrote:
> On Apr 10, 2017, at 2:17 PM, Jim Garrison <jhg at 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-sha256 at 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                                
> louisk at cryptomonkeys.com
> Cryptomonkeys:                                   
> http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/>
> 
> 
> 
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug


More information about the PLUG mailing list