From dwmw2 at infradead.org  Tue Nov  2 00:39:32 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 01 Nov 2004 13:39:32 +0000
Subject: Controlling ssh from an external program
In-Reply-To: <4176D6A9.4070106@zip.com.au>
References: <200410201231.16758.jander@hundredacrewood.org>
	<4176D6A9.4070106@zip.com.au>
Message-ID: <1099316371.13633.2073.camel@hades.cambridge.redhat.com>

On Thu, 2004-10-21 at 07:20 +1000, Darren Tucker wrote:
> Jeff Anderson (by way of Jeff Anderson <jander at hundredacrewood.org>) wrote:
> > I am working on a remote administration tool, and I would like to be able to 
> > control ssh/scp via an external program. I know the standard answer to this 
> > is to use expect, however this is NOT an option.
> > 
> > The next standard answer is to use an empty passphrase or ssh-agent, but I 
> > cannot guarantee that the remote system will have a keypair, so I need to be 
> > able to fallback on password authentication if that fails. The controlling 
> > program needs to be able to feed the password to ssh/scp.  
> > 
> > 
> > Additionally, I can only use an unmodified version of openssh (i.e. whatever 
> > version is available on the system that the admin tool is run from).
> > 
> > Any ideas?????
> 
> Abuse the SSH_ASKPASS mechanism, eg:
> http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=109822418603321

 ( In which Damien Miller writes: )
> DISPLAY=junk SSH_ASKPASS=~/.ssh/add-passphrase.sh ssh-add </dev/null

The same trick doesn't work for ssh. Unless ssh got fixed following the
recent discussions, you still need a hack which disassociates from the
controlling tty before invoking ssh. Redirecting stdin isn't enough.

-- 
dwmw2



From bob at jasomi.com  Tue Nov  2 06:23:15 2004
From: bob at jasomi.com (Bob Bramwell)
Date: Mon, 01 Nov 2004 12:23:15 -0700
Subject: SSHD with PAM question
In-Reply-To: <41543E9A.8040004@anl.gov>
References: <Pine.BSO.4.44.0409221643530.2960-100000@etoh.eviladmin.org>	<4152E075.8060708@anl.gov>	<41537FB0.8070601@mindrot.org>
	<41543E9A.8040004@anl.gov>
Message-ID: <41868D23.307@jasomi.com>

Can anyone provide some insight into why the auth-pam module uses a fork in 
pthread_create (auth-pam.c)?  This completely breaks the ability of one PAM 
function to pass data to others via the pam_set_data/pam_get_data functions.

-- 
Bob Bramwell            Jasomi Networks (Canada) | This space
Ph: 403 269 2938 x155   #310 602 11th Ave SW     | intentionally
FX: 403 269 2993        Calgary, AB, T2R 1J8     | left blank.



From bob at jasomi.com  Tue Nov  2 06:44:37 2004
From: bob at jasomi.com (Bob Bramwell)
Date: Mon, 01 Nov 2004 12:44:37 -0700
Subject: SSHD with PAM question
Message-ID: <41869225.3060805@jasomi.com>

Let me refine my previous question:

> Can anyone provide some insight into why the auth-pam module uses a fork in 
 > pthread_create (auth-pam.c)?  This completely breaks the ability of one PAM 
function
 > to pass data to others via the pam_set_data/pam_get_data functions.

Can anyone tell me how to #define USE_POSIX_THREADS when building --with-pam 
defined?  The autoconfig stuff doesn't test for pthreads libraries, so by 
default you get threads simulated by Unix processes.  Presumably there ought to 
be an "official" way to specify this.

Thanks.

-- 
Bob Bramwell            Jasomi Networks (Canada) | This space
Ph: 403 269 2938 x155   #310 602 11th Ave SW     | intentionally
FX: 403 269 2993        Calgary, AB, T2R 1J8     | left blank.



From mouring at etoh.eviladmin.org  Tue Nov  2 06:52:08 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 1 Nov 2004 13:52:08 -0600 (CST)
Subject: SSHD with PAM question
In-Reply-To: <41869225.3060805@jasomi.com>
Message-ID: <Pine.BSO.4.44.0411011352010.11402-100000@etoh.eviladmin.org>


No there isn't because it will be going away.

- Ben

On Mon, 1 Nov 2004, Bob Bramwell wrote:

> Let me refine my previous question:
>
> > Can anyone provide some insight into why the auth-pam module uses a fork in
>  > pthread_create (auth-pam.c)?  This completely breaks the ability of one PAM
> function
>  > to pass data to others via the pam_set_data/pam_get_data functions.
>
> Can anyone tell me how to #define USE_POSIX_THREADS when building --with-pam
> defined?  The autoconfig stuff doesn't test for pthreads libraries, so by
> default you get threads simulated by Unix processes.  Presumably there ought to
> be an "official" way to specify this.
>
> Thanks.
>
> --
> Bob Bramwell            Jasomi Networks (Canada) | This space
> Ph: 403 269 2938 x155   #310 602 11th Ave SW     | intentionally
> FX: 403 269 2993        Calgary, AB, T2R 1J8     | left blank.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From dtucker at zip.com.au  Tue Nov  2 07:51:28 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 02 Nov 2004 07:51:28 +1100
Subject: SSHD with PAM question
In-Reply-To: <41868D23.307@jasomi.com>
References: <Pine.BSO.4.44.0409221643530.2960-100000@etoh.eviladmin.org>	<4152E075.8060708@anl.gov>	<41537FB0.8070601@mindrot.org>	<41543E9A.8040004@anl.gov>
	<41868D23.307@jasomi.com>
Message-ID: <4186A1D0.6090002@zip.com.au>

Bob Bramwell wrote:
> Can anyone provide some insight into why the auth-pam module uses a fork 
> in pthread_create (auth-pam.c)?  This completely breaks the ability of 
> one PAM function to pass data to others via the 
> pam_set_data/pam_get_data functions.

It basically boils down to this: the PAM functions (pam_authenticate, 
pam_acct_mgmt and so on) block until they complete, and interact with 
the user via a "conversation function", ie a callback.

OpenSSH's sshd is built around a protocol dispatch loop (I suspect most 
SSH implementations are).  Since the PAM calls block, the dispatch loop 
isn't running until the calls complete.  This means the messages needed 
to interact with the user aren't being processed.  Snookered, hence the 
fork.

If you enable USE_POSIX_THREADS, you're trusting that every module you 
use is thread-safe.  If they're not then it could blow up in interesting 
and unusual ways, and may even make daemons fly out your nose.  If that 
happens, dont expect any reaction from us (except maybe "Cool!  What 
colour?" :-).

If you can, use 3.9p1, turn off ChallengeResponseAuthentication and turn 
on PasswordAuthentication (this will use PAM with a blind conversation 
function).

Also see http://bugzilla.mindrot.org/show_bug.cgi?id=688

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From bob at jasomi.com  Tue Nov  2 08:43:31 2004
From: bob at jasomi.com (Bob Bramwell)
Date: Mon, 01 Nov 2004 14:43:31 -0700
Subject: SSHD with PAM question
In-Reply-To: <4186A1D0.6090002@zip.com.au>
References: <Pine.BSO.4.44.0409221643530.2960-100000@etoh.eviladmin.org>	<4152E075.8060708@anl.gov>	<41537FB0.8070601@mindrot.org>	<41543E9A.8040004@anl.gov>
	<41868D23.307@jasomi.com> <4186A1D0.6090002@zip.com.au>
Message-ID: <4186AE03.6090706@jasomi.com>

As long as it is my *nose* the daemons come out of we can all sleep easy :-)

Thanks for the explanation: it was very useful.  I will try to upgrade to 3.9p1 
RSN, but that's not a possibility this week.  So, just in case anyone else want 
to try this sneezing daemon act, the cleanest way I've found to enable the 
pthread version of auth-pam  to configure with:
	--with-pam --with-libs="-lpthread" --with-cflags="-DUSE_POSIX_THREADS"
It seems to work OK in the situation in which I need it.

Cheers,
	Bob.

Darren Tucker wrote:
> Bob Bramwell wrote:
> 
>> Can anyone provide some insight into why the auth-pam module uses a 
>> fork in pthread_create (auth-pam.c)?  This completely breaks the 
>> ability of one PAM function to pass data to others via the 
>> pam_set_data/pam_get_data functions.
> 
> 
> It basically boils down to this: the PAM functions (pam_authenticate, 
> pam_acct_mgmt and so on) block until they complete, and interact with 
> the user via a "conversation function", ie a callback.
> 
> OpenSSH's sshd is built around a protocol dispatch loop (I suspect most 
> SSH implementations are).  Since the PAM calls block, the dispatch loop 
> isn't running until the calls complete.  This means the messages needed 
> to interact with the user aren't being processed.  Snookered, hence the 
> fork.
> 
> If you enable USE_POSIX_THREADS, you're trusting that every module you 
> use is thread-safe.  If they're not then it could blow up in interesting 
> and unusual ways, and may even make daemons fly out your nose.  If that 
> happens, dont expect any reaction from us (except maybe "Cool!  What 
> colour?" :-).
> 
> If you can, use 3.9p1, turn off ChallengeResponseAuthentication and turn 
> on PasswordAuthentication (this will use PAM with a blind conversation 
> function).
> 
> Also see http://bugzilla.mindrot.org/show_bug.cgi?id=688
> 


-- 
Bob Bramwell            Jasomi Networks (Canada) | This space
Ph: 403 269 2938 x155   #310 602 11th Ave SW     | intentionally
FX: 403 269 2993        Calgary, AB, T2R 1J8     | left blank.



From darryl at netbauds.net  Tue Nov  2 14:40:37 2004
From: darryl at netbauds.net (Darryl L. Miles)
Date: Tue, 02 Nov 2004 03:40:37 +0000
Subject: reget reput again...
Message-ID: <418701B5.7060709@netbauds.net>


Ben Lindstrom wrote (a very long time ago) :

 >The problem is in some cases the data being sent to you may be out of
 >order (thankful no sftp server does this yet). So reget/reput without RFC
 >clearifications can lead to bad file transfers.
 >
 >I'm trying to drag up in my mind which one was the problem... I believe
 >reput is fine since the client has control over the ordering. reget is
 >the troublesome some one without RFC clarifications stating out of order
 >transfers are denied.
 >
 >if the RFC get clarified to disallow out of order transfers then a cleaned
 >up version of this patch may not have a problem getting in.


It seems everyone body has a patch for this but it still can't quite 
make it into any official distribution.  Not wanting to stifle technical 
progress down surely the standards body have mechanism to allow new 
concepts to be experimentally deployed without affecting non-cooperating 
parties ?

Is it really necessary to get RFC clarification on this, maybe its 
useful to leave as-is and have the option to execute out-of-order for in 
uses.

Would it be possible to extend the channel initialisation options to 
negotiate a feature requesting "mandatory in-sequence execution of 
commands within this channel".  I'm not sure how these options are 
created or assigned but maybe use some OpenSSH naming space until a 
standard group either accepts or rejects the concept and assigns it a 
standard option name.

Non-conforming servers would not understand the option and the client 
could then disable the reget/reput commands from use in that session.

I do not know enough about the OpenSSH implementation to know if its 
possible for it to ever execute commands out of sequence with respect to 
the channel they are in nor the contraints this may pose to future 
maintainace of OpenSSH.

To confirm the scope of the option suggested, it says nothing about any 
other channel nor the order in which channels are attended to within the 
server, this stays as-is.


RFC ?  Please Cc your reply Thanks.


-- 
Darryl L. Miles



From matthewjq at wanadoo.nl  Wed Nov  3 06:43:56 2004
From: matthewjq at wanadoo.nl (Matthew)
Date: Tue, 2 Nov 2004 14:43:56 -0500
Subject: (no subject)
Message-ID: <20041103045550.C02A327C189@shitei.mindrot.org>

Do you want a cheap Rolex Watch?
http://pvi.evif.com/r/giggles/watchs.html



From Patrice.Gonthier at alcatel.fr  Wed Nov  3 20:05:21 2004
From: Patrice.Gonthier at alcatel.fr (Patrice.Gonthier at alcatel.fr)
Date: Wed, 3 Nov 2004 10:05:21 +0100
Subject: Is it mandatory to generate host keys on the target host,
 or can they be
 generated on another host and transfer to thetarget host
Message-ID: <OFDB7D73C2.B3DE0888-ONC1256F41.0031EC6B-C1256F41.0031EE1B@netfr.alcatel.fr>

Hello,

My question in 2 words is the following:

Is it mandatory to generate host keys on the target host, or can they be
       generated on another host and transfer to thetarget host ?


If my question is not clear here is an example...


I need to install host keys on a host server.

I imagine the usual way is to launch the following command locally on the
host server .
# ssh-keygen -t rsa1 -f /usr/local/etc/ssh_host_key -N ""

My question is:
Is is possible to generate host keys on another host, and in a second step
to install them on athe host server.

Thank you by advance for your help ....

Patrice








From dan at doxpara.com  Wed Nov  3 20:42:42 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 03 Nov 2004 01:42:42 -0800
Subject: Is it mandatory to generate host keys on the target host, or
 can they be generated on another host and transfer to thetarget host
In-Reply-To: <OFDB7D73C2.B3DE0888-ONC1256F41.0031EC6B-C1256F41.0031EE1B@netfr.alcatel.fr>
References: <OFDB7D73C2.B3DE0888-ONC1256F41.0031EC6B-C1256F41.0031EE1B@netfr.alcatel.fr>
Message-ID: <4188A812.4090609@doxpara.com>

Patrice,

    You can generate keys wherever you like; it's however considered 
poor form cryptographically to transfer any private key.  Exceptions are 
generally only allowed when there's only very limited processor 
resources on the host -- but then, why would you use SSH, which 
generates short term RSA keys every couple of hours?

--Dan


Patrice.Gonthier at alcatel.fr wrote:

>Hello,
>
>My question in 2 words is the following:
>
>Is it mandatory to generate host keys on the target host, or can they be
>       generated on another host and transfer to thetarget host ?
>
>
>If my question is not clear here is an example...
>
>
>I need to install host keys on a host server.
>
>I imagine the usual way is to launch the following command locally on the
>host server .
># ssh-keygen -t rsa1 -f /usr/local/etc/ssh_host_key -N ""
>
>My question is:
>Is is possible to generate host keys on another host, and in a second step
>to install them on athe host server.
>
>Thank you by advance for your help ....
>
>Patrice
>
>
>
>
>
>
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev at mindrot.org
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>  
>



From BOD at art.net  Thu Nov  4 08:15:30 2004
From: BOD at art.net (BOD at art.net)
Date: Wed, 03 Nov 2004 21:15:30 +0000
Subject: Licensed programs: from MicroSoft, Adobe, MacroMedia...
In-Reply-To: <20K22BF8FDEEKHI4@mindrot.org>
References: <20K22BF8FDEEKHI4@mindrot.org>
Message-ID: <7439708LK7IBEL9G@art.net>

!! http://66.73.170.21:8180/sft/ !!




From abishop_my at ahcbrand.demon.nl  Fri Nov  5 07:20:58 2004
From: abishop_my at ahcbrand.demon.nl (Adolph Bishop)
Date: Thu, 04 Nov 2004 20:20:58 +0000
Subject: Mens Watches
Message-ID: <LGEAFHNLPBFPNBCPIADLJDGFLAAB.abishop_my@ahcbrand.demon.nl>

Win) a ?{Rolex Watch?

http://rdm.fogw.com/rep/sales/




From tguidry_sk at leics.gov.uk  Fri Nov  5 17:23:47 2004
From: tguidry_sk at leics.gov.uk (Theron Guidry)
Date: Fri, 05 Nov 2004 00:23:47 -0600
Subject: We sell regalis for an affordable price
Message-ID: <222d01c4c300$5dee687b$5b10a5e3@opisto.alkio.fi>

Hi,

Regalis, also known as Superviagra or Cialis
- half a pill Lasts all weekend
- Has less sideeffects
- Has higher success rate

Now you can buy Regalis, for over 70% cheaper than the equivilent brand for sale in US

We ship world wide, and no prescription is required!!

Even if you're not impotent, Regalis will increase size, pleasure and power!

Try it today you wont regret!

Get it here: http://a1medz.com/sup/

Best regards,
Jeremy Stones


No thanks: http://a1medz.com/rr.php



From confirm-s2-bgYJDZHbZz7CJwppqA1qaKENmYA-openssh-unix-dev=mindrot.org at yahoogrupos.com.br  Fri Nov  5 22:06:44 2004
From: confirm-s2-bgYJDZHbZz7CJwppqA1qaKENmYA-openssh-unix-dev=mindrot.org at yahoogrupos.com.br (Yahoo!Grupos)
Date: 5 Nov 2004 11:06:44 -0000
Subject: Confirma =?iso-8859-1?q?=E7=E3?=
	o de pedido para entrar no grupo ForumNews
Message-ID: <1099652804.68.1227.m14@yahoogrupos.com.br>



Ol? openssh-unix-dev at mindrot.org,

Recebemos sua solicita??o para entrar no grupo ForumNews 
do Yahoo! Grupos, um servi?o de comunidades online gratuito e 
super f?cil de usar.

Este pedido expirar? em 7 dias.

PARA ENTRAR NESTE GRUPO: 

1) V? para o site do Yahoo! Grupos clicando neste link:

   http://br.groups.yahoo.com/i?i=bgYJDZHbZz7CJwppqA1qaKENmYA&e=openssh-unix-dev%40mindrot%2Eorg 

  (Se n?o funcionar, use os comandos para cortar e colar o link acima na
   barra de endere?o do seu navegador.)

-OU-

2) RESPONDA a este e-mail clicando em "Responder" e depois em "Enviar",
   no seu programa de e-mail.

Se voc? n?o fez esta solicita??o ou se n?o tem interesse em entrar no grupo
ForumNews, por favor, ignore esta mensagem.

Sauda??es,

Atendimento ao usu?rio do Yahoo! Grupos 


O uso que voc? faz do Yahoo! Grupos est? sujeito aos http://br.yahoo.com/info/utos.html
 







From prkqagb at mail2Alyssa.com  Sat Nov  6 09:17:10 2004
From: prkqagb at mail2Alyssa.com (Hodge Danial)
Date: Fri, 05 Nov 2004 14:17:10 -0800
Subject: I know its gonna work
Message-ID: <AOSWAMU-0004272091156@twin>

**A Notice from the Office of the Registrar 
 
You are now qualified to obtain a Degree from a Prestigious University.
There are NO required tests, classes, books, or interviews.
Associate, Bachelors(BA,LLB) Masters(MBA,MSc) and Doctorate (PhD) are 
obtainable in the field of your choice.
 
Discrete and Inexpensive. We send the degree to all countries (WORLDWIDE)
 
Click below to finish up your Assesment Form and you're on your way to a 
better future.
 
http://fastdegreeservice.com/?partid=s27

Adan Branch, MBA, MSc, PhD
Director Of Admissions
 
 
 
 
 
 
 
 
 
 
 

No future offers:
http://fastdegreeservice.com/st.html



From jakehawkes2001 at yahoo.com  Sun Nov  7 00:48:09 2004
From: jakehawkes2001 at yahoo.com (Jake Hawkes)
Date: Sat, 6 Nov 2004 05:48:09 -0800 (PST)
Subject: sshd refusing logins from certain hosts
Message-ID: <20041106134809.11627.qmail@web41215.mail.yahoo.com>

Ok this is a weird one.

I cannot ssh into my server from the ISP directly.

I CAN ssh into my server from the VPN to my company from the ISP.

I can ssh into my server on a different port from the ISP directly and the VPN.

I am using PAM authentication.

I am using PuTTY

When it fails, it first asks me for my username, then says "connection closed".

any ideas?

=====
Jacob Hawkes, B. Eng (CSE)
jakehawkes2001 at yahoo.com
http://www.infinitylimited.net/


		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 



From iwill at evenetwork.tv  Sun Nov  7 05:36:24 2004
From: iwill at evenetwork.tv (iwill)
Date: Sun, 07 Nov 2004 03:36:24 +0900
Subject: 615 =?iso-2022-jp?b?GyRCJCgkKEA8JE4yLDdyQkAkLDojRnwkLSReJDkbKEI=?=
Message-ID: <1107104033624.1001@pcg-sr-m-series>

???????
??????????4-5-7
???????????????
06-6282-5008
6????????,??????????????
??????????????????,????????????
????????????????????
?????????????
????http://www.evenetwork.tv



From dtucker at zip.com.au  Sun Nov  7 11:07:37 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 07 Nov 2004 11:07:37 +1100
Subject: sshd refusing logins from certain hosts
In-Reply-To: <20041106134809.11627.qmail@web41215.mail.yahoo.com>
References: <20041106134809.11627.qmail@web41215.mail.yahoo.com>
Message-ID: <418D6749.9070409@zip.com.au>

Jake Hawkes wrote:
> I cannot ssh into my server from the ISP directly.
[...]
> When it fails, it first asks me for my username, then says "connection closed".
> 
> any ideas?

Tell us what platform and version of OpenSSH you're using?  Look at the 
log file?  Run sshd in debug mode and see what is says?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From gnayalaon at catholic.or.kr  Sun Nov  7 11:54:14 2004
From: gnayalaon at catholic.or.kr (German N. Ayala)
Date: Sun, 07 Nov 2004 08:54:14 +0800
Subject: We sell regalis for an affordable price
Message-ID: <b5b601c4c464$5283e0fe$38b97e00@cnasys.fi>

Hi,

Regalis, also known as Superviagra or Cialis
- half a pill Lasts all weekend
- Has less sideeffects
- Has higher success rate

Now you can buy Regalis, for over 70% cheaper than the equivilent brand for sale in US

We ship world wide, and no prescription is required!!

Even if you're not impotent, Regalis will increase size, pleasure and power!

Try it today you wont regret!

Get it here: http://123rxrocks.com/sup/

Best regards,
Jeremy Stones


No thanks: http://123rxrocks.com/rr.php



From openssh at roumenpetrov.info  Mon Nov  8 20:44:13 2004
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Mon, 8 Nov 2004 11:44:13 +0200 (EET)
Subject: sshd refusing logins from certain hosts
In-Reply-To: <20041106134809.11627.qmail@web41215.mail.yahoo.com>
References: <20041106134809.11627.qmail@web41215.mail.yahoo.com>
Message-ID: <40806.213.91.169.3.1099907053.squirrel@srv04.zergon.net>

>
> When it fails, it first asks me for my username, then says "connection
> closed".

Please, check /etc/hosts.allow on server side.



From gonzo at etla.org  Tue Nov  9 01:48:32 2004
From: gonzo at etla.org (gonzo at etla.org)
Date: Mon, 08 Nov 2004 14:48:32 +0000
Subject: OnlinR ph@rmacy
In-Reply-To: <F0LFLAIBA8HGDKGE@mindrot.org>
References: <F0LFLAIBA8HGDKGE@mindrot.org>
Message-ID: <4343HKAI2D4HLDKE@etla.org>

http://kwVNn.cgfcdcgk.info/?cYekelcmNMj3ocITzUVv




From djm at mindrot.org  Tue Nov  9 07:23:44 2004
From: djm at mindrot.org (Damien Miller)
Date: Tue,  9 Nov 2004 07:23:44 +1100 (EST)
Subject: RedHat forks OpenSSH?
Message-ID: <20041108202344.334DD1BCC01@baragon.mindrot.org>

It has just come to my notice that Redhat is planning to ship a
forked version of OpenSSH. The change goes beyond the usual 
patches applied to RPMs in the build process: Redhat have built 
their own OpenSSH tarball and are using that in their source RPM
instead of the official release distribution. If you are
interested, have a look at the openssh-3.9p1-7.src.rpm from the
Fedora development/ directory.

This source tarball is modified from the official portable
OpenSSH distribution. It does not have a digital signature, an
independent download site or even a basic list of changes. From
diffing this source against the official release, it appears that
the only change is deletion of files related to the experimental
ACSS cipher. It is unclear why Redhat has chosen to do this: the 
cipher is disabled by default and their own Cygwin product has
shipped these same files for many months, as have many other
Linux distributions.

Nobody disputes Redhat's right to fork OpenSSH, but why does
Redhat not make their desired changes through the standard RPM
patching mechanism? By distributing their own OpenSSH tarballs
instead of patching pristine sources, Redhat breaks the link of
transparency, accountability and trust that their own RPM build
model is supposed to provide.

We are also curious as to the extent that the community was
involved in this decision; OpenSSH is developed by volunteers and
Fedora is at least ostensibly a community effort. The OpenSSH
developers were not contacted and there does not appear to have
been any discussion of the change on any public mailing list.
Even the RPM Changelog entry "disable ACSS support" greatly
understates the nature of the change. It appears that the 
community was not consulted at all and that this change was made
unilaterally by Redhat, with no explanation.

The OpenSSH developers have neither the time nor the desire to
investigate the changes Redhat makes to OpenSSH under the cover
of their modified source tarball. As such, we will be forced to
disregard support requests from users of Redhat or Fedora
systems. Security conscious users are advised to audit the Redhat
changes themselves (for each RPM release) or build OpenSSH from
the original sources.

We consider it very disappointing that Redhat has decided to
effectively fork OpenSSH without consulting the OpenSSH
developers or their own community. It is not too late for Redhat
to reconsider, or for the community to urge them to do so.

Regards, 
Damien Miller



From skvidal at phy.duke.edu  Tue Nov  9 07:26:50 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 08 Nov 2004 15:26:50 -0500
Subject: RedHat forks OpenSSH?
In-Reply-To: <20041108202344.334DD1BCC01@baragon.mindrot.org>
References: <20041108202344.334DD1BCC01@baragon.mindrot.org>
Message-ID: <1099945609.15004.55.camel@opus.phy.duke.edu>

On Mon, 2004-11-08 at 15:23, Damien Miller wrote:
> It has just come to my notice that Redhat is planning to ship a
> forked version of OpenSSH. The change goes beyond the usual 
> patches applied to RPMs in the build process: Redhat have built 
> their own OpenSSH tarball and are using that in their source RPM
> instead of the official release distribution. If you are
> interested, have a look at the openssh-3.9p1-7.src.rpm from the
> Fedora development/ directory.
> 

Do you find that a cross-posted missive to a set of lists like this is:
1. less or more inflammatory than a post to the openssh maintainer
@redhat.com?
2. less or more productive than an entry in bugzilla about the details?

Thanks
-sv




From tsi at ualberta.ca  Tue Nov  9 07:42:11 2004
From: tsi at ualberta.ca (Marc Aurele La France)
Date: Mon, 8 Nov 2004 13:42:11 -0700 (MST)
Subject: RedHat forks OpenSSH?
In-Reply-To: <20041108202344.334DD1BCC01@baragon.mindrot.org>
References: <20041108202344.334DD1BCC01@baragon.mindrot.org>
Message-ID: <Pine.BSO.4.61.0411081340310.15856@login2.srv.ualberta.ca>

On Tue, 9 Nov 2004, Damien Miller wrote:

> It has just come to my notice that Redhat is planning to ship a
> forked version of OpenSSH. The change goes beyond the usual
> patches applied to RPMs in the build process: Redhat have built
> their own OpenSSH tarball and are using that in their source RPM
> instead of the official release distribution. If you are
> interested, have a look at the openssh-3.9p1-7.src.rpm from the
> Fedora development/ directory.

> This source tarball is modified from the official portable
> OpenSSH distribution. It does not have a digital signature, an
> independent download site or even a basic list of changes. From
> diffing this source against the official release, it appears that
> the only change is deletion of files related to the experimental
> ACSS cipher. It is unclear why Redhat has chosen to do this: the
> cipher is disabled by default and their own Cygwin product has
> shipped these same files for many months, as have many other
> Linux distributions.

> Nobody disputes Redhat's right to fork OpenSSH, but why does
> Redhat not make their desired changes through the standard RPM
> patching mechanism? By distributing their own OpenSSH tarballs
> instead of patching pristine sources, Redhat breaks the link of
> transparency, accountability and trust that their own RPM build
> model is supposed to provide.

> We are also curious as to the extent that the community was
> involved in this decision; OpenSSH is developed by volunteers and
> Fedora is at least ostensibly a community effort. The OpenSSH
> developers were not contacted and there does not appear to have
> been any discussion of the change on any public mailing list.
> Even the RPM Changelog entry "disable ACSS support" greatly
> understates the nature of the change. It appears that the
> community was not consulted at all and that this change was made
> unilaterally by Redhat, with no explanation.

> The OpenSSH developers have neither the time nor the desire to
> investigate the changes Redhat makes to OpenSSH under the cover
> of their modified source tarball. As such, we will be forced to
> disregard support requests from users of Redhat or Fedora
> systems. Security conscious users are advised to audit the Redhat
> changes themselves (for each RPM release) or build OpenSSH from
> the original sources.

> We consider it very disappointing that Redhat has decided to
> effectively fork OpenSSH without consulting the OpenSSH
> developers or their own community. It is not too late for Redhat
> to reconsider, or for the community to urge them to do so.

> Regards,
> Damien Miller

Welcome to the world of "Open Source", as defined by RedHat.

XFree86 has already suffered the same fate.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Computing and Network Services  |  fax:    1-780-492-1729           |
|  352 General Services Building   |  email:  tsi at ualberta.ca          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 developer and VP.  ATI driver and X server internals.



From pp at ee.oulu.fi  Tue Nov  9 08:41:42 2004
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Mon, 8 Nov 2004 23:41:42 +0200
Subject: RedHat forks OpenSSH?
In-Reply-To: <20041108202344.334DD1BCC01@baragon.mindrot.org>
References: <20041108202344.334DD1BCC01@baragon.mindrot.org>
Message-ID: <20041108214142.GA5561@ee.oulu.fi>

On Tue, Nov 09, 2004 at 07:23:44AM +1100, Damien Miller wrote:
> the only change is deletion of files related to the experimental
> ACSS cipher. It is unclear why Redhat has chosen to do this: the 
> cipher is disabled by default and their own Cygwin product has
> shipped these same files for many months, as have many other
> Linux distributions.

Of course, the readership might be more enlightened to know what ACSS 
is.

"This library implements the Alleged Content Scrambling System.  It is
believed
to be interoperable with CSS of the DVD Copy Control Association.

