l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Jun 25 16:36

The following is an archive of a post made to our 'vox mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox] secure diary thoughts
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox] secure diary thoughts

> Quoting ME (dugan@passwall.com):
> > The local sysadmin can arrange for local access to memory, and can
> > trojan any application. SSH does *nothing* for securing a host. The
> > only thing that SSH tries to do is to "provide a more secure
> > connection across an insecure network." The assumption is that you
> > have both hosts secured from outsiders. Either host being comprimised
> > means increased risk to the other machine.

On Tue, 25 Jun 2002, Rick Moen wrote:
> Patching SSH to authenticate with OPIE, SKEY, or a SecureID card can fix 
> this (at the cost of significant inconvenience).

And these (above) raise the bar. An ssh from the machine administrated by
the untrusted admin can still be taken over on the tty and anything viewed
on that tty can be found and read by the "eviul admin". OTP, secured
passphrases, etc (and those listed above) are still effective at
insulating the machine at the other end from attack but still not entirely
impossible to trojan in order to local machine to attempt to issue
commands to the remote machine with the same access as the user who just
connected. Though an effective "password" that was used may not be useful
again in replay, injection of malicious commands in the newly created
session are still possible - with the same UID and privs of the person
connecting. And each step added (like the above suggestions from RM are
good) increases the level of complexity for a would-be attacker and
decreases the risk but does not eliminate it. (additional entrtires to
files in the remote users ~/.ssh/ dir for example.)

It is difficult to prevent an admin who has complete access to their files
on their box from being able to use their present access to their system
to leverage access to other systems when a user on the admin's box chooses
to remote login to a remote host that could be attacked - even if it is
only for present sessions and not being able to start others.

The "better" solution is to have an admin you can trust, or be the admin
yourself and make sure nobody else has admin control. :-)

When you only ssh *to* the machine that is remote and controlled by an
untrusted admin, you can have even better security.


Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html

vox mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!