Robert Watson wrote:
I.e., suppose you distributed a single identity.pub to a number of hosts
as authorized_key to log in. Suppose you make use of ssh-agent, and
ssh-add, to cache the keying material for use. Now suppose one of those
hosts is compromised--for the lifetime of your ssh
Ok, just to make sure everyone completely understands my previous post
about SSH xauth.
The whole issue is that by default the *SSH CLIENT* automagicly
requests xforwarding from the server if the client was run during an x
session.
The *entire* reason for the above post was NOT to alert people
Hi Robert,
This thread was about how default configurations can have negative
impact on security. You mention the CheckHostIP option in OpenSSH.
CheckHostIP defaults to 'yes'. It introduces only additional checks
and has not influence on permitting an SSH session to proceed. Thus it
has no
On Sat, 26 Feb 2000, David Pybus wrote:
The issue here has nothing to do with xauth and everything to do with the
trust granted by SSH. If you use SSH to connect to boxes that you don't
trust or can't be confident are secure then you should be concerned about
this. The major threat I see
On Mon, 28 Feb 2000, Niels Provos wrote:
This thread was about how default configurations can have negative
impact on security. You mention the CheckHostIP option in OpenSSH.
CheckHostIP defaults to 'yes'. It introduces only additional checks
and has not influence on permitting an SSH
All children of the SSH connection are able to tunnel X11 sessions
through the X tunnel to the client X11 session. This is
accomplished by running xauth upon logging in.
I'm really suprised this is still the default. I've heard mention of
this at least 4 years ago, and have seen
Robert Watson writes:
[...]
If you search back a few years in the bugtraq archives, you'll see that
one suggestion for dealing with this, and still allowing X11 forwarding
from untrusted clients, is to use the Xnest server, limiting access by the
ssh client to that DISPLAY. [...]
This
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All children of the SSH connection are able to tunnel X11 sessions
through the X tunnel to the client X11 session. This is
accomplished by running xauth upon logging in.
I'm really suprised this is still the default. I've heard mention of
this
On Thu, Feb 24, 2000 at 05:31:35PM -0500, Brian Caswell wrote:
The only thing that is required for the client system to be compromised
is for the client to remotely log via ssh (with X11 forwarding enabled)
into a compromised server.
And of course the sshd binary can be trojaned, your agent
[mailto:[EMAIL PROTECTED]]On Behalf Of Brian
Caswell
Sent: 24 February 2000 22:32
To: [EMAIL PROTECTED]
Subject: SSH xauth
The default SSH configuration for SSH1 and SSH2 allow for remote
controlling of X sessions through X forwarding.
All children of the SSH connection are able to tunnel X11
This is a very round-about way of observing that allowing X11 forwarding
from a client to any untrusted server (by any means -- sshd, xauth, common
accounts, poor file permissions, compromised kernel, etc, etc) with the
current SSH clients results in security problems (which you observe).
What's
In message [EMAIL PROTECTED], Brian Caswell writes:
The default SSH configuration for SSH1 and SSH2 allow for remote
controlling of X sessions through X forwarding.
[discussion of vulnerability edited out]
Allowing X forwarding seems to be turned on by default in SSH1, SSH2,
and OpenSSH.
12 matches
Mail list logo