ACSS is a stream cipher with a fixed key length of 40 bit (5 byte).

ACSS consists of a key setup phase and the actual encryption or decryption
phase."

Apart from the potential legal issues (even if are just some litigious
bastards suing people for fun/profit instead of real ones) surrounding
said algorithms, isn't it OpenBSD policy (dunno about openssh) to not ship
known broken crypto algorithms at all?

-- 
Pekka Pietikainen



From deraadt at cvs.openbsd.org  Tue Nov  9 09:46:47 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Mon, 8 Nov 2004 15:46:47 -0700 (MST)
Subject: RedHat forks OpenSSH?
Message-ID: <200411082246.iA8MklgR007831@cvs.openbsd.org>

> On Tue, Nov 09, 2004 at 07:23:44AM +1100, Damien Miller wrote:
> > the only change is deletion of files related to the experimental
> > ACSS cipher. It is unclear why Redhat has chosen to do this: the 
> > cipher is disabled by default and their own Cygwin product has
> > shipped these same files for many months, as have many other
> > Linux distributions.
>
> Of course, the readership might be more enlightened to know what ACSS 
> is.
>
> "This library implements the Alleged Content Scrambling System.  It is
> believed
> to be interoperable with CSS of the DVD Copy Control Association.
> ACSS is a stream cipher with a fixed key length of 40 bit (5 byte).

I quote from the openssl RC4 manual page:

       This library implements the Alleged RC4 cipher, which is
       described for example in Applied Cryptography.  It is
       believed to be compatible with RC4[TM], a proprietary
       cipher of RSA Security Inc.

> ACSS consists of a key setup phase and the actual encryption or decryption
> phase."
>
> Apart from the potential legal issues (even if are just some litigious
> bastards suing people for fun/profit instead of real ones) surrounding
> said algorithms,

Precisely what legal issues would that be?

What we have here in ACSS is a multi-purpose cipher that can be used
for many things, including but not limited to encrypting ssh sessions.
And it is fast.

> isn't it OpenBSD policy (dunno about openssh) to not ship
> known broken crypto algorithms at all?

It is our policy to provide a secure replacement for telnet and
rlogin, so that people stop using telnet and rlogin.  It is our
policy to release that software in a free fashion so that vendors
can supply their customers with a high quality implimention.

If you don't like what we write, you can run something else..
.



From sakura at sakuraclub.dyndns.biz  Tue Nov  9 10:13:10 2004
From: sakura at sakuraclub.dyndns.biz (=?iso-2022-jp?B?GyRCJTUlLyVpJEEkYyRzGyhC?=)
Date: Tue, 9 Nov 2004 08:13:10 +0900
Subject: =?iso-2022-jp?b?GyRCTCQ+NUJ6OS05cBsoQg==?=
Message-ID: <0d8001c4c5e8$836c1680$6401a8c0@dual>

???????????1??????????
???????????????????????????????
http://www.sakurachan.jp??????????

??????????????????

????????????????????
???????????????
??????????-?-?
???
?????http://www.sakurachan.jp??




From syoukai_ at fj9.so-net.ne.jp  Tue Nov  9 10:21:46 2004
From: syoukai_ at fj9.so-net.ne.jp (syoukai_ at fj9.so-net.ne.jp)
Date: Tue,  9 Nov 2004 10:21:46 +1100 (EST)
Subject: =?utf-8?b?worDusKKw5TCjMOAwpLDqMKBRcKLdMKJwofCj8KVwoNawoPCjMKD?=
	=?utf-8?b?dcKPwpfCkMKrwpbCs8KXwr/Cj8OQwonDrg==?=
Message-ID: 20041106052640

??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????10?????????????????????????????????????????
??????????
syoukai_ at fj9.so-net.ne.jp

???2?3????????????????????24??????????????????????????
syoukai_ at fj9.so-net.ne.jp

?????????????????????????????????????



From stend at sten.org  Tue Nov  9 12:51:39 2004
From: stend at sten.org (Sten Drescher)
Date: Mon, 08 Nov 2004 19:51:39 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411082246.iA8MklgR007831@cvs.openbsd.org>
References: <200411082246.iA8MklgR007831@cvs.openbsd.org>
Message-ID: <419022AB.8040707@sten.org>

Theo de Raadt wrote:

>>Apart from the potential legal issues (even if are just some litigious
>>bastards suing people for fun/profit instead of real ones) surrounding
>>said algorithms,
>>    
>>
>
>Precisely what legal issues would that be?
>  
>
The DVD CCA's belief that there is "legal 'trade secret' protection for 
CSS".  http://www.dvdcca.org/faq.html  While the OpenBSD project may not 
be an attractive target for the DVD CCA, Red Hat's lawyers may believe 
that they could be.  Even if the DVD CCA is wrong and you are right, it 
could still be expensive, both in legal fees and in lost sales, for Red 
Hat to argue the point in court.

>If you don't like what we write, you can run something else...
>  
>
Or, it can be forked, which it appears Red Hat is doing, albeit in a 
very impolite fashion.

Regards, Sten




From sfrost at snowman.net  Tue Nov  9 13:03:21 2004
From: sfrost at snowman.net (Stephen Frost)
Date: Mon, 8 Nov 2004 21:03:21 -0500
Subject: RedHat forks OpenSSH?
In-Reply-To: <419022AB.8040707@sten.org>
References: <200411082246.iA8MklgR007831@cvs.openbsd.org>
	<419022AB.8040707@sten.org>
Message-ID: <20041109020321.GQ12780@ns.snowman.net>

* Sten Drescher (stend at sten.org) wrote:
> The DVD CCA's belief that there is "legal 'trade secret' protection for 
> CSS".  http://www.dvdcca.org/faq.html  While the OpenBSD project may not 
> be an attractive target for the DVD CCA, Red Hat's lawyers may believe 
> that they could be.  Even if the DVD CCA is wrong and you are right, it 
> could still be expensive, both in legal fees and in lost sales, for Red 
> Hat to argue the point in court.

Over a broken and uninteresting cipher, I'm not suprised.  In fact, I
expect Debian will very likely also remove it.

> Or, it can be forked, which it appears Red Hat is doing, albeit in a 
> very impolite fashion.

Impolite is the implication that RedHat is forking OpenSSH because
they're prudently removing specific files which are definitely of a
questionable legal status.

	Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041108/7f869601/attachment.bin 

From tomas.rendel at mdnd.com  Tue Nov  9 13:20:15 2004
From: tomas.rendel at mdnd.com (Tomas Rendel)
Date: Tue, 9 Nov 2004 03:20:15 +0100
Subject: ssh login
Message-ID: <NEENLLIHDNAKGGLNLKEGGEBOCCAA.tomas.rendel@mdnd.com>

sorry - hope this question is not tooo silly,

but i needed to "autologin" to a remote machine
found out that this works fine for me:

sftp -opassword=PASSWORD USER at 192.168.1.1 << EOF
cd ANYDIRECTORY
get ANYFILE
bye
EOF

why isn't this (sftp -opassword=SECRET USER at 192.168.1.1),
setting the password with -opassword=PASSWORD, documentated
anywhere?
bug or feature?

kind regards
tomas






Mediaindustrie GmbH
Marketing - Tomas Rendel
tomas.rendel at mdnd.com
http://www.mediaindustrie.com
Friedingerstrasse 26
D-82229 Seefeld
fon: +49 (0)8152 993 991
fax: +49 (0)8152 993 999



From djm at mindrot.org  Tue Nov  9 13:25:04 2004
From: djm at mindrot.org (Damien Miller)
Date: Tue, 09 Nov 2004 13:25:04 +1100
Subject: ssh login
In-Reply-To: <NEENLLIHDNAKGGLNLKEGGEBOCCAA.tomas.rendel@mdnd.com>
References: <NEENLLIHDNAKGGLNLKEGGEBOCCAA.tomas.rendel@mdnd.com>
Message-ID: <41902A80.2030205@mindrot.org>

Tomas Rendel wrote:
> sorry - hope this question is not tooo silly,
> 
> but i needed to "autologin" to a remote machine
> found out that this works fine for me:
> 
> sftp -opassword=PASSWORD USER at 192.168.1.1 << EOF

This "feature" isn't in the OpenSSH that we release.

What OS and version of OpenSSH are you using?

-d



From mouring at etoh.eviladmin.org  Tue Nov  9 13:32:59 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 8 Nov 2004 20:32:59 -0600 (CST)
Subject: RedHat forks OpenSSH?
In-Reply-To: <20041109020321.GQ12780@ns.snowman.net>
Message-ID: <Pine.BSO.4.44.0411082022090.11402-100000@etoh.eviladmin.org>



On Mon, 8 Nov 2004, Stephen Frost wrote:

> * Sten Drescher (stend at sten.org) wrote:
[..]
> > Or, it can be forked, which it appears Red Hat is doing, albeit in a
> > very impolite fashion.
>
> Impolite is the implication that RedHat is forking OpenSSH because
> they're prudently removing specific files which are definitely of a
> questionable legal status.
>

Impolite in the fact they take a clean tar ball physically remove code
from it instead of using the native RPM patch methology.  Thus you have an
unsignable and unverifiable *.tar.gz file within the srpm.

Frankly, if they feel they need to do this.  Then they should at least be
polite enough to call it "RedhatSSH" or "OurModifiedOpenSSH" so people
expecting such chain of verification will fail if someone tries to verify
it against upstream code.

To me(I can't and won't speak for anyone else), the issue isn't WHAT
they removed more as *HOW* they removed it.

- Ben



From sfrost at snowman.net  Tue Nov  9 13:40:54 2004
From: sfrost at snowman.net (Stephen Frost)
Date: Mon, 8 Nov 2004 21:40:54 -0500
Subject: RedHat forks OpenSSH?
In-Reply-To: <Pine.BSO.4.44.0411082022090.11402-100000@etoh.eviladmin.org>
References: <20041109020321.GQ12780@ns.snowman.net>
	<Pine.BSO.4.44.0411082022090.11402-100000@etoh.eviladmin.org>
Message-ID: <20041109024054.GS12780@ns.snowman.net>

* Ben Lindstrom (mouring at etoh.eviladmin.org) wrote:
> Impolite in the fact they take a clean tar ball physically remove code
> from it instead of using the native RPM patch methology.  Thus you have an
> unsignable and unverifiable *.tar.gz file within the srpm.

Removing it using RPM doesn't remove the problem files from the servers
and mirrors which distribute them.  This issue has been run around on
the Debian legal mailing list quite a few times.  Certainly the absolute
best solution is for upstream to remove it.  In situations where
upstream is unwilling to then it falls to the maintainer.

> Frankly, if they feel they need to do this.  Then they should at least be
> polite enough to call it "RedhatSSH" or "OurModifiedOpenSSH" so people
> expecting such chain of verification will fail if someone tries to verify
> it against upstream code.

Users expect a working distribution to have things like 'ssh'.  The fact
that a few files that 99.99% of users wouldn't even be interested in
were removed is uninteresting and unimportant to them.  Trying to claim
that makes it a fork is a feat of an amazingly overactive imagination.

> To me(I can't and won't speak for anyone else), the issue isn't WHAT
> they removed more as *HOW* they removed it.

A better solution would be nice.  I havn't seen one suggested yet.  It
probably would have been better if they had contacted the OpenSSH
developers and asked them to remove it from upstream but, well, it isn't
always useful to waste that kind of time.

	Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041108/6d50b7f2/attachment.bin 

From mouring at etoh.eviladmin.org  Tue Nov  9 13:44:44 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 8 Nov 2004 20:44:44 -0600 (CST)
Subject: ssh login
In-Reply-To: <NEENLLIHDNAKGGLNLKEGGEBOCCAA.tomas.rendel@mdnd.com>
Message-ID: <Pine.BSO.4.44.0411082041150.11402-100000@etoh.eviladmin.org>



On Tue, 9 Nov 2004, Tomas Rendel wrote:

> sorry - hope this question is not tooo silly,
>
> but i needed to "autologin" to a remote machine
> found out that this works fine for me:
>
> sftp -opassword=PASSWORD USER at 192.168.1.1 << EOF
> cd ANYDIRECTORY
> get ANYFILE
> bye
> EOF
>
> why isn't this (sftp -opassword=SECRET USER at 192.168.1.1),
> setting the password with -opassword=PASSWORD, documentated
> anywhere?
> bug or feature?

Because it isn't a valid option?  Why would one document something that
doesn't exist?

I suspect if it works on your machine it means that someone has modified
your source code.  Either your upstream distro or your company.  Because
it isn't a valid option with OpenSSH baseline code.

- Ben



From deraadt at cvs.openbsd.org  Tue Nov  9 13:53:12 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Mon, 08 Nov 2004 19:53:12 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Mon, 08 Nov 2004 21:03:21 EST."
	<20041109020321.GQ12780@ns.snowman.net> 
Message-ID: <200411090253.iA92rCHx032075@cvs.openbsd.org>

> > The DVD CCA's belief that there is "legal 'trade secret' protection for=
> =20
> > CSS".  http://www.dvdcca.org/faq.html  While the OpenBSD project may not=
> =20
> > be an attractive target for the DVD CCA, Red Hat's lawyers may believe=20
> > that they could be.  Even if the DVD CCA is wrong and you are right, it=
> =20
> > could still be expensive, both in legal fees and in lost sales, for Red=
> =20
> > Hat to argue the point in court.
> 
> Over a broken and uninteresting cipher, I'm not suprised.  In fact, I
> expect Debian will very likely also remove it.
> 
> > Or, it can be forked, which it appears Red Hat is doing, albeit in a=20
> > very impolite fashion.
> 
> Impolite is the implication that RedHat is forking OpenSSH because
> they're prudently removing specific files which are definitely of a
> questionable legal status.

What is so questionable about them?

Is there a trademark?

Is there a patent?

Were the files written by them, and therefore copyrighted by them?

Last I looked, the files were based on

	- entirely legal reverse engineering efforts

	- taken by a cast of hundreds on the net

	- of a trade secret algorithm

	- (which even in the case of DVDs is useless without the
	  actual keys from the disks, by the way)

	- and the actual files in question are written by a german
	  developer of ours

So when you say 'questionable legal status', which laws are you talking
about?

Because I would love to know.


If ACSS is so bad, are you going remove all the ARC4 ciphers from
your operating system?

Either you tell us which laws you are talking about, or you are
precisely the kind of people who DVD CCA should be pushing around.

They don't have a leg to stand on.  ACSS is a multiple-use
cryptographic technology, just like ARC4.  Both are stream ciphers,
both have bugs, both were reverse engineered.

But one of them is a fight worth fighting and one of them is
associated with a bunch of spineless wimps who don't understand how to
use previous multiple-use rulings in our favour.  Wimps.



From dan at doxpara.com  Tue Nov  9 14:06:47 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Mon, 08 Nov 2004 19:06:47 -0800
Subject: RedHat forks OpenSSH?
In-Reply-To: <Pine.BSO.4.44.0411082022090.11402-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0411082022090.11402-100000@etoh.eviladmin.org>
Message-ID: <41903447.1010302@doxpara.com>


>Impolite in the fact they take a clean tar ball physically remove code
>from it instead of using the native RPM patch methology.  Thus you have an
>unsignable and unverifiable *.tar.gz file within the srpm.
>  
>
The point is that they can't ship SRPM's with ACSS, built or not.  
Negative patches still contain the offending code, even as they say 
"don't built this".

--Dan



From mouring at etoh.eviladmin.org  Tue Nov  9 14:30:12 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 8 Nov 2004 21:30:12 -0600 (CST)
Subject: RedHat forks OpenSSH?
In-Reply-To: <41903447.1010302@doxpara.com>
Message-ID: <Pine.BSO.4.44.0411082121000.11402-100000@etoh.eviladmin.org>

y

On Mon, 8 Nov 2004, Dan Kaminsky wrote:

>
> >Impolite in the fact they take a clean tar ball physically remove code
> >from it instead of using the native RPM patch methology.  Thus you have an
> >unsignable and unverifiable *.tar.gz file within the srpm.
> >
> >
> The point is that they can't ship SRPM's with ACSS, built or not.
> Negative patches still contain the offending code, even as they say
> "don't built this".
>

.. Thus giving them an excuse to do bad manors and not provide any
notification within the SRPMs that it isn't "prestine" code.

Honestly, Dan.  Do we really want to encourage such behavior?

Fine.. Redhat is misguided and thinks they have to remove the code.  Fine
let them.  But let them CLEARLY AND UNMISTAKENLY mark the thing as *NOT*
being "prestine" code.  So people can MAKE their own choices.  That is all
what "Open Source" is about?  Being utterly transparent so people can make
their own choices and not be "forced down a SINGLE person's path?"

BTW.. Does Redhat modify the *.tar.gz for the "could be illegal patent
usage" that is within the Truetype font server shipped with X?  Or do they
just not ship it enabled by default?

If they do ship it with it just turned off.. Then they better rush out
and remove the code.  Along with all the other stuff marked questionable.
Otherwise they are being pretty two-faced about the whole issue.

- Ben



From stend at sten.org  Tue Nov  9 14:41:06 2004
From: stend at sten.org (Sten Drescher)
Date: Mon, 08 Nov 2004 21:41:06 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411090253.iA92rCHx032075@cvs.openbsd.org>
References: <200411090253.iA92rCHx032075@cvs.openbsd.org>
Message-ID: <41903C52.108@sten.org>

Theo de Raadt wrote:

>>Impolite is the implication that RedHat is forking OpenSSH because
>>they're prudently removing specific files which are definitely of a
>>questionable legal status.
>>    
>>
>What is so questionable about them?
>  
>
I already pointed that out.

>Is there a trademark?
>
>Is there a patent?
>
>Were the files written by them, and therefore copyrighted by them?
>  
>
Completely irrelevant to a claimed trade secret.

>Last I looked, the files were based on
>
>	- entirely legal reverse engineering efforts
>  
>
Even if the reverse engineering was legal in Norway, using the results 
of that reverse engineering in the United States may not be.

>	- taken by a cast of hundreds on the net
>
>	- of a trade secret algorithm
>
>	- (which even in the case of DVDs is useless without the
>	  actual keys from the disks, by the way)
>
>	- and the actual files in question are written by a german
>	  developer of ours
>  
>
Again, that's not relevant.  If the DVD CCS made reasonable efforts to 
maintain their trade secret, and it was disclosed by a violation of 
their license (with the DVD player manufacturer), then they can still 
argue that it can still be considered to be a trade secret.

>So when you say 'questionable legal status', which laws are you talking
>about?
>  
>
The laws of the state of California, for one.  The preliminary 
injunction in /DVD Copy Control Association, Inc. v. Bunner/ was only 
lifted this past March.  
http://www.mofo.com/news/general.cfm?MCatID=9006&concentrationID=&ID=1180&Type=5  
Even though the DVD CCA has dropped this particular case, they have not 
given up their claim of a trade secret (witness the demise of 321 
Studios at their hands). 

>Either you tell us which laws you are talking about, or you are
>precisely the kind of people who DVD CCA should be pushing around.
>  
>
Done.

>They don't have a leg to stand on.
>
They had enough of a leg to drag out their case versus Bunner for 5 
years, and enough of a case to drive 321 Studios out of business.

>But one of them is a fight worth fighting and one of them is
>associated with a bunch of spineless wimps who don't understand how to
>use previous multiple-use rulings in our favour.  Wimps.
>  
>
That's easy to say when its not your money being spent in the fight.  
Even when you're right, proving it in court isn't inexpensive.  While it 
might not be good for your ego, I can understand why Red Hat would 
consider fighting SCO over Linux to be a better use of their money than 
risking a fight with the DVD CCA over CSS in OpenSSH.

Regards, Sten



From deraadt at cvs.openbsd.org  Tue Nov  9 14:49:04 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Mon, 08 Nov 2004 20:49:04 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Mon, 08 Nov 2004 19:51:39 CST."
	<419022AB.8040707@sten.org> 
Message-ID: <200411090349.iA93n497031054@cvs.openbsd.org>

> >>Apart from the potential legal issues (even if are just some litigious
> >>bastards suing people for fun/profit instead of real ones) surrounding
> >>said algorithms,
> >>    
> >>
> >
> >Precisely what legal issues would that be?
> >  
> >
> The DVD CCA's belief that there is "legal 'trade secret' protection for 
> CSS".

There is no legal basis for what you are saying.

> http://www.dvdcca.org/faq.html  While the OpenBSD project may not 
> be an attractive target for the DVD CCA, Red Hat's lawyers may believe 
> that they could be.  Even if the DVD CCA is wrong and you are right, it 
> could still be expensive, both in legal fees and in lost sales, for Red 
> Hat to argue the point in court.

There is no legal basis for what you are saying.  None.

I recommend you remove the ARC4 cipher from your machines, if you
believe so.

> >If you don't like what we write, you can run something else...
> >  
> >
> Or, it can be forked, which it appears Red Hat is doing, albeit in a 
> very impolite fashion.

The way they are doing it, their users no longer get any support.



From dan at doxpara.com  Tue Nov  9 14:55:30 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Mon, 08 Nov 2004 19:55:30 -0800
Subject: RedHat forks OpenSSH?
In-Reply-To: <Pine.BSO.4.44.0411082121000.11402-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0411082121000.11402-100000@etoh.eviladmin.org>
Message-ID: <41903FB2.4090103@doxpara.com>


>.. Thus giving them an excuse to do bad manors and not provide any
>notification within the SRPMs that it isn't "prestine" code.
>
>Honestly, Dan.  Do we really want to encourage such behavior?
>
>Fine.. Redhat is misguided and thinks they have to remove the code.  Fine
>let them.  But let them CLEARLY AND UNMISTAKENLY mark the thing as *NOT*
>being "prestine" code.  So people can MAKE their own choices.  That is all
>what "Open Source" is about?  Being utterly transparent so people can make
>their own choices and not be "forced down a SINGLE person's path?"
>
>BTW.. Does Redhat modify the *.tar.gz for the "could be illegal patent
>usage" that is within the Truetype font server shipped with X?  Or do they
>just not ship it enabled by default?
>
>If they do ship it with it just turned off.. Then they better rush out
>and remove the code.  Along with all the other stuff marked questionable.
>Otherwise they are being pretty two-faced about the whole issue.
>
>- Ben
>
>  
>
Be fair.  Truetype rendering is much more central to a font server than 
ACSS is to OpenSSH.  I appreciate the stand Theo and the rest of you are 
making, but using package security as a bludgeon to attack law is bad 
form -- be insecure, or be exposed legally?  What's our priority here?

This being said, Theo's right.  ACSS is in the same category as RC4, 
with empty threats being the only thing separating the former from the 
latter.

And you're right:  It's not your tarball, so it shouldn't be named as 
such.  The tarball should be renamed to rh_openssh.tgz, and a hash 
embedded of the following command:  "cat openssh.tgz rh_openssh.tgz | 
sha1sum".  That creates a security chain w/o forcing Redhat to embed the 
code in a release.

Personally, I'm furious at the lawyers who are frankly lying about CSS 
being anything close to a trade secret every time they send a C&D.  But 
they *are* sending C&D's.  And Redhat apparently got one.  The technical 
solution you prescribed -- patching -- doesn't satisfy the desist.  The 
above, admittedly awkward hack does.  They can either ship OpenSSH pure, 
w/ the lawsuit bait, or they can use that.

--Dan



From syoukai_ at fj9.so-net.ne.jp  Tue Nov  9 15:21:01 2004
From: syoukai_ at fj9.so-net.ne.jp (syoukai_ at fj9.so-net.ne.jp)
Date: Tue,  9 Nov 2004 15:21:01 +1100 (EST)
Subject: =?utf-8?b?worDusKKw5TCjMOAwpLDqMKBRcKLdMKJwofCj8KVwoNawoPCjMKD?=
	=?utf-8?b?dcKPwpfCkMKrwpbCs8KXwr/Cj8OQwonDrg==?=
Message-ID: 20041106231404

??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????10?????????????????????????????????????????
??????????
syoukai_ at fj9.so-net.ne.jp

???2?3????????????????????24??????????????????????????
syoukai_ at fj9.so-net.ne.jp

?????????????????????????????????????



From djm at mindrot.org  Tue Nov  9 15:27:49 2004
From: djm at mindrot.org (Damien Miller)
Date: Tue, 09 Nov 2004 15:27:49 +1100
Subject: RedHat forks OpenSSH?
In-Reply-To: <41903FB2.4090103@doxpara.com>
References: <Pine.BSO.4.44.0411082121000.11402-100000@etoh.eviladmin.org>
	<41903FB2.4090103@doxpara.com>
Message-ID: <41904745.3000700@mindrot.org>

Dan Kaminsky wrote:
>
> Personally, I'm furious at the lawyers who are frankly lying about CSS 
> being anything close to a trade secret every time they send a C&D.  But 
> they *are* sending C&D's.  And Redhat apparently got one. 

Did they? They haven't said a word.

