Re: [cobalt-security] SSH Protocol 2

["E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>]

RS> Date: Sun, 30 Jun 2002 08:20:07 +0100
RS> From: Richard Sidlin


RS> I was making sure that I had only protocol 2 as my setting. I
RS> looked at sshd_config and nearly everything in there has a #

	sshd -?

will make sshd complain about invalid settings, and display valid
options.  Note that, by "-f", it displays the default config
file, including path.  It sounds like you have the proper file,
but this is a good way to confirm, assuming that "-f" isn't
overriding the default when sshd is started.


RS> before it. Is that the correct file to modify and should it
RS> be like that?

Should it be that way?  In short, yes.  Many options are unneeded
by default, but the config file serves as a handy place to
demonstrate their use.  Solution: comment out unused settings.

I usually

	cp some.cfg.file some.cfg.file.ORIG

to save the factory config file for reference, then build my own.
In mine, I strip out unneeded cruft, and comment as _I_ see fit.
Any time I want to check the original config file, I look at the
copy I made.

I also

	cp some.cfg.file some.cfg.file.KNOWNGOOD-20020630-0857

to make a time- and status-stamped backup of my config file
before editting.  Note that this is a good idea in general when
dealing with the RAQ's GUI.  If you've ever had a config file
autogenerated, overwriting your manual changes, you know why...

Yes, I could use rcs or cvs to archive my config files.  I don't
want the added complexity or dependency on any more binaries than
I need.


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@xxxxxxxxx>, or you are likely to
be blocked.