Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Jun 2001 15:25:57 +0200
From:      Patrick Atamaniuk <patrick-lists@atabersk.de>
To:        freebsd-security@FreeBSD.ORG
Subject:   Re: Apache Software Foundation Server compromised, resecured. (fwd)
Message-ID:  <20010603152556.B51658@mail.atabersk.de>
In-Reply-To: <Pine.BSF.4.31.0106010850550.679-100000@localhost>; from brian@collab.net on Fri, Jun 01, 2001 at 08:55:16AM -0700
References:  <xzpvgmgwbvv.fsf@flood.ping.uio.no> <Pine.BSF.4.31.0106010850550.679-100000@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help

--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Brian Behlendorf(brian@collab.net)@2001.06.01 08:55:16 +0000:
> On 1 Jun 2001, Dag-Erling Smorgrav wrote:
> > You don't need passwords to run CVS against a remote repository.  All
> > you need is 'CVSROOT=3Duser@server:/path/to/repo' and 'CVS_RSH=3Dssh'.
>=20
> For those who use windows and mac GUI CVS clients, pserver's a
> requirement.
>=20
> IMHO, passwords are neither better nor worse, necessarily, than keys, in
> authenticating to a server.  The basic difference is between "what you
> know" and "what you have".  I'm as worried about people who have poor
> password management practices, as I am about people whose home or work
> machines where their private keys are may not be the most secure.
OR having the same private key on more than one machine.

The second problem is the practice of 'hopping', which then
involves typing pass[wd|phrase] on a trojaned client. Using ssh-agent or
not, using an untrusted client for performing challenge-response operations
caused the secondary attack to 3rd servers.
Host-hopping must become a banished practice.

If hopping has to be done, the untrusted client must not perform any
authentication to the 3rd server. This probably can be achieved with standa=
rd
port forwarding.
Assume i do have a private key on my local workstation A for host B and C.

i establish a tunnel from A to B:
A> ssh -L 9999:C:22 B
and use it with
A> ssh -p 9999 localhost

host B is only involed with authorized_keys authorizing the tunnel establis=
hment.
All authentication between C and A does not involve the client B decrypting=
 anything.
Though B can snoop the communication as it would be on local lan, it cannot=
 directly
intercept keystrokes for passphrase or perform AUTH_SOCK capturing.

imvho.

--=20
regards,
        Patrick

----------------------------------------------------
Patrick Atamaniuk       patrick@atabersk.de
----------------------------------------------------

--sm4nu43k4a2Rpi4c
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE7GjrkeMAU+YCwvPYRAjA1AKCjVhi7EX/4arFsQciBlsVcBh0C8wCeIQ57
vo5TK8jbVitfb4TXkCehuIE=
=xTSx
-----END PGP SIGNATURE-----

--sm4nu43k4a2Rpi4c--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010603152556.B51658>