Even if they did, it is pretty stupid of them to buckle at the first
hint of a threat. If we, a much smaller, non-commercial project had
caved like this, then you wouldn't have the luxury of typing "ssh" to
run ssh (cf. ssh.com's trademark threats against us in 2000).

-d



From cmadams at hiwaay.net  Tue Nov  9 15:45:56 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Mon, 8 Nov 2004 22:45:56 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <Pine.BSO.4.44.0411082121000.11402-100000@etoh.eviladmin.org>
References: <41903447.1010302@doxpara.com>
	<Pine.BSO.4.44.0411082121000.11402-100000@etoh.eviladmin.org>
Message-ID: <20041109044556.GA928156@hiwaay.net>

Once upon a time, Ben Lindstrom <mouring at etoh.eviladmin.org> said:
> .. Thus giving them an excuse to do bad manors and not provide any
> notification within the SRPMs that it isn't "prestine" code.

Sure they do.  The contents of the SRPM are:

openssh-3.6.1p2-groups.patch
openssh-3.8.1p1-krb5-config.patch
openssh-3.8.1p1-skip-initial.patch
openssh-3.8p1-gssapimitm.patch
openssh-3.9p1-noacss.tar.gz
openssh-3.9p1-redhat.patch
openssh-nukeacss.sh
openssh-selinux.patch
openssh.spec
x11-ssh-askpass-1.2.4.1.tar.gz

Note that the primary source tar file is "openssh-3.9p1-noacss.tar.gz"
instead of "openssh-3.9p1.tar.gz".  Note also that the script used to
clean the source of the quetionable material is "openssh-nukeacss.sh".

Since the OpenSSH project doesn't distribute anything called
"openssh-3.9p1-noacss.tar.gz", it is pretty obvious that the file didn't
come from the OpenSSH project.

Also, the openssh.spec file has:

#Source0: ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-%{version}.tar.gz
#Source1: ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-%{version}.tar.gz.sig
Source0: openssh-%{version}-noacss.tar.gz

That makes it pretty obvious that the code originally came from
ftp.openbsd.org but that the included modified code did not.

This is not so much a "fork" as a patch.  The problem is that the patch
needs to remove questionable material, and that cannot be done with a
regular patch (as the SRPM would still contain the questionable
material, both in its original form and in the patch as removed lines).
The patch script _is_ included in the SRPM (so future versions can be
patched in exactly the same manner).

As for it being "impolite" that Red Hat didn't notify someone they were
doing this: were Tatu Yl?nen and Datafellows notified that ssh 1.2.12
was going to be forked into OSSH, and then they and Bj?rn Gr?nvall
notified that OSSH was going to be forked into OpenSSH?  Those are true
code forks (not just a patch); was prior notification made or was
OpenSSH an "impolite" fork?

The OpenSSH web site history page says:

   Therefore, the version of OpenSSH was based on these older versions
   of ssh 1.2.12, but with many bugs removed and newer features
   re-added:

     * has all components of a restrictive nature (i.e. patents,
       see ssl) directly removed from the source code

The CSS algorithm is claimed as a trade secret and there have been
several court cases fought over it.  Is that not code "of a restrictive
nature"?  Why is such code in OpenSSH?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From syoukai_ at fj9.so-net.ne.jp  Tue Nov  9 17:40:54 2004
From: syoukai_ at fj9.so-net.ne.jp (syoukai_ at fj9.so-net.ne.jp)
Date: Tue,  9 Nov 2004 17:40:54 +1100 (EST)
Subject: =?utf-8?b?worDusKKw5TCjMOAwpLDqMKBRcKLdMKJwofCj8KVwoNawoPCjMKD?=
	=?utf-8?b?dcKPwpfCkMKrwpbCs8KXwr/Cj8OQwonDrg==?=
Message-ID: 20041107123745

??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????10?????????????????????????????????????????
??????????
syoukai_ at fj9.so-net.ne.jp

???2?3????????????????????24??????????????????????????
syoukai_ at fj9.so-net.ne.jp

?????????????????????????????????????



From deraadt at cvs.openbsd.org  Tue Nov  9 18:26:49 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Tue, 09 Nov 2004 00:26:49 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Mon, 08 Nov 2004 19:06:47 PST."
	<41903447.1010302@doxpara.com> 
Message-ID: <200411090726.iA97QnEH017073@cvs.openbsd.org>

> >Impolite in the fact they take a clean tar ball physically remove code
> >from it instead of using the native RPM patch methology.  Thus you have an
> >unsignable and unverifiable *.tar.gz file within the srpm.
> >  
> >
> The point is that they can't ship SRPM's with ACSS, built or not.  
> Negative patches still contain the offending code, even as they say 
> "don't built this".

Yes they can.

I am looking forward to telling me why the SSH protocol cannot use the
ACSS cipher.



From deraadt at cvs.openbsd.org  Tue Nov  9 18:29:50 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Tue, 09 Nov 2004 00:29:50 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Tue, 09 Nov 2004 15:27:49 +1100."
	<41904745.3000700@mindrot.org> 
Message-ID: <200411090729.iA97Toww011671@cvs.openbsd.org>

> > Personally, I'm furious at the lawyers who are frankly lying about CSS 
> > being anything close to a trade secret every time they send a C&D.  But 
> > they *are* sending C&D's.  And Redhat apparently got one. 
> 
> Did they? They haven't said a word.
> 
> Even if they did, it is pretty stupid of them to buckle at the first
> hint of a threat. If we, a much smaller, non-commercial project had
> caved like this, then you wouldn't have the luxury of typing "ssh" to
> run ssh (cf. ssh.com's trademark threats against us in 2000).

Damien is right.

Have you guys forgotten what I went through to give the world
free SSH usage?

If I had buckled you all would still be using Telnet.

Whoever at Redhat made this decision is a spineless twit, and
I am being polite.

Whever at Redhat made this decision should immediately stop
using OpenSSH.  Come on.  Spineless twat, stop using it.  You
suck.  You are food for lawyers.



From deraadt at cvs.openbsd.org  Tue Nov  9 18:35:48 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Tue, 09 Nov 2004 00:35:48 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Mon, 08 Nov 2004 21:41:06 CST."
	<41903C52.108@sten.org> 
Message-ID: <200411090735.iA97ZmHf013896@cvs.openbsd.org>

> Even if the reverse engineering was legal in Norway, using the results 
> of that reverse engineering in the United States may not be.

Where is the law for that?  Please, I want real law.

> >	- taken by a cast of hundreds on the net
> >
> >	- of a trade secret algorithm
> >
> >	- (which even in the case of DVDs is useless without the
> >	  actual keys from the disks, by the way)
> >
> >	- and the actual files in question are written by a german
> >	  developer of ours
> >  
> >
> Again, that's not relevant.  If the DVD CCS made reasonable efforts to 
> maintain their trade secret, and it was disclosed by a violation of 
> their license (with the DVD player manufacturer), then they can still 
> argue that it can still be considered to be a trade secret.

Where is the law for that?

I've checked into this.  In case of a trade secret, the only people
you can litigate against are those who you had agreements with, and
who broke their agreements.  What law are you basing your statements
on?  Are you a lawyer?

> >So when you say 'questionable legal status', which laws are you talking
> >about?
> >  
> >
> The laws of the state of California, for one.  The preliminary 
> injunction in /DVD Copy Control Association, Inc. v. Bunner/ was only 
> lifted this past March.  

A preliminary injunction is not a law.

> http://www.mofo.com/news/general.cfm?MCatID=9006&concentrationID=&ID=1180&Type=5  
> Even though the DVD CCA has dropped this particular case, they have not 
> given up their claim of a trade secret (witness the demise of 321 
> Studios at their hands). 

A claim is not a law.

Where's the law?

> >Either you tell us which laws you are talking about, or you are
> >precisely the kind of people who DVD CCA should be pushing around.
> >  
> >
> Done.

NO!  I asked for LAWS but instead you gave non-laws, and waved your
hands around like a wimp.

> >They don't have a leg to stand on.
> >
> They had enough of a leg to drag out their case versus Bunner for 5 
> years, and enough of a case to drive 321 Studios out of business.

No, because that is a lawsuit case, not a LAW.

Are you still quivering in fear at their law suits, or are there
REAL LAWS?

> >But one of them is a fight worth fighting and one of them is
> >associated with a bunch of spineless wimps who don't understand how to
> >use previous multiple-use rulings in our favour.  Wimps.
> >  
> >
> That's easy to say when its not your money being spent in the fight.  

Money is not law.  It is threat, it is power, but it is not law.

Where's the law, wimp?

> Even when you're right, proving it in court isn't inexpensive.  While it 
> might not be good for your ego, I can understand why Red Hat would 
> consider fighting SCO over Linux to be a better use of their money than 
> risking a fight with the DVD CCA over CSS in OpenSSH.

OK -- I get it now.  You are a wimp, and Redhat are wimps, and it's OK
to be a wimp?

I get it.



From deraadt at cvs.openbsd.org  Tue Nov  9 18:38:06 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Tue, 09 Nov 2004 00:38:06 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Mon, 08 Nov 2004 22:45:56 CST."
	<20041109044556.GA928156@hiwaay.net> 
Message-ID: <200411090738.iA97c6wh011568@cvs.openbsd.org>

> The OpenSSH web site history page says:
> 
>    Therefore, the version of OpenSSH was based on these older versions
>    of ssh 1.2.12, but with many bugs removed and newer features
>    re-added:
> 
>      * has all components of a restrictive nature (i.e. patents,
>        see ssl) directly removed from the source code
> 
> The CSS algorithm is claimed as a trade secret and there have been
> several court cases fought over it.  Is that not code "of a restrictive
> nature"?  Why is such code in OpenSSH?

I claim that the colour red is a trade secret of me.

Are you afraid?

Why is Redhat such a pushover?

Is it because they are an American company?

Come on!  Someone tell me what law prohibits the ACSS cipher from
being used to protect an SSH communication!

Why does noone want to answer this question?



From sfrost at snowman.net  Tue Nov  9 23:33:53 2004
From: sfrost at snowman.net (Stephen Frost)
Date: Tue, 9 Nov 2004 07:33:53 -0500
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411090738.iA97c6wh011568@cvs.openbsd.org>
References: <20041109044556.GA928156@hiwaay.net>
	<200411090738.iA97c6wh011568@cvs.openbsd.org>
Message-ID: <20041109123353.GU12780@ns.snowman.net>

* Theo de Raadt (deraadt at cvs.openbsd.org) wrote:
> Why does noone want to answer this question?

It's generally not useful to feed a troll.

	Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041109/dfe8c708/attachment.bin 

From elijah at aclue.com  Wed Nov 10 04:11:58 2004
From: elijah at aclue.com (Eli Klein)
Date: Tue, 9 Nov 2004 10:11:58 -0700
Subject: Solaris + PAM/LDAP + pubkey failing?
Message-ID: <20041109171158.GR17834@aclue.com>

I've got a Solaris 8 and 9 box using LDAP to successfully authenticate users.
I can get logged in via ssh using keyboard interactive (via PAM/LDAP). When 
I try to use pubkey authentication, both the pubkey as well as the fallback to
keyboard interactive always fail.  I've tried openssh versions as early as 3.4 
and as new as the 11-06 snapshot with the same behavior.  Everything works fine 
on a linux machine which is configured to use PAM/LDAP and has openssh 3.9p1 
installed.  Logs follow.

Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: userauth-request for user testuser service ssh-connection method publickey
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: attempt 1 failures 1
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug2: input_userauth_request: try method publickey
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: test whether pkalg/pkblob are acceptable
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: temporarily_use_uid: 999/1002 (e=0/0)
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: trying public key file /home/testuser/.ssh/authorized_keys
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: restore_uid: 0/0
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: temporarily_use_uid: 999/1002 (e=0/0)
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: trying public key file /home/testuser/.ssh/authorized_keys2
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug3: secure_filename: checking '/home/testuser/.ssh'
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug3: secure_filename: checking '/home/testuser'
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug3: secure_filename: terminating check at '/home/testuser'
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: matching key found: file /home/testuser/.ssh/authorized_keys2, line 3
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.info] Found matching DSA key: 6d:28:e4:fa:93:3a:69:7e:57:1d:cf:c2:36:55:4d:e4
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: restore_uid: 0/0
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.info] Postponed publickey for testuser from 1.2.3.4 port 33457 ssh2

** snip -- it automatically tries pubkey auth 2 more times with the same error **

Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: userauth-request for user testuser service ssh-connection method keyboard-interactive
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: attempt 5 failures 3
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug2: input_userauth_request: try method keyboard-interactive
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: keyboard-interactive devs 
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: auth2_challenge: user=testuser devs=
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: kbdint_alloc: devices 'pam'
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug2: auth2_challenge_start: devices pam
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug2: kbdint_next_device: devices <empty>
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug1: auth2_challenge_start: trying authentication method 'pam'
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug3: PAM: sshpam_init_ctx entering
Nov  9 10:00:07 sshserver sshd[27977]: [ID 384020 auth.debug] PAM[27977]: pam_set_item(7f6e8:conv)
Nov  9 10:00:07 sshserver sshd[27977]: [ID 225850 auth.debug] PAM[27977]: pam_authenticate(7f6e8, 1)
Nov  9 10:00:07 sshserver sshd[27977]: [ID 348363 auth.debug] PAM[27977]: load_modules(7f6e8, pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1
Nov  9 10:00:07 sshserver sshd[27977]: [ID 258498 auth.debug] PAM[27977]: load_function: successful load of pam_sm_authenticate
Nov  9 10:00:07 sshserver sshd[27977]: [ID 348363 auth.debug] PAM[27977]: load_modules(7f6e8, pam_sm_authenticate)=/usr/lib/security/pam_dhkeys.so.1
Nov  9 10:00:07 sshserver sshd[27977]: [ID 258498 auth.debug] PAM[27977]: load_function: successful load of pam_sm_authenticate
Nov  9 10:00:07 sshserver sshd[27977]: [ID 348363 auth.debug] PAM[27977]: load_modules(7f6e8, pam_sm_authenticate)=/usr/lib/security/pam_unix_auth.so.1
Nov  9 10:00:07 sshserver sshd[27977]: [ID 258498 auth.debug] PAM[27977]: load_function: successful load of pam_sm_authenticate
Nov  9 10:00:07 sshserver sshd[27977]: [ID 348363 auth.debug] PAM[27977]: load_modules(7f6e8, pam_sm_authenticate)=/usr/lib/security/pam_ldap.so.1
Nov  9 10:00:07 sshserver sshd[27977]: [ID 258498 auth.debug] PAM[27977]: load_function: successful load of pam_sm_authenticate
Nov  9 10:00:07 sshserver sshd[27977]: [ID 334087 auth.debug] PAM[27977]: pam_get_user(7f6e8, 61746500, NULL)
Nov  9 10:00:07 sshserver sshd[27977]: [ID 800047 auth.debug] debug3: PAM: sshpam_thread_conv entering, 1 messages
Nov  9 10:00:07 sshserver sshd[27977]: [ID 800047 auth.debug] debug3: ssh_msg_send: type 1
Nov  9 10:00:07 sshserver sshd[27977]: [ID 800047 auth.debug] debug3: ssh_msg_recv entering
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug3: PAM: sshpam_query entering
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.debug] debug3: ssh_msg_recv entering
Nov  9 10:00:07 sshserver sshd[27976]: [ID 800047 auth.info] Postponed keyboard-interactive for testuser from 1.2.3.4 port 33457 ssh2
Nov  9 10:00:52 sshserver sshd[27976]: [ID 800047 auth.debug] debug2: PAM: sshpam_respond entering, 1 responses
Nov  9 10:00:52 sshserver sshd[27976]: [ID 800047 auth.debug] debug3: ssh_msg_send: type 6
Nov  9 10:00:52 sshserver sshd[27976]: [ID 800047 auth.debug] debug3: PAM: sshpam_query entering
Nov  9 10:00:52 sshserver sshd[27976]: [ID 800047 auth.debug] debug3: ssh_msg_recv entering
Nov  9 10:00:52 sshserver sshd[27977]: [ID 384020 auth.debug] PAM[27977]: pam_set_item(7f6e8:authtok)
Nov  9 10:00:52 sshserver last message repeated 1 time
Nov  9 10:00:52 sshserver sshd[27977]: [ID 334087 auth.debug] PAM[27977]: pam_get_user(7f6e8, 0, NULL)
Nov  9 10:00:52 sshserver sshd[27977]: [ID 800047 auth.debug] debug3: ssh_msg_send: type 9
Nov  9 10:00:52 sshserver sshd[27976]: [ID 800047 auth.error] error: PAM: Success for testuser from co-klein-linux.trans.corp
Nov  9 10:00:52 sshserver sshd[27976]: [ID 800047 auth.debug] debug2: auth2_challenge_start: devices <empty>
Nov  9 10:00:52 sshserver sshd[27976]: [ID 800047 auth.debug] debug3: PAM: sshpam_free_ctx entering
Nov  9 10:00:52 sshserver sshd[27976]: [ID 800047 auth.debug] debug3: PAM: sshpam_thread_cleanup entering
Nov  9 10:00:52 sshserver sshd[27976]: [ID 800047 auth.info] Failed keyboard-interactive/pam for testuser from 1.2.3.4 port 33457 ssh2

Keyboard interactive fails as well, note the "error: PAM: Success".  If I move authorized_keys2 out
of the way, keyboard interactive works fine.

Any help is greatly appreciated.  

Thanks!

-Eli




From smooge at gmail.com  Wed Nov 10 05:33:13 2004
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Tue, 9 Nov 2004 11:33:13 -0700
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411090738.iA97c6wh011568@cvs.openbsd.org>
References: <20041109044556.GA928156@hiwaay.net>
	<200411090738.iA97c6wh011568@cvs.openbsd.org>
Message-ID: <80d7e40904110910336aa5534f@mail.gmail.com>

On Tue, 09 Nov 2004 00:38:06 -0700, Theo de Raadt
<deraadt at cvs.openbsd.org> wrote:
> 
> 
> > The OpenSSH web site history page says:
> >
> >    Therefore, the version of OpenSSH was based on these older versions
> >    of ssh 1.2.12, but with many bugs removed and newer features
> >    re-added:
> >
> >      * has all components of a restrictive nature (i.e. patents,
> >        see ssl) directly removed from the source code
> >
> > The CSS algorithm is claimed as a trade secret and there have been
> > several court cases fought over it.  Is that not code "of a restrictive
> > nature"?  Why is such code in OpenSSH?
> 
> I claim that the colour red is a trade secret of me.
> 
> Are you afraid?

Do you know enough about Trade Secret law in the United States and
Europe to really make such a claim? In most cases you could not
consider the colour red a trade secret.. how you make a specific
colour red specifically for your dye manufacturing would be.

> 
> Why is Redhat such a pushover?
> 

Maybe its because the value of the algorithm is not considered enough
to fight over. The other issues could be that ArcFour was desiminated
before DMCA and other US and European laws.. and ACSS was done so
afterwords.

> Is it because they are an American company?
> 

More than likely. They also have a lot of stockholders and lawsuits
filed anytime the stock drops more than 20cents because someone filed
a frivolous item.


> Come on!  Someone tell me what law prohibits the ACSS cipher from
> being used to protect an SSH communication!
> 

I do not think there are any lawyers on this list so any answer people
gave you would be worthless. Most lawyers do not post legal opinions
to electronic lists because they open themselves to various criminal
and civil lawsuits.

> Why does noone want to answer this question?
> 
> 

Because it is so much more fun to bait you and watch your responses. 
I think that most of this argument has been to see if someone can get
you to have Touriets Syndrome.

In the end, Red Hat did not say to OpenSSH that they were going to do
this, but really under the BSD license they do not have to. Heck they
do not have to give the code if they want.

In their .src.rpm, Red Hat does put in a script that was used to take
out the code, AND they did label the tar-ball as openssh-noaccs.tar.gz
versus calling it openssh.tar.gz. All of these things were things that
the original email Damien mentioned that he was worried about not
being there.

On the other side, OpenSSH does not have to answer support/problem
reports from Red Hat, SuSE, Debian or any other group that decides the
ACCS is not to be shipped. On the other hand, they do not have to
answer questions if the code was there either. The fact that people do
answer questions is a nicety that too few people recognize with words
or dollars.


-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator



From deraadt at cvs.openbsd.org  Wed Nov 10 05:40:46 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Tue, 09 Nov 2004 11:40:46 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Tue, 09 Nov 2004 11:33:13 MST."
	<80d7e40904110910336aa5534f@mail.gmail.com> 
Message-ID: <200411091840.iA9Iek0O002627@cvs.openbsd.org>

> > > The OpenSSH web site history page says:
> > >
> > >    Therefore, the version of OpenSSH was based on these older versions
> > >    of ssh 1.2.12, but with many bugs removed and newer features
> > >    re-added:
> > >
> > >      * has all components of a restrictive nature (i.e. patents,
> > >        see ssl) directly removed from the source code
> > >
> > > The CSS algorithm is claimed as a trade secret and there have been
> > > several court cases fought over it.  Is that not code "of a restrictive
> > > nature"?  Why is such code in OpenSSH?
> > 
> > I claim that the colour red is a trade secret of me.
> > 
> > Are you afraid?
> 
> Do you know enough about Trade Secret law in the United States and
> Europe to really make such a claim? In most cases you could not
> consider the colour red a trade secret.. how you make a specific
> colour red specifically for your dye manufacturing would be.

Trade secret law only lets you take action against those who have
violated agreements.  If there is no agreement, and the secret gets
out, it is out.  Tough shit.  Come on, go for it, go do some research,
that is how it works!

> > Why is Redhat such a pushover?
> > 
> 
> Maybe its because the value of the algorithm is not considered enough
> to fight over. The other issues could be that ArcFour was desiminated
> before DMCA and other US and European laws.. and ACSS was done so
> afterwords.

There is no value.  It was a secret.  It is not not a secret.  A trade
secret has ZERO value, and you cannot push around people who discovered
it outside of the framework of an agreement.

> > Is it because they are an American company?
> > 
> 
> More than likely. They also have a lot of stockholders and lawsuits
> filed anytime the stock drops more than 20cents because someone filed
> a frivolous item.

I thought that their users were people they would consult, but
apparently not.


> > Come on!  Someone tell me what law prohibits the ACSS cipher from
> > being used to protect an SSH communication!
> > 
> 
> I do not think there are any lawyers on this list so any answer people
> gave you would be worthless. Most lawyers do not post legal opinions
> to electronic lists because they open themselves to various criminal
> and civil lawsuits.

Well, I have consulted lawyers on this, unlike people who post in
reply (like you).

> > Why does noone want to answer this question?
> > 
> > 
> 
> Because it is so much more fun to bait you and watch your responses. 
> I think that most of this argument has been to see if someone can get
> you to have Touriets Syndrome.
> 
> In the end, Red Hat did not say to OpenSSH that they were going to do
> this, but really under the BSD license they do not have to. Heck they
> do not have to give the code if they want.

They acted disrespectfully towards their user base, and now their user
base is in all likely going to get zero support from the OpenSSH
developers themselves.

> In their .src.rpm, Red Hat does put in a script that was used to take
> out the code, AND they did label the tar-ball as openssh-noaccs.tar.gz
> versus calling it openssh.tar.gz. All of these things were things that
> the original email Damien mentioned that he was worried about not
> being there.
>

> On the other side, OpenSSH does not have to answer support/problem
> reports from Red Hat, SuSE, Debian or any other group that decides the
> ACCS is not to be shipped.

You're right, now they won't get any support.

> On the other hand, they do not have to
> answer questions if the code was there either. The fact that people do
> answer questions is a nicety that too few people recognize with words
> or dollars.

So they have decided for their user base.



From mouring at etoh.eviladmin.org  Wed Nov 10 05:53:29 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 9 Nov 2004 12:53:29 -0600 (CST)
Subject: RedHat forks OpenSSH?
In-Reply-To: <80d7e40904110910336aa5534f@mail.gmail.com>
Message-ID: <Pine.BSO.4.44.0411091250200.8826-100000@etoh.eviladmin.org>



On Tue, 9 Nov 2004, Stephen J. Smoogen wrote:

> On Tue, 09 Nov 2004 00:38:06 -0700, Theo de Raadt
> <deraadt at cvs.openbsd.org> wrote:
> >
> >
> > > The OpenSSH web site history page says:
> > >
> > >    Therefore, the version of OpenSSH was based on these older versions
> > >    of ssh 1.2.12, but with many bugs removed and newer features
> > >    re-added:
> > >
> > >      * has all components of a restrictive nature (i.e. patents,
> > >        see ssl) directly removed from the source code
> > >
> > > The CSS algorithm is claimed as a trade secret and there have been
> > > several court cases fought over it.  Is that not code "of a restrictive
> > > nature"?  Why is such code in OpenSSH?
> >
> > I claim that the colour red is a trade secret of me.
> >
> > Are you afraid?
>
> Do you know enough about Trade Secret law in the United States and
> Europe to really make such a claim? In most cases you could not
> consider the colour red a trade secret.. how you make a specific
> colour red specifically for your dye manufacturing would be.
>

Even at that.. You may *ONLY* sue the person that leaked the trade secret.
Anyone how figures it out on their own (either via reverse engineering or
mistake) are not bound to keep your secret.

People seem to forget this, and MPAA and others keep wanting to link
"Trade Secret" with "Patented Works".. which is confuses things even more.
=)

- Ben




From stend at sten.org  Wed Nov 10 06:12:54 2004
From: stend at sten.org (Sten Drescher)
Date: Tue, 09 Nov 2004 13:12:54 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411090735.iA97ZmHf013896@cvs.openbsd.org>
References: <200411090735.iA97ZmHf013896@cvs.openbsd.org>
Message-ID: <419116B6.4040600@sten.org>

Theo de Raadt wrote:

>Where is the law for that?
>
>I've checked into this.  In case of a trade secret, the only people
>you can litigate against are those who you had agreements with, and
>who broke their agreements.  What law are you basing your statements
>on?  Are you a lawyer?
>  
>
No, I'm not - are you?  I expect that Bunner was represented by 
competent lawyers, though, and if there wasn't law to support the DVD 
CCA's claims, they would have been able to get the case (or at least the 
trade secret claims) dismissed as a matter of law.  They weren't, and if 
"the trade secret had been obtained through improper means", then 
California law supports going after those who subsequently obtained it, 
even if they did not themselves have an agreement with the owner of the 
trade secret.

>No, because that is a lawsuit case, not a LAW.
>
>Are you still quivering in fear at their law suits, or are there
>REAL LAWS?
>  
>
Hint: law suits are based on laws.

> OK -- I get it now. You are a wimp, and Redhat are wimps, and it's OK 
> to be a wimp?

If you're so confident of your position, how about you imdemnify Red Hat 
against any losses due to any trade secret litigation from the DVD CCA - 
or are you too much of a wimp to do that?

Sten



From stend at sten.org  Wed Nov 10 06:15:19 2004
From: stend at sten.org (Sten Drescher)
Date: Tue, 09 Nov 2004 13:15:19 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <Pine.BSO.4.44.0411091250200.8826-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0411091250200.8826-100000@etoh.eviladmin.org>
Message-ID: <41911747.8030502@sten.org>

Ben Lindstrom wrote:

>Even at that.. You may *ONLY* sue the person that leaked the trade secret.
>Anyone how figures it out on their own (either via reverse engineering or
>mistake) are not bound to keep your secret.
>  
>
Then why was Bunner sued?  He neither leaked the trade secret, nor did 
he perform the reverse engineering.

Regards, Sten



From deraadt at cvs.openbsd.org  Wed Nov 10 06:19:27 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Tue, 09 Nov 2004 12:19:27 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Tue, 09 Nov 2004 13:12:54 CST."
	<419116B6.4040600@sten.org> 
Message-ID: <200411091919.iA9JJRLp002751@cvs.openbsd.org>

> >Where is the law for that?
> >
> >I've checked into this.  In case of a trade secret, the only people
> >you can litigate against are those who you had agreements with, and
> >who broke their agreements.  What law are you basing your statements
> >on?  Are you a lawyer?
> >  
> >
> No, I'm not - are you?

No, but the lawyers do take me out for beer every once in a while.

> I expect that Bunner was represented by 
> competent lawyers, though, and if there wasn't law to support the DVD 
> CCA's claims, they would have been able to get the case (or at least the 
> trade secret claims) dismissed as a matter of law.

No, there is not even US law to explain this; what there is is legal
fears alone.

> They weren't, and if 
> "the trade secret had been obtained through improper means",

Where do you get these things from?  What is 'improper means'?

> then 
> California law supports going after those who subsequently obtained it, 

	I think we are all pretty sure that the dis-assembly of the
	80 lines of code in question were done all over the world by
	lots of people, but that the code chunks that most of us use
	now were done in Europe, specificaly in countries of Europe
	that have very strong legal protection for reverse engineering.

> even if they did not themselves have an agreement with the owner of the 
> trade secret.

	Then they go after the person who broke the trade secret
	agreements.

They do not go after you.  Not after me.  Under trade secret law they
can ONLY GO after the people who broke the agreements.

There are no questions.  Go ask a lawyer.  He'll explain it to you
in 3 sentences.

> >No, because that is a lawsuit case, not a LAW.
> >
> >Are you still quivering in fear at their law suits, or are there
> >REAL LAWS?
> >  
> >
> Hint: law suits are based on laws.

No, civil law suits are based in a premise that you can make a quick
buck on the back of some previous case law.

Criminal law, on the other hand, is based on real law.

> > OK -- I get it now. You are a wimp, and Redhat are wimps, and it's OK 
> > to be a wimp?
> 
> If you're so confident of your position, how about you imdemnify Red Hat 
> against any losses due to any trade secret litigation from the DVD CCA - 
> or are you too much of a wimp to do that?

I have better things to do, like make sure that Red Hat's users never
get support from the OpenSSH developers again.

Where are the Red Hat users?



From mouring at etoh.eviladmin.org  Wed Nov 10 06:39:44 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 9 Nov 2004 13:39:44 -0600 (CST)
Subject: RedHat forks OpenSSH?
In-Reply-To: <41911747.8030502@sten.org>
Message-ID: <Pine.BSO.4.44.0411091336380.8826-100000@etoh.eviladmin.org>



On Tue, 9 Nov 2004, Sten Drescher wrote:

> Ben Lindstrom wrote:
>
> >Even at that.. You may *ONLY* sue the person that leaked the trade secret.
> >Anyone how figures it out on their own (either via reverse engineering or
> >mistake) are not bound to keep your secret.
> >
> >
> Then why was Bunner sued?  He neither leaked the trade secret, nor did
> he perform the reverse engineering.
>

Why was DC and AutoZone sued?  <shrug> Same reasons.  Just instead of SCO
coming out on top (as the MPAA seems to have) it just caused them more
pain.

Civil law is screwy.  For as much as I hate trying to remember Criminal
Speedy Trial rules.  It is more consistant in the procedure.

Rarely in Criminal law do you have an attorney trying to "redefine" an
existing congressal law.  Which happens alot in Civil.

- Ben
IAMAL.. I just work around them.



From stend at sten.org  Wed Nov 10 07:03:01 2004
From: stend at sten.org (Sten Drescher)
Date: Tue, 09 Nov 2004 14:03:01 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411091919.iA9JJRLp002751@cvs.openbsd.org>
References: <200411091919.iA9JJRLp002751@cvs.openbsd.org>
Message-ID: <41912275.8050200@sten.org>

Theo de Raadt wrote:

>>They weren't, and if 
>>"the trade secret had been obtained through improper means",
>>    
>>
>
>Where do you get these things from?  What is 'improper means'?
>  
>
That came from the injunction against Bunner.  I thought that you had 
done your research into this?

>They do not go after you.  Not after me.  Under trade secret law they
>can ONLY GO after the people who broke the agreements.
>  
>
Then why was Bunner sued?  It's not as cut and dried as you pretend it 
to be.

>>If you're so confident of your position, how about you imdemnify Red Hat 
>>against any losses due to any trade secret litigation from the DVD CCA - 
>>or are you too much of a wimp to do that?
>>    
>>
>I have better things to do, like make sure that Red Hat's users never
>get support from the OpenSSH developers again.
>  
>
And Red Hat has better things to do than risk having to defend your 
inclusion of ACSS in OpenSSH.

Sten



From cmadams at hiwaay.net  Wed Nov 10 08:13:36 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 9 Nov 2004 15:13:36 -0600
Subject: RedHat forks OpenSSH?
Message-ID: <20041109211336.GC1429068@hiwaay.net>

Has anyone actually _asked_ Red Hat why they patch the code out?
Mailing list posts are not going to get answers, and I see nothing open
in bugzilla.redhat.com.

Someone said the reason may be trade secret (and I carried on the idea
as well as others), but it is more likely that they're doing it because
of the DMCA.  IIRC all the CSS lawsuits based on trade secrets have been
dropped or lost, while DMCA based suits are apparently succeeding.  Yes,
I realize how stupid the DMCA is, but the fact is that it is being
applied to CSS, but Red Hat has other legal battles to fight (like SCO).

I do have a question that it would be nice if someone could answer: why
would I want to use CSS as a cipher in SSH?  As I understand it, CSS is
a fairly weak algorithm; why would I want to use a weak encryption
method?

A different question: why are any of the ciphers being included in
OpenSSH?  I thought that's why OpenSSL was used (if not, why not just
put all the ciphers in OpenSSH and not require OpenSSL?).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From merlette at niksun.com  Wed Nov 10 08:41:01 2004
From: merlette at niksun.com (Darryle Merlette)
Date: Tue, 09 Nov 2004 16:41:01 -0500
Subject: Old vulnerability (CAN-2000-0999)
Message-ID: <4191396D.C137BF30@niksun.com>

Hi folks,
When running Foundstone scan against an appliance with
SSH-1.99-OpenSSH_3.8p1, it flags the following as a high risk
vulnerability:
-------------------------
CVE: CAN-2000-0999
Name: SSH BSD Format String Root Buffer Overflow Vulnerability
Description: A format string vulnerability in SSH may allow remote root
access.
Observation:
  The Secure Shell (sshd) daemon, used for remote administration on the
identified BSD system contains multiple printf format string
vulnerabilities. This allows local attackers to execute arbitrary code
and thereby escalate privileges to root level.
--------------------------

Since this vulnerability is so old, and a patch for it has been known to
exist for almost as long
(ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.7/common/028_format_strings.patch),
I would conclude that this likely is no longer a problem, and the
Foundstone scan result is a false positive. However, I've been unable to
find documented evidence that this has been fixed. Does anyone know for
sure and/or can point me to the proof?
Thanks in advance,
    Darryle
--
___________________________________________________________________________

Darryle Merlette, CISSP        NIKSUN, Inc.
Tel: +1 732 821-5000 x3324     http://www.niksun.com
Cel: +1 908 510-3574           1100 Cornwall Road
Fax: +1 732 821-6000           Monmouth Junction, NJ 08852 USA

"There are 10 types of people. Those who know binary, and those who
don't."
___________________________________________________________________________





From djm at mindrot.org  Wed Nov 10 11:39:16 2004
From: djm at mindrot.org (Damien Miller)
Date: Wed, 10 Nov 2004 11:39:16 +1100
Subject: RedHat forks OpenSSH?
In-Reply-To: <80d7e40904110910336aa5534f@mail.gmail.com>
References: <20041109044556.GA928156@hiwaay.net>	<200411090738.iA97c6wh011568@cvs.openbsd.org>
	<80d7e40904110910336aa5534f@mail.gmail.com>
