ssh vulnerability in the wild
see tinyurl.com/nios Sorry if this is a rehash, but I dont recall seeing a discussion and I'd really like to think my stable boxes are safe :) I know several people that are being attacked/had to patch ssh/filter traffic. -- Mental ([EMAIL PROTECTED]) "The Torah... The Gospels... The Koran... Each claimed as the infallible word of GOD. Misquoted, misinterpreted, misunderstood, and misapplied. Maybe that's why he doesn't do any more interviews." - sinfest.net CARPE NOCTEM, QUAM MINIMUM CREDULA POSTERO. GPG public key: http://www.neverlight.com/pas/Mental.asc
Re: ssh vulnerability in the wild
Hi, Mental Patient wrote: > see tinyurl.com/nios > > Sorry if this is a rehash, but I dont recall seeing a discussion and I'd > really like to think my stable boxes are safe :) > > I know several people that are being attacked/had to patch ssh/filter > traffic. According to Wichert, the security team is already working on an update. - Alexander -- "Good luck... The only good thing about being compromised is that it makes you more paranoid about being on the net." - Jamie Lawrence on debian-security signature.asc Description: Digital signature
Re: ssh vulnerability in the wild
On Tue, 16 Sep 2003, Alexander Neumann wrote: > According to Wichert, the security team is already working on an update. Is there an emergency patch/workaround for this, if disabling ssh is not an option? Are systems with Privilege Separation affected? Thanks, Thomas
Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: Is there an emergency patch/workaround for this, if disabling ssh is not an option? No. Are systems with Privilege Separation affected? Yes, as far as I know. Mike Stone
Re: [d-security] Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > On Tue, 16 Sep 2003, Alexander Neumann wrote: > > > According to Wichert, the security team is already working on an update. > > Is there an emergency patch/workaround for this, if disabling ssh is not > an option? Are systems with Privilege Separation affected? The new version has already been installed. This was quick. Good work, security team. openssh (1:3.4p1-1.1) stable-security; urgency=high * NMU by the security team. * Merge patch from OpenBSD to fix a security problem in buffer handling -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 bye, -christian- -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 11:26:52AM -0400, Michael Stone wrote: > On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > >Is there an emergency patch/workaround for this, if disabling ssh is not > >an option? > > No. > Actually, there is a patch for buffer.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/openssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7&f=h I've applied that patch to woody's ssh source, rebuilt it, and installed it on a number of servers already. Hopefully that's the patch for this particular exploit. Not having seen the source code for the exploit, I have no idea what is being exploited. Steve
Re: ssh vulnerability in the wild
On Maw, 2003-09-16 at 16:26, Michael Stone wrote: > On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > >Is there an emergency patch/workaround for this, if disabling ssh is not > >an option? > > No. You could install Openssh 3.7 manually, or apply the patch mentioned at http://www.mindrot.org/pipermail/openssh-unix-announce/2003-September/63.html Gareth
Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > Is there an emergency patch/workaround for this, if disabling ssh is not > an option? Are systems with Privilege Separation affected? There's already a new package on security.debian.org. I can't vouch for it myself, but here's the changelog: openssh (1:3.4p1-1.1) stable-security; urgency=high * NMU by the security team. * Merge patch from OpenBSD to fix a security problem in buffer handling -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 Andrew
Re: ssh vulnerability in the wild
* Thomas Horsten ([EMAIL PROTECTED]) [030916 17:32]: > Is there an emergency patch/workaround for this, if disabling ssh is not > an option? Are systems with Privilege Separation affected? Filtering access to allow only trusted machines. But please remember: Each allowed machine could exploit your machine. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 04:49:19PM +0100, Thomas Horsten wrote: > Thanks, apt-get upgrade worked for me. I guess we'll find out soon enough > if it was the correct patch... > > Good work on getting it integrated so quickly! Heh. I can't take any credit for this. That's the work of the debian security team. I submitted a diff just in case they were busy elsewhere but I'm guessing they already had everything patched by then. Nice job to debian security team again. Steve
Re: sshd, pam and expired passwords
On Fri, Sep 12, 2003 at 03:47:32PM +0300, Juha J?ykk? wrote: > It seems I have managed to hit the ages-old problem of not being able to > enforce changing of expired passwords when logging in via ssh. > > This problem existed years ago in potato but I cannot seem to find any > mention of its existence or non-existence in woody. What is the situation > at the moment? As far as I know it is not possible to do this in any of stable, testing, and unstable at the moment. OpenSSH 3.7 should fix it. -- Colin Watson [EMAIL PROTECTED]
Re: OpenSSH
On Wed, Sep 03, 2003 at 11:20:45AM +0200, Matthias Faulstich wrote: > Hello, > > does anybody know, whether the chroot-patch will be included in future > versions of the official ssh package? Very unlikely unless you get it accepted by upstream. Doing this is the right thing to do anyway. -- Colin Watson [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Tue, 16 Sep 2003, Steve Suehring wrote: > Actually, there is a patch for buffer.c: > http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/openssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7&f=h > > I've applied that patch to woody's ssh source, rebuilt it, and installed > it on a number of servers already. Hopefully that's the patch for this > particular exploit. Not having seen the source code for the exploit, I > have no idea what is being exploited. Thanks, apt-get upgrade worked for me. I guess we'll find out soon enough if it was the correct patch... Good work on getting it integrated so quickly! Regards, Thomas
Re: ssh vulnerability in the wild
Mental Patient <[EMAIL PROTECTED]> [2003:09:16:10:22:01-0400] scribed: > see tinyurl.com/nios > > Sorry if this is a rehash, but I dont recall seeing a discussion and I'd > really like to think my stable boxes are safe :) > > I know several people that are being attacked/had to patch ssh/filter > traffic. openssh (1:3.6.1p2-6.0.fixed) unstable; urgency=low * Apply http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/openssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7 -- Ivo Timmermans <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:11:45 +0200 -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- pgpon99eKDhgj.pgp Description: PGP signature
Re: ssh vulnerability in the wild
On Tuesday, Sep 16, 2003, at 08:34 US/Pacific, Andreas Barth wrote: * Thomas Horsten ([EMAIL PROTECTED]) [030916 17:32]: Is there an emergency patch/workaround for this, if disabling ssh is not an option? Are systems with Privilege Separation affected? Filtering access to allow only trusted machines. But please remember: Each allowed machine could exploit your machine. Does this vulnerability require a login? Is a system safe if it does not allow root login, and password logins?
Re: ssh vulnerability in the wild
On Tue, 16 Sep 2003, Steve Suehring wrote: > Nice job to debian security team again. Indeed. The level of commitment routinely shown by the folks on the security team is nothing short of astounding.
Re: OpenSSH
> > does anybody know, whether the chroot-patch will be included in future > > versions of the official ssh package? What does this patch do? Voodooman
Re: [d-security] Re: ssh vulnerability in the wild
On 2003.09.16, Christian Hammers <[EMAIL PROTECTED]> wrote: > The new version has already been installed. This was quick. Good work, > security team. > > openssh (1:3.4p1-1.1) stable-security; urgency=high > > * NMU by the security team. > * Merge patch from OpenBSD to fix a security problem in buffer handling > > -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 Is 3.6.1p2-3 vulnerable? For those of us who want security, must we downgrade to 3.4p1-1.1 or build from source after patching by hand? Or will this security fix be applied to sarge as well? -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
Re: ssh vulnerability in the wild
Ted Roby <[EMAIL PROTECTED]> writes: > Does this vulnerability require a login? Is a system safe if it does not > allow root login, and password logins? Nobody knows the answer at the moment. There isn't any obvious way to exploit the overflow (mind that the attacker cannot write arbitrary data, just a couple of zeros), and I still doubt if it is exploitable at all.
Re: [d-security] Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 01:10:34PM -0400, Dossy wrote: > Is 3.6.1p2-3 vulnerable? For those of us who want security, must we > downgrade to 3.4p1-1.1 or build from source after patching by hand? Or > will this security fix be applied to sarge as well? I guess the patch will apply to sarge as well, so you can easily build a patched version yourself. Don't expect official security updates for testing. It'll be fixed when the version from sid gets promoted to sarge. Jan signature.asc Description: Digital signature
Re: ssh vulnerability in the wild
Actually, people have reported that there is an exploit, and in fact even OpenBSD is vulnerable. I would still patch ASAP. Best not to risk it. It's probably a matter of time before a widely available exploit is released. Right now it seems it's in the hands of a select few, but that will probably change sooner than later. By the way, you can grab the incoming openssh package from: http://incoming.debian.org/ssh_3.6.1p2-6.0_i386.deb if you want to patch your unstable system without building your own package with the buffer.c patch. (assuming i386 of course). I personally would like to see said exploit so I can test my systems post-patch. But I guess we'll have to trust the packages and/or buffer.c patch. Josh Florian Weimer ([EMAIL PROTECTED]) wrote: > Ted Roby <[EMAIL PROTECTED]> writes: > > > Does this vulnerability require a login? Is a system safe if it does not > > allow root login, and password logins? > > Nobody knows the answer at the moment. There isn't any obvious way to > exploit the overflow (mind that the attacker cannot write arbitrary > data, just a couple of zeros), and I still doubt if it is exploitable > at all. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: [d-security] Re: ssh vulnerability in the wild
* Dossy ([EMAIL PROTECTED]) wrote: > On 2003.09.16, Christian Hammers <[EMAIL PROTECTED]> wrote: > > The new version has already been installed. This was quick. Good work, > > security team. > > > > openssh (1:3.4p1-1.1) stable-security; urgency=high > > > > * NMU by the security team. > > * Merge patch from OpenBSD to fix a security problem in buffer handling > > > > -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 > > Is 3.6.1p2-3 vulnerable? For those of us who want security, must we > downgrade to 3.4p1-1.1 or build from source after patching by hand? Or > will this security fix be applied to sarge as well? There's at least a version on incoming.debian.org which has the version for unstable. I don't know what to tell you about testing/sarge. I'm sure it will be in before release but beyond that I've no idea when it will make it into testing. Stephen pgpudpP4hCqE2.pgp Description: PGP signature
Re: [d-security] Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 07:29:33PM +0200, Jan Niehusmann wrote: > On Tue, Sep 16, 2003 at 01:10:34PM -0400, Dossy wrote: > > Is 3.6.1p2-3 vulnerable? For those of us who want security, must we > > downgrade to 3.4p1-1.1 or build from source after patching by hand? Or > > will this security fix be applied to sarge as well? > I downgraded to be safe.
Re: ssh vulnerability in the wild
* Ted Roby ([EMAIL PROTECTED]) [030916 19:05]: > Does this vulnerability require a login? Is a system safe if it does not > allow root login, and password logins? No. (And: The patch is uploaded to stable-security, and to unstable, so just upgrade.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: [d-security] Re: ssh vulnerability in the wild
On 2003.09.16, Stephen Frost <[EMAIL PROTECTED]> wrote: > > Is 3.6.1p2-3 vulnerable? For those of us who want security, must we > > downgrade to 3.4p1-1.1 or build from source after patching by hand? Or > > will this security fix be applied to sarge as well? > > There's at least a version on incoming.debian.org which has the version > for unstable. I don't know what to tell you about testing/sarge. I'm > sure it will be in before release but beyond that I've no idea when it > will make it into testing. Eek. So, if we want to run secure systems, we either have to run unstable (and all the troubles that comes with) or stable? I find that "testing" is a good middle ground for a reasonably stable system but with reasonably up-to-date packages, so that's why I run it. Running "stable" involves hand-managing way too many packages that I do need more recent versions, and "unstable" involves way too many troubles if I apt-get update without carefully inspecting what's being updated, which I don't have the time for. :-( poop. Guess I'll go the deb-src route and hand-patch, I guess. Not what I wanted to do today ... ;-) -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
Re: ssh vulnerability in the wild
Hello, I don't really know much about computer security, but I do have ssh installed on my computer so I'm somewhat concerned, please forgive my stupidity if I ask questions that seem stupid, ignorant or trivial. When I read slashdot this morning, I thought the article titled "New ssh Exploit in the Wild" implied that an exploit was already out ... or does "in the Wild" generally mean it's theoretically possible, but not necessairly done yet? Also, from the sounds of the debian-security list, I get the impression that the SSH vulnerability is not as bad as it sounds -- but from the Slashdot posts (with people posting random sections of logs, links to RPMS/SRPMS, and suggesting alternatives) it seems as if the risk is most serious. Can anyone enlighten my ignorance on this? On a slightly off topic note, I'm thinking about running an ftp/http/ssh server for personal use in college. What precautionary measures should I take, or rather can I take? From reading over the various Slashdot posts, I'm thinking that beyond (1) making sure system isn't running any unnecessary servers (Debian seems pretty good in this by default) (2) making sure all software is up to date and (3) since it's a college campus, possibly being able to ask technical support for the subnet (correct word?) of all campus IP addresses, and only allowing access IP addresses on that subnet beyond all of that, there really isn't much that I can do is there? Thanks, --TongKe Xue --- Josh Carroll <[EMAIL PROTECTED]> wrote: > Actually, people have reported that there is an exploit, and in > fact even OpenBSD is vulnerable. > > I would still patch ASAP. Best not to risk it. > > It's probably a matter of time before a widely available exploit is > released. Right now it seems > it's in the hands of a select few, but that will probably change > sooner than later. > > By the way, you can grab the incoming openssh package from: > > http://incoming.debian.org/ssh_3.6.1p2-6.0_i386.deb > > if you want to patch your unstable system without building your own > package with the buffer.c > patch. (assuming i386 of course). > > I personally would like to see said exploit so I can test my > systems post-patch. But I guess > we'll have to trust the packages and/or buffer.c patch. > > Josh > > > Florian Weimer ([EMAIL PROTECTED]) wrote: > > Ted Roby <[EMAIL PROTECTED]> writes: > > > > > Does this vulnerability require a login? Is a system safe if it > does not > > > allow root login, and password logins? > > > > Nobody knows the answer at the moment. There isn't any obvious > way to > > exploit the overflow (mind that the attacker cannot write > arbitrary > > data, just a couple of zeros), and I still doubt if it is > exploitable > > at all. > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: [d-security] Re: ssh vulnerability in the wild
Quoting Stephen Frost ([EMAIL PROTECTED]): > There's at least a version on incoming.debian.org which has the version > for unstable. I don't know what to tell you about testing/sarge. I'm > sure it will be in before release but beyond that I've no idea when it > will make it into testing. The version in incoming _seems_ to cause no problems on testing/sarge if you're willing to install libc6 from unstable, which I've just done, and am so far seeing no problems. Versions: http://incoming.debian.org/ssh_3.6.1p2-7_i386.deb http://http.us.debian.org/debian/pool/main/g/glibc/libc6_2.3.2-7_i386.deb -- Cheers, Wall Street has all the emotional stability of a Rick Moenthirteen-year-old girl. -- Louis Rukeyser [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Tue, 16 Sep 2003, Josh Carroll wrote: > Actually, people have reported that there is an exploit, and in fact > even OpenBSD is vulnerable. A number of people have claimed that others have said it is exploitable. This is quite a common occurance with well publicised exploits. I've seen no proof of an exploit as yet. > I would still patch ASAP. Best not to risk it. Definately. This is always best practice regardless of whether there is a known exploit or not. Cheers, Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah
Re: ssh vulnerability in the wild
Josh Carroll <[EMAIL PROTECTED]> writes: > Actually, people have reported that there is an exploit, and in fact > even OpenBSD is vulnerable. Yes, I've seen these claims, but you have to keep in mind that not everyone who posts to mailing lists is entirely honest. 8-) Early claims such as "*BDDs, GNU/Linux and Solaris are all affected" should be taken with a grain of salt, especially if a heap-based overflow is involved. The malloc() implementations are quite different, and the *BSDs are less vulnerable to heap corruption than other systems. > I would still patch ASAP. Best not to risk it. If I was still busy recovering from MS03-039, I wouldn't stop this work in favor of this. My gut feeling is that it's okay to wait for vendor patches. > It's probably a matter of time before a widely available exploit is > released. First of all, the bug has to be actually exploitable. Please keep in mind that so far, *zero* evidence has been published that this is actually possible. If it is exploitable, it has to be an anonymous exploit (without proper login), unless it won't have a wide-spread impact. > I personally would like to see said exploit so I can test my systems > post-patch. At least you can use the package version indicator in the reply string to see which version of the binary is running.
Re: [d-security] Re: ssh vulnerability in the wild
Christian Hammers <[EMAIL PROTECTED]> écrivait (wrote) : > On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > > On Tue, 16 Sep 2003, Alexander Neumann wrote: > > > > > According to Wichert, the security team is already working on an update. > > > > Is there an emergency patch/workaround for this, if disabling ssh is not > > an option? Are systems with Privilege Separation affected? > > The new version has already been installed. This was quick. Good work, > security team. Same for most boxes here but there seem to be a versioning conflict between security update and woody proposed update : apt-cache policy ssh ssh: Installed: 1:3.4p1-1.woody.1 Candidate: 1:3.4p1-1.woody.1 Version Table: *** 1:3.4p1-1.woody.1 0 500 ftp://ftp.u-picardie.fr woody-proposed-updates/main Packages 100 /var/lib/dpkg/status 1:3.4p1-1.1 0 500 http://security.debian.org woody/updates/main Packages 1:3.4p1-1 0 500 ftp://ftp.u-picardie.fr woody/main Packages I will force the security.debian.org version to apply but I think people should be aware of the risq of using woody/updates and maybe one of the too should be renumbered. Jean Charles
ssh-krb5
Hello all, Is there a plan to update ssh-krb5 to handle the new buffer overflow, or is this already done in 3.4p1-0wood? Thanks, David Sayre Los Alamos National Labs
Re: [d-security] Re: ssh vulnerability in the wild
Dossy wrote: On 2003.09.16, Stephen Frost <[EMAIL PROTECTED]> wrote: Is 3.6.1p2-3 vulnerable? For those of us who want security, must we downgrade to 3.4p1-1.1 or build from source after patching by hand? Or will this security fix be applied to sarge as well? There's at least a version on incoming.debian.org which has the version for unstable. I don't know what to tell you about testing/sarge. I'm sure it will be in before release but beyond that I've no idea when it will make it into testing. Eek. So, if we want to run secure systems, we either have to run unstable (and all the troubles that comes with) or stable? I find that "testing" is a good middle ground for a reasonably stable system but with reasonably up-to-date packages, so that's why I run it. Running "stable" involves hand-managing way too many packages that I do need more recent versions, and "unstable" involves way too many troubles if I apt-get update without carefully inspecting what's being updated, which I don't have the time for. :-( poop. Guess I'll go the deb-src route and hand-patch, I guess. Not what I wanted to do today ... ;-) -- Dossy Or (to get a reasonably up to date system): * Set your default release to stable (I actually prefer to use distribution names, so that if I'm asleep at the switch when a new version is released I don't accidentally 'apt-get upgrade' when I should 'apt-get dist-upgrade') * Include testing and unstable in sources.conf * Include apt-src for testing and/or unstable. * Install a stable system, then for special needs, try 'apt-get install foo/testing' (or "foo/unstable"). If you can live with the dependancies, great. If things turn ugly, then apt-get source instead. This way, you'll have stable (with the corresponding security updates) for just about everything. For the few packages that need to be from unstable or testing, either patch them yourself, or watch incoming, or watch for others to contribute .debs. Plus, you can apt-get update && upgrade without having your system blow up. I've found fairly few cases where I actually *need* a more recent version, so this approach works great for me. In most cases, the only perceved need for a more recent version has been for security updates, which, of course, are backported in Debian stable. Of course, YMMV. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: [d-security] Re: ssh vulnerability in the wild
Quoting Dossy ([EMAIL PROTECTED]): > Eek. So, if we want to run secure systems, we either have to run > unstable (and all the troubles that comes with) or stable? The Security Team FAQ addresses this: http://www.debian.org/security/faq#testing Q: How is security handled for testing and unstable? A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, the security secretaries will try to fix problems in testing and unstable after they are fixed in the stable release. The FAQ is your friend. ;-> > I find that "testing" is a good middle ground for a reasonably stable > system but with reasonably up-to-date packages, so that's why I run > it. You can certainly do that. But the burden is on you to read DSAs and take manual action as needed. E.g., if a DSA says some exposed piece of software you elect to run has a vulnerability you care about, you might find it in your interest to do one of the following: 1. Downgrade to the stable branch's version. 2. Install the binary version from the unstable branch[1]. 3. apt-get source the unstable version, then recompile and dpkg -i it. 4. deb-src and hand-patch, as you say. 5. Switch temporarily from the affected package to an equivalent that isn't affected. (Remember, there's lsh, for example.) (The above is for the benefit of list readership at large. I'm certainly not suggesting you personally aren't aware of those options.) [1] Add Package: * Pin: release a=unstable Pin-Priority: 50 to /etc/apt/preferences. Have both testing and unstable lines in /etc/apt/sources.list . Then, after another apt-get update: # apt-get -t unstable install ...will get and any needed dependencies from the unstable branch. (Note that you cannot assume unstable automatically fixes security bugs.) Alternatively, use "=" syntax to fetch a specified package version: apt-get install somepackage=12.17.4-4 Tutorial: http://jaqque.sbih.org/kplug/apt-pinning.html -- Cheers, "I don't like country music, but I don't mean to denigrate Rick Moen those who do. And, for the people who like country music, [EMAIL PROTECTED] denigrate means 'put down'." -- Bob Newhart
Re: [d-security] Re: ssh vulnerability in the wild
* Dossy ([EMAIL PROTECTED]) wrote: > Eek. So, if we want to run secure systems, we either have to run > unstable (and all the troubles that comes with) or stable? I find that Old news... Sorry. Stephen pgpvTdoiywATE.pgp Description: PGP signature
Re: [d-security] Re: ssh vulnerability in the wild
## Jean Charles Delepine ([EMAIL PROTECTED]): > Same for most boxes here but there seem to be a versioning conflict > between security update and woody proposed update : I stumbled over this earlier this year. In short, "proposed-updates is NOT meant to be added by users." (Martin Schulze). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=182413&archive=yes Regards, cmt -- Spare Space
Re: ssh vulnerability in the wild
TongKe Xue <[EMAIL PROTECTED]> writes: > When I read slashdot this morning, I thought the article titled > "New ssh Exploit in the Wild" implied that an exploit was already out > ... Exactly. > or does "in the Wild" generally mean it's theoretically possible, > but not necessairly done yet? No, quite the contrary. The simple explanation is that the Slashdot posted a story which mostly contained speculation and exaggeration. Which is, when you think about it, just a typical Slashdot story. 8-/
Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 11:59:34AM -0700, TongKe Xue wrote: > Hello, Hi, > On a slightly off topic note, I'm thinking about running an > ftp/http/ssh server for personal use in college. What precautionary > measures should I take, or rather can I take? From reading over the > various Slashdot posts, I'm thinking that beyond > > (1) making sure system isn't running any unnecessary servers > (Debian seems pretty good in this by default) > (2) making sure all software is up to date > and > (3) since it's a college campus, possibly being able to ask > technical support for the subnet (correct word?) of all campus IP > addresses, and only allowing access IP addresses on that subnet > > beyond all of that, there really isn't much that I can do is there? Well, like everything else it depends how much time you want to spend on security. Is it an anonymous-only ftp? If not, encrypt the traffic to protect the usernames and passwords. Are you the only one that's going to connect with ssh? If not, consider chroot()ing the other accounts. Public webserver? If not, only allow certain addresses and use SSL/TLS if needed. Also consider building a custom kernel with, for example, PaX. Grsecurity (www.grsecurity.org) is a good kernel patch with PaX and a simple ACL among other things. If you're building your own packages, consider using the SSP (http://www.research.ibm.com/trl/projects/security/ssp/) patch for GCC. /Thomas -- == [EMAIL PROTECTED] | [EMAIL PROTECTED] == Encrypted e-mails preferred | GPG KeyID: 114AA85C -- signature.asc Description: Digital signature
RE: OpenSSH
Sven Hoexter wrote: > On Wed, Sep 03, 2003 at 11:20:45AM +0200, Matthias Faulstich wrote: > > Hi, > >> does anybody know, whether the chroot-patch will be included in >> future versions of the official ssh package? > To me it looks like you can do the same thing without patching the > sshd if you use scponlyc (scponly[1] shell with chroot() support). In testing and unstable there are scponly packages: http://tinyurl.com/nm0f [packages.debian.org] Another option if you are using testing or unstable is rssh: http://rssh.sourceforge.net/ http://tinyurl.com/nm0o [packages.debian.org] These both restrict the commands available to the user to allow only scp (and sftp e.tc. possibly). I know scponly can be recompiled with customised commands if required. -- Andrew StephenDDI:+64 4 460 6849 IT Security Architect Mobile: +64 25 582 304 New Zealand Post Fax:+64 4 494 4299 "...shouldn't a DMZ actually be called a Free Fire Zone?" -- Chris Mahn, Three Tiered DMZ's, May 2001 This email with any attachments is confidential and may be subject to legal privilege. If it is not intended for you please reply immediately, destroy it and do not copy, disclose or use it in any way.
Re: [d-security] Re: ssh vulnerability in the wild
Hello there, Christian Hammers schrieb: > > On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > > On Tue, 16 Sep 2003, Alexander Neumann wrote: > > > > > According to Wichert, the security team is already working on an update. > > The new version has already been installed. This was quick. Good work, > security team. > > openssh (1:3.4p1-1.1) stable-security; urgency=high > > * NMU by the security team. > * Merge patch from OpenBSD to fix a security problem in buffer handling > > -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 So only one problem remains: The version in woody-proposed-updates is 1:3.4p1-1.woody.1 which is "newer" than the patched version. So I had to manually "downgrade" my proposed-updates-version to get the fix. (apt-get dist-upgrade didn't show any packages to upgrade) When will there be a "new" version in proposed-updates for apt-getting the fix? bye, Matthias Merz smime.p7s Description: Kryptographische Unterschrift mit S/MIME
SSH Update for Potato?
Hi Guys, This might be a longshot, but is there an update for potato? Is it vulnerable? I unfortunately still have a few clients running potato boxes. :( I didnt see anything about potato in the DSA. On a more general note, is potato still supported by the Security Team? If not then I will definately urge these clients to upgrade (ive been trying thus far without success for these people to get upgraded to woody). I appreciate any feedback. Cheers, Shane.
ssh vulnerability in the wild
see tinyurl.com/nios Sorry if this is a rehash, but I dont recall seeing a discussion and I'd really like to think my stable boxes are safe :) I know several people that are being attacked/had to patch ssh/filter traffic. -- Mental ([EMAIL PROTECTED]) "The Torah... The Gospels... The Koran... Each claimed as the infallible word of GOD. Misquoted, misinterpreted, misunderstood, and misapplied. Maybe that's why he doesn't do any more interviews." - sinfest.net CARPE NOCTEM, QUAM MINIMUM CREDULA POSTERO. GPG public key: http://www.neverlight.com/pas/Mental.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
Hi, Mental Patient wrote: > see tinyurl.com/nios > > Sorry if this is a rehash, but I dont recall seeing a discussion and I'd > really like to think my stable boxes are safe :) > > I know several people that are being attacked/had to patch ssh/filter > traffic. According to Wichert, the security team is already working on an update. - Alexander -- "Good luck... The only good thing about being compromised is that it makes you more paranoid about being on the net." - Jamie Lawrence on debian-security signature.asc Description: Digital signature
Re: ssh vulnerability in the wild
On Tue, 16 Sep 2003, Alexander Neumann wrote: > According to Wichert, the security team is already working on an update. Is there an emergency patch/workaround for this, if disabling ssh is not an option? Are systems with Privilege Separation affected? Thanks, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: Is there an emergency patch/workaround for this, if disabling ssh is not an option? No. Are systems with Privilege Separation affected? Yes, as far as I know. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > On Tue, 16 Sep 2003, Alexander Neumann wrote: > > > According to Wichert, the security team is already working on an update. > > Is there an emergency patch/workaround for this, if disabling ssh is not > an option? Are systems with Privilege Separation affected? The new version has already been installed. This was quick. Good work, security team. openssh (1:3.4p1-1.1) stable-security; urgency=high * NMU by the security team. * Merge patch from OpenBSD to fix a security problem in buffer handling -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 bye, -christian- -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Maw, 2003-09-16 at 16:26, Michael Stone wrote: > On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > >Is there an emergency patch/workaround for this, if disabling ssh is not > >an option? > > No. You could install Openssh 3.7 manually, or apply the patch mentioned at http://www.mindrot.org/pipermail/openssh-unix-announce/2003-September/63.html Gareth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > Is there an emergency patch/workaround for this, if disabling ssh is not > an option? Are systems with Privilege Separation affected? There's already a new package on security.debian.org. I can't vouch for it myself, but here's the changelog: openssh (1:3.4p1-1.1) stable-security; urgency=high * NMU by the security team. * Merge patch from OpenBSD to fix a security problem in buffer handling -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 11:26:52AM -0400, Michael Stone wrote: > On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > >Is there an emergency patch/workaround for this, if disabling ssh is not > >an option? > > No. > Actually, there is a patch for buffer.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/openssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7&f=h I've applied that patch to woody's ssh source, rebuilt it, and installed it on a number of servers already. Hopefully that's the patch for this particular exploit. Not having seen the source code for the exploit, I have no idea what is being exploited. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
* Thomas Horsten ([EMAIL PROTECTED]) [030916 17:32]: > Is there an emergency patch/workaround for this, if disabling ssh is not > an option? Are systems with Privilege Separation affected? Filtering access to allow only trusted machines. But please remember: Each allowed machine could exploit your machine. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 04:49:19PM +0100, Thomas Horsten wrote: > Thanks, apt-get upgrade worked for me. I guess we'll find out soon enough > if it was the correct patch... > > Good work on getting it integrated so quickly! Heh. I can't take any credit for this. That's the work of the debian security team. I submitted a diff just in case they were busy elsewhere but I'm guessing they already had everything patched by then. Nice job to debian security team again. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sshd, pam and expired passwords
On Fri, Sep 12, 2003 at 03:47:32PM +0300, Juha J?ykk? wrote: > It seems I have managed to hit the ages-old problem of not being able to > enforce changing of expired passwords when logging in via ssh. > > This problem existed years ago in potato but I cannot seem to find any > mention of its existence or non-existence in woody. What is the situation > at the moment? As far as I know it is not possible to do this in any of stable, testing, and unstable at the moment. OpenSSH 3.7 should fix it. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenSSH
On Wed, Sep 03, 2003 at 11:20:45AM +0200, Matthias Faulstich wrote: > Hello, > > does anybody know, whether the chroot-patch will be included in future > versions of the official ssh package? Very unlikely unless you get it accepted by upstream. Doing this is the right thing to do anyway. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Tue, 16 Sep 2003, Steve Suehring wrote: > Actually, there is a patch for buffer.c: > http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/openssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7&f=h > > I've applied that patch to woody's ssh source, rebuilt it, and installed > it on a number of servers already. Hopefully that's the patch for this > particular exploit. Not having seen the source code for the exploit, I > have no idea what is being exploited. Thanks, apt-get upgrade worked for me. I guess we'll find out soon enough if it was the correct patch... Good work on getting it integrated so quickly! Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
Mental Patient <[EMAIL PROTECTED]> [2003:09:16:10:22:01-0400] scribed: > see tinyurl.com/nios > > Sorry if this is a rehash, but I dont recall seeing a discussion and I'd > really like to think my stable boxes are safe :) > > I know several people that are being attacked/had to patch ssh/filter > traffic. openssh (1:3.6.1p2-6.0.fixed) unstable; urgency=low * Apply http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/openssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7 -- Ivo Timmermans <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:11:45 +0200 -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- pgp0.pgp Description: PGP signature
Re: ssh vulnerability in the wild
On Tuesday, Sep 16, 2003, at 08:34 US/Pacific, Andreas Barth wrote: * Thomas Horsten ([EMAIL PROTECTED]) [030916 17:32]: Is there an emergency patch/workaround for this, if disabling ssh is not an option? Are systems with Privilege Separation affected? Filtering access to allow only trusted machines. But please remember: Each allowed machine could exploit your machine. Does this vulnerability require a login? Is a system safe if it does not allow root login, and password logins? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Tue, 16 Sep 2003, Steve Suehring wrote: > Nice job to debian security team again. Indeed. The level of commitment routinely shown by the folks on the security team is nothing short of astounding. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenSSH
> > does anybody know, whether the chroot-patch will be included in future > > versions of the official ssh package? What does this patch do? Voodooman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
On 2003.09.16, Christian Hammers <[EMAIL PROTECTED]> wrote: > The new version has already been installed. This was quick. Good work, > security team. > > openssh (1:3.4p1-1.1) stable-security; urgency=high > > * NMU by the security team. > * Merge patch from OpenBSD to fix a security problem in buffer handling > > -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 Is 3.6.1p2-3 vulnerable? For those of us who want security, must we downgrade to 3.4p1-1.1 or build from source after patching by hand? Or will this security fix be applied to sarge as well? -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
Ted Roby <[EMAIL PROTECTED]> writes: > Does this vulnerability require a login? Is a system safe if it does not > allow root login, and password logins? Nobody knows the answer at the moment. There isn't any obvious way to exploit the overflow (mind that the attacker cannot write arbitrary data, just a couple of zeros), and I still doubt if it is exploitable at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 01:10:34PM -0400, Dossy wrote: > Is 3.6.1p2-3 vulnerable? For those of us who want security, must we > downgrade to 3.4p1-1.1 or build from source after patching by hand? Or > will this security fix be applied to sarge as well? I guess the patch will apply to sarge as well, so you can easily build a patched version yourself. Don't expect official security updates for testing. It'll be fixed when the version from sid gets promoted to sarge. Jan signature.asc Description: Digital signature
Re: ssh vulnerability in the wild
Actually, people have reported that there is an exploit, and in fact even OpenBSD is vulnerable. I would still patch ASAP. Best not to risk it. It's probably a matter of time before a widely available exploit is released. Right now it seems it's in the hands of a select few, but that will probably change sooner than later. By the way, you can grab the incoming openssh package from: http://incoming.debian.org/ssh_3.6.1p2-6.0_i386.deb if you want to patch your unstable system without building your own package with the buffer.c patch. (assuming i386 of course). I personally would like to see said exploit so I can test my systems post-patch. But I guess we'll have to trust the packages and/or buffer.c patch. Josh Florian Weimer ([EMAIL PROTECTED]) wrote: > Ted Roby <[EMAIL PROTECTED]> writes: > > > Does this vulnerability require a login? Is a system safe if it does not > > allow root login, and password logins? > > Nobody knows the answer at the moment. There isn't any obvious way to > exploit the overflow (mind that the attacker cannot write arbitrary > data, just a couple of zeros), and I still doubt if it is exploitable > at all. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
* Dossy ([EMAIL PROTECTED]) wrote: > On 2003.09.16, Christian Hammers <[EMAIL PROTECTED]> wrote: > > The new version has already been installed. This was quick. Good work, > > security team. > > > > openssh (1:3.4p1-1.1) stable-security; urgency=high > > > > * NMU by the security team. > > * Merge patch from OpenBSD to fix a security problem in buffer handling > > > > -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 > > Is 3.6.1p2-3 vulnerable? For those of us who want security, must we > downgrade to 3.4p1-1.1 or build from source after patching by hand? Or > will this security fix be applied to sarge as well? There's at least a version on incoming.debian.org which has the version for unstable. I don't know what to tell you about testing/sarge. I'm sure it will be in before release but beyond that I've no idea when it will make it into testing. Stephen pgp0.pgp Description: PGP signature
Re: [d-security] Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 07:29:33PM +0200, Jan Niehusmann wrote: > On Tue, Sep 16, 2003 at 01:10:34PM -0400, Dossy wrote: > > Is 3.6.1p2-3 vulnerable? For those of us who want security, must we > > downgrade to 3.4p1-1.1 or build from source after patching by hand? Or > > will this security fix be applied to sarge as well? > I downgraded to be safe. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
* Ted Roby ([EMAIL PROTECTED]) [030916 19:05]: > Does this vulnerability require a login? Is a system safe if it does not > allow root login, and password logins? No. (And: The patch is uploaded to stable-security, and to unstable, so just upgrade.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
On 2003.09.16, Stephen Frost <[EMAIL PROTECTED]> wrote: > > Is 3.6.1p2-3 vulnerable? For those of us who want security, must we > > downgrade to 3.4p1-1.1 or build from source after patching by hand? Or > > will this security fix be applied to sarge as well? > > There's at least a version on incoming.debian.org which has the version > for unstable. I don't know what to tell you about testing/sarge. I'm > sure it will be in before release but beyond that I've no idea when it > will make it into testing. Eek. So, if we want to run secure systems, we either have to run unstable (and all the troubles that comes with) or stable? I find that "testing" is a good middle ground for a reasonably stable system but with reasonably up-to-date packages, so that's why I run it. Running "stable" involves hand-managing way too many packages that I do need more recent versions, and "unstable" involves way too many troubles if I apt-get update without carefully inspecting what's being updated, which I don't have the time for. :-( poop. Guess I'll go the deb-src route and hand-patch, I guess. Not what I wanted to do today ... ;-) -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
Hello, I don't really know much about computer security, but I do have ssh installed on my computer so I'm somewhat concerned, please forgive my stupidity if I ask questions that seem stupid, ignorant or trivial. When I read slashdot this morning, I thought the article titled "New ssh Exploit in the Wild" implied that an exploit was already out ... or does "in the Wild" generally mean it's theoretically possible, but not necessairly done yet? Also, from the sounds of the debian-security list, I get the impression that the SSH vulnerability is not as bad as it sounds -- but from the Slashdot posts (with people posting random sections of logs, links to RPMS/SRPMS, and suggesting alternatives) it seems as if the risk is most serious. Can anyone enlighten my ignorance on this? On a slightly off topic note, I'm thinking about running an ftp/http/ssh server for personal use in college. What precautionary measures should I take, or rather can I take? From reading over the various Slashdot posts, I'm thinking that beyond (1) making sure system isn't running any unnecessary servers (Debian seems pretty good in this by default) (2) making sure all software is up to date and (3) since it's a college campus, possibly being able to ask technical support for the subnet (correct word?) of all campus IP addresses, and only allowing access IP addresses on that subnet beyond all of that, there really isn't much that I can do is there? Thanks, --TongKe Xue --- Josh Carroll <[EMAIL PROTECTED]> wrote: > Actually, people have reported that there is an exploit, and in > fact even OpenBSD is vulnerable. > > I would still patch ASAP. Best not to risk it. > > It's probably a matter of time before a widely available exploit is > released. Right now it seems > it's in the hands of a select few, but that will probably change > sooner than later. > > By the way, you can grab the incoming openssh package from: > > http://incoming.debian.org/ssh_3.6.1p2-6.0_i386.deb > > if you want to patch your unstable system without building your own > package with the buffer.c > patch. (assuming i386 of course). > > I personally would like to see said exploit so I can test my > systems post-patch. But I guess > we'll have to trust the packages and/or buffer.c patch. > > Josh > > > Florian Weimer ([EMAIL PROTECTED]) wrote: > > Ted Roby <[EMAIL PROTECTED]> writes: > > > > > Does this vulnerability require a login? Is a system safe if it > does not > > > allow root login, and password logins? > > > > Nobody knows the answer at the moment. There isn't any obvious > way to > > exploit the overflow (mind that the attacker cannot write > arbitrary > > data, just a couple of zeros), and I still doubt if it is > exploitable > > at all. > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
Quoting Stephen Frost ([EMAIL PROTECTED]): > There's at least a version on incoming.debian.org which has the version > for unstable. I don't know what to tell you about testing/sarge. I'm > sure it will be in before release but beyond that I've no idea when it > will make it into testing. The version in incoming _seems_ to cause no problems on testing/sarge if you're willing to install libc6 from unstable, which I've just done, and am so far seeing no problems. Versions: http://incoming.debian.org/ssh_3.6.1p2-7_i386.deb http://http.us.debian.org/debian/pool/main/g/glibc/libc6_2.3.2-7_i386.deb -- Cheers, Wall Street has all the emotional stability of a Rick Moenthirteen-year-old girl. -- Louis Rukeyser [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Tue, 16 Sep 2003, Josh Carroll wrote: > Actually, people have reported that there is an exploit, and in fact > even OpenBSD is vulnerable. A number of people have claimed that others have said it is exploitable. This is quite a common occurance with well publicised exploits. I've seen no proof of an exploit as yet. > I would still patch ASAP. Best not to risk it. Definately. This is always best practice regardless of whether there is a known exploit or not. Cheers, Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
Josh Carroll <[EMAIL PROTECTED]> writes: > Actually, people have reported that there is an exploit, and in fact > even OpenBSD is vulnerable. Yes, I've seen these claims, but you have to keep in mind that not everyone who posts to mailing lists is entirely honest. 8-) Early claims such as "*BDDs, GNU/Linux and Solaris are all affected" should be taken with a grain of salt, especially if a heap-based overflow is involved. The malloc() implementations are quite different, and the *BSDs are less vulnerable to heap corruption than other systems. > I would still patch ASAP. Best not to risk it. If I was still busy recovering from MS03-039, I wouldn't stop this work in favor of this. My gut feeling is that it's okay to wait for vendor patches. > It's probably a matter of time before a widely available exploit is > released. First of all, the bug has to be actually exploitable. Please keep in mind that so far, *zero* evidence has been published that this is actually possible. If it is exploitable, it has to be an anonymous exploit (without proper login), unless it won't have a wide-spread impact. > I personally would like to see said exploit so I can test my systems > post-patch. At least you can use the package version indicator in the reply string to see which version of the binary is running. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
Christian Hammers <[EMAIL PROTECTED]> écrivait (wrote) : > On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > > On Tue, 16 Sep 2003, Alexander Neumann wrote: > > > > > According to Wichert, the security team is already working on an update. > > > > Is there an emergency patch/workaround for this, if disabling ssh is not > > an option? Are systems with Privilege Separation affected? > > The new version has already been installed. This was quick. Good work, > security team. Same for most boxes here but there seem to be a versioning conflict between security update and woody proposed update : apt-cache policy ssh ssh: Installed: 1:3.4p1-1.woody.1 Candidate: 1:3.4p1-1.woody.1 Version Table: *** 1:3.4p1-1.woody.1 0 500 ftp://ftp.u-picardie.fr woody-proposed-updates/main Packages 100 /var/lib/dpkg/status 1:3.4p1-1.1 0 500 http://security.debian.org woody/updates/main Packages 1:3.4p1-1 0 500 ftp://ftp.u-picardie.fr woody/main Packages I will force the security.debian.org version to apply but I think people should be aware of the risq of using woody/updates and maybe one of the too should be renumbered. Jean Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ssh-krb5
Hello all, Is there a plan to update ssh-krb5 to handle the new buffer overflow, or is this already done in 3.4p1-0wood? Thanks, David Sayre Los Alamos National Labs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
Dossy wrote: On 2003.09.16, Stephen Frost <[EMAIL PROTECTED]> wrote: Is 3.6.1p2-3 vulnerable? For those of us who want security, must we downgrade to 3.4p1-1.1 or build from source after patching by hand? Or will this security fix be applied to sarge as well? There's at least a version on incoming.debian.org which has the version for unstable. I don't know what to tell you about testing/sarge. I'm sure it will be in before release but beyond that I've no idea when it will make it into testing. Eek. So, if we want to run secure systems, we either have to run unstable (and all the troubles that comes with) or stable? I find that "testing" is a good middle ground for a reasonably stable system but with reasonably up-to-date packages, so that's why I run it. Running "stable" involves hand-managing way too many packages that I do need more recent versions, and "unstable" involves way too many troubles if I apt-get update without carefully inspecting what's being updated, which I don't have the time for. :-( poop. Guess I'll go the deb-src route and hand-patch, I guess. Not what I wanted to do today ... ;-) -- Dossy Or (to get a reasonably up to date system): * Set your default release to stable (I actually prefer to use distribution names, so that if I'm asleep at the switch when a new version is released I don't accidentally 'apt-get upgrade' when I should 'apt-get dist-upgrade') * Include testing and unstable in sources.conf * Include apt-src for testing and/or unstable. * Install a stable system, then for special needs, try 'apt-get install foo/testing' (or "foo/unstable"). If you can live with the dependancies, great. If things turn ugly, then apt-get source instead. This way, you'll have stable (with the corresponding security updates) for just about everything. For the few packages that need to be from unstable or testing, either patch them yourself, or watch incoming, or watch for others to contribute .debs. Plus, you can apt-get update && upgrade without having your system blow up. I've found fairly few cases where I actually *need* a more recent version, so this approach works great for me. In most cases, the only perceved need for a more recent version has been for security updates, which, of course, are backported in Debian stable. Of course, YMMV. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
Quoting Dossy ([EMAIL PROTECTED]): > Eek. So, if we want to run secure systems, we either have to run > unstable (and all the troubles that comes with) or stable? The Security Team FAQ addresses this: http://www.debian.org/security/faq#testing Q: How is security handled for testing and unstable? A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, the security secretaries will try to fix problems in testing and unstable after they are fixed in the stable release. The FAQ is your friend. ;-> > I find that "testing" is a good middle ground for a reasonably stable > system but with reasonably up-to-date packages, so that's why I run > it. You can certainly do that. But the burden is on you to read DSAs and take manual action as needed. E.g., if a DSA says some exposed piece of software you elect to run has a vulnerability you care about, you might find it in your interest to do one of the following: 1. Downgrade to the stable branch's version. 2. Install the binary version from the unstable branch[1]. 3. apt-get source the unstable version, then recompile and dpkg -i it. 4. deb-src and hand-patch, as you say. 5. Switch temporarily from the affected package to an equivalent that isn't affected. (Remember, there's lsh, for example.) (The above is for the benefit of list readership at large. I'm certainly not suggesting you personally aren't aware of those options.) [1] Add Package: * Pin: release a=unstable Pin-Priority: 50 to /etc/apt/preferences. Have both testing and unstable lines in /etc/apt/sources.list . Then, after another apt-get update: # apt-get -t unstable install ...will get and any needed dependencies from the unstable branch. (Note that you cannot assume unstable automatically fixes security bugs.) Alternatively, use "=" syntax to fetch a specified package version: apt-get install somepackage=12.17.4-4 Tutorial: http://jaqque.sbih.org/kplug/apt-pinning.html -- Cheers, "I don't like country music, but I don't mean to denigrate Rick Moen those who do. And, for the people who like country music, [EMAIL PROTECTED] denigrate means 'put down'." -- Bob Newhart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
* Dossy ([EMAIL PROTECTED]) wrote: > Eek. So, if we want to run secure systems, we either have to run > unstable (and all the troubles that comes with) or stable? I find that Old news... Sorry. Stephen pgp0.pgp Description: PGP signature
Re: [d-security] Re: ssh vulnerability in the wild
## Jean Charles Delepine ([EMAIL PROTECTED]): > Same for most boxes here but there seem to be a versioning conflict > between security update and woody proposed update : I stumbled over this earlier this year. In short, "proposed-updates is NOT meant to be added by users." (Martin Schulze). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=182413&archive=yes Regards, cmt -- Spare Space -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
TongKe Xue <[EMAIL PROTECTED]> writes: > When I read slashdot this morning, I thought the article titled > "New ssh Exploit in the Wild" implied that an exploit was already out > ... Exactly. > or does "in the Wild" generally mean it's theoretically possible, > but not necessairly done yet? No, quite the contrary. The simple explanation is that the Slashdot posted a story which mostly contained speculation and exaggeration. Which is, when you think about it, just a typical Slashdot story. 8-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 11:59:34AM -0700, TongKe Xue wrote: > Hello, Hi, > On a slightly off topic note, I'm thinking about running an > ftp/http/ssh server for personal use in college. What precautionary > measures should I take, or rather can I take? From reading over the > various Slashdot posts, I'm thinking that beyond > > (1) making sure system isn't running any unnecessary servers > (Debian seems pretty good in this by default) > (2) making sure all software is up to date > and > (3) since it's a college campus, possibly being able to ask > technical support for the subnet (correct word?) of all campus IP > addresses, and only allowing access IP addresses on that subnet > > beyond all of that, there really isn't much that I can do is there? Well, like everything else it depends how much time you want to spend on security. Is it an anonymous-only ftp? If not, encrypt the traffic to protect the usernames and passwords. Are you the only one that's going to connect with ssh? If not, consider chroot()ing the other accounts. Public webserver? If not, only allow certain addresses and use SSL/TLS if needed. Also consider building a custom kernel with, for example, PaX. Grsecurity (www.grsecurity.org) is a good kernel patch with PaX and a simple ACL among other things. If you're building your own packages, consider using the SSP (http://www.research.ibm.com/trl/projects/security/ssp/) patch for GCC. /Thomas -- == [EMAIL PROTECTED] | [EMAIL PROTECTED] == Encrypted e-mails preferred | GPG KeyID: 114AA85C -- signature.asc Description: Digital signature
RE: OpenSSH
Sven Hoexter wrote: > On Wed, Sep 03, 2003 at 11:20:45AM +0200, Matthias Faulstich wrote: > > Hi, > >> does anybody know, whether the chroot-patch will be included in >> future versions of the official ssh package? > To me it looks like you can do the same thing without patching the > sshd if you use scponlyc (scponly[1] shell with chroot() support). In testing and unstable there are scponly packages: http://tinyurl.com/nm0f [packages.debian.org] Another option if you are using testing or unstable is rssh: http://rssh.sourceforge.net/ http://tinyurl.com/nm0o [packages.debian.org] These both restrict the commands available to the user to allow only scp (and sftp e.tc. possibly). I know scponly can be recompiled with customised commands if required. -- Andrew StephenDDI:+64 4 460 6849 IT Security Architect Mobile: +64 25 582 304 New Zealand Post Fax:+64 4 494 4299 "...shouldn't a DMZ actually be called a Free Fire Zone?" -- Chris Mahn, Three Tiered DMZ's, May 2001 This email with any attachments is confidential and may be subject to legal privilege. If it is not intended for you please reply immediately, destroy it and do not copy, disclose or use it in any way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
Hello there, Christian Hammers schrieb: > > On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > > On Tue, 16 Sep 2003, Alexander Neumann wrote: > > > > > According to Wichert, the security team is already working on an update. > > The new version has already been installed. This was quick. Good work, > security team. > > openssh (1:3.4p1-1.1) stable-security; urgency=high > > * NMU by the security team. > * Merge patch from OpenBSD to fix a security problem in buffer handling > > -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 So only one problem remains: The version in woody-proposed-updates is 1:3.4p1-1.woody.1 which is "newer" than the patched version. So I had to manually "downgrade" my proposed-updates-version to get the fix. (apt-get dist-upgrade didn't show any packages to upgrade) When will there be a "new" version in proposed-updates for apt-getting the fix? bye, Matthias Merz smime.p7s Description: Kryptographische Unterschrift mit S/MIME
SSH Update for Potato?
Hi Guys, This might be a longshot, but is there an update for potato? Is it vulnerable? I unfortunately still have a few clients running potato boxes. :( I didnt see anything about potato in the DSA. On a more general note, is potato still supported by the Security Team? If not then I will definately urge these clients to upgrade (ive been trying thus far without success for these people to get upgraded to woody). I appreciate any feedback. Cheers, Shane. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 05:31:06PM +0200, Christian Hammers wrote: > The new version has already been installed. This was quick. Good work, > security team. > > openssh (1:3.4p1-1.1) stable-security; urgency=high > > * NMU by the security team. > * Merge patch from OpenBSD to fix a security problem in buffer handling > > -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 According to the DSA, this is based on the 3.7 fix. OpenSSH's site lists the only not vulnerable version as 3.7.1. In my mind, that means the ssh version on security.debian.org right now is _STILL_ vulnerable. I'm not a security expert, nor do I have time to actually see if that's true, so, I'm asking the list if anyone can confirm/deny that. -- Regards Birzan George Cristian pgp0.pgp Description: PGP signature
Re: [d-security] Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 01:10:34PM -0400, Dossy wrote: > On 2003.09.16, Christian Hammers <[EMAIL PROTECTED]> wrote: > > The new version has already been installed. This was quick. Good work, > > security team. > > > > openssh (1:3.4p1-1.1) stable-security; urgency=high > > > > * NMU by the security team. > > * Merge patch from OpenBSD to fix a security problem in buffer handling > > > > -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 16 Sep 2003 13:06:31 +0200 > > Is 3.6.1p2-3 vulnerable? For those of us who want security, must we > downgrade to 3.4p1-1.1 or build from source after patching by hand? Or > will this security fix be applied to sarge as well? It's not routine practice, but assuming glibc doesn't suddenly get fixed in the next couple of days, I expect to upload a fixed openssh to testing-proposed-updates once the dust settles. That should be able to get into testing fairly quickly. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
On Tue, Sep 16, 2003 at 09:51:43PM +0200, Matthias Merz wrote: > So only one problem remains: The version in woody-proposed-updates is > 1:3.4p1-1.woody.1 which is "newer" than the patched version. So I had to > manually "downgrade" my proposed-updates-version to get the fix. > (apt-get dist-upgrade didn't show any packages to upgrade) > When will there be a "new" version in proposed-updates for apt-getting > the fix? This will be sorted out soon: I believe the next version in security will include the changes in proposed-updates and so will have a higher version number. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ssh v2 hostbased authentication after woody security upgrade
Hi all! After the woody security fix of ssh (new version 3.4p1-1.1) we cannot use HostBased Authentication for SSH V.2. There was no change in the configuration files or the host keys, besides, interestingly the /etc/ssh/ssh_host_key (responsible for V.1 authentication, thus uninteresing for my problem I guess) has a newer timestamp, while the corresponding .pub file has not changed at all. We have on both ssh ends the followng permission (in /etc/ssh) -rw---1 root root 672 Feb 2 2002 ssh_host_dsa_key -rw-r--r--1 root root 600 Feb 2 2002 ssh_host_dsa_key.pub -rw---1 root root 883 Feb 2 2002 ssh_host_rsa_key -rw-r--r--1 root root 220 Feb 2 2002 ssh_host_rsa_key.pub in sshd_config: HostbasedAuthentication yes in ssh_config: Host * Protocol 2,1 HostbasedAuthentication yes ssh-keysign is setuid root: -rwsr-xr-x1 root root 151496 Sep 16 13:33 /usr/lib/ssh-keysign So I do not understand what is going on. The only thing I found in the log files is: sshd[26845]: error: ssh_rsa_verify: RSA_verify failed: error:0A071003:lib(10):func(113):reason(3) sshd[26847]: error: ssh_rsa_verify: RSA_verify failed: error:0A071003:lib(10):func(113):reason(3) sshd[26847]: Failed password for user from AAA.BBB.CCC.DDD port 1028 ssh2 I started the server with LogLevel DEBUG3 and this is what I got: sshd[5432]: debug1: Bind to port 22 on 0.0.0.0. sshd[5432]: Server listening on 0.0.0.0 port 22. sshd[5432]: Generating 768 bit RSA key. sshd[5432]: RSA key generation complete. sshd[5440]: Connection from AAA.BBB.CCC.DDD port 3894 sshd[5432]: debug1: Forked child 5440. sshd[5440]: debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1 Debian 1:3.4p1-1.1 sshd[5440]: debug1: match: OpenSSH_3.4p1 Debian 1:3.4p1-1.1 pat OpenSSH* sshd[5440]: Enabling compatibility mode for protocol 2.0 sshd[5440]: debug1: Local version string SSH-1.99-OpenSSH_3.4p1 Debian 1:3.4p1-1.1 sshd[5440]: debug2: Network child is on pid 5441 sshd[5440]: debug3: preauth child monitor started sshd[5440]: debug3: mm_request_receive entering sshd[5440]: debug3: monitor_read: checking request 0 sshd[5440]: debug3: mm_answer_moduli: got parameters: 1024 2048 8192 sshd[5440]: debug3: mm_request_send entering: type 1 sshd[5440]: debug2: monitor_read: 0 used once, disabling now sshd[5440]: debug3: mm_request_receive entering sshd[5440]: debug3: monitor_read: checking request 4 sshd[5440]: debug3: mm_answer_sign sshd[5440]: debug3: mm_answer_sign: signature 0x8095650(143) sshd[5440]: debug3: mm_request_send entering: type 5 sshd[5440]: debug2: monitor_read: 4 used once, disabling now sshd[5440]: debug3: mm_request_receive entering sshd[5440]: debug3: monitor_read: checking request 6 sshd[5440]: debug3: mm_answer_pwnamallow sshd[5440]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 sshd[5440]: debug3: mm_request_send entering: type 7 sshd[5440]: debug2: monitor_read: 6 used once, disabling now sshd[5440]: debug3: mm_request_receive entering sshd[5440]: debug3: monitor_read: checking request 37 sshd[5440]: debug1: Starting up PAM with username "user" sshd[5440]: debug3: Trying to reverse map address AAA.BBB.CCC.DDD. sshd[5440]: debug1: PAM setting rhost to "origin.mydomain.foo" sshd[5440]: debug2: monitor_read: 37 used once, disabling now sshd[5440]: debug3: mm_request_receive entering sshd[5440]: debug3: monitor_read: checking request 3 sshd[5440]: debug3: mm_answer_authserv: service=ssh-connection, style= sshd[5440]: debug2: monitor_read: 3 used once, disabling now sshd[5440]: debug3: mm_request_receive entering sshd[5440]: debug3: monitor_read: checking request 10 sshd[5440]: debug3: mm_answer_authpassword: sending result 0 sshd[5440]: debug3: mm_request_send entering: type 11 sshd[5440]: Failed none for user from AAA.BBB.CCC.DDD port 3894 ssh2 sshd[5440]: debug3: mm_request_receive entering sshd[5440]: debug3: monitor_read: checking request 20 sshd[5440]: debug3: mm_answer_keyallowed entering sshd[5440]: debug3: mm_answer_keyallowed: key_from_blob: 0x809fd20 sshd[5440]: debug2: userauth_hostbased: chost origin.mydomain.foo. resolvedname origin.mydomain.foo ipaddr AAA.BBB.CCC.DDD sshd[5440]: debug2: stripping trailing dot from chost origin.mydomain.foo. sshd[5440]: debug2: auth_rhosts2: clientuser user hostname origin.mydomain.foo ipaddr AAA.BBB.CCC.DDD sshd[5440]: debug1: temporarily_use_uid: 1045/1000 (e=0) sshd[5440]: debug1: restore_uid sshd[5440]: debug2: userauth_hostbased: access allowed by auth_rhosts2 sshd[5440]: debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts sshd[5440]: debug3: key_read: type mismatch OK here we start with host based authentication: sshd[5440]: debug3: check_host_in_hostfile: match line 18 sshd[5440]: debug2: check_key_in_hostfiles: key ok for origin.mydomain.foo Found the right key sshd[5440]: debug3: mm_answer_keyallowed: key 0x809fd20 is allowed sshd[5440]: debug3: mm_appe
