Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Secure-Shell
[Top] [All Lists]

Re: Locking down ssh config in large env

Subject: Re: Locking down ssh config in large env
Date: Mon, 13 Sep 2004 11:02:07 +0300 (EEST)
Christopher.Price@encana.com (Price, Christopher) asked:

     I am also looking for a way in which to have ssh only reference a
global known_hosts file (eg: /usr/local/etc/known_hosts) and completely
ignore individual users .ssh/known_hosts entries. Effectively what I want is
a centrally managed and distributed known_hosts file to be used in
conjunction with StrictHostKeyChecking to not allow ssh connections from
hosts not listed in the global known_hosts file. The global known_hosts file

to which Alvin Oga of Ring Inc (linux-consulting.com) replied thus

a) we erase their changes if they change it ( trivial )
b) modify the ssh sources ( too much headache )

You are discounting the possibility that they might have their own
copies of ssh that could use a differently named configuration file.

if they have root passwds, all bets are off ... its a computer
usage policy issue if people will use their linux root skills
to get around corp security and usage policy

All bets are off even without users having to have root passwords.

If a compiler is available to the users of a computer, they can just
bring in the source code and compile their own version of ssh.  On a
computer with no compiler, they can bring in binaries compiled else-
where.  If the home directories and all user-writable locations (/tmp
etc) can be mounted with the noexec option, you may be able to slow
them down a little, but be prepared to accept the resulting drop in
usability (no self-made shell scripts any more, for example).

Unless Mr. Price forces his customers to use the restricted shell (which,
among other things, attempts to prevent the execution of programs that
are not in the PATH), he will have no way of accomplishing what he wants
in a reliable manner, and even then, it may not be entirely reliable.

You can modify the source code of the system standard ssh, you can over-
write the users' local configuration files as often as cron will allow
you, but unless you can prevent the running of binaries not provided by
the system administration all you are doing is just slowing them down,
not stopping them.

-- 
Atro Tossavainen (Mr.)               / The Institute of Biotechnology at
Systems Analyst, Techno-Amish &     / the University of Helsinki, Finland,
+358-9-19158939  UNIX Dinosaur     / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

<Prev in Thread] Current Thread [Next in Thread>