Message-ID: <41916334.2090407@mindrot.org>

Stephen J. Smoogen wrote:
> In their .src.rpm, Red Hat does put in a script that was used to take
> out the code, AND they did label the tar-ball as openssh-noaccs.tar.gz
> versus calling it openssh.tar.gz. All of these things were things that
> the original email Damien mentioned that he was worried about not
> being there.

Read my original email a few times more, then maybe you won't
misrepresent what I said.



From djm at mindrot.org  Wed Nov 10 11:46:19 2004
From: djm at mindrot.org (Damien Miller)
Date: Wed, 10 Nov 2004 11:46:19 +1100
Subject: RedHat forks OpenSSH?
In-Reply-To: <41912275.8050200@sten.org>
References: <200411091919.iA9JJRLp002751@cvs.openbsd.org>
	<41912275.8050200@sten.org>
Message-ID: <419164DB.2010209@mindrot.org>

Sten Drescher wrote:

>>I have better things to do, like make sure that Red Hat's users never
>>get support from the OpenSSH developers again.
>> 
> And Red Hat has better things to do than risk having to defend your 
> inclusion of ACSS in OpenSSH.

I don't really case what Redhat does, but if they make it difficult for
us to review their changes, then their users don't get support from us.
Simple consequence.

Obviously all the Redhat users are happy with this outcome, so I'm
pretty much done talking on this issue.

-d



From tim at multitalents.net  Wed Nov 10 10:00:53 2004
From: tim at multitalents.net (Tim Rice)
Date: Tue, 9 Nov 2004 15:00:53 -0800 (PST)
Subject: Old vulnerability (CAN-2000-0999)
In-Reply-To: <4191396D.C137BF30@niksun.com>
References: <4191396D.C137BF30@niksun.com>
Message-ID: <Pine.UW2.4.61.0411091455570.23640@server01.int.multitalents.net>

On Tue, 9 Nov 2004, Darryle Merlette wrote:

> Hi folks,
> When running Foundstone scan against an appliance with
> SSH-1.99-OpenSSH_3.8p1, it flags the following as a high risk
> vulnerability:
> -------------------------
> CVE: CAN-2000-0999
[snip]
>
> Since this vulnerability is so old, and a patch for it has been known to
> exist for almost as long
> (ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.7/common/028_format_strings.patch),
> I would conclude that this likely is no longer a problem, and the
> Foundstone scan result is a false positive. However, I've been unable to
> find documented evidence that this has been fixed. Does anyone know for
> sure and/or can point me to the proof?

You can check the CVSWEB at http://cvsweb.mindrot.org/index.cgi/openssh/
That was fixed back in 2.1.1P3

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From dtucker at zip.com.au  Wed Nov 10 12:21:38 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 10 Nov 2004 12:21:38 +1100
Subject: Solaris + PAM/LDAP + pubkey failing?
In-Reply-To: <20041109171158.GR17834@aclue.com>
References: <20041109171158.GR17834@aclue.com>
Message-ID: <41916D22.7010109@zip.com.au>

Eli Klein wrote:
> I've got a Solaris 8 and 9 box using LDAP to successfully authenticate users.
> I can get logged in via ssh using keyboard interactive (via PAM/LDAP). When 
> I try to use pubkey authentication, both the pubkey as well as the fallback to
> keyboard interactive always fail.  I've tried openssh versions as early as 3.4 
> and as new as the 11-06 snapshot with the same behavior.  Everything works fine 
> on a linux machine which is configured to use PAM/LDAP and has openssh 3.9p1 
> installed.  Logs follow.

Which OpenSSH version are those logs from?  What do the sshd parts of 
/etc/pam.conf look like?  Do you have ldap listed in the passwd part of 
/etc/nsswitch.conf (I suspect you do, but it's worth checking).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From davidtg-openssh at justpickone.org  Wed Nov 10 15:10:19 2004
From: davidtg-openssh at justpickone.org (David T-G)
Date: Tue, 9 Nov 2004 23:10:19 -0500
Subject: avoiding 'authenticity' prompt
Message-ID: <20041110041019.GM35474@justpickone.org>

Hi, all --

I have much the same question that Roni Karpachevsky did back in
September.  We use ssh as part of our batch scripts and occasionally come
across a machine we haven't visited before and get hung up.

Within this network we can trust and believe all machines, so I would
like to set a flag that causes the new host key, whatever it may be, to
be added to the known_hosts file and we move on.

Can this be accomplished without taking apart the program and modifying
the source code?


TIA & HAND

:-D
-- 
David T-G
davidtg at justpickone.org
http://justpickone.org/davidtg/      Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041109/82cca2a3/attachment.bin 

From djm at mindrot.org  Wed Nov 10 15:29:32 2004
From: djm at mindrot.org (Damien Miller)
Date: Wed, 10 Nov 2004 15:29:32 +1100
Subject: avoiding 'authenticity' prompt
In-Reply-To: <20041110041019.GM35474@justpickone.org>
References: <20041110041019.GM35474@justpickone.org>
Message-ID: <4191992C.9000102@mindrot.org>

David T-G wrote:
> Hi, all --
> 
> I have much the same question that Roni Karpachevsky did back in
> September.  We use ssh as part of our batch scripts and occasionally come
> across a machine we haven't visited before and get hung up.
> 
> Within this network we can trust and believe all machines, so I would
> like to set a flag that causes the new host key, whatever it may be, to
> be added to the known_hosts file and we move on.

You could start by reading the manpages. You may be pleasantly
surprised.

-d



From davidtg-openssh at justpickone.org  Wed Nov 10 15:35:27 2004
From: davidtg-openssh at justpickone.org (David T-G)
Date: Tue, 9 Nov 2004 23:35:27 -0500
Subject: avoiding 'authenticity' prompt
In-Reply-To: <4191992C.9000102@mindrot.org>
References: <20041110041019.GM35474@justpickone.org>
	<4191992C.9000102@mindrot.org>
Message-ID: <20041110043527.GE68046@justpickone.org>

Damien, et al --

...and then Damien Miller said...
% 
% David T-G wrote:
% > 
...
% > Within this network we can trust and believe all machines, so I would
% > like to set a flag that causes the new host key, whatever it may be, to
% > be added to the known_hosts file and we move on.
% 
% You could start by reading the manpages. You may be pleasantly
% surprised.

I'm sure I would be.  I have read the man pages a few times now but do
acknowledge that I certainly may have overlooked the answer every time.
I have just checked again and neither of the strings'authenticity' nor
'key.fingerprint' appear in my FreeBSD

  OpenSSH_3.5p1 FreeBSD-20030201, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

nor Solaris

  OpenSSH_3.8.1p1-sshrc, OpenSSL 0.9.7d 17 Mar 2004

man pages.  I trust that I should be looking in the ssh(1) pages and not
at the sshd(8) or otherwise esoteric pages.

Might I ask for a hint or two to set me on my way?


% 
% -d


TIA again & HANN

:-D
-- 
David T-G
davidtg at justpickone.org
http://justpickone.org/davidtg/      Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041109/e49e9082/attachment.bin 

From mouring at etoh.eviladmin.org  Wed Nov 10 15:49:20 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 9 Nov 2004 22:49:20 -0600 (CST)
Subject: avoiding 'authenticity' prompt
In-Reply-To: <20041110043527.GE68046@justpickone.org>
Message-ID: <Pine.BSO.4.44.0411092248280.8826-100000@etoh.eviladmin.org>



On Tue, 9 Nov 2004, David T-G wrote:

> Damien, et al --
>
> ...and then Damien Miller said...
> %
> % David T-G wrote:
> % >
> ...
> % > Within this network we can trust and believe all machines, so I would
> % > like to set a flag that causes the new host key, whatever it may be, to
> % > be added to the known_hosts file and we move on.
> %
> % You could start by reading the manpages. You may be pleasantly
> % surprised.
>
> I'm sure I would be.  I have read the man pages a few times now but do
> acknowledge that I certainly may have overlooked the answer every time.
> I have just checked again and neither of the strings'authenticity' nor
> 'key.fingerprint' appear in my FreeBSD
>
>   OpenSSH_3.5p1 FreeBSD-20030201, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
>
> nor Solaris
>
>   OpenSSH_3.8.1p1-sshrc, OpenSSL 0.9.7d 17 Mar 2004
>
> man pages.  I trust that I should be looking in the ssh(1) pages and not
> at the sshd(8) or otherwise esoteric pages.
>
> Might I ask for a hint or two to set me on my way?
>
I suggest ssh_config and "StrictHostKeyChecking".

- Ben



From dtucker at zip.com.au  Wed Nov 10 15:52:38 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 10 Nov 2004 15:52:38 +1100
Subject: avoiding 'authenticity' prompt
In-Reply-To: <20041110043527.GE68046@justpickone.org>
References: <20041110041019.GM35474@justpickone.org>	<4191992C.9000102@mindrot.org>
	<20041110043527.GE68046@justpickone.org>
Message-ID: <41919E96.3010106@zip.com.au>

David T-G wrote:
> man pages.  I trust that I should be looking in the ssh(1) pages and not
> at the sshd(8) or otherwise esoteric pages.
> 
> Might I ask for a hint or two to set me on my way?

Try "man ssh_config" and look for StrictHostKeyChecking.

The ssh_config(5) page documents the config file options and is 
mentioned several times in the ssh(1) page, so I don't think it's esoteric.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From elijah at aclue.com  Wed Nov 10 16:33:51 2004
From: elijah at aclue.com (Eli Klein)
Date: Tue, 9 Nov 2004 22:33:51 -0700
Subject: Solaris + PAM/LDAP + pubkey failing?
In-Reply-To: <41916D22.7010109@zip.com.au>
References: <20041109171158.GR17834@aclue.com> <41916D22.7010109@zip.com.au>
Message-ID: <20041110053351.GS17834@aclue.com>

On Wed, Nov 10, 2004 at 12:21:38PM +1100, Darren Tucker wrote:
> Eli Klein wrote:
> >I've got a Solaris 8 and 9 box using LDAP to successfully authenticate 
> >users.
> >I can get logged in via ssh using keyboard interactive (via PAM/LDAP). 
> >When I try to use pubkey authentication, both the pubkey as well as the 
> >fallback to
> >keyboard interactive always fail.  I've tried openssh versions as early as 
> >3.4 and as new as the 11-06 snapshot with the same behavior.  Everything 
> >works fine on a linux machine which is configured to use PAM/LDAP and has 
> >openssh 3.9p1 installed.  Logs follow.
> 
> Which OpenSSH version are those logs from?  What do the sshd parts of 

3.9p1

> /etc/pam.conf look like?  Do you have ldap listed in the passwd part of 

i've tried a separate entry for sshd:

sshd    auth sufficient         pam_unix_auth.so.1 server_policy
sshd    auth required           pam_ldap.so.1

and just grouping it under "other":

other   auth requisite          pam_authtok_get.so.1
other   auth required           pam_dhkeys.so.1
other   auth binding            pam_unix_auth.so.1 server_policy
other   auth required           pam_ldap.so.1

got the same result under both.. 

> /etc/nsswitch.conf (I suspect you do, but it's worth checking).

yes ;)  ldap login works fine when i'm NOT using a public key..

Thanks!

-Eli



From dan at doxpara.com  Wed Nov 10 17:17:40 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 09 Nov 2004 22:17:40 -0800
Subject: avoiding 'authenticity' prompt
In-Reply-To: <41919E96.3010106@zip.com.au>
References: <20041110041019.GM35474@justpickone.org>	<4191992C.9000102@mindrot.org>	<20041110043527.GE68046@justpickone.org>
	<41919E96.3010106@zip.com.au>
Message-ID: <4191B284.8080706@doxpara.com>

Darren Tucker wrote:

> David T-G wrote:
>
>> man pages.  I trust that I should be looking in the ssh(1) pages and not
>> at the sshd(8) or otherwise esoteric pages.
>>
>> Might I ask for a hint or two to set me on my way?
>
>
> Try "man ssh_config" and look for StrictHostKeyChecking.
>
> The ssh_config(5) page documents the config file options and is 
> mentioned several times in the ssh(1) page, so I don't think it's 
> esoteric.


Heh.  *I* didn't know StrictHostKeyChecking had a "no" option.  I 
thought "no" was the default, not "ask".  When did we get trinary options?

--Dan





From dtucker at zip.com.au  Wed Nov 10 18:39:28 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 10 Nov 2004 18:39:28 +1100
Subject: avoiding 'authenticity' prompt
In-Reply-To: <4191B284.8080706@doxpara.com>
References: <20041110041019.GM35474@justpickone.org>	<4191992C.9000102@mindrot.org>	<20041110043527.GE68046@justpickone.org>	<41919E96.3010106@zip.com.au>
	<4191B284.8080706@doxpara.com>
Message-ID: <4191C5B0.3080306@zip.com.au>

Dan Kaminsky wrote:
> Heh.  *I* didn't know StrictHostKeyChecking had a "no" option.  I
> thought "no" was the default, not "ask".  When did we get trinary options?

Some time before OpenSSH was forked (September 1999), apparently.  This 
from the OpenBSD tree:

$ cvs up -r 1.1 readconf.c
$ cat readconf.c

     case oStrictHostKeyChecking:
[...]
       else if (strcmp(cp, "ask") == 0)
         value = 2;

$ cvs log readconf.c
[...]
revision 1.1
date: 1999/09/26 20:53:37;  author: deraadt;  state: Exp;

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From davidtg-openssh at justpickone.org  Wed Nov 10 21:10:18 2004
From: davidtg-openssh at justpickone.org (David T-G)
Date: Wed, 10 Nov 2004 05:10:18 -0500
Subject: avoiding 'authenticity' prompt
In-Reply-To: <Pine.BSO.4.44.0411092248280.8826-100000@etoh.eviladmin.org>
References: <20041110043527.GE68046@justpickone.org>
	<Pine.BSO.4.44.0411092248280.8826-100000@etoh.eviladmin.org>
Message-ID: <20041110101018.GH68046@justpickone.org>

Ben, et al --

...and then Ben Lindstrom said...
% 
% On Tue, 9 Nov 2004, David T-G wrote:
% 
...
% > Might I ask for a hint or two to set me on my way?
% >
% I suggest ssh_config and "StrictHostKeyChecking".

Aha!  A thousand thanks!

Wow, that is quite cool.  I will definitely be in good shape with that.


% 
% - Ben
% 


Thanks again & HAND

:-D
-- 
David T-G
davidtg at justpickone.org
http://justpickone.org/davidtg/      Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041110/2acb2dc6/attachment.bin 

From davidtg-openssh at justpickone.org  Wed Nov 10 21:12:20 2004
From: davidtg-openssh at justpickone.org (David T-G)
Date: Wed, 10 Nov 2004 05:12:20 -0500
Subject: avoiding 'authenticity' prompt
In-Reply-To: <41919E96.3010106@zip.com.au>
References: <20041110041019.GM35474@justpickone.org>
	<4191992C.9000102@mindrot.org>
	<20041110043527.GE68046@justpickone.org>
	<41919E96.3010106@zip.com.au>
Message-ID: <20041110101220.GI68046@justpickone.org>

Darren, et al --

...and then Darren Tucker said...
% 
% David T-G wrote:
% >man pages.  I trust that I should be looking in the ssh(1) pages and not
% >at the sshd(8) or otherwise esoteric pages.
% >
% >Might I ask for a hint or two to set me on my way?
% 
% Try "man ssh_config" and look for StrictHostKeyChecking.

Thanks!


% 
% The ssh_config(5) page documents the config file options and is 
% mentioned several times in the ssh(1) page, so I don't think it's esoteric.

Indeed.  I had also read through the config man page but must have glazed
over (although my search strings were not in there, either).  Not esoteric
but simply elusive :-)


% 
% -- 
% Darren Tucker (dtucker at zip.com.au)
% GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
%     Good judgement comes with experience. Unfortunately, the experience
% usually comes from bad judgement.


Thanks again & HAND

:-D
-- 
David T-G
davidtg at justpickone.org
http://justpickone.org/davidtg/      Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041110/5d24a622/attachment.bin 

From aphor at mac.com  Thu Nov 11 06:26:28 2004
From: aphor at mac.com (Jeremy McMillan)
Date: Wed, 10 Nov 2004 13:26:28 -0600
Subject: openssh-unix-dev Digest, Vol 19, Issue 8
In-Reply-To: <20041110042601.670AC27C331@shitei.mindrot.org>
References: <20041110042601.670AC27C331@shitei.mindrot.org>
Message-ID: <6B2B9C54-334E-11D9-9121-00039384AB40@mac.com>

On Nov 9, 2004, at 10:26 PM, Chris Adams <cmadams at hiwaay.net> wrote:

> Message: 4
> Date: Tue, 9 Nov 2004 15:13:36 -0600
> From: Chris Adams <cmadams at hiwaay.net>
> Subject: Re: RedHat forks OpenSSH?
> To: openssh-unix-dev at mindrot.org
> Message-ID: <20041109211336.GC1429068 at hiwaay.net>
> Content-Type: text/plain; charset=us-ascii
[deletion for brevity]
> I do have a question that it would be nice if someone could answer: why
> would I want to use CSS as a cipher in SSH?  As I understand it, CSS is
> a fairly weak algorithm; why would I want to use a weak encryption
> method?

Inclusion in OpenSSH as opposed to OpenSSL? No clue.
However, since DVD decoding hardware is fairly ubiquitous, maybe there 
is potential for OpenSSL-engine support to leverage hardware 
acceleration for the ACSS cipher for everything in your system, and not 
just a couple of DVD player apps. The last time I checked, hardware 
crypto acceleration cards are expensive (the cheapest hifn based board 
was around $100 if I remember correctly), and optimized for short SSL 
web traffic. Also, relatively weak symmetric ciphers can be 
strengthened by changing symmetric keys relatively more often.

> A different question: why are any of the ciphers being included in
> OpenSSH?  I thought that's why OpenSSL was used (if not, why not just
> put all the ciphers in OpenSSH and not require OpenSSL?).
>
> -- 
> Chris Adams <cmadams at hiwaay.net>
> Systems and Network Administrator - HiWAAY Internet Services
> I don't speak for anybody but myself - that's enough trouble.
>
---
Jeremy McMillan



From listz at hate.cx  Thu Nov 11 07:26:47 2004
From: listz at hate.cx (listz at hate.cx)
Date: Wed, 10 Nov 2004 13:26:47 -0700
Subject: RedHat forks OpenSSH?
In-Reply-To: <419164DB.2010209@mindrot.org>
References: <200411091919.iA9JJRLp002751@cvs.openbsd.org>
	<41912275.8050200@sten.org> <419164DB.2010209@mindrot.org>
Message-ID: <20041110202647.GA19935@chaos.enmity.org>

i use redhat at work and i think its a bit silly, but then again i never use the
redhat openssh rpm's anyway, we always compile our own so i guess it really
doesn't affect me unless (until?) redhat does something within its other
packages to only allow the redhatssh.

on Wed Nov 10 11:46, Damien Miller disclosed: 
> Sten Drescher wrote:
> 
> >>I have better things to do, like make sure that Red Hat's users never
> >>get support from the OpenSSH developers again.
> >> 
> > And Red Hat has better things to do than risk having to defend your 
> > inclusion of ACSS in OpenSSH.
> 
> I don't really case what Redhat does, but if they make it difficult for
> us to review their changes, then their users don't get support from us.
> Simple consequence.
> 
> Obviously all the Redhat users are happy with this outcome, so I'm
> pretty much done talking on this issue.
> 
> -d
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

<EOF>
::[ RFC 2795 ]::
 "Democracy means simply the bludgeoning of the
 people by the people for the people."
 -Oscar Wilde



From deraadt at cvs.openbsd.org  Thu Nov 11 10:34:51 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Wed, 10 Nov 2004 16:34:51 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Wed, 10 Nov 2004 13:26:47 MST."
	<20041110202647.GA19935@chaos.enmity.org> 
Message-ID: <200411102334.iAANYplp032587@cvs.openbsd.org>

Er, since you are a redhat user, I think you are posting to the wrong
list...

> i use redhat at work and i think its a bit silly, but then again i never use the
> redhat openssh rpm's anyway, we always compile our own so i guess it really
> doesn't affect me unless (until?) redhat does something within its other
> packages to only allow the redhatssh.
> 
> on Wed Nov 10 11:46, Damien Miller disclosed: 
> > Sten Drescher wrote:
> > 
> > >>I have better things to do, like make sure that Red Hat's users never
> > >>get support from the OpenSSH developers again.
> > >> 
> > > And Red Hat has better things to do than risk having to defend your 
> > > inclusion of ACSS in OpenSSH.
> > 
> > I don't really case what Redhat does, but if they make it difficult for
> > us to review their changes, then their users don't get support from us.
> > Simple consequence.
> > 
> > Obviously all the Redhat users are happy with this outcome, so I'm
> > pretty much done talking on this issue.
> > 
> > -d
> > 
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> <EOF>
> ::[ RFC 2795 ]::
>  "Democracy means simply the bludgeoning of the
>  people by the people for the people."
>  -Oscar Wilde
> 



From stend at sten.org  Thu Nov 11 11:12:36 2004
From: stend at sten.org (Sten Drescher)
Date: Wed, 10 Nov 2004 18:12:36 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411102334.iAANYplp032587@cvs.openbsd.org>
References: <200411102334.iAANYplp032587@cvs.openbsd.org>
Message-ID: <4192AE74.30905@sten.org>

Theo de Raadt wrote:

>Er, since you are a redhat user, I think you are posting to the wrong
>list...
>  
>
So now any Red Hat user, even if they build their own OpenSSH binaries 
from your tarballs, is persona non grata on your (apparently) personal 
lists?  Wonderful attitude, just wonderful.

Sten



From cmadams at hiwaay.net  Thu Nov 11 11:21:59 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 10 Nov 2004 18:21:59 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <4192AE74.30905@sten.org>
References: <200411102334.iAANYplp032587@cvs.openbsd.org>
	<4192AE74.30905@sten.org>
Message-ID: <20041111002159.GB1255458@hiwaay.net>

Once upon a time, Sten Drescher <stend at sten.org> said:
> Theo de Raadt wrote:
> >Er, since you are a redhat user, I think you are posting to the wrong
> >list...
> >
> So now any Red Hat user, even if they build their own OpenSSH binaries 
> from your tarballs, is persona non grata on your (apparently) personal 
> lists?  Wonderful attitude, just wonderful.

All this is is a patch!  Red Hat has always applied patches to OpenSSH
for their distribution.  Why the attitude now?

Are you going to tell everyone trying to use OpenSSH on Solaris (or
Cobalt RaQ550s, or ...) to go away as well because the OS vendor patched
it before shipping it?  How many of those vendors even make their
(possibly modified) source code available at all?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From djm at mindrot.org  Thu Nov 11 11:33:23 2004
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Nov 2004 11:33:23 +1100
Subject: RedHat forks OpenSSH?
In-Reply-To: <20041111002159.GB1255458@hiwaay.net>
References: <200411102334.iAANYplp032587@cvs.openbsd.org>	<4192AE74.30905@sten.org>
	<20041111002159.GB1255458@hiwaay.net>
Message-ID: <4192B353.2030001@mindrot.org>

Chris Adams wrote:
> All this is is a patch!  Red Hat has always applied patches to OpenSSH
> for their distribution.  Why the attitude now?

It is not just a patch, it is a pain in the arse. I can't be bothered
looking inside redhat's tarball to see if they have made changes for
each release, or verifying which version random redhat users are
reporting bugs against, so i'll spend my time doing more productive
things.



From djm at mindrot.org  Thu Nov 11 11:35:30 2004
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Nov 2004 11:35:30 +1100
Subject: RedHat forks OpenSSH?
In-Reply-To: <4192AE74.30905@sten.org>
References: <200411102334.iAANYplp032587@cvs.openbsd.org>
	<4192AE74.30905@sten.org>
Message-ID: <4192B3D2.90809@mindrot.org>

Sten Drescher wrote:

> So now any Red Hat user, even if they build their own OpenSSH binaries 
> from your tarballs, is persona non grata on your (apparently) personal 
> lists?  Wonderful attitude, just wonderful.

Nobody has ever been kicked off this list, so please spare us the non
sequiturs.



From stend at sten.org  Thu Nov 11 12:19:33 2004
From: stend at sten.org (Sten Drescher)
Date: Wed, 10 Nov 2004 19:19:33 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <4192B3D2.90809@mindrot.org>
References: <200411102334.iAANYplp032587@cvs.openbsd.org>
	<4192AE74.30905@sten.org> <4192B3D2.90809@mindrot.org>
Message-ID: <4192BE25.80809@sten.org>

Damien Miller wrote:

>Sten Drescher wrote:
>
>  
>
>>So now any Red Hat user, even if they build their own OpenSSH binaries 
>>from your tarballs, is persona non grata on your (apparently) personal 
>>lists?  Wonderful attitude, just wonderful.
>>    
>>
>
>Nobody has ever been kicked off this list, so please spare us the non
>sequiturs.
>  
>
It was hardly a non sequitur.  Mr de Raadt repeatedly made comments 
about how Red Hat users apparently (or "obviously") felt, but as soon as 
one spoke up and expressed his feelings, making a point to note that 
they built their own binaries, Mr de Raadt suggested that he was posting 
to the wrong list.  Care to explain why that should not be expected to 
make that Red Hat user (and, by extension, all Red Hat users) feel 
unwelcome?

Regards, Sten



From djm at mindrot.org  Thu Nov 11 12:41:12 2004
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Nov 2004 12:41:12 +1100
Subject: RedHat forks OpenSSH?
In-Reply-To: <4192BE25.80809@sten.org>
References: <200411102334.iAANYplp032587@cvs.openbsd.org>	<4192AE74.30905@sten.org>
	<4192B3D2.90809@mindrot.org> <4192BE25.80809@sten.org>
Message-ID: <4192C338.6030807@mindrot.org>

Sten Drescher wrote:

> It was hardly a non sequitur.  Mr de Raadt repeatedly made comments 
> about how Red Hat users apparently (or "obviously") felt, but as soon as 
> one spoke up and expressed his feelings, making a point to note that 
> they built their own binaries, Mr de Raadt suggested that he was posting 
> to the wrong list.  Care to explain why that should not be expected to 
> make that Red Hat user (and, by extension, all Red Hat users) feel 
> unwelcome?

I was referring to you erroneous assertion that the lists are the
"personal" playthings of anyone.



From meshino at zebet.co.jp  Thu Nov 11 13:04:54 2004
From: meshino at zebet.co.jp (meshino at zebet.co.jp)
Date: Thu, 11 Nov 2004 11:04:54 +0900
Subject: =?iso-2022-jp?b?WxskQjlwQ04bKEJdGyRCIihMJD41Qno5LTlwIigbKEI=?=
Message-ID: <20041111.1104540302.babaq@meshino-zebet.co.jp>

[AD]
??????????
http://61.197.233.43/at/a.php?i=6


????????
?????????????
???????
????????WEB??????
??????????
2,000??4?????????????????????????


????????? ???
???
http://zebet.co.jp/meshino



From deraadt at cvs.openbsd.org  Thu Nov 11 14:52:23 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Wed, 10 Nov 2004 20:52:23 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Wed, 10 Nov 2004 19:19:33 CST."
	<4192BE25.80809@sten.org> 
Message-ID: <200411110352.iAB3qNwd006389@cvs.openbsd.org>

> >>So now any Red Hat user, even if they build their own OpenSSH binaries 
> >>from your tarballs, is persona non grata on your (apparently) personal 
> >>lists?  Wonderful attitude, just wonderful.
> >>    
> >>
> >
> >Nobody has ever been kicked off this list, so please spare us the non
> >sequiturs.
> >  
> >
> It was hardly a non sequitur.  Mr de Raadt repeatedly made comments 
> about how Red Hat users apparently (or "obviously") felt, but as soon as 
> one spoke up and expressed his feelings,

	to Red Hat... please

> making a point to note that 
> they built their own binaries, Mr de Raadt suggested that he was posting 
> to the wrong list.

Aren't you?  It is their tarball you are building from, isn't it?

> Care to explain why that should not be expected to 
> make that Red Hat user (and, by extension, all Red Hat users) feel 
> unwelcome?

How about you make Red Hat work with the community, instead of attacking
us?



From cmadams at hiwaay.net  Thu Nov 11 15:38:21 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 10 Nov 2004 22:38:21 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411110352.iAB3qNwd006389@cvs.openbsd.org>
References: <4192BE25.80809@sten.org>
	<200411110352.iAB3qNwd006389@cvs.openbsd.org>
Message-ID: <20041111043821.GC1255458@hiwaay.net>

Once upon a time, Theo de Raadt <deraadt at cvs.openbsd.org> said:
> > It was hardly a non sequitur.  Mr de Raadt repeatedly made comments 
> > about how Red Hat users apparently (or "obviously") felt, but as soon as 
> > one spoke up and expressed his feelings,
> 
> 	to Red Hat... please

You asked for users to speak up.  Do you only want to hear from the
users that agree with you?

Damien Miller said in the message that started all of this:

    We consider it very disappointing that Redhat has decided to
    effectively fork OpenSSH without consulting the OpenSSH
    developers or their own community. It is not too late for Redhat
    to reconsider, or for the community to urge them to do so.

Now some users are saying to the OpenSSH developers that maybe they
should reconsider.  Will you not at least listen, as you ask Red Hat to
do?

Damien also said:

    This source tarball is modified from the official portable
    OpenSSH distribution. It does not have a digital signature, an
    independent download site or even a basic list of changes.

Red Hat's long-time interpretation of "pristine" is not necessarily that
the original tarball downloaded from the original location is used.  For
a while now they have routinely re-compressed tarballs (from gzip to
bzip2) to save space (although I think this may be going away as more
CDs and DVDs are used).  Source RPMs for OpenSSH have never to my
knowlege included any digital signature files (the SRPM itself is signed
by Red Hat).

Red Hat also has a well-known policy of removing source code that falls
under patents or the DMCA; source code that cannot legally be
distributed freely in the US (they are after all a US company).  Code
that implements MP3 decoding is a well-known example (removed from
xmms).  The DMCA and its applications to CSS is bad.  However, for the
time being, Fedora cannot include CSS code and still be freely
distributable in the US.  Even if the code is not used, including it in
the source RPMs is not allowed.

