I can ping it, and I just did an apt-get update which connected fine.
Maybe it just came back up.
Yes, it came back! Everything fine now ! ;-)
Cheers Jonas
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Good evening, all. I just went through the upgrade of SSH, and now I
cannot log into my potatoe box.
Luckly, I did keep a session logged in, for debugging don't you know. So
I can say that the debug error is as follows:
Jun 25 21:35:33 ian sshd[12644]: debug1: Starting up PAM with username
Ok, it's resolved.
I have never generated keys for ssh2 so, rather than fall back to ssh1,
it just fails.
If I tell the client to force ssh1 ssh -1, it works with the ssh1 RSA
keys just fine.
If I turn on password authentication, it fails back to that just fine.
I guess if the server and client
I am installing Debian but having problem to connect to non-us.debian.org,
Pls help. Thanks.
Fong Chu
- Original Message -
From: Jonas Weismüller [EMAIL PROTECTED]
To: debian-security@lists.debian.org
Sent: Wednesday, June 26, 2002 12:02 PM
Subject: Re: security.debian.org is down
I
Ng Fong Chu wrote:
I am installing Debian but having problem to connect to non-us.debian.org,
Pls help. Thanks.
Fong Chu
Have you tried the mirrors?
deb http://ftp.jp.debian.org/debian-non-US testing/non-US main contrib
non-free
--
September 11th, 2001
The proudest day for gun control
Both are on SurfNet in The netherlands, I suppose they went down for a
short while or the connection between your ISP and Surf went down.
Greetings,
Ivo van Dongen
-Original Message-
From: Ng Fong Chu [EMAIL PROTECTED]
Date: Wed, 26 Jun 2002 13:51:06 +0800
Subject: non-us.debian.org is
Back it out...
If you read the release notes you would have seen that the ssh
upgrade has problems with PAM. Use something like IPCHAINS or
IPTABLES to restrict which IP addresses are allowed to access
your box via SSH until such time that SSH using privilege
separation handles PAM properly.
On Wed, Jun 26, 2002 at 02:35:09PM +0900, Curt Howland wrote:
Ok, it's resolved.
I have never generated keys for ssh2 so, rather than fall back to ssh1,
it just fails.
If I tell the client to force ssh1 ssh -1, it works with the ssh1 RSA
keys just fine.
If I turn on password
It seems to be down again... I'm getting connection timed out messages,
though, I was able to connect a half hour ago.
On Tue, 2002-06-25 at 23:02, Jonas Weismüller wrote:
Yes, it came back! Everything fine now ! ;-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On 26 Jun 2002, David Bell wrote:
It seems to be down again... I'm getting connection timed out messages,
though, I was able to connect a half hour ago.
SurfNet (where s.d.o is hosted) is having some router gone wild. It tends
to be down one minute and up a few later. They're working on the
Title: Re: Problems with SSH Upgrade
Hi,
Disabling protocol version 2. Could not load host key
Restarting OpenBSD Secure Shell server: sshd
Disabling protocol version 2. Could not load host key
[SNIP]
Hi all
Messing up with sshd_config for all the privsep stuff, I've noticed that
PermitRootLogin was set to yes in my three woody boxes. I usually
consider this a problem (although it has been my fault - i should have
checked and noticed this much time ago). What do you think of this?
IMHO, we'd
Is
there any landscape in which you may want to allow direct
root login to
your host?
I allow it to my firewall, since there isnt any other account on there. but
then again, that system only listens to my internal interfaces.. So, not
typical maybe?
--
To UNSUBSCRIBE, email to [EMAIL
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis G?mez wrote:
IMHO, we'd better set it to no. I always thought it was much better. Is
there any landscape in which you may want to allow direct root login to
your host?
rsync where you want to keep userid/groupid info.
--
I tend to set it to without-password to allow a remote root entry only
via RSA/DSA keys, also making sure to restrict it further with as many
applicable options for AuthorizedKeysFile ( man sshd )
This is done as a restricated remote root backdoor as well as automated
network backups via dump
On Wed, Jun 26, 2002 at 02:11:00PM +0200 or thereabouts, InfoEmergencias - Luis
Gómez wrote:
Messing up with sshd_config for all the privsep stuff, I've noticed that
PermitRootLogin was set to yes in my three woody boxes. I usually
consider this a problem (although it has been my fault - i
On Wed, Jun 26, 2002 at 04:05:58PM +0200, Christoph Ulrich Scholler wrote:
On Wed, Jun 26, 2002 at 02:11:00PM +0200 or thereabouts, InfoEmergencias -
Luis Gómez wrote:
Messing up with sshd_config for all the privsep stuff, I've noticed that
PermitRootLogin was set to yes in my three woody
Simon Kirby [EMAIL PROTECTED] writes:
Using su root later is worse than just logging in as root with a key.
I cannot understand why using su root later would be worse. Can you
enlighten me?
--
Christian Egli
wyona: research development
http://www.wyona.com
--
To UNSUBSCRIBE, email to
Hi Mark,
From the OpenSSH web page:
At least one major security vulnerability exists in many deployed
OpenSSH versions (2.9.9 to 3.3). Please see the ISS advisory, or our own
OpenSSH advisory on this topic where simple patches are provided for the
pre-authentication problem. Systems running with
On Wed, Jun 26, 2002 at 04:05:58PM +0200, Christoph Ulrich Scholler wrote:
On Wed, Jun 26, 2002 at 02:11:00PM +0200 or thereabouts,
InfoEmergencias - Luis Gómez wrote:
Messing up with sshd_config for all the privsep stuff, I've noticed that
PermitRootLogin was set to yes in my three woody
On Wed, Jun 26, 2002 at 05:08:32PM +0200, Christian Egli wrote:
Simon Kirby [EMAIL PROTECTED] writes:
Using su root later is worse than just logging in as root with a key.
I cannot understand why using su root later would be worse. Can you
enlighten me?
Sure.
In all cases, you always
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote:
IMHO, we'd better set it to no. I always thought it was much better. Is
there any landscape in which you may want to allow direct root login to
your host?
Yes, there is. For example I have some servers that retrieve
El mié, 26-06-2002 a las 16:39, Sebastian Rittau escribió:
Yes, there is. For example I have some servers that retrieve their user
information from a database. If the database is not reachable, an
ordinary user can't login, but root can, since it's the only local
account with login privileges.
Sebastian Rittau [EMAIL PROTECTED] writes:
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote:
IMHO, we'd better set it to no. I always thought it was much better. Is
there any landscape in which you may want to allow direct root login to
your host?
Yes,
I am a bit worried about the ssh advisories, not the actual package
itself (well, that too) but the way it was handled -- the openssh team
issued new versions of a package and a security advisory asking
everyone to update to the new package, Debian and others jumped on it
and sent the new version
Hi Simon,
This one time, [EMAIL PROTECTED] wrote:
I am a bit worried about the ssh advisories, not the actual package
itself (well, that too) but the way it was handled -- the openssh team
issued new versions of a package and a security advisory asking
everyone to update to the new package,
Head over to OpenSSH.com
They have just released version 3.4, which should fix some overflow
problems and adds lot's of new checks against dubious input.
Advisories and updates on the various pages there.
Mark Janssen
Syconos IT Consultancy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Florian Weimer [EMAIL PROTECTED] writes:
Wichert Akkerman [EMAIL PROTECTED] writes:
Definitely. I really wish we could do more but the complete lack
of more information we have make things difficult. Backporting
OpenSSH 3.3p1 to to potato is also slightly complicated by missing
build
I think there may be a compromise solution here...
In short: it is good to make people log in as a normal user before trying
to log in as root, because that way an attacker needs to compromise a
normal user before starting on root. The standard way of doing this is
to use su, but that only
I don't see a better way of handling the OpenSSH announcement. More details or
a patch would have allowed people to start writing exploits, at least they
warned users of an upcoming bug and provided a work around. The OpenSSH team
had to communicate with many vendors and eventually the details
On Wed, 2002-06-26 at 13:23, Florian Weimer wrote:
Well, it appears if OpenSSH 1.2.3 was *not* vulnerable, so the whole
exercise was rather pointless.
Thanks, Theo.
Worst advisory ever.
-m
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
On Wed, Jun 26, 2002 at 07:23:49PM +0200, Florian Weimer wrote:
Well, it appears if OpenSSH 1.2.3 was *not* vulnerable, so the whole
exercise was rather pointless.
But drill inspector Theo (update and don't ask questions, soldier!), showed
at least how good our new security upload architecture
On Wednesday, 2002-06-26 at 18:14:35 +0200, Mark Janssen wrote:
From what I understand, the advisory below is for the security issue
we've been buggering over for the last 2-3 days.
As I understand it, there is no need to upgrade to openssh 3.3 and use
priv-sep code, when we turn of the
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote:
Hi all
Messing up with sshd_config for all the privsep stuff, I've noticed that
PermitRootLogin was set to yes in my three woody boxes. I usually
consider this a problem (although it has been my fault - i should
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So as it turns out, AFAIK, none of the versions of OpenSSH in Debian
were actually vulnerable to the exploit found by ISS and reported in
DSA-134
Potato wasn't vulnerable because it is SSH1 only, and the problem lies
in the
On Wed, Jun 26, 2002 at 02:35:21PM -0500, Paul Baker wrote:
I'm curious what recourse Debian is planning to take now? Perhaps
removing the buggy OpenSSH 3.3 packages off of security.debian.org so
people don't upgrade to it since it's not at all necessary and it will
only cause problems
This won't work. Have you noticed how EVERY MESSAGE says exactly how to do
it, and how you didn't do that?
You need to sent the message to [EMAIL PROTECTED]
On Wed, Jun 26, 2002 at 09:34:09PM +0200, [EMAIL PROTECTED] wrote:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
On Wed, 26 Jun 2002, Paul Baker wrote:
I'm curious what recourse Debian is planning to take now? Perhaps
removing the buggy OpenSSH 3.3 packages off of security.debian.org so
people don't upgrade to it since it's not at all necessary and it will
only cause problems like screwing up
On Wednesday, June 26, 2002, at 03:50 PM, Richard wrote:
Even worse, on 2.0.x kernels PrivilegeSeparation doesn't work,
rendinging sshd useless for interactive sessions or make it vurneble is
you disable it.
All debian versions of ssh packages are not vulnerable, AFAIK. I'm
hoping the
That's how monkey.org got taken over--they SCREENed a su, and the attacker
reattached it after getting as user via EPIC...
On 26 Jun 2002, Christian Egli wrote:
Simon Kirby [EMAIL PROTECTED] writes:
Using su root later is worse than just logging in as root with a key.
I cannot understand
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote:
Hi all
Messing up with sshd_config for all the privsep stuff, I've noticed that
PermitRootLogin was set to yes in my three woody boxes. I usually
consider this a problem (although it has been my fault - i should
hi all
if an attacker got in ... as a user game over... they got in ???
- question is what damage can they do as user ...
if an attacker get in the same way as root... game is really over...
as they now have complete control of yoru machine..
- i prefer to disallow root
-Original Message-
From: X-Force [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 26, 2002 9:56 PM
To: bugtraq@securityfocus.com
Subject: ISS Advisory: OpenSSH Remote Challenge Vulnerability
-BEGIN PGP SIGNED MESSAGE-
Internet Security Systems Security Advisory
June 26, 2002
hi ya
in order to update 10, 100 boxes ... with new setof changes..
you do NOT need to login into any of um ... many different ways to update
each target box based on some master distribution server
-- you do want to test the updates in a test farm before it goes out to
production and
Alvin,
If the cracker can get in as a user, it's merely a matter of time before they
can worm their way into becoming root. Defenses against this are difficult, the
NSA version SELinux deliberately places great restrictions on user abilities
to try to prevent just such things. But I don't
On Wed, 26 Jun 2002, Alvin Oga wrote:
hi all
if an attacker got in ... as a user game over... they got in ???
- question is what damage can they do as user ...
that's what happened--the EPIC hole gave user. monkey.org (Dug Song) was
using standard security practice at that
Travis Cole [EMAIL PROTECTED] writes:
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote:
Hi all
Messing up with sshd_config for all the privsep stuff, I've
noticed that PermitRootLogin was set to yes in my three woody
boxes. I usually consider this a
El mar, 25-06-2002 a las 12:40, Robert van der Meulen escribió:
and disclosure is only done when it doesn't affect
openbsd (or the '5 years without..' line on openbsd.org).
You'll love this one:
One remote hole in the default install, in nearly 6 years!
Great X'DD
Depending on the language
hi ya john
On Wed, 26 Jun 2002, John Galt wrote:
On Wed, 26 Jun 2002, Alvin Oga wrote:
if an attacker got in ... as a user game over... they got in ???
- question is what damage can they do as user ...
that's what happened--the EPIC hole gave user. monkey.org (Dug Song) was
50 matches
Mail list logo