In the case of the modified OpenSSH tarball, the script used to
generated the modified tarball is included.  That means it takes one
additional step to verify that the sources have not been tampered with;
instead of untarring an "official" OpenSSH tarball, untarring the
tarball from the SRPM, and running diff, the script from the SRPM needs
to be run on the source extracted from the official tarball.

Damien:

    We are also curious as to the extent that the community was
    involved in this decision; OpenSSH is developed by volunteers and
    Fedora is at least ostensibly a community effort. The OpenSSH
    developers were not contacted and there does not appear to have
    been any discussion of the change on any public mailing list.
    Even the RPM Changelog entry "disable ACSS support" greatly
    understates the nature of the change. It appears that the
    community was not consulted at all and that this change was made
    unilaterally by Redhat, with no explanation.

The acss support was added to OpenSSH without public discussion that I
see.  It has the unique position of being the only un-documented cipher
in OpenSSH.  I have asked here why it is there at all and why I would
want to use it with no response.  How open is that?

> Aren't you?  It is their tarball you are building from, isn't it?

If you read what was written originally you would have seen the answer
to that.  Instead, you attack.

> > Care to explain why that should not be expected to 
> > make that Red Hat user (and, by extension, all Red Hat users) feel 
> > unwelcome?
> 
> How about you make Red Hat work with the community, instead of attacking
> us?

How did Red Hat attack you?  Patching your code is not an attack.  You
have attacked Red Hat.

If you have read this far: would the OpenSSH developers consider moving
the CSS code to a library distributed separately from OpenSSH such that
the OpenSSH tarballs are not "tainted"?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From djm at mindrot.org  Thu Nov 11 16:28:46 2004
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Nov 2004 16:28:46 +1100
Subject: RedHat forks OpenSSH?
In-Reply-To: <20041111043821.GC1255458@hiwaay.net>
References: <4192BE25.80809@sten.org>	<200411110352.iAB3qNwd006389@cvs.openbsd.org>
	<20041111043821.GC1255458@hiwaay.net>
Message-ID: <4192F88E.8090803@mindrot.org>

Chris Adams wrote:

> Now some users are saying to the OpenSSH developers that maybe they
> should reconsider.  Will you not at least listen, as you ask Red Hat to
> do?

Who said we haven't listened? I just haven't heard any convincing
arguments why we should spend extra time supporting a vendor who
makes our jobs harder and won't even do us the courtesy of responding
to our comments.



From deraadt at cvs.openbsd.org  Thu Nov 11 16:31:13 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Wed, 10 Nov 2004 22:31:13 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Thu, 11 Nov 2004 16:28:46 +1100."
	<4192F88E.8090803@mindrot.org> 
Message-ID: <200411110531.iAB5VDBa029778@cvs.openbsd.org>

> > Now some users are saying to the OpenSSH developers that maybe they
> > should reconsider.  Will you not at least listen, as you ask Red Hat to
> > do?
> 
> Who said we haven't listened? I just haven't heard any convincing
> arguments why we should spend extra time supporting a vendor who
> makes our jobs harder and won't even do us the courtesy of responding
> to our comments.

Damien is right.

Noone at Red Hat has responded.  Very few users have responded too.

Our opinions as to how to deal with this are starting to calcify.

Perhaps that is for the better.



From Jefferson.Ogata at noaa.gov  Thu Nov 11 16:55:50 2004
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Thu, 11 Nov 2004 00:55:50 -0500
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411110531.iAB5VDBa029778@cvs.openbsd.org>
References: <200411110531.iAB5VDBa029778@cvs.openbsd.org>
Message-ID: <4192FEE6.1060108@noaa.gov>

Theo de Raadt wrote:
> Damien is right.
> 
> Noone at Red Hat has responded.  Very few users have responded too.
> 
> Our opinions as to how to deal with this are starting to calcify.
> 
> Perhaps that is for the better.

All due respect to you, Theo, but one thing perplexes me:

What practical difference in terms of support would it make that Red Hat 
has omitted a cipher? Is it really likely to change the nature of the 
problems people have? I guess if someone complains that they can't 
figure out why acss isn't working, sure, but otherwise...?

I'm also curious why it's important to have this code in the 
distribution. What practical use does it serve? Shouldn't we just stick 
with blowfish et al anyway?

I find Red Hat to be a pretty competent company, and I'm a fairly heavy 
user. I have no problem with them dropping this cipher if they see fit. 
It's certainly no threat to security not to have an apparently 
questionable cipher in the mix. It is perhaps odd that no one from Red 
Hat has chimed in on this, but maybe that just means that the DMCA 
threat explanation is the right one.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>



From djm at mindrot.org  Thu Nov 11 17:14:39 2004
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Nov 2004 17:14:39 +1100
Subject: RedHat forks OpenSSH?
In-Reply-To: <4192FEE6.1060108@noaa.gov>
References: <200411110531.iAB5VDBa029778@cvs.openbsd.org>
	<4192FEE6.1060108@noaa.gov>
Message-ID: <4193034F.6050207@mindrot.org>

Jefferson Ogata wrote:

> I'm also curious why it's important to have this code in the 
> distribution. What practical use does it serve? Shouldn't we just stick 
> with blowfish et al anyway?

I don't really care if Redhat disables ciphers or modifies ssh. They
have patched ssh for years and we don't have a problem with that. These
patches are conveniently located in their source RPM, so they can be
easily reviewed.

OTOH by making their own tarball, they add extra hassle that we have to
go through when we investigate bug reports from redhat users. We can't
just look at the patches, we have to do this silly dance with diff.

Who knows what their misguided lawyers are going to chop next?
(A)RC4 is in exactly the same legal boat as ACSS, it just isn't as well
publicised among the masses. DSA too has had vague threats hanging over
it. Maybe they may wake up on the wrong side of bed and start taking
the five year old ssh trademark threat seriously? (yes, this last one is
a joke)

Nobody has answered: why should we put in extra effort to support
RedHat users? That is the essence of the problem.



From raynorj at mn.rr.com  Thu Nov 11 18:00:10 2004
From: raynorj at mn.rr.com (J Raynor)
Date: Thu, 11 Nov 2004 01:00:10 -0600
Subject: patch adding none cipher/mac for ssh v2
Message-ID: <41930DFA.8080105@mn.rr.com>


Below is a patch that adds the ability to have a none cipher and mac for 
protocol version 2.  By default, sshd will not allow these to be used; 
an admin will have to explicitly allow them in the Ciphers and MACs 
section of sshd_config.  Additionally, the client will not use these 
unless explicitly instructed to by the user.

The actual name of the cipher is 'none2', to distinguish it from the 
'none' cipher available for ssh v1.  The name of the mac is hmac-none.

The reasoning for having these is that there are times when a user might 
not want their session encrypted.  For instance, when using ssh over an 
already secured interface (IPsec), through another ssh tunnel, or when 
doing port forwarding over the loopback interface.  It can be worthwhile 
to save on cpu usage in these and other cases.



Index: cipher.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/cipher.c,v
retrieving revision 1.71
diff -c -r1.71 cipher.c
*** cipher.c    2004/07/28 09:40:29     1.71
--- cipher.c    2004/11/11 01:07:02
***************
*** 65,70 ****
--- 65,71 ----
         { "3des",               SSH_CIPHER_3DES, 8, 16, evp_ssh1_3des },
         { "blowfish",           SSH_CIPHER_BLOWFISH, 8, 32, evp_ssh1_bf },

+       { "none2",              SSH_CIPHER_SSH2, 8, 0, EVP_enc_null },
         { "3des-cbc",           SSH_CIPHER_SSH2, 8, 24, EVP_des_ede3_cbc },
         { "blowfish-cbc",       SSH_CIPHER_SSH2, 8, 16, EVP_bf_cbc },
         { "cast128-cbc",        SSH_CIPHER_SSH2, 8, 16, EVP_cast5_cbc },
Index: mac.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/mac.c,v
retrieving revision 1.6
diff -c -r1.6 mac.c
*** mac.c       2003/09/18 13:02:21     1.6
--- mac.c       2004/11/11 01:07:03
***************
*** 45,50 ****
--- 45,51 ----
         { "hmac-md5-96",                EVP_md5, 96 },
         { "hmac-ripemd160",             EVP_ripemd160, 0 },
         { "hmac-ripemd160 at openssh.com", EVP_ripemd160, 0 },
+       { "hmac-none",                  EVP_md_null, 0 },
         { NULL,                         NULL, 0 }
   };





From dtucker at zip.com.au  Thu Nov 11 18:43:51 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 11 Nov 2004 18:43:51 +1100
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <41930DFA.8080105@mn.rr.com>
References: <41930DFA.8080105@mn.rr.com>
Message-ID: <41931837.9080307@zip.com.au>

J Raynor wrote:
> Below is a patch that adds the ability to have a none cipher and mac for 
> protocol version 2. [..]
> 
> The actual name of the cipher is 'none2', to distinguish it from the 
> 'none' cipher available for ssh v1.  The name of the mac is hmac-none.

Leaving aside whether or not this is a good idea (which has been done to 
death here and elsewhere many times before, check the archives) if 
you're going to do this then you ought to either stick with the specs[1] 
and call them "none" or make them local extensions[2], eg 
"none2 at your.domain.com".

[1] http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-19.txt
(section 6.3 & 6.4)

[2] http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-17.txt
(section 4.2 and 6)

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From deraadt at cvs.openbsd.org  Thu Nov 11 19:08:05 2004
From: deraadt at cvs.openbsd.org (Theo de Raadt)
Date: Thu, 11 Nov 2004 01:08:05 -0700
Subject: RedHat forks OpenSSH? 
In-Reply-To: Your message of "Thu, 11 Nov 2004 00:55:50 EST."
	<4192FEE6.1060108@noaa.gov> 
Message-ID: <200411110808.iAB885DT006260@cvs.openbsd.org>

> Theo de Raadt wrote:
> > Damien is right.
> > 
> > Noone at Red Hat has responded.  Very few users have responded too.
> > 
> > Our opinions as to how to deal with this are starting to calcify.
> > 
> > Perhaps that is for the better.
> 
> All due respect to you, Theo, but one thing perplexes me:
> 
> What practical difference in terms of support would it make that Red Hat 
> has omitted a cipher? Is it really likely to change the nature of the 
> problems people have? I guess if someone complains that they can't 
> figure out why acss isn't working, sure, but otherwise...?
> 
> I'm also curious why it's important to have this code in the 
> distribution. What practical use does it serve? Shouldn't we just stick 
> with blowfish et al anyway?
> 
> I find Red Hat to be a pretty competent company, and I'm a fairly heavy 
> user.

<snip>

Then you talk to them.  You just lost some people's support.



From listz at hate.cx  Thu Nov 11 19:19:47 2004
From: listz at hate.cx (listz at hate.cx)
Date: Thu, 11 Nov 2004 01:19:47 -0700
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411110352.iAB3qNwd006389@cvs.openbsd.org>
References: <4192BE25.80809@sten.org>
	<200411110352.iAB3qNwd006389@cvs.openbsd.org>
Message-ID: <20041111081947.GA20533@chaos.enmity.org>

No, I am using the tarball directly from the OpenSSH group, from 
ftp.openbsd.org. I understand that you don't want to support RedHat's 
modifications to the source, but I am using the source directly from OpenSSH on 
a RedHat system. Does that mean the list is unwilling to hear my questions 
(should one arise)?

on Wed Nov 10 20:52, Theo de Raadt disclosed: 
> > >>So now any Red Hat user, even if they build their own OpenSSH binaries 
> > >>from your tarballs, is persona non grata on your (apparently) personal 
> > >>lists?  Wonderful attitude, just wonderful.
> > >>    
> > >>
> > >
> > >Nobody has ever been kicked off this list, so please spare us the non
> > >sequiturs.
> > >  
> > >
> > It was hardly a non sequitur.  Mr de Raadt repeatedly made comments 
> > about how Red Hat users apparently (or "obviously") felt, but as soon as 
> > one spoke up and expressed his feelings,
> 
> 	to Red Hat... please
> 
> > making a point to note that 
> > they built their own binaries, Mr de Raadt suggested that he was posting 
> > to the wrong list.
> 
> Aren't you?  It is their tarball you are building from, isn't it?
> 
> > Care to explain why that should not be expected to 
> > make that Red Hat user (and, by extension, all Red Hat users) feel 
> > unwelcome?
> 
> How about you make Red Hat work with the community, instead of attacking
> us?
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

<EOF>
::[ RFC 2795 ]::
 "Democracy means simply the bludgeoning of the
 people by the people for the people."
 -Oscar Wilde



From raynorj at mn.rr.com  Thu Nov 11 20:54:03 2004
From: raynorj at mn.rr.com (J Raynor)
Date: Thu, 11 Nov 2004 03:54:03 -0600
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <41931837.9080307@zip.com.au>
References: <41930DFA.8080105@mn.rr.com> <41931837.9080307@zip.com.au>
Message-ID: <419336BB.2040608@mn.rr.com>

Below is an updated patch, FWIW.

I only found 1 thread about this in the past, but that might be because 
the archive search isn't working well.  For that thread, I didn't see 
any good arguments against adding this.

I'd like to reiterate that, for this patch:

1.  An admin would have to explicitly allow the none cipher/mac by 
modifying the Ciphers and MACs sections of sshd_config.
2.  The client would have to explicitly request the none cipher.  In 
other words, a user couldn't unknowingly/accidentally initiate an 
unencrypted ssh session, even if the ssh server allowed the none cipher.


I certainly see the argument for not allowing the none cipher/mac by 
default.  But if someone with admin rights wants/needs an unencrypted 
login session, you aren't going to prevent them from setting it up by 
disallowing the none cipher.  You'll just force them to use another 
tool, like rsh.




Index: cipher.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/cipher.c,v
retrieving revision 1.71
diff -c -r1.71 cipher.c
*** cipher.c    2004/07/28 09:40:29     1.71
--- cipher.c    2004/11/11 09:07:30
***************
*** 60,70 ****
         u_int   key_len;
         const EVP_CIPHER        *(*evptype)(void);
   } ciphers[] = {
-       { "none",               SSH_CIPHER_NONE, 8, 0, EVP_enc_null },
         { "des",                SSH_CIPHER_DES, 8, 8, EVP_des_cbc },
         { "3des",               SSH_CIPHER_3DES, 8, 16, evp_ssh1_3des },
         { "blowfish",           SSH_CIPHER_BLOWFISH, 8, 32, evp_ssh1_bf },

         { "3des-cbc",           SSH_CIPHER_SSH2, 8, 24, EVP_des_ede3_cbc },
         { "blowfish-cbc",       SSH_CIPHER_SSH2, 8, 16, EVP_bf_cbc },
         { "cast128-cbc",        SSH_CIPHER_SSH2, 8, 16, EVP_cast5_cbc },
--- 60,70 ----
         u_int   key_len;
         const EVP_CIPHER        *(*evptype)(void);
   } ciphers[] = {
         { "des",                SSH_CIPHER_DES, 8, 8, EVP_des_cbc },
         { "3des",               SSH_CIPHER_3DES, 8, 16, evp_ssh1_3des },
         { "blowfish",           SSH_CIPHER_BLOWFISH, 8, 32, evp_ssh1_bf },

+       { "none",               SSH_CIPHER_SSH2, 8, 0, EVP_enc_null },
         { "3des-cbc",           SSH_CIPHER_SSH2, 8, 24, EVP_des_ede3_cbc },
         { "blowfish-cbc",       SSH_CIPHER_SSH2, 8, 16, EVP_bf_cbc },
         { "cast128-cbc",        SSH_CIPHER_SSH2, 8, 16, EVP_cast5_cbc },
Index: mac.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/mac.c,v
retrieving revision 1.6
diff -c -r1.6 mac.c
*** mac.c       2003/09/18 13:02:21     1.6
--- mac.c       2004/11/11 09:07:32
***************
*** 45,50 ****
--- 45,51 ----
         { "hmac-md5-96",                EVP_md5, 96 },
         { "hmac-ripemd160",             EVP_ripemd160, 0 },
         { "hmac-ripemd160 at openssh.com", EVP_ripemd160, 0 },
+       { "none",                       EVP_md_null, 0 },
         { NULL,                         NULL, 0 }
   };




Darren Tucker wrote:
> J Raynor wrote:
> 
>> Below is a patch that adds the ability to have a none cipher and mac 
>> for protocol version 2. [..]
>>
>> The actual name of the cipher is 'none2', to distinguish it from the 
>> 'none' cipher available for ssh v1.  The name of the mac is hmac-none.
> 
> 
> Leaving aside whether or not this is a good idea (which has been done to 
> death here and elsewhere many times before, check the archives) if 
> you're going to do this then you ought to either stick with the specs[1] 
> and call them "none" or make them local extensions[2], eg 
> "none2 at your.domain.com".
> 
> [1] http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-19.txt
> (section 6.3 & 6.4)
> 
> [2] 
> http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-17.txt
> (section 4.2 and 6)
> 



From dtucker at zip.com.au  Thu Nov 11 21:07:30 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 11 Nov 2004 21:07:30 +1100
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <419336BB.2040608@mn.rr.com>
References: <41930DFA.8080105@mn.rr.com> <41931837.9080307@zip.com.au>
	<419336BB.2040608@mn.rr.com>
Message-ID: <419339E2.60108@zip.com.au>

J Raynor wrote:
> I only found 1 thread about this in the past, but that might be because 
> the archive search isn't working well.  For that thread, I didn't see 
> any good arguments against adding this.

Try: http://bugzilla.mindrot.org/show_bug.cgi?id=877

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From cmadams at hiwaay.net  Fri Nov 12 01:16:17 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 11 Nov 2004 08:16:17 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <4192F88E.8090803@mindrot.org>
References: <4192BE25.80809@sten.org>
	<200411110352.iAB3qNwd006389@cvs.openbsd.org>
	<20041111043821.GC1255458@hiwaay.net>
	<4192F88E.8090803@mindrot.org>
Message-ID: <20041111141616.GB1508368@hiwaay.net>

Once upon a time, Damien Miller <djm at mindrot.org> said:
> Chris Adams wrote:
> > Now some users are saying to the OpenSSH developers that maybe they
> > should reconsider.  Will you not at least listen, as you ask Red Hat to
> > do?
> 
> Who said we haven't listened? I just haven't heard any convincing
> arguments why we should spend extra time supporting a vendor who
> makes our jobs harder and won't even do us the courtesy of responding
> to our comments.

As you said, Red Hat is just part of the Fedora community.  Are they the
only part of the community you will listen to?

Someone said that Debian is considering or will likely make the same
change (again because of the DMCA).  Would you consider moving acss out
of the main tarbll then?  If so, how about saving them the trouble and
doing it now?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From Richard.Dickens at reuters.com  Fri Nov 12 03:04:23 2004
From: Richard.Dickens at reuters.com (Richard Dickens)
Date: Thu, 11 Nov 2004 16:04:23 +0000
Subject: Any plans implement MaxAuthTriesLog?
Message-ID: <115DC4D74CF1CF4C8C5C5069BA00978D021C39F0@LONSMSXM02.emea.ime.reuters.com>

Hello there,

I've just upgraded to 3.9p1 and I notice that I'm not getting any "Too
many authorization failure" messages written to my syslog. 

This seems to be controlled by MaxAuthTriesLog in Sun's implementation
of SSH. Are there any plans to do the same in OpenSSH?

Regards,
Richard Dickens


-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.



From mouring at etoh.eviladmin.org  Fri Nov 12 03:49:58 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 11 Nov 2004 10:49:58 -0600 (CST)
Subject: Any plans implement MaxAuthTriesLog?
In-Reply-To: <115DC4D74CF1CF4C8C5C5069BA00978D021C39F0@LONSMSXM02.emea.ime.reuters.com>
Message-ID: <Pine.BSO.4.44.0411111049360.8826-100000@etoh.eviladmin.org>


     MaxAuthTries
             Specifies the maximum number of authentication attempts permitted
             per connection.  Once the number of failures reaches half this
             value, additional failures are logged.  The default is 6.


- Ben

On Thu, 11 Nov 2004, Richard Dickens wrote:

> Hello there,
>
> I've just upgraded to 3.9p1 and I notice that I'm not getting any "Too
> many authorization failure" messages written to my syslog.
>
> This seems to be controlled by MaxAuthTriesLog in Sun's implementation
> of SSH. Are there any plans to do the same in OpenSSH?
>
> Regards,
> Richard Dickens
>
>
> -----------------------------------------------------------------
>         Visit our Internet site at http://www.reuters.com
>
> Get closer to the financial markets with Reuters Messaging - for more
> information and to register, visit http://www.reuters.com/messaging
>
> Any views expressed in this message are those of  the  individual
> sender,  except  where  the sender specifically states them to be
> the views of Reuters Ltd.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From Jefferson.Ogata at noaa.gov  Fri Nov 12 04:05:59 2004
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Thu, 11 Nov 2004 12:05:59 -0500
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411110808.iAB885DT006260@cvs.openbsd.org>
References: <200411110808.iAB885DT006260@cvs.openbsd.org>
Message-ID: <41939BF7.9040004@noaa.gov>

Theo de Raadt wrote:
>Jefferson Ogata wrote:
[attribution restored]
>>I'm also curious why it's important to have this code in the 
>>distribution. What practical use does it serve? Shouldn't we just stick 
>>with blowfish et al anyway?
>>
>>I find Red Hat to be a pretty competent company, and I'm a fairly heavy 
>>user.
> 
> <snip>
> 
> Then you talk to them.  You just lost some people's support.

I don't understand the petulant attitude. All I've ever done here is to 
contribute; I've never asked for support. Why are you so married to this 
bit of code that you're willing to alienate people over it? I have no 
doubt that you understand the practical issue here: there's no point in 
including code someone--right or wrong--might sue you over, if that code 
doesn't do anything particularly useful. Of all the ciphers in openssh, 
acss is clearly the one that has been tangentially the subject of a lot 
of recent litigation, and that not for use, but for dissemination of 
code. Personally, if I can do something simple, cheap, and harmless to 
avoid getting a subpoena, I'll do it. I have mouths to feed and real 
work to do.

What it's starting to sound like is that a few openssh developers 
decided it was time to use openssh to take a stand against RIAA on 
CSS--lamely, I might add: acss in openssh is completely unnecessary. If 
so, this is just going to marginalize openssh, and we should expect to 
see vendors react to protect themselves. If you don't feel like 
supporting those vendors' customers, fine--the rest of us will do it. 
But it would seem kind of selfish on the part of those who want to take 
a stand if they also use it as an excuse to avoid helping people. That's 
all it is: an excuse. I read the questions people post here; I'll be 
amazed if Red Hat's omission of acss or their modified tarball ever, 
ever arise as practical support issues.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>



From raynorj at mn.rr.com  Fri Nov 12 04:28:26 2004
From: raynorj at mn.rr.com (J Raynor)
Date: Thu, 11 Nov 2004 11:28:26 -0600
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <419339E2.60108@zip.com.au>
References: <41930DFA.8080105@mn.rr.com> <41931837.9080307@zip.com.au>
	<419336BB.2040608@mn.rr.com> <419339E2.60108@zip.com.au>
Message-ID: <4193A13A.3080006@mn.rr.com>


Thank you for taking the time to send your responses.  Since it looks 
like the patch won't be applied, please count me as one more user who 
feels openssh shouldn't dictate policy.

As a final note, I'd like to point out that kerberos allows the user to 
choose whether their session is encrypted or not.  So aside from the few 
people who may have argued the point on the openssh mailing lists, there 
are groups of people out there who want this choice.


Darren Tucker wrote:
> J Raynor wrote:
> 
>> I only found 1 thread about this in the past, but that might be 
>> because the archive search isn't working well.  For that thread, I 
>> didn't see any good arguments against adding this.
> 
> 
> Try: http://bugzilla.mindrot.org/show_bug.cgi?id=877
> 



From Jefferson.Ogata at noaa.gov  Fri Nov 12 04:27:40 2004
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Thu, 11 Nov 2004 12:27:40 -0500
Subject: RedHat forks OpenSSH?
In-Reply-To: <41939BF7.9040004@noaa.gov>
References: <200411110808.iAB885DT006260@cvs.openbsd.org>
	<41939BF7.9040004@noaa.gov>
Message-ID: <4193A10C.2020107@noaa.gov>

Jefferson Ogata wrote:
> What it's starting to sound like is that a few openssh developers 
> decided it was time to use openssh to take a stand against RIAA on 
> CSS--lamely, I might add: acss in openssh is completely unnecessary. If 

I mean MPAA. Still uncoffeed here...

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>



From listz at hate.cx  Fri Nov 12 04:32:48 2004
From: listz at hate.cx (listz at hate.cx)
Date: Thu, 11 Nov 2004 10:32:48 -0700
Subject: RedHat forks OpenSSH?
In-Reply-To: <41939BF7.9040004@noaa.gov>
References: <200411110808.iAB885DT006260@cvs.openbsd.org>
	<41939BF7.9040004@noaa.gov>
Message-ID: <20041111173248.GA24096@chaos.enmity.org>

However if Theo and other did cave at every prospect of some corporation
flexing their muscles then, as he pointed out before, ssh.com would have already
subjected the project and you couldn't type "ssh" at the command line for
OpenSSH. 

However, I think that if someone decides they don't agree with Red Hat's
decision or want support from this mailing list they can compile the code
from ftp.openbsd.org themselves (consequently I compile for other reasons). Red
Hat never asked us (well me anyway) whether they should make the change, we
didn't have any input. Unfortunately I am stuck with Red Hat at work, lots of
commercial applications that I must use only support Red Hat Linux (used to
support BSD's but no longer, also only the RH distro). 

While I know Red Hat does some QA on packages I remember a glibc patch recently
that crapped up any system running a custom (not stock RH) kernel. They're only
human, while trying to remove ACSS they could crap something else up
inadvertantly and it shouldn't be Theo, Damien or anyone else's job on this list
(unless there are RH engineers subscribed) to support them.

I'd love to move those systems back to a BSD like I have at home, I just don't
have that luxury. At the same time I hope even though circumstances dictate I
must use Red Hat I can still come to the list with questions should I need some
help.

on Thu Nov 11 12:05, Jefferson Ogata disclosed: 
> Theo de Raadt wrote:
> >Jefferson Ogata wrote:
> [attribution restored]
> >>I'm also curious why it's important to have this code in the 
> >>distribution. What practical use does it serve? Shouldn't we just stick 
> >>with blowfish et al anyway?
> >>
> >>I find Red Hat to be a pretty competent company, and I'm a fairly heavy 
> >>user.
> >
> ><snip>
> >
> >Then you talk to them.  You just lost some people's support.
> 
> I don't understand the petulant attitude. All I've ever done here is to 
> contribute; I've never asked for support. Why are you so married to this 
> bit of code that you're willing to alienate people over it? I have no 
> doubt that you understand the practical issue here: there's no point in 
> including code someone--right or wrong--might sue you over, if that code 
> doesn't do anything particularly useful. Of all the ciphers in openssh, 
> acss is clearly the one that has been tangentially the subject of a lot 
> of recent litigation, and that not for use, but for dissemination of 
> code. Personally, if I can do something simple, cheap, and harmless to 
> avoid getting a subpoena, I'll do it. I have mouths to feed and real 
> work to do.
> 
> What it's starting to sound like is that a few openssh developers 
> decided it was time to use openssh to take a stand against RIAA on 
> CSS--lamely, I might add: acss in openssh is completely unnecessary. If 
> so, this is just going to marginalize openssh, and we should expect to 
> see vendors react to protect themselves. If you don't feel like 
> supporting those vendors' customers, fine--the rest of us will do it. 
> But it would seem kind of selfish on the part of those who want to take 
> a stand if they also use it as an excuse to avoid helping people. That's 
> all it is: an excuse. I read the questions people post here; I'll be 
> amazed if Red Hat's omission of acss or their modified tarball ever, 
> ever arise as practical support issues.
> 
> -- 
> Jefferson Ogata <Jefferson.Ogata at noaa.gov>
> NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

<EOF>
::[ RFC 2795 ]::
 "Democracy means simply the bludgeoning of the
 people by the people for the people."
 -Oscar Wilde



From Jefferson.Ogata at noaa.gov  Fri Nov 12 06:16:32 2004
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Thu, 11 Nov 2004 14:16:32 -0500
Subject: RedHat forks OpenSSH?
In-Reply-To: <20041111173248.GA24096@chaos.enmity.org>
References: <200411110808.iAB885DT006260@cvs.openbsd.org>	<41939BF7.9040004@noaa.gov>
	<20041111173248.GA24096@chaos.enmity.org>
Message-ID: <4193BA90.7080800@noaa.gov>

listz at hate.cx wrote:
> However if Theo and other did cave at every prospect of some corporation
> flexing their muscles then, as he pointed out before, ssh.com would have already
> subjected the project and you couldn't type "ssh" at the command line for
> OpenSSH. 

If acss were somehow central to openssh's functionality, as it is with 
DVD decoding, I'd totally agree. But here is seems it's been added for 
no other reason than to taunt lawyers. It's not a question of caving; 
it's more like antagonism, all the more so because acss is a cipher with 
  a very small key size. Inclusion of acss does nothing to strengthen 
openssh, and may well weaken it or even introduce a critical vulnerability.

Like everyone else, Red Hat chooses its battles, and, having deep 
pockets, it's a tempting target for litigation. I'm grateful to them for 
fighting SCO, and I've got no problem if they want to build fences to 
keep the other bozos away.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>



From Sergio.Gelato at astro.su.se  Fri Nov 12 06:54:15 2004
From: Sergio.Gelato at astro.su.se (Sergio Gelato)
Date: Thu, 11 Nov 2004 20:54:15 +0100
Subject: RedHat forks OpenSSH?
In-Reply-To: <20041111141616.GB1508368@hiwaay.net>
References: <4192BE25.80809@sten.org>
	<200411110352.iAB3qNwd006389@cvs.openbsd.org>
	<20041111043821.GC1255458@hiwaay.net>
	<4192F88E.8090803@mindrot.org>
	<20041111141616.GB1508368@hiwaay.net>
Message-ID: <20041111195415.GB21858@astro.su.se>

* Chris Adams [2004-11-11 08:16:17 -0600]:
> Someone said that Debian is considering or will likely make the same
> change (again because of the DMCA).

As far as I can tell (after searching the archives for "openssh acss")
the matter hasn't been brought up on debian-legal yet. One has to wonder
what informed that Someone's opinion.



From Jefferson.Ogata at noaa.gov  Fri Nov 12 07:18:44 2004
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Thu, 11 Nov 2004 15:18:44 -0500
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <4193A13A.3080006@mn.rr.com>
References: <41930DFA.8080105@mn.rr.com>
	<41931837.9080307@zip.com.au>	<419336BB.2040608@mn.rr.com>
	<419339E2.60108@zip.com.au> <4193A13A.3080006@mn.rr.com>
Message-ID: <4193C924.7020708@noaa.gov>

J Raynor wrote:
> As a final note, I'd like to point out that kerberos allows the user to 
> choose whether their session is encrypted or not.  So aside from the few 
> people who may have argued the point on the openssh mailing lists, there 
> are groups of people out there who want this choice.

SSL2 and SSL3 also support a null cipher.

Does anyone else see the irony of what's going on here?

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>



From deengert at anl.gov  Fri Nov 12 08:00:20 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 11 Nov 2004 15:00:20 -0600
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <4193C924.7020708@noaa.gov>
References: <41930DFA.8080105@mn.rr.com>	<41931837.9080307@zip.com.au>	<419336BB.2040608@mn.rr.com>	<419339E2.60108@zip.com.au>
	<4193A13A.3080006@mn.rr.com> <4193C924.7020708@noaa.gov>
Message-ID: <4193D2E4.30104@anl.gov>



Jefferson Ogata wrote:
> J Raynor wrote:
> 
>> As a final note, I'd like to point out that kerberos allows the user 
>> to choose whether their session is encrypted or not.  So aside from 
>> the few people who may have argued the point on the openssh mailing 
>> lists, there are groups of people out there who want this choice.
> 
> 
> SSL2 and SSL3 also support a null cipher.
> 
> Does anyone else see the irony of what's going on here?

Not really. The Kerberos case and ssl2 or ssl3 with NULL are more
historical then a current requirment. It comes from when sending
encrypted data could have been against the law in some places,
or the need to authenticate but not encrypt was common.

But today, not only do you have to authenticate, but you need to
protect the integrity of the session to help avoid hijacking
as well as protecting the data.

So why do you need ssh without encryption? Won't telnet or rsh
do just as well? Most Kerberos shops I know of are turning off
the Kerberized BSD applications and using ssh with gssapi instead.

So although I don't see the need for a null encryption, you claim
there are groups of people out there that want the choice. But Why?


> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444



From nickls at apple.com  Fri Nov 12 08:14:47 2004
From: nickls at apple.com (Nick Lane-Smith)
Date: Thu, 11 Nov 2004 13:14:47 -0800
Subject: openssh-3.7p1+ and PAM on OS X
Message-ID: <B773B984-3426-11D9-8F7C-000D93363490@apple.com>

Hello list,

Bug 688 is causing me a massive headache on OS X.

The fact that each PAM authentication takes place in a separate process 
means the PAM context data isn't shared and therefore prevents the 
passing of data between modules. (pam_set_data, and pam_get_data)

Compiling with pthreads isn't really an option because of the added 
security risk and the fact that some of the PAM modules are not thread 
safe and would be troublesome to make thread safe.

Storing the data in the environment really isn't an option, as it is 
sensitive.

Is there another solution that you could suggest?

How do you plan to fix 688?
does the fix have an ETA?

Cheers,
-Nick

Also, PAM support in 3.9p1 is completely broken on OS X. (I'm still 
investigating)

http://bugzilla.mindrot.org/show_bug.cgi?id=688



From Jefferson.Ogata at noaa.gov  Fri Nov 12 08:21:44 2004
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Thu, 11 Nov 2004 16:21:44 -0500
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <4193D2E4.30104@anl.gov>
References: <41930DFA.8080105@mn.rr.com>	<41931837.9080307@zip.com.au>	<419336BB.2040608@mn.rr.com>	<419339E2.60108@zip.com.au>	<4193A13A.3080006@mn.rr.com>
	<4193C924.7020708@noaa.gov> <4193D2E4.30104@anl.gov>
Message-ID: <4193D7E8.90105@noaa.gov>

Douglas E. Engert wrote:
> Jefferson Ogata wrote:
>> J Raynor wrote:
>>> As a final note, I'd like to point out that kerberos allows the user 
>>> to choose whether their session is encrypted or not.  So aside from 
>>> the few people who may have argued the point on the openssh mailing 
>>> lists, there are groups of people out there who want this choice.
>>
>> SSL2 and SSL3 also support a null cipher.
>>
>> Does anyone else see the irony of what's going on here?
> 
> Not really. The Kerberos case and ssl2 or ssl3 with NULL are more
> historical then a current requirment. It comes from when sending
> encrypted data could have been against the law in some places,
> or the need to authenticate but not encrypt was common.
> 
> But today, not only do you have to authenticate, but you need to
> protect the integrity of the session to help avoid hijacking
> as well as protecting the data.

The irony I was referring to has to do with the contrast between the 
vehement support for inclusion of a weak 40-bit cipher in one thread, 
contrasted with the strong disdain for a null cipher, even though a 
number of other products provide a null cipher while none that I know of 
includes the weak 40-bit cipher.

> So why do you need ssh without encryption? Won't telnet or rsh
> do just as well? Most Kerberos shops I know of are turning off
> the Kerberized BSD applications and using ssh with gssapi instead.
> 
> So although I don't see the need for a null encryption, you claim
> there are groups of people out there that want the choice. But Why?

I didn't say I do need it. But I do understand J Raynor's explanation. J 
wants to use ssh authentication without incurring crypto overhead on the 
session; this saves CPU when doing large transfers. This is handy for 
scp or rsync over ssh (I usually use blowfish for this since it seems to 
be the fastest cipher in the suite). J specifically stated that this 
could be used on channels that are already secure, e.g. IPsec or ssh 
tunnels.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>



From richard at drdispatch.com  Fri Nov 12 11:25:52 2004
From: richard at drdispatch.com (Richard Holland)
Date: Thu, 11 Nov 2004 18:25:52 -0600
Subject: RedHat forks OpenSSH?
Message-ID: <41940310.5000807@drdispatch.com>

I work for lawyers, have for 5 years now.  I consulted several on this 
issue, some educated enough on this area of law, others not.  A lot of 
what's said here is true on both accounts.  What Theo De Raadt says 
about "trade secret" law appears to be true, he's not blowing steam up 
your asses.  They all agree it's somewhat questionable as to wether or 
not what OpenSSH is doing with aacs is "illegal".

Discussing this issue over some scotch with one attorney, one I consider 
a good friend, after hearing the basic flow of this argument he posed 
this question:

"Why do the OpenSSH folks care?  If Red Hat took their code and is 
distributing in a state they don't like, refuse to support it.  Being 
that a simple civil law suit from one of these hardball prick 
organizations like the MPAA/RIAA hell bent on protecting their property 
or whatever the hell can destroy a publicly held company once the media 
gets wind of the lawsuit being filed". 

If Red Hat removed this code in question from a legal standpoint, it's 
probably just a safegaurd and perhaps not needed.  Red Hat wouldn't care 
to have the media saying bogus things like "Red Hat, provider of Linux, 
is using some super encryption code and distributing it illegally".  
Untrue as that is, it would affect stock price.  This is a possible 
motivation.

This is obviously not an issue OpenSSH should bother caring about.

Red Hat is distributing OpenSSH's project and work in a state they deem 
as being hard for OpenSSH to support.  Red Hat can either fix it, or 
have their tarball recognized as something OpenSSH neither condones nor 
will support.

OpenSSH seems firm in their stance, so that is that. 

Red Hat probably should properly contact the OpenSSH people and explain 
why this was done.  Perhaps they feel they have fixed something here.  
It is possible that this code hack has nothing at all to do with US 
law.  Anytime you change a person's code you should provide a reason 
why, it may be beneficial to the original code's maintainer.

Don't get confused, the first half of this mail is just me trying to 
explain a reason as to why this list debating the legality of aacs is 
probably moot.  I don't use Red Hat, never have.  I don't agree with how 
they've handled their source changes to OpenSSH.

Richard Holland
Holland Transportation









From deengert at anl.gov  Fri Nov 12 08:46:58 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 11 Nov 2004 15:46:58 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <200411110531.iAB5VDBa029778@cvs.openbsd.org>
References: <200411110531.iAB5VDBa029778@cvs.openbsd.org>
Message-ID: <4193DDD2.9000602@anl.gov>



Theo de Raadt wrote:

>>>Now some users are saying to the OpenSSH developers that maybe they
>>>should reconsider.  Will you not at least listen, as you ask Red Hat to
>>>do?
>>
>>Who said we haven't listened? I just haven't heard any convincing
>>arguments why we should spend extra time supporting a vendor who
>>makes our jobs harder and won't even do us the courtesy of responding
>>to our comments.
> 
> 
> Damien is right.
> 
> Noone at Red Hat has responded.  Very few users have responded too.

You ask why users are not responding? From the tone of the messages on
this thread it should be obvious that they afraid. I thought about if I
should respond to this since last night.  But some have spoke up so I
will too.

But the real users of OpenSSH are not the people on these list. There are
the many users using all versions of operating systems that have OpenSSH
(and other compatibles clients and servers.) Many of these users
may never have read a line of "C" code in their life.

Many of these users use vendor provided versions of OpenSSH, provided and
compiled by the OS vendors.

We have been using OpenSSH since version 2.0 and got serious about it
when it started to support Kerberos, even if it mean adding mods
and distributing internally.

Now that OpenSSH-3.9 support the gssapi and vendors like RedHat, HP
and (I believe) Sun in Solaris 10 are shipping OpenSSH with the gssapi
compiled in, we will be looking at not having to compile and distribute
our own version. I know that we may not be as up to date as we have
been, but many more of our users will benefit.

> 
> Our opinions as to how to deal with this are starting to calcify.
> 

Sorry you feel this way. In my option your end user customers have
increased my orders of magnitudes over the last few years but this is
because the vendors have been packaging and distributing the binaries.

Your real users are the vendors today.


> Perhaps that is for the better.

No it not. You have a great product, and letting this ACSS issue
with RedHat get you upset is not good. You have the master mailing
lists, I am sure there are people from RedHat on the lists, have
you tried contacting them? Maybe you can work something out.


> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444



From mstevens at cmu.edu  Fri Nov 12 09:18:54 2004
From: mstevens at cmu.edu (Michael A Stevens)
Date: Thu, 11 Nov 2004 17:18:54 -0500 (EST)
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <4193D7E8.90105@noaa.gov>
References: <41930DFA.8080105@mn.rr.com> <41931837.9080307@zip.com.au>
	<419336BB.2040608@mn.rr.com> <419339E2.60108@zip.com.au>
	<4193A13A.3080006@mn.rr.com>
	<4193C924.7020708@noaa.gov> <4193D2E4.30104@anl.gov>
	<4193D7E8.90105@noaa.gov>
Message-ID: <Pine.GSO.4.60-041.0411111716330.4716@unix2.andrew.cmu.edu>

> I didn't say I do need it. But I do understand J Raynor's explanation. J 
> wants to use ssh authentication without incurring crypto overhead on the 
> session; this saves CPU when doing large transfers. This is handy for scp or 
> rsync over ssh (I usually use blowfish for this since it seems to be the 
> fastest cipher in the suite). J specifically stated that this could be used 
> on channels that are already secure, e.g. IPsec or ssh tunnels.

The factest cipher from our tests has been arcfour, by a wide margin.



From genty at austin.ibm.com  Wed Nov 10 01:48:19 2004
From: genty at austin.ibm.com (Denise Genty)
Date: Tue, 09 Nov 2004 08:48:19 -0600
Subject: RedHat forks OpenSSH?
In-Reply-To: <20041109123353.GU12780@ns.snowman.net>
References: <20041109044556.GA928156@hiwaay.net>	<200411090738.iA97c6wh011568@cvs.openbsd.org>
	<20041109123353.GU12780@ns.snowman.net>
Message-ID: <4190D8B3.7060909@austin.ibm.com>

I've read this entire thread and here at IBM, it is making me very 
nervous.  And yes,
I'm a wimp.
 
Stephen Frost wrote:

>* Theo de Raadt (deraadt at cvs.openbsd.org) wrote:
>  
>
>>Why does noone want to answer this question?
>>    
>>
>
>It's generally not useful to feed a troll.
>
>	Stephen
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev at mindrot.org
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>  
>


-- 
Denise M. Genty        
genty at austin.ibm.com    (512)838-8170 - T/L 678-8170
AIX Network Security Development        
Systems and Technology Division, pSeries




From Jefferson.Ogata at noaa.gov  Fri Nov 12 09:48:15 2004
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Thu, 11 Nov 2004 17:48:15 -0500
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <Pine.GSO.4.60-041.0411111716330.4716@unix2.andrew.cmu.edu>
References: <41930DFA.8080105@mn.rr.com> <41931837.9080307@zip.com.au>
	<419336BB.2040608@mn.rr.com> <419339E2.60108@zip.com.au>
	<4193A13A.3080006@mn.rr.com> <4193C924.7020708@noaa.gov>
	<4193D2E4.30104@anl.gov> <4193D7E8.90105@noaa.gov>
	<Pine.GSO.4.60-041.0411111716330.4716@unix2.andrew.cmu.edu>
Message-ID: <4193EC2F.9070901@noaa.gov>

Michael A Stevens wrote:
>> I didn't say I do need it. But I do understand J Raynor's explanation. 
>> J wants to use ssh authentication without incurring crypto overhead on 
>> the session; this saves CPU when doing large transfers. This is handy 
>> for scp or rsync over ssh (I usually use blowfish for this since it 
>> seems to be the fastest cipher in the suite). J specifically stated 
>> that this could be used on channels that are already secure, e.g. 
>> IPsec or ssh tunnels.
> 
> The factest cipher from our tests has been arcfour, by a wide margin.

Thanks for the info.

For this to be true in practice, however, certain modifications have to 
be made to openssh's windowing size. Are these changes now part of the 
openssh distribution, and enabled by default? Also, have they been 
backported to other vendors' distributions, e.g. Sun, Red Hat?

Without these changes, arcfour, blowfish, and aes128 perform 
equivalently in terms of bandwidth. With the changes, blowfish is the 
second fastest after arcfour. Note that some people avoid using arcfour 
for legal reasons; blowfish is a completely unencumbered and 
unthreatened alternative that performs quite well.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>



From dtucker at zip.com.au  Fri Nov 12 11:33:26 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 12 Nov 2004 11:33:26 +1100
Subject: openssh-3.7p1+ and PAM on OS X
In-Reply-To: <B773B984-3426-11D9-8F7C-000D93363490@apple.com>
References: <B773B984-3426-11D9-8F7C-000D93363490@apple.com>
Message-ID: <419404D6.30508@zip.com.au>

Nick Lane-Smith wrote:
> Bug 688 is causing me a massive headache on OS X.
> 
> The fact that each PAM authentication takes place in a separate process 
> means the PAM context data isn't shared and therefore prevents the 
> passing of data between modules. (pam_set_data, and pam_get_data)
> 
> Compiling with pthreads isn't really an option because of the added 
> security risk and the fact that some of the PAM modules are not thread 
> safe and would be troublesome to make thread safe.
> 
> Storing the data in the environment really isn't an option, as it is 
> sensitive.

I thought the PAM environment (pam_putenv, pam_setenv) is a separate 
namespace to the regular environment space and not visible to other 
users.  (Or are you worried about the PAM application or other PAM 
modules getting their hands on this data?)

> Is there another solution that you could suggest?

Is the PAM password authentication (via a "blind" conversation function) 
in 3.9p1 usable for you?  It doesn't fork, and it would be relatively 
easy to backport if necessary.  It's no good for real challenge-response 
though.

> How do you plan to fix 688?

Possibly, if there's some cure that isn't worse than the disease.  So 
far, one hasn't been obvious :-)

> does the fix have an ETA?

Not right now.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From sfrost at snowman.net  Sat Nov 13 01:26:38 2004
From: sfrost at snowman.net (Stephen Frost)
Date: Fri, 12 Nov 2004 09:26:38 -0500
Subject: RedHat forks OpenSSH?
In-Reply-To: <20041111195415.GB21858@astro.su.se>
References: <4192BE25.80809@sten.org>
	<200411110352.iAB3qNwd006389@cvs.openbsd.org>
	<20041111043821.GC1255458@hiwaay.net>
	<4192F88E.8090803@mindrot.org>
	<20041111141616.GB1508368@hiwaay.net>
	<20041111195415.GB21858@astro.su.se>
Message-ID: <20041112142638.GA10437@ns.snowman.net>

* Sergio Gelato (Sergio.Gelato at astro.su.se) wrote:
> * Chris Adams [2004-11-11 08:16:17 -0600]:
> > Someone said that Debian is considering or will likely make the same
> > change (again because of the DMCA).
> 
> As far as I can tell (after searching the archives for "openssh acss")
> the matter hasn't been brought up on debian-legal yet. One has to wonder
> what informed that Someone's opinion.

The fact that I've seen similar things on debian-legal previously.  As a
Debian developer, it's one of the lists I tend to read.  Debian also
tends to assume upstream isn't distributing things which are very
questionable.  What that means is that, you're right, it hasn't been
brought up on debian-legal, probably because it hadn't been noticed.
With RedHat making the change the question will probably come up on
debian-legal before long and if there's much doubt about it it'll
probably get removed- in the same manner as it was removed from RedHat,
which is the only way to remove the threat.

	Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041112/d1163fd8/attachment.bin 

From picasso at madflower.com  Sat Nov 13 01:56:14 2004
From: picasso at madflower.com (Sean O'Malley)
Date: Fri, 12 Nov 2004 09:56:14 -0500 (EST)
Subject: RedHat forks OpenSSH?
In-Reply-To: <41940310.5000807@drdispatch.com>
Message-ID: <Pine.GSO.4.33.0411120931100.7913-100000@eclipse.cl.msu.edu>

Redhat if they get hit with a major lawsuit, say a 100M dollar settlement.
They go out of business. period. They made 13M last year, -17M in 2002,
and -138M in 2001. They have 700M in long term liabilities (debts).

They also dropped MP3 codec support from their distribution. Sure you can
GET the rpm to add the support, but they don't include it for legal
reasons. Lawsuits can cost millions of dollars even if you win, and RHAT
does not have the cash to sustain any major lawsuits.

The LAST time RH did something like forking, it was over the configuration
files for KDE. RH asked for certain changes between Gnome and KDE to make
user experience more cohesive between the two.  They asked KDE, who didn't
budge and they asked Gnome who didn't budge. And RH made the decision to
just change how all the KDE applications config file worked. The KDE
people were extremely upset. yada yada.

The point is they made the move to help the long term goal of getting
Linux on the desktop. And if you have applications behaving two different
ways it gets really confusing. Good in the long term, crappy to have
developers you are full of shit, and their way is the one true way.



On Thu, 11 Nov 2004, Richard Holland wrote:

> I work for lawyers, have for 5 years now.  I consulted several on this
> issue, some educated enough on this area of law, others not.  A lot of
> what's said here is true on both accounts.  What Theo De Raadt says
> about "trade secret" law appears to be true, he's not blowing steam up
> your asses.  They all agree it's somewhat questionable as to wether or
> not what OpenSSH is doing with aacs is "illegal".
>
> Discussing this issue over some scotch with one attorney, one I consider
> a good friend, after hearing the basic flow of this argument he posed
> this question:
>
> "Why do the OpenSSH folks care?  If Red Hat took their code and is
> distributing in a state they don't like, refuse to support it.  Being
> that a simple civil law suit from one of these hardball prick
> organizations like the MPAA/RIAA hell bent on protecting their property
> or whatever the hell can destroy a publicly held company once the media
> gets wind of the lawsuit being filed".
>
> If Red Hat removed this code in question from a legal standpoint, it's
> probably just a safegaurd and perhaps not needed.  Red Hat wouldn't care
> to have the media saying bogus things like "Red Hat, provider of Linux,
> is using some super encryption code and distributing it illegally".
> Untrue as that is, it would affect stock price.  This is a possible
> motivation.
>
> This is obviously not an issue OpenSSH should bother caring about.
>
> Red Hat is distributing OpenSSH's project and work in a state they deem
> as being hard for OpenSSH to support.  Red Hat can either fix it, or
> have their tarball recognized as something OpenSSH neither condones nor
> will support.
>
> OpenSSH seems firm in their stance, so that is that.
>
> Red Hat probably should properly contact the OpenSSH people and explain
> why this was done.  Perhaps they feel they have fixed something here.
> It is possible that this code hack has nothing at all to do with US
> law.  Anytime you change a person's code you should provide a reason
> why, it may be beneficial to the original code's maintainer.
>
> Don't get confused, the first half of this mail is just me trying to
> explain a reason as to why this list debating the legality of aacs is
> probably moot.  I don't use Red Hat, never have.  I don't agree with how
> they've handled their source changes to OpenSSH.
>
> Richard Holland
> Holland Transportation
>
>
>
>
>
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>




From mstevens at cmu.edu  Sat Nov 13 03:07:25 2004
From: mstevens at cmu.edu (Michael A Stevens)
Date: Fri, 12 Nov 2004 11:07:25 -0500 (EST)
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <4193EC2F.9070901@noaa.gov>
References: <41930DFA.8080105@mn.rr.com> <41931837.9080307@zip.com.au>
	<419336BB.2040608@mn.rr.com> <419339E2.60108@zip.com.au>
	<4193A13A.3080006@mn.rr.com>
	<4193C924.7020708@noaa.gov> <4193D2E4.30104@anl.gov>
	<4193D7E8.90105@noaa.gov>
	<Pine.GSO.4.60-041.0411111716330.4716@unix2.andrew.cmu.edu>
	<4193EC2F.9070901@noaa.gov>
Message-ID: <Pine.GSO.4.60-041.0411121105030.2475@unix2.andrew.cmu.edu>

>
> Thanks for the info.
>
> For this to be true in practice, however, certain modifications have to be 
> made to openssh's windowing size. Are these changes now part of the openssh 
> distribution, and enabled by default? Also, have they been backported to 
> other vendors' distributions, e.g. Sun, Red Hat?

The OpenSSH people don't seem to care about the patch. The PSC maintains 
the patch for current versions of openssh though.


Mike



From rurban at x-ray.at  Sun Nov 14 00:04:41 2004
From: rurban at x-ray.at (Reini Urban)
Date: Sat, 13 Nov 2004 14:04:41 +0100
Subject: contrib/ssh-copy-id patch (get rid of identity.pub)
Message-ID: <41960669.2090206@x-ray.at>

Please consider this simple ssh-copy-id patch,
and adding contrib/ssh-copy-id as install target for cygwin. (man and 
shellscript)

20041113
  - [contrib\ssh-copy-id]: change default to newest .ssh/id*.pub
	From: Reini Urban rurban at x-ray.at

--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ssh-copy-id_latest.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041113/c8390d98/attachment.ksh 

From ed at membled.com  Sun Nov 14 00:21:45 2004
From: ed at membled.com (Ed Avis)
Date: Sat, 13 Nov 2004 13:21:45 +0000 (GMT)
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <20041112092344.E080E27C488@shitei.mindrot.org>
Message-ID: <Pine.LNX.4.20L2.0411131314020.31756-100000@budvar.future-i.net>

Douglas E. Engert wrote:
                                                                                                                                               
>So why do you need ssh without encryption? Won't telnet or rsh do
>just as well?

This is just a personal preference but I'd rather not use telnet or
rsh for anything.  They are crusty.  Much better to use ssh all the
time - only one daemon to run instead of two, only one command to run.  
Anything that helps get rid of telnet and rsh is a good thing!

Those are my subjective feelings. A more rational explanation is to
say that the ssh and sshd code is of good quality and well audited for
security holes.  You can't be so confident about rshd or telnetd.  If
you want a remote connection without encryption, ssh is certainly a
more secure way to do the job than any of the old stuff.

Users who ask for ssh with 'none' encryption are paying the openssh
developers a compliment by showing that ssh is worth using for its
code quality and ease-of-use alone, even without the added security of
strong encryption.

-- 
Ed Avis <ed at membled.com>





From mstevens at cmu.edu  Sun Nov 14 10:59:07 2004
From: mstevens at cmu.edu (Michael A Stevens)
Date: Sat, 13 Nov 2004 18:59:07 -0500 (EST)
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <Pine.LNX.4.20L2.0411131314020.31756-100000@budvar.future-i.net>
References: <Pine.LNX.4.20L2.0411131314020.31756-100000@budvar.future-i.net>
Message-ID: <Pine.GSO.4.60-041.0411131852090.4203@unix2.andrew.cmu.edu>



On Sat, 13 Nov 2004, Ed Avis wrote:

> Douglas E. Engert wrote:
>
>> So why do you need ssh without encryption? Won't telnet or rsh do
>> just as well?
>
> This is just a personal preference but I'd rather not use telnet or
> rsh for anything.  They are crusty.  Much better to use ssh all the
> time - only one daemon to run instead of two, only one command to run.
> Anything that helps get rid of telnet and rsh is a good thing!
>
> Those are my subjective feelings. A more rational explanation is to
> say that the ssh and sshd code is of good quality and well audited for
> security holes.  You can't be so confident about rshd or telnetd.  If
> you want a remote connection without encryption, ssh is certainly a
> more secure way to do the job than any of the old stuff.
>
> Users who ask for ssh with 'none' encryption are paying the openssh
> developers a compliment by showing that ssh is worth using for its
> code quality and ease-of-use alone, even without the added security of
> strong encryption.

I think the idea here is that it should be reasonably hard for people to 
shoot themselves in the foot by turning off encryption. If you put none 
into the supported ciphers list, then you risk it getting picked if no 
other ciphers match. A dual stage setup where a user needs to enable 
sending none, and then prompts them if that is the only one available 
would be the most appropriate. The problem with is that none almost 
defeats the purpose of ssh and it should be really hard to do this by 
accident.

If you absolutely must use none and want authentication security, then 
re-kex'ing with a changed cipher list would let you switch to none after 
authenticating. Alternatively you could use RSA keys and not use passwords 
at all. If you leave the MAC algorithm in place you should be protected 
against injection attacks, but all your session info will be in the clear, 
so if you login via password to another system, your password will be 
going in the clear over the local line.


Mike



From bob at proulx.com  Sun Nov 14 13:02:24 2004
From: bob at proulx.com (Bob Proulx)
Date: Sat, 13 Nov 2004 19:02:24 -0700
Subject: avoiding 'authenticity' prompt
In-Reply-To: <20041110101220.GI68046@justpickone.org>
References: <20041110041019.GM35474@justpickone.org>
	<4191992C.9000102@mindrot.org>
	<20041110043527.GE68046@justpickone.org>
	<41919E96.3010106@zip.com.au>
	<20041110101220.GI68046@justpickone.org>
Message-ID: <20041114020224.GB18846@dementia.proulx.com>

David T-G wrote:
> % >Might I ask for a hint or two to set me on my way?

Having been through this myself let me suggest the following.

  ssh -oBatchmode=yes -oStrictHostKeyChecking=no -oCheckHostIP=no -oUserKnownHostsFile=/dev/null

Basically for this cron task I never keep the keys around.  They might
change.  So they are useless and I store them in /dev/null.

Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041113/147b0bdd/attachment.bin 

From davidtg-openssh at justpickone.org  Sun Nov 14 13:35:12 2004
From: davidtg-openssh at justpickone.org (David T-G)
Date: Sat, 13 Nov 2004 21:35:12 -0500
Subject: avoiding 'authenticity' prompt
In-Reply-To: <20041114020224.GB18846@dementia.proulx.com>
References: <20041110041019.GM35474@justpickone.org>
	<4191992C.9000102@mindrot.org>
	<20041110043527.GE68046@justpickone.org>
	<41919E96.3010106@zip.com.au>
	<20041110101220.GI68046@justpickone.org>
	<20041114020224.GB18846@dementia.proulx.com>
Message-ID: <20041114023512.GP35474@justpickone.org>

Bob, et al --

Hi, Bob!  Small world :-)

...and then Bob Proulx said...
% 
% David T-G wrote:
% > % >Might I ask for a hint or two to set me on my way?
% 
% Having been through this myself let me suggest the following.
% 
%   ssh -oBatchmode=yes -oStrictHostKeyChecking=no -oCheckHostIP=no -oUserKnownHostsFile=/dev/null

Thanks!  It's the StrictHostKeyChecking that really helped, and I've just
symlinked known_hosts to dev null directly :-)  I'll have a look at the
other options as well.


% 
% Basically for this cron task I never keep the keys around.  They might
% change.  So they are useless and I store them in /dev/null.

Yep.


% 
% Bob


Thanks!

:-D
-- 
David T-G
davidtg at justpickone.org
http://justpickone.org/davidtg/      Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041113/9dbf02e5/attachment.bin 

From dan at doxpara.com  Sun Nov 14 18:24:04 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Sat, 13 Nov 2004 23:24:04 -0800
Subject: avoiding 'authenticity' prompt
In-Reply-To: <20041114020224.GB18846@dementia.proulx.com>
References: <20041110041019.GM35474@justpickone.org>	<4191992C.9000102@mindrot.org>	<20041110043527.GE68046@justpickone.org>	<41919E96.3010106@zip.com.au>	<20041110101220.GI68046@justpickone.org>
	<20041114020224.GB18846@dementia.proulx.com>
Message-ID: <41970814.8090304@doxpara.com>

Bob Proulx wrote:

>David T-G wrote:
>  
>
>>% >Might I ask for a hint or two to set me on my way?
>>    
>>
>
>Having been through this myself let me suggest the following.
>
>  ssh -oBatchmode=yes -oStrictHostKeyChecking=no -oCheckHostIP=no -oUserKnownHostsFile=/dev/null
>
>Basically for this cron task I never keep the keys around.  They might
>change.  So they are useless and I store them in /dev/null.
>  
>
And of course, all these options can be thrown in /etc/ssh_config .

What's the present status of putting SSH host keys in DNS, btw?  Anyone 
know?

--Dan



From jhilliard_bv at corpbanca.com.ve  Sun Nov 14 18:58:14 2004
From: jhilliard_bv at corpbanca.com.ve (Janna Hilliard)
Date: Sun, 14 Nov 2004 12:58:14 +0500
Subject: We sell regalis for an affordable price
Message-ID: <17ae01c4ca1f$33a68fe7$537f8d7b@muranet.com.br>

Hi,

Regalis, also known as Superviagra or Cialis
- half a pill Lasts all weekend
- Has less sideeffects
- Has higher success rate

Now you can buy Regalis, for over 70% cheaper than the equivilent brand for sale in US

We ship world wide, and no prescription is required!!

Even if you're not impotent, Regalis will increase size, pleasure and power!

Try it today you wont regret!

Get it here: http://web4deals.com/sup/

Best regards,
Jeremy Stones


No thanks: http://web4deals.com/rr.php



From djm at mindrot.org  Sun Nov 14 21:03:03 2004
From: djm at mindrot.org (Damien Miller)
Date: Sun, 14 Nov 2004 21:03:03 +1100
Subject: avoiding 'authenticity' prompt
In-Reply-To: <41970814.8090304@doxpara.com>
References: <20041110041019.GM35474@justpickone.org>	<4191992C.9000102@mindrot.org>	<20041110043527.GE68046@justpickone.org>	<41919E96.3010106@zip.com.au>	<20041110101220.GI68046@justpickone.org>	<20041114020224.GB18846@dementia.proulx.com>
	<41970814.8090304@doxpara.com>
Message-ID: <41972D57.8090403@mindrot.org>

Dan Kaminsky wrote:
> And of course, all these options can be thrown in /etc/ssh_config .
> 
> What's the present status of putting SSH host keys in DNS, btw?  Anyone 
> know?

Dan, you should know how to read manpages and use google better
than most :)

The RR type is assigned and support has been in OpenSSH since
3.7p1 (IIRC). Bind 9 has had support for the RR type for quite a
while too. For full support you really need DNSSEC, though results
will be displayed without it.

ssh-keygen can convert from host pubkeys into SSHFP records using the
-r option. "dig baragon.mindrot.org any" for an example. Checking is
enabled using the "VerifyHostKeyDNS" ssh option. See README.DNS for
details.

It works well in practice using my DNSSEC test domain.

-d



From juliecs at rogers.com  Sun Nov 14 14:30:11 2004
From: juliecs at rogers.com (Julie)
Date: Sat, 13 Nov 2004 22:30:11 -0500
Subject: (no subject)
Message-ID: <20041114131200.02E4227C18A@shitei.mindrot.org>

Do you want a cheap Watch?
http://vkx.afeet.com



From davidtg-openssh at justpickone.org  Mon Nov 15 00:29:26 2004
From: davidtg-openssh at justpickone.org (David T-G)
Date: Sun, 14 Nov 2004 08:29:26 -0500
Subject: avoiding 'authenticity' prompt
In-Reply-To: <41970814.8090304@doxpara.com>
References: <20041110041019.GM35474@justpickone.org>
	<4191992C.9000102@mindrot.org>
	<20041110043527.GE68046@justpickone.org>
	<41919E96.3010106@zip.com.au>
	<20041110101220.GI68046@justpickone.org>
	<20041114020224.GB18846@dementia.proulx.com>
	<41970814.8090304@doxpara.com>
Message-ID: <20041114132926.GQ35474@justpickone.org>

Dan, et al --

...and then Dan Kaminsky said...
% 
% Bob Proulx wrote:
% 
...
% > ssh -oBatchmode=yes -oStrictHostKeyChecking=no -oCheckHostIP=no 
% > -oUserKnownHostsFile=/dev/null
...
% And of course, all these options can be thrown in /etc/ssh_config .

True -- but that doesn't work in my environment because 1) I don't
necessarily want to set such slack behavior for everyone and 2) I also
don't want to have to go and bake that functionality into every box.


Thanks & HAND

:-D
-- 
David T-G
davidtg at justpickone.org
http://justpickone.org/davidtg/      Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041114/a44f57aa/attachment.bin 

From markus at openbsd.org  Mon Nov 15 03:01:15 2004
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 14 Nov 2004 17:01:15 +0100
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <Pine.GSO.4.60-041.0411121105030.2475@unix2.andrew.cmu.edu>
References: <41931837.9080307@zip.com.au> <419336BB.2040608@mn.rr.com>
	<419339E2.60108@zip.com.au> <4193A13A.3080006@mn.rr.com>
	<4193C924.7020708@noaa.gov> <4193D2E4.30104@anl.gov>
	<4193D7E8.90105@noaa.gov>
	<Pine.GSO.4.60-041.0411111716330.4716@unix2.andrew.cmu.edu>
	<4193EC2F.9070901@noaa.gov>
	<Pine.GSO.4.60-041.0411121105030.2475@unix2.andrew.cmu.edu>
Message-ID: <20041114160115.GA13273@folly>

On Fri, Nov 12, 2004 at 11:07:25AM -0500, Michael A Stevens wrote:
> >
> >Thanks for the info.
> >
> >For this to be true in practice, however, certain modifications have to be 
> >made to openssh's windowing size. Are these changes now part of the 
> >openssh distribution, and enabled by default? Also, have they been 
> >backported to other vendors' distributions, e.g. Sun, Red Hat?
> 
> The OpenSSH people don't seem to care about the patch. The PSC maintains 
> the patch for current versions of openssh though.

well i do care, but it's incomplete and has problems.



From markus at openbsd.org  Mon Nov 15 03:02:41 2004
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 14 Nov 2004 17:02:41 +0100
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <Pine.LNX.4.20L2.0411131314020.31756-100000@budvar.future-i.net>
References: <20041112092344.E080E27C488@shitei.mindrot.org>
	<Pine.LNX.4.20L2.0411131314020.31756-100000@budvar.future-i.net>
Message-ID: <20041114160241.GB13273@folly>

On Sat, Nov 13, 2004 at 01:21:45PM +0000, Ed Avis wrote:
> Users who ask for ssh with 'none' encryption are paying the openssh
> developers a compliment by showing that ssh is worth using for its
> code quality and ease-of-use alone, even without the added security of
> strong encryption.

why don't you use arcfour as a cipher if you don't
need strong encryption?  i doubt that 'none' is faster.



From mgoyette at bestweb.net  Mon Nov 15 12:27:46 2004
From: mgoyette at bestweb.net (info)
Date: Sun, 14 Nov 2004 20:27:46 -0500
Subject: Press release openssh-unix-dev@mindrot.org
Message-ID: <20041115012150.4E8B427C187@shitei.mindrot.org>

openssh-unix-dev at mindrot.org


Canadian Subsidy Directory
4865 Hwy. 138
St-Andrews west
Ontario
K0C 2A0

CANADIAN SUBSIDY DIRECTORY YEAR 2004 EDITION

PRESS RELEASE


Legal Deposit-National Library of Canada
ISBN 2-922870-05-7

The revised edition of the Canadian Subsidy Directory is available. 
The most complete and affordable reference for anyone looking for
financial support.
It is deemed to be the perfect tool for new or existing businesses,
individual ventures, foundations and associations.

This Publication contains  more than 2600 direct and indirect financial
subsidies, grants and loans offered by government departments and
agencies, foundations, associations and organizations.  In this 2004
edition all programs are well described.

The Canadian Subsidy Directory is sold $ 69.95, to obtain a copy please
call:
Canadian Publications toll free at: 1 - 8 6 6 - 3 2 2 - 3 3 7 6



From dtucker at zip.com.au  Mon Nov 15 13:12:10 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 15 Nov 2004 13:12:10 +1100
Subject: openssh-3.7p1+ and PAM on OS X
In-Reply-To: <B773B984-3426-11D9-8F7C-000D93363490@apple.com>
References: <B773B984-3426-11D9-8F7C-000D93363490@apple.com>
Message-ID: <4198107A.602@zip.com.au>

Nick Lane-Smith wrote:
> Bug 688 is causing me a massive headache on OS X.
[..]
> How do you plan to fix 688?

Sorry, I missed the "How" in my first reply.

So far there appears to be two potential solutions, neither of which are 
particularly palatable:

1) Invert the parent-child relationship in the existing code: ie have 
the parent make the PAM calls and the child talk to the user/privsep 
slave.  (Ironically, this may be easier to implement with privsep than 
without it since key and compression state is less of an issue).

See http://marc.theaimsgroup.com/?l=secure-shell&m=108231421231223

2) Implement the PAM conversation as a coroutine.  Clever, but 
potentially unportable, a maintenance hassle and a debugging nightmare.

See http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From jhutz at cmu.edu  Mon Nov 15 13:13:59 2004
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Sun, 14 Nov 2004 21:13:59 -0500
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <1478260000.1075517862@minbar.fac.cs.cmu.edu>
References: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1134@es10snlnt.sandia.gov>
	<1478260000.1075517862@minbar.fac.cs.cmu.edu>
Message-ID: <3721540000.1100484839@minbar.fac.cs.cmu.edu>



On Friday, January 30, 2004 21:57:42 -0500 Jeffrey Hutzelman 
<jhutz at cmu.edu> wrote:

> The spec says clients SHOULD set mutual_req to "false", which means not
> requesting mutual authentication.  I know of no mechanisms which will do
> mutual auth (and produce a context with mutual_flag set) if the client
> sets mutual_req to "false".
>
> What this means is that a compliant client is _likely_ not to work with
> the openssh server as it stands.  It is possible to be compatible with
> openssh and still be compliant (SHOULD means approximately "do this
> unless you have a good reason not to"); however, not all compliant
> clients will be compatible with openssh.  Note that the openssh client is
> an example of a client that interoperates with the openssh server (AFAIK)
> and is compliant (at least, with respect to this issue).
>
> The spec does not specifically prohibit openssh's current behaviour, but
> it is likely to cause interop problems.  IMHO, the fact that this is not
> specified more clearly is an oversight -- the spec does not provide
> enough information to write interoperable clients and servers.  Thank you
> both for finding this; I'll be addressing the issue in the next version.

draft-ietf-secsh-gsskeyex-08.txt did not contain any changes related to 
fixing this issue.  However, I am proposing adding the follosing text
to the next version of the draft...

In key exchange:

The server MUST NOT fail the key exchange on the basis of the values of
any of conf_avail, replay_det_state, sequence_state, or anon_state.


In user authentication:

The server MUST NOT fail user authentication on the basis of the values
any of conf_avail, replay_det_state, sequence_state, or mutual_state.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA



From mstevens at cmu.edu  Mon Nov 15 14:34:46 2004
From: mstevens at cmu.edu (Michael A Stevens)
Date: Sun, 14 Nov 2004 22:34:46 -0500 (EST)
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <20041114160115.GA13273@folly>
References: <41931837.9080307@zip.com.au> <419336BB.2040608@mn.rr.com>
	<419339E2.60108@zip.com.au> <4193A13A.3080006@mn.rr.com>
	<4193C924.7020708@noaa.gov>
	<4193D2E4.30104@anl.gov> <4193D7E8.90105@noaa.gov>
	<Pine.GSO.4.60-041.0411111716330.4716@unix2.andrew.cmu.edu>
	<4193EC2F.9070901@noaa.gov>
	<Pine.GSO.4.60-041.0411121105030.2475@unix2.andrew.cmu.edu>
	<20041114160115.GA13273@folly>
Message-ID: <Pine.GSO.4.60-041.0411142231260.6233@unix2.andrew.cmu.edu>



On Sun, 14 Nov 2004, Markus Friedl wrote:

> On Fri, Nov 12, 2004 at 11:07:25AM -0500, Michael A Stevens wrote:
>>>
>>> Thanks for the info.
>>>
>>> For this to be true in practice, however, certain modifications have to be
>>> made to openssh's windowing size. Are these changes now part of the
>>> openssh distribution, and enabled by default? Also, have they been
>>> backported to other vendors' distributions, e.g. Sun, Red Hat?
>>
>> The OpenSSH people don't seem to care about the patch. The PSC maintains
>> the patch for current versions of openssh though.
>
> well i do care, but it's incomplete and has problems.
>

The newest version does the scaling automatically without any command line 
options. It also checks for interoperability with the older versions of 
OpenSSH because of the problem with the input buffer not limiting the data 
that it reads in on the window and trying to grow the buffer too large. If 
you have any suggestions as to what would need to be changed we would be 
open to any ideas.


Mike



From mstevens at cmu.edu  Mon Nov 15 14:49:30 2004
From: mstevens at cmu.edu (Michael A Stevens)
Date: Sun, 14 Nov 2004 22:49:30 -0500 (EST)
Subject: patch adding none cipher/mac for ssh v2
In-Reply-To: <20041114160241.GB13273@folly>
References: <20041112092344.E080E27C488@shitei.mindrot.org>
	<Pine.LNX.4.20L2.0411131314020.31756-100000@budvar.future-i.net>
	<20041114160241.GB13273@folly>
Message-ID: <Pine.GSO.4.60-041.0411142245190.6233@unix2.andrew.cmu.edu>



On Sun, 14 Nov 2004, Markus Friedl wrote:

> On Sat, Nov 13, 2004 at 01:21:45PM +0000, Ed Avis wrote:
>> Users who ask for ssh with 'none' encryption are paying the openssh
>> developers a compliment by showing that ssh is worth using for its
>> code quality and ease-of-use alone, even without the added security of
>> strong encryption.
>
> why don't you use arcfour as a cipher if you don't
> need strong encryption?  i doubt that 'none' is faster.

None with a MAC algorithm is actually significantly faster than ARCFOUR.


Mike



From Richard.Dickens at reuters.com  Tue Nov 16 04:25:08 2004
From: Richard.Dickens at reuters.com (Richard Dickens)
Date: Mon, 15 Nov 2004 17:25:08 +0000
Subject: [Spam] Any plans implement MaxAuthTriesLog?
Message-ID: <T6d49ad24bac407b711d14@dtcseuvig5.dtc.lon.ime.reuters.com>

I'll rephrase my question...

When a user gets their password wrong more than MaxAuthTries times why
isn't the message "Too many authentication failures for %.100s" written
to syslog? The user seems to get it (in a dialog in putty) but it
doesn't get logged. The usual "Failed password for..." messages are
logged.

Regards,
Richard Dickens

-----Original Message-----
From: openssh-unix-dev-bounces+richard.dickens=reuters.com at mindrot.org
[mailto:openssh-unix-dev-bounces+richard.dickens=reuters.com at mindrot.org
] On Behalf Of Richard Dickens
Sent: 11 November 2004 16:04
To: openssh-unix-dev at mindrot.org
Subject: [Spam] Any plans implement MaxAuthTriesLog?


Hello there,

I've just upgraded to 3.9p1 and I notice that I'm not getting any "Too
many authorization failure" messages written to my syslog. 

This seems to be controlled by MaxAuthTriesLog in Sun's implementation
of SSH. Are there any plans to do the same in OpenSSH?

Regards,
Richard Dickens


-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be the
views of Reuters Ltd.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev


--------------------------------------------------------------- -
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.



From dtucker at zip.com.au  Tue Nov 16 13:59:58 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 16 Nov 2004 13:59:58 +1100
Subject: Any plans implement MaxAuthTriesLog?
In-Reply-To: <T6d49ad24bac407b711d14@dtcseuvig5.dtc.lon.ime.reuters.com>
References: <T6d49ad24bac407b711d14@dtcseuvig5.dtc.lon.ime.reuters.com>
Message-ID: <41996D2E.90806@zip.com.au>

Richard Dickens wrote:
> When a user gets their password wrong more than MaxAuthTries times why
> isn't the message "Too many authentication failures for %.100s" written
> to syslog? The user seems to get it (in a dialog in putty) but it
> doesn't get logged. The usual "Failed password for..." messages are
> logged.

AFAIK vanilla OpenSSH has never logged those (it only sends it to the 
user via packet_disconnect).  Maybe it should log too?  And if so, maybe 
it should log some more info?  Anyway, try this patch.

OpenSSH does the equivalent of MaxAuthTriesLog at MaxAuthTries/2.  I 
suspect the behaviour you're describing is not directly related to 
MaxAuthTriesLog.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-maxauth-log.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041116/d2588b24/attachment.ksh 

From bparent at calvin.ucsd.edu  Tue Nov 16 17:57:28 2004
From: bparent at calvin.ucsd.edu (Brian Parent)
Date: Mon, 15 Nov 2004 22:57:28 -0800
Subject: conversation function for pam_acct_mgmt failing?
Message-ID: <20041116065728.GA8405@calvin.ucsd.edu>

I'm trying to use PAM on Solaris 8 with sshd (openssh 3.9p1) to run
the pam_acct_mgmt function and give some feedback to the user
if/when their account doesn't meet the necessary local requirements.

Things work fine when I use rlogin, i.e. a user gets authenticated
by typing in their password, and if their account has been suspended
(locally written programs maintain a database which a pam module checks),
they receive a nice message that tells them why their login failed.  
When I use sshd, the functionality is correct (logins fail after authentication
if account is suspended), except that the message to the user never makes it
to their screen.  I've used debugging to show that the message does make it 
to the conversation function, but the message never prints out.

I found some archived email to this list with:

 Subject:  PATCH: Public key authentication defeats passwd age warning.

that sounds like it is closely related from Sep. 2004, but applying the
patch found there hasn't helped my situation.  I tried forcing the use
of various conversation functions, (sshpam_store_conv, sshpam_tty_conv,
sshpam_passwd_conv) but can't get anything to print to the users
terminal.

I've seen other posts which suggest that using posix_threads may work,
but only if all other modules are thread-safe, and that this is not
the preferred workaround.

I'm running out of things to try, hence this post.



From dtucker at zip.com.au  Tue Nov 16 19:35:07 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 16 Nov 2004 19:35:07 +1100
Subject: conversation function for pam_acct_mgmt failing?
In-Reply-To: <20041116065728.GA8405@calvin.ucsd.edu>
References: <20041116065728.GA8405@calvin.ucsd.edu>
Message-ID: <4199BBBB.7090506@zip.com.au>

Brian Parent wrote:
> I'm trying to use PAM on Solaris 8 with sshd (openssh 3.9p1) to run
> the pam_acct_mgmt function and give some feedback to the user
> if/when their account doesn't meet the necessary local requirements.
> 
> Things work fine when I use rlogin, i.e. a user gets authenticated
> by typing in their password, and if their account has been suspended
> (locally written programs maintain a database which a pam module checks),
> they receive a nice message that tells them why their login failed.  
> When I use sshd, the functionality is correct (logins fail after authentication
> if account is suspended), except that the message to the user never makes it
> to their screen.  I've used debugging to show that the message does make it 
> to the conversation function, but the message never prints out.

Funny you should mention that, it's been fixed in -current.  Well, mostly.

The problem is that although the conversation works, there wasn't an 
easy way to get the messages to the user.  Post-3.9, we added some code 
to pass the message from the monitor to the slave, and to send it (in 
one of several ways) to the user if the auth or session modules fail. 
(The attached "pam-merged" patch contains a backport of those changes to 
3.9p1.)

At the moment, for auth modules, it'll return the message but won't 
terminate the connection, so the user can try to reauthenticate 
(although it will never succeed).  There's still a patch pending to fix 
this ("pam-disconnect", attached, which applies on top of "pam-merged").

It won't fix the SSHv2 keyboard-interactive (which needs some additional 
work), so you'll need to disable it and enable PasswordAuthentication, 
but it should work for all other auth types.

Try them (either both on 3.9p1, or just "pam-disconnect" on a snapshot) 
and let us know how it goes.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-pam-merged.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041116/99460003/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-pam-disconnect.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041116/99460003/attachment-0001.ksh 

From dtucker at zip.com.au  Tue Nov 16 19:56:14 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 16 Nov 2004 19:56:14 +1100
Subject: OpenSSH snaps have sftp libedit (command line history/editing)
	support
Message-ID: <4199C0AE.9070507@zip.com.au>

Hi All.
	For a couple of weeks, the Portable snapshots have contained optional 
support for NetBSD's libedit in the sftp client, thanks to djm's work in 
OpenBSD.  It's enabled with: ./configure --with-libedit.

	If enabled, sftp gains command history, recall and line editing (and 
probably other features too, I haven't looked into libedit's 
capabilities much).  If not enabled, sftp behaves the same as before.

	Some platforms have libedit available natively, such as NetBSD 
(obviously), Debian (libedit2 and libedit-dev) or Mandrake (libedit0). 
There are some URLs for ports of libedit to other platforms listed in 
OpenSSH's INSTALL (it works fine on all of the platforms I've tried it 
on, although some needed GNU awk to build it).

	Have fun, folks.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From dtucker at zip.com.au  Tue Nov 16 21:54:43 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 16 Nov 2004 21:54:43 +1100
Subject: Any plans implement MaxAuthTriesLog?
In-Reply-To: <41996D2E.90806@zip.com.au>
References: <T6d49ad24bac407b711d14@dtcseuvig5.dtc.lon.ime.reuters.com>
	<41996D2E.90806@zip.com.au>
Message-ID: <4199DC73.5030805@zip.com.au>

Darren Tucker wrote:
> Richard Dickens wrote:
> 
>> When a user gets their password wrong more than MaxAuthTries times why
>> isn't the message "Too many authentication failures for %.100s" written
>> to syslog? The user seems to get it (in a dialog in putty) but it
>> doesn't get logged. The usual "Failed password for..." messages are
>> logged.
> 
> AFAIK vanilla OpenSSH has never logged those (it only sends it to the 
> user via packet_disconnect).  Maybe it should log too?  And if so, maybe 
> it should log some more info?  Anyway, try this patch.

Richard pointed out that packet_disconnect already calls logit().  D'oh.

The reason it's not logged is privsep: the packet_disconnect and logit 
call happen in the unprivileged child (which is chrooted and doesn't 
have access to /dev/log).  Trying it with UsePrivilegeSeparation=no has 
the messages logged OK.  Not sure how to fix it for privsep=yes, other 
than adding a /dev/log to the chroot.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From bparent at calvin.ucsd.edu  Wed Nov 17 07:06:10 2004
From: bparent at calvin.ucsd.edu (Brian Parent)
Date: Tue, 16 Nov 2004 12:06:10 -0800
Subject: conversation function for pam_acct_mgmt failing?
In-Reply-To: <4199BBBB.7090506@zip.com.au>
References: <20041116065728.GA8405@calvin.ucsd.edu>
	<4199BBBB.7090506@zip.com.au>
Message-ID: <20041116200610.GB16894@calvin.ucsd.edu>

Re:
> Date: Tue, 16 Nov 2004 19:35:07 +1100
> From: Darren Tucker <dtucker at zip.com.au>
> To: Brian Parent <bparent at calvin.ucsd.edu>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: conversation function for pam_acct_mgmt failing?
> 
> Brian Parent wrote:
> >I'm trying to use PAM on Solaris 8 with sshd (openssh 3.9p1) to run
> >the pam_acct_mgmt function and give some feedback to the user
> >if/when their account doesn't meet the necessary local requirements.
> >
> >Things work fine when I use rlogin, i.e. a user gets authenticated
> >by typing in their password, and if their account has been suspended
> >(locally written programs maintain a database which a pam module checks),
> >they receive a nice message that tells them why their login failed.  
> >When I use sshd, the functionality is correct (logins fail after 
> >authentication
> >if account is suspended), except that the message to the user never makes 
> >it
> >to their screen.  I've used debugging to show that the message does make 
> >it to the conversation function, but the message never prints out.
> 
> Funny you should mention that, it's been fixed in -current.  Well, mostly.
> 
> The problem is that although the conversation works, there wasn't an 
> easy way to get the messages to the user.  Post-3.9, we added some code 
> to pass the message from the monitor to the slave, and to send it (in 
> one of several ways) to the user if the auth or session modules fail. 
> (The attached "pam-merged" patch contains a backport of those changes to 
> 3.9p1.)
> 
> At the moment, for auth modules, it'll return the message but won't 
> terminate the connection, so the user can try to reauthenticate 
> (although it will never succeed).  There's still a patch pending to fix 
> this ("pam-disconnect", attached, which applies on top of "pam-merged").
> 
> It won't fix the SSHv2 keyboard-interactive (which needs some additional 
> work), so you'll need to disable it and enable PasswordAuthentication, 
> but it should work for all other auth types.
> 
> Try them (either both on 3.9p1, or just "pam-disconnect" on a snapshot) 
> and let us know how it goes.
> 
> -- 
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.

Thanks so much for the patches!  I applied the first set, pam-merged,
and tested, but got the same (broken) behaviour.  I then applied the
pam-disconnect patches, and tested, and it worked - the message got
through to the client ssh process, and printed out.

I ran all these tests with "ChallengeResponseAuthentication no".
I also tested with UsePrivilegeSeparation both ways (yes and no).
Let me know if there are any other tests you'd like me to run.

My next hurdle is to recompile and run on our linux systems.
If there's interest, I'll let you know how that goes.



From dtucker at zip.com.au  Wed Nov 17 07:34:03 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 17 Nov 2004 07:34:03 +1100
Subject: conversation function for pam_acct_mgmt failing?
In-Reply-To: <20041116200610.GB16894@calvin.ucsd.edu>
References: <20041116065728.GA8405@calvin.ucsd.edu>
	<4199BBBB.7090506@zip.com.au>
	<20041116200610.GB16894@calvin.ucsd.edu>
Message-ID: <419A643B.10403@zip.com.au>

Brian Parent wrote:
> Thanks so much for the patches!  I applied the first set, pam-merged,
> and tested, but got the same (broken) behaviour.

You didn't happen to be using Protocol 1 for that connection, did you? 
Without the 2nd patch, its behaviour is unchanged.

>I then applied the
> pam-disconnect patches, and tested, and it worked - the message got
> through to the client ssh process, and printed out.
> 
> I ran all these tests with "ChallengeResponseAuthentication no".
> I also tested with UsePrivilegeSeparation both ways (yes and no).
> Let me know if there are any other tests you'd like me to run.
> 
> My next hurdle is to recompile and run on our linux systems.
> If there's interest, I'll let you know how that goes.

Please let us know if there's any problems.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From bparent at calvin.ucsd.edu  Wed Nov 17 07:58:46 2004
From: bparent at calvin.ucsd.edu (Brian Parent)
Date: Tue, 16 Nov 2004 12:58:46 -0800
Subject: conversation function for pam_acct_mgmt failing?
In-Reply-To: <419A643B.10403@zip.com.au>
References: <20041116065728.GA8405@calvin.ucsd.edu>
	<4199BBBB.7090506@zip.com.au>
	<20041116200610.GB16894@calvin.ucsd.edu>
	<419A643B.10403@zip.com.au>
Message-ID: <20041116205846.GH16894@calvin.ucsd.edu>

Re:
> Date: Wed, 17 Nov 2004 07:34:03 +1100
> From: Darren Tucker <dtucker at zip.com.au>
> To: Brian Parent <bparent at calvin.ucsd.edu>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: conversation function for pam_acct_mgmt failing?
> 
> Brian Parent wrote:
> >Thanks so much for the patches!  I applied the first set, pam-merged,
> >and tested, but got the same (broken) behaviour.
> 
> You didn't happen to be using Protocol 1 for that connection, did you? 
> Without the 2nd patch, its behaviour is unchanged.

Yup, you're right.  Switching to Protocol 2 made the first patch set
alone work, though without terminating the connection, as would be 
expected without the second patch.

Thanks again!



From mail2mz at yahoo.com  Wed Nov 17 09:27:40 2004
From: mail2mz at yahoo.com (mike zheng)
Date: Tue, 16 Nov 2004 14:27:40 -0800 (PST)
Subject: openssh porting
Message-ID: <20041116222740.72448.qmail@web53709.mail.yahoo.com>

Hi All,

I want port the openssh on an embedded system based on
powerPC. Is there any document that can guide me to
start?

Thanks in advance,

Mike Zheng

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From djm at mindrot.org  Wed Nov 17 09:53:05 2004
From: djm at mindrot.org (Damien Miller)
Date: Wed, 17 Nov 2004 09:53:05 +1100
Subject: openssh porting
In-Reply-To: <20041116222740.72448.qmail@web53709.mail.yahoo.com>
References: <20041116222740.72448.qmail@web53709.mail.yahoo.com>
Message-ID: <419A84D1.2010609@mindrot.org>

mike zheng wrote:
> Hi All,
> 
> I want port the openssh on an embedded system based on
> powerPC. Is there any document that can guide me to
> start?

No, and unless your system implements most of POSIX then you may
have a hard time. A necessary first step would be getting OpenSSL
working on your platform.

-d



From mouring at etoh.eviladmin.org  Wed Nov 17 10:00:52 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 16 Nov 2004 17:00:52 -0600 (CST)
Subject: openssh porting
In-Reply-To: <20041116222740.72448.qmail@web53709.mail.yahoo.com>
Message-ID: <Pine.BSO.4.44.0411161659090.8826-100000@etoh.eviladmin.org>


You'll need to ensure you have zlib and openssl at least.  Depending on
the PowerPC OS your using you may need additional helper functions (IE
openbsd-compat/).

Otherwise there is not much more for documentation to help with porting.

Feel free to post issues for the platform in question and we may be able
to provide assistants on an issue by issue base.

Or work to get the hardware into one or two of the developer's hands in
the OpenSSH project for them to work on the port.

- Ben

On Tue, 16 Nov 2004, mike zheng wrote:

> Hi All,
>
> I want port the openssh on an embedded system based on
> powerPC. Is there any document that can guide me to
> start?
>
> Thanks in advance,
>
> Mike Zheng
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From dan at doxpara.com  Wed Nov 17 14:53:38 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 16 Nov 2004 19:53:38 -0800
Subject: openssh porting
In-Reply-To: <20041116222740.72448.qmail@web53709.mail.yahoo.com>
References: <20041116222740.72448.qmail@web53709.mail.yahoo.com>
Message-ID: <419ACB42.2030901@doxpara.com>

Mike,

    You may have an easier time getting Dropbear to work.

    http://matt.ucc.asn.au/dropbear/dropbear.html

    As mentioned, this becomes much harder if you don't have a POSIX 
layer.  Some commercial solutions you may want to look into:

    http://www.mocana.com/ssh.html
    http://www.teamf1.com/SSHield.htm

    Hope this helps!

--Dan

   

mike zheng wrote:

>Hi All,
>
>I want port the openssh on an embedded system based on
>powerPC. Is there any document that can guide me to
>start?
>
>Thanks in advance,
>
>Mike Zheng
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev at mindrot.org
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>  
>



From stefan.strandfelt at nordea.com  Wed Nov 17 18:32:43 2004
From: stefan.strandfelt at nordea.com (stefan.strandfelt at nordea.com)
Date: Wed, 17 Nov 2004 09:32:43 +0200
Subject: (no subject)
Message-ID: <A17CE5BC84627745BD2B8F92E967DB2F394A83@fid1ms08.fid1.root4.net>




From mail2mz at yahoo.com  Thu Nov 18 01:43:40 2004
From: mail2mz at yahoo.com (mike zheng)
Date: Wed, 17 Nov 2004 06:43:40 -0800 (PST)
Subject: openssh porting
In-Reply-To: <419ACB42.2030901@doxpara.com>
Message-ID: <20041117144340.57730.qmail@web53702.mail.yahoo.com>

Hi All,

Thanks for all the suggestions.

Right now, I am using VxWorks. I've download OpenSSH
suite from http://openssh.org/. Do I need anything
else? 

Thanks again for the great help,

Mike
--- Dan Kaminsky <dan at doxpara.com> wrote:

> Mike,
> 
>     You may have an easier time getting Dropbear to
> work.
> 
>     http://matt.ucc.asn.au/dropbear/dropbear.html
> 
>     As mentioned, this becomes much harder if you
> don't have a POSIX 
> layer.  Some commercial solutions you may want to
> look into:
> 
>     http://www.mocana.com/ssh.html
>     http://www.teamf1.com/SSHield.htm
> 
>     Hope this helps!
> 
> --Dan
> 
>    
> 
> mike zheng wrote:
> 
> >Hi All,
> >
> >I want port the openssh on an embedded system based
> on
> >powerPC. Is there any document that can guide me to
> >start?
> >
> >Thanks in advance,
> >
> >Mike Zheng
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> >http://mail.yahoo.com 
> >
> >_______________________________________________
> >openssh-unix-dev mailing list
> >openssh-unix-dev at mindrot.org
>
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >  
> >
> 
> 



		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 



From mouring at etoh.eviladmin.org  Thu Nov 18 02:47:36 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 17 Nov 2004 09:47:36 -0600 (CST)
Subject: openssh porting
In-Reply-To: <20041117144340.57730.qmail@web53702.mail.yahoo.com>
Message-ID: <Pine.BSO.4.44.0411170935450.8826-100000@etoh.eviladmin.org>


Ermm.. I know nothing about VxWorks.  But I remember someone else doing a
vxworks port to OpenSSH a few years back.

Only VXWorks OpenSSH drived service I know of off hand is:

	http://www.teamf1.com/SSHield.htm

So it must be possible.

- Ben


On Wed, 17 Nov 2004, mike zheng wrote:

> Hi All,
>
> Thanks for all the suggestions.
>
> Right now, I am using VxWorks. I've download OpenSSH
> suite from http://openssh.org/. Do I need anything
> else?
>
> Thanks again for the great help,
>
> Mike
> --- Dan Kaminsky <dan at doxpara.com> wrote:
>
> > Mike,
> >
> >     You may have an easier time getting Dropbear to
> > work.
> >
> >     http://matt.ucc.asn.au/dropbear/dropbear.html
> >
> >     As mentioned, this becomes much harder if you
> > don't have a POSIX
> > layer.  Some commercial solutions you may want to
> > look into:
> >
> >     http://www.mocana.com/ssh.html
> >     http://www.teamf1.com/SSHield.htm
> >
> >     Hope this helps!
> >
> > --Dan
> >
> >
> >
> > mike zheng wrote:
> >
> > >Hi All,
> > >
> > >I want port the openssh on an embedded system based
> > on
> > >powerPC. Is there any document that can guide me to
> > >start?
> > >
> > >Thanks in advance,
> > >
> > >Mike Zheng
> > >
> > >__________________________________________________
> > >Do You Yahoo!?
> > >Tired of spam?  Yahoo! Mail has the best spam
> > protection around
> > >http://mail.yahoo.com
> > >
> > >_______________________________________________
> > >openssh-unix-dev mailing list
> > >openssh-unix-dev at mindrot.org
> >
> >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> > >
> > >
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Meet the all-new My Yahoo! - Try it today!
> http://my.yahoo.com
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From dmouldin at enterasys.com  Thu Nov 18 08:28:30 2004
From: dmouldin at enterasys.com (Moulding, Dan)
Date: Wed, 17 Nov 2004 16:28:30 -0500
Subject: openssh porting
Message-ID: <B32B3E03933E7748917067F7E6FC5E6B4E7F9F@MAANDMBX2.ets.enterasys.com>

A couple of years ago, I ported OpenSSH to Nucleus. While Nucleus is not
exactly the same as vxWorks, the obstacles you'll need to overcome will
probably be very similar.

Mainly, you'll need a POSIX layer for vxWorks, which a few people have
already mentioned. Maybe someone has already done this for vxWorks. This
would be worth looking into. If not, you could port your own (from
OpenBSD for example), though I don't how easy this would be for vxWorks.
We did it for Nucleus, and it wasn't really all that bad.

I'd also recommend cutting out any OpenSSH functionality that you don't
absolutely need in your end product. This will reduce the amount of work
you'll need to do to port your own POSIX layer, if that's what you
decide to do. For example, if you don't need port forwarding, then
remove it. Same thing with PAM, Kerberos, etc. You can significanly
reduce the amount of work required if you carefully note your
requirements and then start removing modules that you know you won't
need.

-- Dan

-----Original Message-----
From: openssh-unix-dev-bounces+dmouldin=enterasys.com at mindrot.org
[mailto:openssh-unix-dev-bounces+dmouldin=enterasys.com at mindrot.org] On
Behalf Of mike zheng
Sent: Tuesday, November 16, 2004 5:28 PM
To: openssh-unix-dev at mindrot.org
Subject: openssh porting

Hi All,

I want port the openssh on an embedded system based on powerPC. Is there
any document that can guide me to start?

Thanks in advance,

Mike Zheng

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev




From mail2mz at yahoo.com  Fri Nov 19 03:14:41 2004
From: mail2mz at yahoo.com (mike zheng)
Date: Thu, 18 Nov 2004 08:14:41 -0800 (PST)
Subject: Port OpenSSH to VxWorks
In-Reply-To: <419A84D1.2010609@mindrot.org>
Message-ID: <20041118161442.21934.qmail@web53708.mail.yahoo.com>

Hi All,

Does anyone did the porting of OpenSSH to VxWorks? 
Please let me know if you already done it. Then I may
quit my job. :-)

Thanks,

Mike


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 



From dan at doxpara.com  Fri Nov 19 06:43:12 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Thu, 18 Nov 2004 11:43:12 -0800
Subject: Port OpenSSH to VxWorks
In-Reply-To: <20041118161442.21934.qmail@web53708.mail.yahoo.com>
References: <20041118161442.21934.qmail@web53708.mail.yahoo.com>
Message-ID: <419CFB50.5020000@doxpara.com>

mike zheng wrote:

>Hi All,
>
>Does anyone did the porting of OpenSSH to VxWorks? 
>Please let me know if you already done it. Then I may
>quit my job. :-)
>
>Thanks,
>
>Mike
>  
>
You could always bug this guy :)

http://www.csh.rit.edu/~tebrown/resume.php

But there doesn't appear to be a publically available port (I'm sure 
we'd appreciate one, though).  Be aware that OpenSSH isn't exactly the 
most lightweight code out there; you may want to evaluate some of the 
publically available alternatives.

--Dan



From bparent at calvin.ucsd.edu  Sat Nov 20 10:30:50 2004
From: bparent at calvin.ucsd.edu (Brian Parent)
Date: Fri, 19 Nov 2004 15:30:50 -0800
Subject: Linux/Solaris PAM incompatabilities
In-Reply-To: <419A643B.10403@zip.com.au>
References: <20041116065728.GA8405@calvin.ucsd.edu>
	<4199BBBB.7090506@zip.com.au>
	<20041116200610.GB16894@calvin.ucsd.edu>
	<419A643B.10403@zip.com.au>
Message-ID: <20041119233050.GX16894@calvin.ucsd.edu>

I'm having trouble compiling openssh 3.9p1 on Linux.

The problem appears to be the difference in the way the pam_get_item
function is declared on Linux vs. Solaris.

on Linux: 2.4.21-20.ELsmp in /usr/include/security/_pam_types.h:

	extern int pam_get_item(const pam_handle_t *pamh, int item_type,
				const void **item);

on Solaris 8 in /usr/include/security/pam_appl.h:

	extern int
	pam_get_item(
		const pam_handle_t *pamh,       /* PAM handle */
		int item_type,                  /* Type of object - see below */
		void ** item                    /* Address of place to put pointer */
						/*   to object */
	);


This is how a call looks in auth-pam.c in 3.9p1:

	pam_get_item(sshpam_handle, PAM_USER, (void **)&pam_user);

Solaris compiles fine, Linux is unhappy.

In auth-pam.c in 3.8.1p1, the call looks like:

	pam_get_item(sshpam_handle, PAM_USER, (const void **)&pam_user);

which makes Linux happy, but Solaris won't compile.

I can go through the code and doctor it with ifdefs but I figured this
may have already been dealt with in a clean way by the developers.
Or maybe I'm missing a config flag (though I've looked).



From carson at taltos.org  Sat Nov 20 10:51:01 2004
From: carson at taltos.org (Carson Gaspar)
Date: Fri, 19 Nov 2004 18:51:01 -0500
Subject: Linux/Solaris PAM incompatabilities
In-Reply-To: <20041119233050.GX16894@calvin.ucsd.edu>
References: <20041116065728.GA8405@calvin.ucsd.edu>
	<4199BBBB.7090506@zip.com.au>	<20041116200610.GB16894@calvin.ucsd.edu>
	<419A643B.10403@zip.com.au> <20041119233050.GX16894@calvin.ucsd.edu>
Message-ID: <D7D0A206698C75E89DA82690@taltos.ny.fw.gs.com>



--On Friday, November 19, 2004 15:30:50 -0800 Brian Parent 
<bparent at calvin.ucsd.edu> wrote:

> This is how a call looks in auth-pam.c in 3.9p1:
>
> 	pam_get_item(sshpam_handle, PAM_USER, (void **)&pam_user);
>
> Solaris compiles fine, Linux is unhappy.

Get rid of -Werror and it should compile on Linux, too. It will emit a 
warning, but that's it.

-- 
Carson



From dtucker at zip.com.au  Sat Nov 20 14:50:25 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 20 Nov 2004 14:50:25 +1100
Subject: Linux/Solaris PAM incompatabilities
In-Reply-To: <20041119233050.GX16894@calvin.ucsd.edu>
References: <20041116065728.GA8405@calvin.ucsd.edu>	<4199BBBB.7090506@zip.com.au>	<20041116200610.GB16894@calvin.ucsd.edu>	<419A643B.10403@zip.com.au>
	<20041119233050.GX16894@calvin.ucsd.edu>
Message-ID: <419EBF01.4050206@zip.com.au>

Brian Parent wrote:
> I'm having trouble compiling openssh 3.9p1 on Linux.
> 
> The problem appears to be the difference in the way the pam_get_item
> function is declared on Linux vs. Solaris.

Yes, the joy of standards is that there's so many different ones to 
choose from.  Same goes for varying *implementations* of standards.

In this particular instance, OpenSSH complies with the PAM RFC[1] and 
XSSO[2], and LinuxPAM doesn't.  This mismatch ought to result in only a 
warning.  Remove -Werror (or your compiler's equivalent) as mentioned 
up-thread.

[1] http://www.opengroup.org/tech/rfc/mirror-rfc/rfc86.0.txt
[2] http://www.opengroup.org/onlinepubs/008329799/toc.pdf

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



From kqfoxhrpresssw at nacola.com.br  Sun Nov 21 11:12:17 2004
From: kqfoxhrpresssw at nacola.com.br (RendaExtra)
Date: Sat, 20 Nov 2004 22:12:17 -0200
Subject: RendaExtra com Internet - openssh-unix-dev@mindrot.org
Message-ID: <20041121063210.211EF27C187@shitei.mindrot.org>

Renda-Extra, Trabalho e Neg?cio, com uso da Internet e demais ferramentas,
em tempo parcial ou integral e com Altos Ganhos.
Pegue seu Ebook GR?TIS!

Visite: http://www.rendaforte.com

KRDCorp - D?vidas http://www.rendaforte.com/contato/




Essa mensagem foi enviada para o email: openssh-unix-dev at mindrot.org



Para ser removido de futuros correios, por favor, envie email para
ngtcad at ibest.com.br, com o assunto REMOVER. Obrigado.



From f.gardner_mn at stpauls.it  Sun Nov 21 18:29:39 2004
From: f.gardner_mn at stpauls.it (Florine Gardner)
Date: Sun, 21 Nov 2004 02:29:39 -0500
Subject: We sell regalis for an affordable price
Message-ID: <623901c4cf9b$910aadde$572f0a9e@hin.de>

Hi,

Regalis, also known as Superviagra or Cialis
- half a pill Lasts all weekend
- Has less sideeffects
- Has higher success rate

Now you can buy Regalis, for over 70% cheaper than the equivilent brand for sale in US

We ship world wide, and no prescription is required!!

Even if you're not impotent, Regalis will increase size, pleasure and power!

Try it today you wont regret!

Get it here: http://go-medz.com/sup/

Best regards,
Jeremy Stones


No thanks: http://go-medz.com/rr.php



From oqihzqpalev at hotmail.com  Mon Nov 22 08:01:53 2004
From: oqihzqpalev at hotmail.com (Janie)
Date: Sun, 21 Nov 2004 18:01:53 -0300
Subject: Pre--App(roved Appl.ication Saturday November 20
Message-ID: <YLJYPZKCCNTGKTGJCPTPXPL@hotmail.com> 

Your mortg\age process has been PRE-Appr|oved for RAtes starting at 3.25%, fixed.
Please use our secure site to fill-out your Appl!ication.

Thank you.

visit us at:

hTTp://onpyad.e-lenderz.com/index2.php?refid=x











alaska frightful cryptology crew southern cleric welsh slick inertial umbilicus gadfly morrissey

cruel inviolable cotman because destiny arianism cargo agleam allot redundant mcdonald countrify flaxen goodrich centric revelation


From Y469726e at yahoo.com  Tue Nov 23 06:36:42 2004
From: Y469726e at yahoo.com (Les Epps)
Date: Mon, 22 Nov 2004 16:36:42 -0300
Subject: Pre   Approved Applic/ation Nov 22, 2004
Message-ID: <wxdphaeqlbdfuibihwtkrn@yahoo.com> 

Your mort:gage process has been Pre-- Ap!proved for rates starting at 3.25%, fixed.
Please use our secure site to fill-out your Applicati/on.

Thank you.

visit us at:

HtTp://vqwpwmw.e-lenderz.com/index2.php?refid=x













dominant arbitrate contaminate kigali reese abet centrist numerate proportionate youngish blat looseleaf mathematician seedbed
hypotheses pecos treadmill congress dwarves envy sleepwalk tier bellini communicant mane pelham don


From hiro at dusk.org  Mon Nov 22 22:04:07 2004
From: hiro at dusk.org (Adam Wiggins)
Date: Mon, 22 Nov 2004 03:04:07 -0800
Subject: patch to fix non-echo tty on scp SIGINT
Message-ID: <20041122110407.GA11596@dusk.org>


A long-time missing feature (or bug, depending on how you look at it) is
that a Ctrl-C at the password prompt in scp does not restore the
terminal settings, thus dropping you to the command prompt without any
keyboard echo.  (A "reset" command will fix it.)  This is a pretty
regular occurance for me, and some others I've talked to - usually when
you realize that the scp command you typed has a typo and decide to
abort.

Strangely, ssh handles this correctly, but scp does not.  The single
handler in scp.c is killchild(), which should pass the SIGINT along to
the ssh process, which would restore the terminal.  However this doesn't
work for some reason I couldn't discern - perhaps the ssh process is
invoked in such a way that it doesn't have access to the terminal
settings?

I created the attached patch which fixes the problem by saving the
terminal settings at the start of program execution and restoring them
on SIGINT.  Although this is slightly hacky I think it is good general
practice to leave the terminal in the same state that it began in.  Even
if the ssh process were hardlocked this would still restore the
terminal.

Adam

-------------- next part --------------
--- openssh-3.9p1/scp.c 2004-08-13 04:19:38.000000000 -0700
+++ openssh-3.9p1-ttyfix/scp.c  2004-11-22 00:54:45.679885981 -0800
@@ -105,12 +105,19 @@
 /* This is used to store the pid of ssh_program */
 pid_t do_cmd_pid = -1;

+/* Save terminal state for restore on exit */
+static struct termios _saved_tio;
+
 static void
 killchild(int signo)
 {
        if (do_cmd_pid > 1)
                kill(do_cmd_pid, signo);

+       /* restore the terminal to its original state */
+       if (tcsetattr(fileno(stdin), TCSADRAIN, &_saved_tio) == -1)
+               perror("tcsetattr");
+
        _exit(1);
 }

@@ -218,6 +225,11 @@
        extern char *optarg;
        extern int optind;

+       if (tcgetattr(fileno(stdin), &_saved_tio) == -1) {
+               perror("tcgetattr");
+               return 0;
+       }
+
        __progname = ssh_get_progname(argv[0]);

        args.list = NULL;

From info at bbband.com  Tue Nov 23 01:03:30 2004
From: info at bbband.com (bbband)
Date: Mon, 22 Nov 2004 15:03:30 +0100 (added by postmaster@fastwebnet.it)
Subject: Richiesta di autorizzazione.
Message-ID: <00d701c4d09c$22223800$1b02a8c0@giorgio>

Ai sensi del Testo Unico sulla Privacy e in conformit? con quanto disposto dal Garante in materia di spamming, Le chiediamo l'autorizzazione ad inviarLe materiale informativo riguardante "band per intrattenimento e serate musicali"




From torsten.foertsch at gmx.net  Thu Nov 25 02:22:50 2004
From: torsten.foertsch at gmx.net (Torsten Foertsch)
Date: Wed, 24 Nov 2004 16:22:50 +0100
Subject: remote port forwarding timeout?
Message-ID: <200411241622.51368.torsten.foertsch@gmx.net>

Hi,

is it possible to establish a remote port forwarding with a timeout? I want

ssh -R 2000:x.y.z:80 --remote-forwarding-timeout 10 sleep 100

to return after 100 sec. But the remote sshd should be listening on port 2000 
only for 10 sec and then close the listening socket. For the last 90 sec port 
2000 should not be forwarded anymore but established connections should 
remain working.

If it is not possible would it be a useful feature? I could also think of 
limiting the number of connections to port 2000. Would it be difficult to 
implement?

Torsten



From jannie_jaramillo_ct at falkeborg.dk  Thu Nov 25 11:35:49 2004
From: jannie_jaramillo_ct at falkeborg.dk (Jannie Jaramillo)
Date: Wed, 24 Nov 2004 19:35:49 -0500
Subject: We sell regalis for an affordable price
Message-ID: <b92601c4d286$df4694c0$f7bd68a2@dillmann-jun.de>

Hi,

Regalis, also known as Superviagra or Cialis
- half a pill Lasts all weekend
- Has less sideeffects
- Has higher success rate

Now you can buy Regalis, for over 70% cheaper than the equivilent brand for sale in US

We ship world wide, and no prescription is required!!

Even if you're not impotent, Regalis will increase size, pleasure and power!

Try it today you wont regret!

Get it here: http://go-medz.com/sup/

Best regards,
Jeremy Stones


No thanks: http://go-medz.com/rr.php



From rr_itcsec at t-online.de  Fri Nov 26 08:56:32 2004
From: rr_itcsec at t-online.de (Roland)
Date: Thu, 25 Nov 2004 22:56:32 +0100
Subject: Searching for original UID at remote (sshd) host
Message-ID: <41A65510.5050302@t-online.de>

Hi,

does there exist a functionality in the current code, which allows the 
setting of an environment variable at the server side that represents 
the original user id at the ssh client side. The intention for that is, 
that i will know who the real user at the ssh client side is, if the 
user sets the option "-l <user>" in the ssh command. In the current 
code, I found only the options.user  structure, which contains the 
username for the new session, but there is no parameter  for 
transferring the original user name if the -l option is used. I need the 
original UID for an auditing mechanism at the server side.

Example: user1 at host1>ssh host2 -l user2   : host2 does't know, that 
user1 has made the ssh connection from host1


Roland




From djm at mindrot.org  Fri Nov 26 14:55:21 2004
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Nov 2004 14:55:21 +1100
Subject: Searching for original UID at remote (sshd) host
In-Reply-To: <41A65510.5050302@t-online.de>
References: <41A65510.5050302@t-online.de>
Message-ID: <41A6A929.6070403@mindrot.org>

Roland wrote:
> Hi,
> 
> does there exist a functionality in the current code, which allows the 
> setting of an environment variable at the server side that represents 
> the original user id at the ssh client side.

No, the server side would have to trust the client to not lie about the
uid anyway.

If you are happy with this trust, then you could probably cook something
up with the existing environment passing support (see SendEnv and
AcceptEnv in client and server config manpages)

-d



From djm at mindrot.org  Fri Nov 26 14:59:35 2004
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Nov 2004 14:59:35 +1100
Subject: testing, please ignore
Message-ID: <41A6AA27.2010805@mindrot.org>

Just testing some new anti-spam measures. Please ignore.

-d



From dmiller at netstarnetworks.com  Fri Nov 26 15:00:25 2004
From: dmiller at netstarnetworks.com (Damien Miller)
Date: Fri, 26 Nov 2004 15:00:25 +1100
Subject: Testing, please ignore (again)
Message-ID: <41A6AA59.8010203@netstarnetworks.com>

Still testing.



From djm at mindrot.org  Fri Nov 26 15:11:02 2004
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Nov 2004 15:11:02 +1100
Subject: Anti-spam: challenge-response for non-subscriber postings
Message-ID: <41A6ACD6.8030409@mindrot.org>

Hi,

The openssh-unix-dev list now requires posts from non-subscribed
addresses to pass a challenge-response before being accepted to the
list.

This may bite you if you use a different address to post from the one
you subscribed with, but you should only need to perform the challenge-
response once (it will remember your address from then on).

Apologies for any inconvenience, but this should greatly reduce the
amount of spam that makes it to the list while still allowing postings
from non-subscribers. Apologies also for taking so long to implement
it :)

-d



From djm at mindrot.org  Fri Nov 26 15:32:06 2004
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Nov 2004 15:32:06 +1100
Subject: remote port forwarding timeout?
In-Reply-To: <200411241622.51368.torsten.foertsch@gmx.net>
References: <200411241622.51368.torsten.foertsch@gmx.net>
Message-ID: <41A6B1C6.7000702@mindrot.org>

Torsten Foertsch wrote:
> Hi,
> 
> is it possible to establish a remote port forwarding with a timeout? I want
> 
> ssh -R 2000:x.y.z:80 --remote-forwarding-timeout 10 sleep 100

I'd like to extend the new mulitplex command mode in CVS to allow
cancellation of port-forwardings. Then you could do:

ssh -NfR 2000:x.y.z:80 -S ~/.ssh/your-ctl yourhost sleep 100 &
sleep 10 ; ssh -S ~/.ssh/your-ctl -O cancel-rforward 2000:x.y.z:80 &

-d



From torsten.foertsch at gmx.net  Fri Nov 26 19:54:11 2004
From: torsten.foertsch at gmx.net (Torsten Foertsch)
Date: Fri, 26 Nov 2004 09:54:11 +0100
Subject: remote port forwarding timeout?
In-Reply-To: <41A6B1C6.7000702@mindrot.org>
References: <200411241622.51368.torsten.foertsch@gmx.net>
	<41A6B1C6.7000702@mindrot.org>
Message-ID: <200411260954.18294.torsten.foertsch@gmx.net>

On Friday 26 November 2004 05:32, Damien Miller wrote:
> > is it possible to establish a remote port forwarding with a timeout? I
> > want
> >
> > ssh -R 2000:x.y.z:80 --remote-forwarding-timeout 10 sleep 100
>
> I'd like to extend the new mulitplex command mode in CVS to allow
> cancellation of port-forwardings. Then you could do:
>
> ssh -NfR 2000:x.y.z:80 -S ~/.ssh/your-ctl yourhost sleep 100 &
> sleep 10 ; ssh -S ~/.ssh/your-ctl -O cancel-rforward 2000:x.y.z:80 &

I had already played with the control path options and wondered why forwarderd 
connections could not be added or canceled this way. Will that included in 
the next openssh release? Can I help to implement it (haven't looked yet at 
the source)?

Is it right that in a connection made via control path the escape character 
does not work?

console1:
ssh -MS ~/.ssh/ctl x at y.z

then console2:
ssh -S ~/.ssh/ctl x at y.z

then ~. in console1 will abort both connections as expected but ~. in console2 
will be transfered literally. (OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004)

Torsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041126/23ce210a/attachment.bin 

From djm at mindrot.org  Fri Nov 26 21:37:47 2004
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Nov 2004 21:37:47 +1100
Subject: remote port forwarding timeout?
In-Reply-To: <200411260954.18294.torsten.foertsch@gmx.net>
References: <200411241622.51368.torsten.foertsch@gmx.net>
	<41A6B1C6.7000702@mindrot.org>
	<200411260954.18294.torsten.foertsch@gmx.net>
Message-ID: <41A7077B.3020704@mindrot.org>

Torsten Foertsch wrote:
> I had already played with the control path options and wondered why forwarderd 
> connections could not be added or canceled this way. Will that included in 
> the next openssh release?

Maybe, but i think we are adding too many options without making
cleanups or savings elsewhere.

> Can I help to implement it (haven't looked yet at 
> the source)?

Of course!

> Is it right that in a connection made via control path the escape character 
> does not work?

Yes, that is also on the list - we need to hook up the escape char
filter to subsequent session channels. This would be a good thing to
start helping with.

-d



From spam.pkoch at dfgh.net  Sat Nov 27 22:08:30 2004
From: spam.pkoch at dfgh.net (Peter Koch)
Date: Sat, 27 Nov 2004 12:08:30 +0100
Subject: buffer_get_bignum2: negative numbers not supported
Message-ID: <461907746@web.de>

Hi

I have added smartcard support to PuTTY and this worked fine
until yesterday when we replaced one of our Slackware-9 machines
by a Slackware-10 one.

Slackware-9 contained OpenSSH 3.5p1 while Slackware-10 has
OpenSSH 3.8.1p1.

Now the same keys that worked before do not work anymore and
OpenSSH fails with
buffer_get_bignum2: negative numbers not supported

I first supected that my smartcard-modification were the reason
and I double-checked the way I deliver the smartcards public
key to PuTTY. Maybe I forgot to prepend a 0x00 byte to a
modulus starting with 0x80. But I did not.

Here's the relevant output from sshd -ddd:

debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 20
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 0x8098168
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /etc/ssh/authorized_keys.root
debug3: secure_filename: checking '/etc/ssh'
debug3: secure_filename: checking '/etc'
debug3: secure_filename: checking '/'

buffer_get_bignum2: negative numbers not supported

debug1: do_cleanup
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 21
debug3: mm_request_receive entering
debug1: do_cleanup


And here's the relevant output from PuTTYs logfile:

Event Log: Pageant is running. Requesting keys.
Event Log: Pageant has 1 SSH2 keys
Event Log: Trying Pageant key #0
Outgoing packet type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
00000000 00 00 00 04 72 6f 6f 74 00 00 00 0e 73 73 68 2d ....root....ssh-
00000010 63 6f 6e 6e 65 63 74 69 6f 6e 00 00 00 09 70 75 connection....pu
00000020 62 6c 69 63 6b 65 79 00 00 00 00 07 73 73 68 2d blickey.....ssh-
00000030 72 73 61 00 00 00 98 00 00 00 07 73 73 68 2d 72 rsa........ssh-r
00000040 73 61 00 00 00 04 40 00 00 81 00 00 00 81 00 8b sa.... at .........
00000050 b2 9f 59 54 a9 6e 07 fd 50 bf 59 e1 b5 f3 a8 5d ..YT.n..P.Y....]
00000060 c5 60 df 39 58 ac 96 23 79 5d 75 c3 6b 3b e4 dd .`.9X..#y]u.k;..
00000070 21 42 4d be e7 e6 a5 d2 28 f1 3c f0 6d 77 3e b6 !BM.....(.<.mw>.
00000080 14 08 5d b6 d5 b1 7f 8a 13 6f 2e d7 00 bf 86 84 ..]......o......
00000090 a8 ac 22 01 2a 1f d9 5b 52 5a ff fa fc 1f e0 45 ..".*..[RZ.....E
000000a0 f1 e2 96 a6 20 da d7 94 2d 90 96 27 65 0f a1 be .... ...-..'e...
000000b0 6a 08 f5 bb fb 02 be 4a 07 80 cf cd 22 f0 40 2a j......J....".@*
000000c0 4a 61 f2 19 5d 9c 1e 1e 79 22 e9 c5 57 9d df Ja..]...y"..W..

As you can see the public key contained in the UserAuth-Request
is properly formatted. Public exponent is 40:00:00:81 (positive number)
and public modulus is 00:8b:b2....8d:df (also positive number)

So what's going on here. Since this is happening with my modified
PuTTY-only there may be something special with our smartcard
keys. The public exponent 40:00:00:81 is one that a "normal"
PuTTY-user would never use. But it worked with OpenSSH 3.5p1.

Any ideas?? The next thing I will try is to recompile OpenSSH 3.8.1p1
and add more debug-output to buffer-get_bignum2 so I can find
out what number OpenSSH thinks is a negative one. If that does
not help I probably must remove the negative-number-check.

But that's a dirty workaround only since our users could contact
our own OpenSSH servers only.

Peter Koch, (spam.pkoch at dfgh.net please replace spam by openssh)
__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201