From smooge at gmail.com  Thu Jun  1 01:37:54 2006
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 31 May 2006 09:37:54 -0600
Subject: Patch to add resume feature to scp
In-Reply-To: <20060531081152.GA805@calimero.vinschen.de>
References: <dbbab2cc0605100010g26e1b46cl4533ba358b6cdc10@mail.gmail.com>
	<20060511054006.GE1397@crawfish.ais.com>
	<Pine.BSO.4.64.0605111553390.28466@fuyu.mindrot.org>
	<4463558D.4020006@psc.edu> <20060513004737.GB16533@mathom.us>
	<20060531081152.GA805@calimero.vinschen.de>
Message-ID: <80d7e4090605310837p7b3bd67foff42b76c3286e8f8@mail.gmail.com>

On 5/31/06, Corinna Vinschen <vinschen at redhat.com> wrote:
> On May 12 20:47, Michael Stone wrote:
> > On Thu, May 11, 2006 at 11:17:33AM -0400, you wrote:
> > >Based on the interactions I have with the people that make use of our
> > >facilities most people still prefer SCP especially when it comes to
> > >automated file transfer processes. Since SCP, as such, is unmaintainable
> > >maybe it makes sense to actually write a new SCP that incorporates the
> > >best points of the old version (ease of use, ease of scripting, etc)
> > >with more advanced features. That way backward compatibility is
> > >maintained without abandoning a useful and widely used file transfer tool.
> >
> > Or, just change/add an interface to sftp. I can't think of any generally
> > useful feature of scp that can't be implemented fairly cleanly over the
> > sftp protocol.
>
> I'm almost 100% sure that users could be trained using sftp if two
> scp command line options are added to sftp, -r and -p.
>

The large issue I have seen is not with users (though many of them
were hard enough to train to use scp versus rcp) but legacy
scripts/code.

I was told that the scp2 command from ssh.com was really just an
overlay of the sftp protocol. It does the automatic translations of
put/get etc and it just looks like scp to the user.

-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator



From rapier at psc.edu  Thu Jun  1 03:33:50 2006
From: rapier at psc.edu (Chris Rapier)
Date: Wed, 31 May 2006 13:33:50 -0400
Subject: Patch to add resume feature to scp
In-Reply-To: <20060531081152.GA805@calimero.vinschen.de>
References: <dbbab2cc0605100010g26e1b46cl4533ba358b6cdc10@mail.gmail.com>	<20060511054006.GE1397@crawfish.ais.com>	<Pine.BSO.4.64.0605111553390.28466@fuyu.mindrot.org>	<4463558D.4020006@psc.edu>
	<20060513004737.GB16533@mathom.us>
	<20060531081152.GA805@calimero.vinschen.de>
Message-ID: <447DD37E.5040204@psc.edu>



Corinna Vinschen wrote:

> I'm almost 100% sure that users could be trained using sftp if two
> scp command line options are added to sftp, -r and -p.


Really depends on the users doesn't it? At our facility we supply grants 
of computing time and other resources on 3000+ node supercomputers to at 
least 12,000 local users, researchers, scientists, and organizations 
scattered throughout the US and the world. We could probably force our 
local staff to make any changes but the researchers and scientists? It 
would be about as easy as shaving a cat hopped up on coke - especially 
if they didn't perceive any compelling reason to do it (like a 
performance boost). As such, anything that breaks a script or changes 
how they do something is a disaster for us.

There are at least 4 other centers that do similar things and would have 
similar problems.



From tkoponen at iki.fi  Mon Jun  5 14:26:03 2006
From: tkoponen at iki.fi (Teemu Koponen)
Date: Sun, 4 Jun 2006 21:26:03 -0700
Subject: Resilient Connections for SSH
Message-ID: <80CF5477-A982-4730-8A05-5B540DF2B36D@iki.fi>

Dear OpenSSH Community,

Please find an experimental patch for resilient SSH connections from  
the web page below. It enables an SSH session to continue over  
sequential TCP connections in case of a broken TCP connection or  
change of an IP address. The page also includes the related USENIX'06  
paper which describes the design in detail.

http://www.infrahip.net/resilient/

Best regards,
Teemu, Pasi and Mikko

--



From rogier at tw.reverze.net  Sun Jun 11 03:05:47 2006
From: rogier at tw.reverze.net (Rogier Stam)
Date: Sun, 11 Jun 2006 01:05:47 +0800
Subject: Problems after having crosscompiled for XScale
Message-ID: <448AFBEB.4080008@tw.reverze.net>

Dear OpenSSH developers,

I tried porting OpenSSH-4.3p2 to arm-linux (IXP425 Xscale platform) 
using openssl-0.9.8b and uClibc. This on the snapgear 3.2.0 
distribution. It all compiles without problems, but when i run any 
openssh executable it will always show output similar to the following:
# ssh
sh: /usr/bin/ssh: No such file or directory
#

I checked for the libraries, they are all in /lib. To give you an ls:
lrwxrwxrwx    1 0        0              24 Jun 10 12:38 ld-linux.so.2 -> 
/lib/ld-uClibc-0.9.27.so
-rwxr-xr-x    1 0        0           20008 Jun 10 12:38 ld-uClibc-0.9.27.so
-rwxr-xr-x    1 0        0           20008 Jun 10 12:38 ld-uClibc.so.0
-rw-r--r--    1 0        0          269016 Jun 10 12:38 libc.so.0
-rw-r--r--    1 0        0            9992 Jun 10 12:37 libcrypt-0.9.27.so
-rw-r--r--    1 0        0            9992 Jun 10 12:38 libcrypt.so.0
lrwxrwxrwx    1 0        0              18 Jun 10 12:38 libcrypto.so -> 
libcrypto.so.0.9.8
-rwxr-xr-x    1 0        0         1186860 Jun 10 12:38 libcrypto.so.0.9.8
-rw-r--r--    1 0        0            7132 Jun 10 12:37 libdl-0.9.27.so
-rw-r--r--    1 0        0            7132 Jun 10 12:38 libdl.so.0
-rwxr-xr-x    1 0        0           36436 Jun 10 12:38 libeap-1.1.2.so
lrwxrwxrwx    1 0        0              20 Jun 10 12:38 libeap.so -> 
/lib/libeap-1.1.2.so
lrwxrwxrwx    1 0        0              21 Jun 10 12:38 libltdl.so -> 
/lib/libltdl.so.3.1.0
lrwxrwxrwx    1 0        0              21 Jun 10 12:38 libltdl.so.3 -> 
/lib/libltdl.so.3.1.0
-rwxr-xr-x    1 0        0           36508 Jun 10 12:38 libltdl.so.3.1.0
-rw-r--r--    1 0        0           55104 Jun 10 12:38 libm-0.9.27.so
-rw-r--r--    1 0        0           55104 Jun 10 12:38 libm.so.0
-rw-r--r--    1 0        0            1472 Jun 10 12:38 libnsl-0.9.27.so
-rw-r--r--    1 0        0            1472 Jun 10 12:38 libnsl.so.0
-rw-r--r--    1 0        0           68464 Jun 10 12:38 libpthread-0.9.27.so
-rw-r--r--    1 0        0           68464 Jun 10 12:38 libpthread.so.0
-rwxr-xr-x    1 0        0          131484 Jun 10 12:38 libradius-1.1.2.so
lrwxrwxrwx    1 0        0              23 Jun 10 12:38 libradius.so -> 
/lib/libradius-1.1.2.so
-rw-r--r--    1 0        0            1480 Jun 10 12:38 libresolv-0.9.27.so
-rw-r--r--    1 0        0            1480 Jun 10 12:38 libresolv.so.0
-rw-r--r--    1 0        0            3288 Jun 10 12:38 librt-0.9.27.so
-rw-r--r--    1 0        0            3288 Jun 10 12:38 librt.so.0
lrwxrwxrwx    1 0        0              15 Jun 10 12:38 libssl.so -> 
libssl.so.0.9.8
-rwxr-xr-x    1 0        0          230568 Jun 10 12:38 libssl.so.0.9.8
-rw-r--r--    1 0        0          269016 Jun 10 12:38 libuClibc-0.9.27.so
-rw-r--r--    1 0        0            4212 Jun 10 12:38 libutil-0.9.27.so
-rw-r--r--    1 0        0            4212 Jun 10 12:38 libutil.so.0

I used the following options for configure:
./configure --host=arm-linux --disable-etc-default-login 
--with-ssl-dir=/tmp/uClinux-dist/snapgear/modules/openssl-0.9.8b/ 
--with-md5-passwords --enable-shared --disable-static 
--without-kereberos5 --without-x --without-pam --without-bsd-auth 
CC="arm-linux-gcc" CFLAGS="-mbig-endian -g -O2 
-I/tmp/uClinux-dist/snapgear/lib/zlib 
-I/tmp/uClinux-dist/snapgear/uClibc/include" LDFLAGS="-g 
-L/tmp/uClinux-dist/snapgear/uClibc/lib -nostdlib 
-L/tmp/uClinux-dist/snapgear/modules/openssl-0.9.8b 
-L/tmp/uClinux-dist/snapgear/lib/zlib -EB -lc -ldl 
/tmp/uClinux-dist/snapgear/uClibc/lib/crt0.o $(arm-linux-gcc 
-mbig-endian --print-libgcc-file-name)" LD=arm-linux-ld

I know the openssl libraries are working since radiusd works without 
problems, as does the openssl binary. I needed to make a very small 
modification to the Makefile, to change the order of the libraries to 
let it compile (-lssl had to be put before LDFLAGS in order for it to 
compile).
Can anyone give me any idea why it shows file not found ? Even executing 
it from /usr/bin where ssh resides (by ./ssh) will show this error. All 
binaries are in the PATH. Even gdbserver immediately on starting shows 
this error message. Yet the binaries are there, and are not empty 
(hexdump -C shows an ELF header).

I hope you can help me.

Regards,

Rogier Stam



From dtucker at zip.com.au  Sun Jun 11 07:06:09 2006
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 11 Jun 2006 07:06:09 +1000
Subject: Problems after having crosscompiled for XScale
In-Reply-To: <448AFBEB.4080008@tw.reverze.net>
References: <448AFBEB.4080008@tw.reverze.net>
Message-ID: <448B3441.80208@zip.com.au>

Rogier Stam wrote:

> I tried porting OpenSSH-4.3p2 to arm-linux (IXP425 Xscale platform) > using openssl-0.9.8b and uClibc. This on the snapgear 3.2.0 
> distribution. It all compiles without problems, but when i run any 
> openssh executable it will always show output similar to the following:
> # ssh
> sh: /usr/bin/ssh: No such file or directory
> #
> 
> I checked for the libraries, they are all in /lib. To give you an ls:
[list of libs]

libz.so seems to be missing.

If that's not it, do you have ldd on your target, and if so what does 
ldd /usr/bin/ssh say?

-- 
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 rogier at tw.reverze.net  Sun Jun 11 14:35:50 2006
From: rogier at tw.reverze.net (Rogier Stam)
Date: Sun, 11 Jun 2006 12:35:50 +0800
Subject: Problems after having crosscompiled for XScale
In-Reply-To: <448B3441.80208@zip.com.au>
References: <448AFBEB.4080008@tw.reverze.net> <448B3441.80208@zip.com.au>
Message-ID: <448B9DA6.7080609@tw.reverze.net>

Thanks for the reply. Unfortunately no LDD. But using arm-linux-objdump 
-x reveals the following:
Dynamic Section:
  NEEDED      libc.so.0
  NEEDED      libdl.so.0
  NEEDED      libz.so
  NEEDED      libcrypto.so.0.9.8
  NEEDED      libutil.so.0
  NEEDED      libcrypt.so.0
  NEEDED      libresolv.so.0
  HASH        0x8130
  STRTAB      0x9888
  SYMTAB      0x8858
  STRSZ       0xa56
  SYMENT      0x10
  DEBUG       0x0
  PLTGOT      0x4551c
  PLTRELSZ    0x758
  PLTREL      0x11
  JMPREL      0xa328
  REL         0xa2e0
  RELSZ       0x48
  RELENT      0x8

I cut out only the dynamic section ... I didnt think the rest was very 
relevant in this case. I made sure this time that the libz was there 
this time, and the binaries were compiled against this library. The 
library list:
# ls -al /tmp/
drwxr-xr-x    3 0        0               0 Jun 10 22:00 .
drwxr-xr-x   14 0        0             129 Jun 10 12:37 ..
-rwxr-xr-x    1 0        0           40108 Jun 10 22:00 gdbserver
drwxr-xr-x    3 0        0               0 Jun 10 21:55 lib
-rwxr-xr-x    1 0        0         2147127 Jun 10 21:58 ssh
# ls -al /lib/
drwxr-xr-x    3 0        0               0 Jun 10 21:55 .
drwxr-xr-x   14 0        0             129 Jun 10 12:37 ..
lrwxrwxrwx    1 0        0              24 Jun 10 21:05 ld-linux.so.2 -> 
/lib/ld-uClibc-0.9.27.so
-rwxr-xr-x    1 0        0           20008 Jun 10 12:38 ld-uClibc-0.9.27.so
-rwxr-xr-x    1 0        0           20008 Jun 10 12:38 ld-uClibc.so.0
-rw-r--r--    1 0        0          269016 Jun 10 12:38 libc.so.0
-rw-r--r--    1 0        0            9992 Jun 10 12:37 libcrypt-0.9.27.so
-rw-r--r--    1 0        0            9992 Jun 10 12:38 libcrypt.so.0
lrwxrwxrwx    1 0        0              18 Jun 10 21:05 libcrypto.so -> 
libcrypto.so.0.9.8
-rwxr-xr-x    1 0        0         1186860 Jun 10 12:38 libcrypto.so.0.9.8
-rw-r--r--    1 0        0            7132 Jun 10 12:37 libdl-0.9.27.so
-rw-r--r--    1 0        0            7132 Jun 10 12:38 libdl.so.0
-rwxr-xr-x    1 0        0           36436 Jun 10 12:38 libeap-1.1.2.so
lrwxrwxrwx    1 0        0              20 Jun 10 21:05 libeap.so -> 
/lib/libeap-1.1.2.so
lrwxrwxrwx    1 0        0              21 Jun 10 21:05 libltdl.so -> 
/lib/libltdl.so.3.1.0
lrwxrwxrwx    1 0        0              21 Jun 10 21:05 libltdl.so.3 -> 
/lib/libltdl.so.3.1.0
-rwxr-xr-x    1 0        0           36508 Jun 10 12:38 libltdl.so.3.1.0
-rw-r--r--    1 0        0           55104 Jun 10 12:38 libm-0.9.27.so
-rw-r--r--    1 0        0           55104 Jun 10 12:38 libm.so.0
-rw-r--r--    1 0        0            1472 Jun 10 12:38 libnsl-0.9.27.so
-rw-r--r--    1 0        0            1472 Jun 10 12:38 libnsl.so.0
-rw-r--r--    1 0        0           68464 Jun 10 12:38 libpthread-0.9.27.so
-rw-r--r--    1 0        0           68464 Jun 10 12:38 libpthread.so.0
-rwxr-xr-x    1 0        0          131484 Jun 10 12:38 libradius-1.1.2.so
lrwxrwxrwx    1 0        0              23 Jun 10 21:05 libradius.so -> 
/lib/libradius-1.1.2.so
-rw-r--r--    1 0        0            1480 Jun 10 12:38 libresolv-0.9.27.so
-rw-r--r--    1 0        0            1480 Jun 10 12:38 libresolv.so.0
-rw-r--r--    1 0        0            3288 Jun 10 12:38 librt-0.9.27.so
-rw-r--r--    1 0        0            3288 Jun 10 12:38 librt.so.0
lrwxrwxrwx    1 0        0              15 Jun 10 21:05 libssl.so -> 
libssl.so.0.9.8
-rwxr-xr-x    1 0        0          230568 Jun 10 12:38 libssl.so.0.9.8
-rw-r--r--    1 0        0          269016 Jun 10 12:38 libuClibc-0.9.27.so
-rw-r--r--    1 0        0            4212 Jun 10 12:38 libutil-0.9.27.so
-rw-r--r--    1 0        0            4212 Jun 10 12:38 libutil.so.0
lrwxrwxrwx    1 0        0              18 Jun 10 21:45 libz.so -> 
/lib/libz.so.1.1.4
lrwxrwxrwx    1 0        0              18 Jun 10 21:45 libz.so.1 -> 
/lib/libz.so.1.1.4
-rwxr-xr-x    1 0        0           57585 Jun 10 21:54 libz.so.1.1.4
drwxr-xr-x    3 0        0               0 Jun 10 12:38 modules

As a further test I tried the following:
export 
LD_PRELOAD=/lib/libc.so.0:/lib/libdl.so.0:/lib/libz.so:/lib/libcrypto.so.0.9.8:/lib/libutil.so.0:/lib/libcrypt.so.0:/lib/libresolv.so.0
ssh

The result remains the same. Even adding some printf statements to the 
beginning of main in ssh.c did not show up. I'm beginning to wonder if 
something is linked wrong ?

I hope you can help....

Thanks so far & regards,

Rogier
Darren Tucker wrote:

> Rogier Stam wrote:
>
>> I tried porting OpenSSH-4.3p2 to arm-linux (IXP425 Xscale platform) > 
>> using openssl-0.9.8b and uClibc. This on the snapgear 3.2.0 
>> distribution. It all compiles without problems, but when i run any 
>> openssh executable it will always show output similar to the following:
>> # ssh
>> sh: /usr/bin/ssh: No such file or directory
>> #
>>
>> I checked for the libraries, they are all in /lib. To give you an ls:
>
> [list of libs]
>
> libz.so seems to be missing.
>
> If that's not it, do you have ldd on your target, and if so what does 
> ldd /usr/bin/ssh say?
>



From rogier at tw.reverze.net  Sun Jun 11 14:58:18 2006
From: rogier at tw.reverze.net (Rogier Stam)
Date: Sun, 11 Jun 2006 12:58:18 +0800
Subject: Problems after having crosscompiled for XScale
In-Reply-To: <448B3441.80208@zip.com.au>
References: <448AFBEB.4080008@tw.reverze.net> <448B3441.80208@zip.com.au>
Message-ID: <448BA2EA.9080702@tw.reverze.net>

Darren Tucker wrote:

> Rogier Stam wrote:
>
>> I tried porting OpenSSH-4.3p2 to arm-linux (IXP425 Xscale platform) > 
>> using openssl-0.9.8b and uClibc. This on the snapgear 3.2.0 
>> distribution. It all compiles without problems, but when i run any 
>> openssh executable it will always show output similar to the following:
>> # ssh
>> sh: /usr/bin/ssh: No such file or directory
>> #
>>
>> I checked for the libraries, they are all in /lib. To give you an ls:
>
> [list of libs]
>
> libz.so seems to be missing.
>
> If that's not it, do you have ldd on your target, and if so what does 
> ldd /usr/bin/ssh say?
>
I just managed to crosscompile ldd on my host platform. The result is 
the following:
root at RinceWind:/tmp/uClinux-dist/snapgear/uClibc/utils# ./ldd.host 
../../modules/openssh-4.3p2/sftp
        libc.so.0 => not found (0x00000000)
        libdl.so.0 => not found (0x00000000)
        libz.so => /usr/lib/libz.so (0x00000000)
        libcrypto.so.0.9.8 => not found (0x00000000)
        libutil.so.0 => not found (0x00000000)
        libcrypt.so.0 => not found (0x00000000)
        libresolv.so.0 => not found (0x00000000)
        libc.so.6 => not found (0x00000000)
        not a dynamic executable
Don't mind the not found messages, as it cannot find these libraries as 
the libraries are not in the system path yet, as i run ldd on the host 
not the target. This just to show what ldd says.
Symlinking libc.so.6 to libc.so.0 or /lib/libuClibc-0.9.27.so does not 
seem to solve the problem either.



From stuge-openssh-unix-dev at cdy.org  Sun Jun 11 17:57:43 2006
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Sun, 11 Jun 2006 09:57:43 +0200
Subject: Problems after having crosscompiled for XScale
In-Reply-To: <448BA2EA.9080702@tw.reverze.net>
References: <448AFBEB.4080008@tw.reverze.net> <448B3441.80208@zip.com.au>
	<448BA2EA.9080702@tw.reverze.net>
Message-ID: <20060611075745.22279.qmail@cdy.org>

On Sun, Jun 11, 2006 at 12:58:18PM +0800, Rogier Stam wrote:
> Symlinking libc.so.6 to libc.so.0 or /lib/libuClibc-0.9.27.so does
> not seem to solve the problem either.

How about: strace /usr/bin/ssh

Does that give any clue as to which library is missing?


//Peter



From rogier at tw.reverze.net  Mon Jun 12 02:42:59 2006
From: rogier at tw.reverze.net (Rogier Stam)
Date: Mon, 12 Jun 2006 00:42:59 +0800
Subject: Problems after having crosscompiled for XScale
In-Reply-To: <448B3441.80208@zip.com.au>
References: <448AFBEB.4080008@tw.reverze.net> <448B3441.80208@zip.com.au>
Message-ID: <448C4813.2010709@tw.reverze.net>

Darren Tucker wrote:

> Rogier Stam wrote:
>
>> I tried porting OpenSSH-4.3p2 to arm-linux (IXP425 Xscale platform) > 
>> using openssl-0.9.8b and uClibc. This on the snapgear 3.2.0 
>> distribution. It all compiles without problems, but when i run any 
>> openssh executable it will always show output similar to the following:
>> # ssh
>> sh: /usr/bin/ssh: No such file or directory
>> #
>>
>> I checked for the libraries, they are all in /lib. To give you an ls:
>
> [list of libs]
>
> libz.so seems to be missing.
>
> If that's not it, do you have ldd on your target, and if so what does 
> ldd /usr/bin/ssh say?
>
In the meantime i've tried openssh-4.0p1 and 4.2p1, all with the same 
results. I also found that this bug occurred before in 3.5, but wasn't 
solved due to incomplete bug report 
(http://bugzilla.mindrot.org/show_bug.cgi?id=422).
Should (in the case of a missing library) the name of the missing lib 
not be displayed? (assuming this is the case). Strangely enough i see 
(using ldd) a libc.so.6 aside from my libc.so.0. yet i have not 
specified it, and i link with the -nostdlib option. Where it comes from 
I don't know. Checking with arm-linux-objdump -x  doesn't show it 
either, nor does a grep -r. Could this be an errant message from the 
host compiled ldd?



From rogier at tw.reverze.net  Tue Jun 13 01:58:06 2006
From: rogier at tw.reverze.net (Rogier Stam)
Date: Mon, 12 Jun 2006 23:58:06 +0800
Subject: Problems after having crosscompiled for XScale
In-Reply-To: <448B3441.80208@zip.com.au>
References: <448AFBEB.4080008@tw.reverze.net> <448B3441.80208@zip.com.au>
Message-ID: <448D8F0E.2090408@tw.reverze.net>

Just wanted to let you guys know what the reason was. The problem is 
that ld.so.1 is not symlinked to the /lib/ld-uClibc-0.9.27.so file. 
Since I use uclibc. Default that one is not created, and while none of 
my other apps seem to have a problem with this, openssh apparently does....

Thanks for the help!

Regards,

Rogier
Darren Tucker wrote:

> Rogier Stam wrote:
>
>> I tried porting OpenSSH-4.3p2 to arm-linux (IXP425 Xscale platform) > 
>> using openssl-0.9.8b and uClibc. This on the snapgear 3.2.0 
>> distribution. It all compiles without problems, but when i run any 
>> openssh executable it will always show output similar to the following:
>> # ssh
>> sh: /usr/bin/ssh: No such file or directory
>> #
>>
>> I checked for the libraries, they are all in /lib. To give you an ls:
>
> [list of libs]
>
> libz.so seems to be missing.
>
> If that's not it, do you have ldd on your target, and if so what does 
> ldd /usr/bin/ssh say?
>



From derek at derekfrye.com  Tue Jun 13 04:44:22 2006
From: derek at derekfrye.com (Derek Frye)
Date: Mon, 12 Jun 2006 13:44:22 -0500
Subject: Possible to print message(s) before login?
Message-ID: <448DB606.7040805@derekfrye.com>

Hi,

Is there a way to print a message before the login prompt or after the 
login prompt but before the password prompt? This way unauthenticated 
users can see a small message (like "Hello!").

I looked through the source for version 4.2 and couldn't find where the 
login strings are constructed and sent (except in the client software 
portion). Maybe all strings (like "login: ", where users enter username) 
are generated and encrypted in the client software in response to server 
packets (non-strings)? So is there even a way to send strings before 
successful authentication?

Maybe this would violate the design of openssh?

Thanks,
Derek Frye



From rapier at psc.edu  Tue Jun 13 04:59:17 2006
From: rapier at psc.edu (Chris Rapier)
Date: Mon, 12 Jun 2006 14:59:17 -0400
Subject: Possible to print message(s) before login?
In-Reply-To: <448DB606.7040805@derekfrye.com>
References: <448DB606.7040805@derekfrye.com>
Message-ID: <448DB985.5080409@psc.edu>

I'm curious as to why you'd want to do this. Not that there is never any 
reasons to do this but I'm wondering why.


Derek Frye wrote:
> Hi,
> 
> Is there a way to print a message before the login prompt or after the 
> login prompt but before the password prompt? This way unauthenticated 
> users can see a small message (like "Hello!").
> 
> I looked through the source for version 4.2 and couldn't find where the 
> login strings are constructed and sent (except in the client software 
> portion). Maybe all strings (like "login: ", where users enter username) 
> are generated and encrypted in the client software in response to server 
> packets (non-strings)? So is there even a way to send strings before 
> successful authentication?
> 
> Maybe this would violate the design of openssh?



From derek at derekfrye.com  Tue Jun 13 05:23:23 2006
From: derek at derekfrye.com (Derek Frye)
Date: Mon, 12 Jun 2006 14:23:23 -0500
Subject: Possible to print message(s) before login?
In-Reply-To: <448DB985.5080409@psc.edu>
References: <448DB606.7040805@derekfrye.com> <448DB985.5080409@psc.edu>
Message-ID: <448DBF2B.6090100@derekfrye.com>

I want to do this so I can print a message to persons/bots attempting 
automated ssh login. Maybe something like "Good luck getting in, this 
box runs OpenSSH".

:)

Chris Rapier wrote:
> I'm curious as to why you'd want to do this. Not that there is never any 
> reasons to do this but I'm wondering why.

Thanks,
Derek Frye



From derek at derekfrye.com  Tue Jun 13 05:27:56 2006
From: derek at derekfrye.com (Derek Frye)
Date: Mon, 12 Jun 2006 14:27:56 -0500
Subject: Possible to print message(s) before login?
In-Reply-To: <448DB985.5080409@psc.edu>
References: <448DB606.7040805@derekfrye.com> <448DB985.5080409@psc.edu>
Message-ID: <448DC03C.30600@derekfrye.com>

Ah yes, this was exactly what I was looking for. Knowing that I needed a 
"banner" would have helped when parsing the source ;)

Chris Rapier wrote:
> I'm curious as to why you'd want to do this. Not that there is never any 
> reasons to do this but I'm wondering why.
> 
> 
> Derek Frye wrote:
>> Hi,
>>
>> Is there a way to print a message before the login prompt or after the 
>> login prompt but before the password prompt? This way unauthenticated 
>> users can see a small message (like "Hello!").
>>
>> I looked through the source for version 4.2 and couldn't find where 
>> the login strings are constructed and sent (except in the client 
>> software portion). Maybe all strings (like "login: ", where users 
>> enter username) are generated and encrypted in the client software in 
>> response to server packets (non-strings)? So is there even a way to 
>> send strings before successful authentication?
>>
>> Maybe this would violate the design of openssh?



From rapier at psc.edu  Tue Jun 13 05:38:14 2006
From: rapier at psc.edu (Chris Rapier)
Date: Mon, 12 Jun 2006 15:38:14 -0400
Subject: Possible to print message(s) before login?
In-Reply-To: <448DBF2B.6090100@derekfrye.com>
References: <448DB606.7040805@derekfrye.com> <448DB985.5080409@psc.edu>
	<448DBF2B.6090100@derekfrye.com>
Message-ID: <448DC2A6.1040206@psc.edu>

In this case, since its not serving any sort of critical need, I would 
suggest against it. One way to maintain security it to prevent the 
leakage of any information that might be used by an intruder to their 
advantage. Also, taunting hackers never really seems to work out too 
well. :)


Derek Frye wrote:
> I want to do this so I can print a message to persons/bots attempting 
> automated ssh login. Maybe something like "Good luck getting in, this 
> box runs OpenSSH".
> 
> :)
> 
> Chris Rapier wrote:
>> I'm curious as to why you'd want to do this. Not that there is never any 
>> reasons to do this but I'm wondering why.
> 
> Thanks,
> Derek Frye
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From imorgan at nas.nasa.gov  Tue Jun 13 07:00:00 2006
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Mon, 12 Jun 2006 14:00:00 -0700 (PDT)
Subject: Possible to print message(s) before login?
In-Reply-To: <448DB606.7040805@derekfrye.com> from Derek Frye at "Jun 12, 2006
	01:44:22 pm"
Message-ID: <200606122100.k5CL00qd028950@ganymede.nas.nasa.gov>

Sometime ago, Derek Frye wrote:
> Hi,
> 
> Is there a way to print a message before the login prompt or after the 
> login prompt but before the password prompt? This way unauthenticated 
> users can see a small message (like "Hello!").
> 
> I looked through the source for version 4.2 and couldn't find where the 
> login strings are constructed and sent (except in the client software 
> portion). Maybe all strings (like "login: ", where users enter username) 
> are generated and encrypted in the client software in response to server 
> packets (non-strings)? So is there even a way to send strings before 
> successful authentication?
> 
> Maybe this would violate the design of openssh?
> 
> Thanks,
> Derek Frye
> 

Before digging through the source code, you might want to read the man
pages first. :-) The Banner option in the sshd_config(5) man page sounds
like what you're looking for.

--
Iain Morgan



From senthilkumar_sen at hotpop.com  Wed Jun 14 15:34:01 2006
From: senthilkumar_sen at hotpop.com (Senthil Kumar)
Date: Wed, 14 Jun 2006 11:04:01 +0530
Subject: Deleting root credentials
Message-ID: <482901c68f74$2b6670f0$220110ac@sekco>

Hello All,

I'm using OpenSSH 4.3 compiled with PAM support. Im using a proprietary PAM 
module for my Authentication. When the root user logs out, it throws a 
message "pam_setcred : Pemission denied" in syslog. The PAM engineer told me 
that the module can't delete root users credentials. Instead he is asking me 
to skip the call pam_setcred() in sshpam_cleanup() in auth-pam.c for root 
user. Is this is the right way? Is there any impact with this?

Thanks,
Senthil Kumar. 




From dtucker at zip.com.au  Wed Jun 14 15:51:18 2006
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 14 Jun 2006 15:51:18 +1000
Subject: Deleting root credentials
In-Reply-To: <482901c68f74$2b6670f0$220110ac@sekco>
References: <482901c68f74$2b6670f0$220110ac@sekco>
Message-ID: <448FA3D6.5010609@zip.com.au>

Senthil Kumar wrote:
> I'm using OpenSSH 4.3 compiled with PAM support. Im using a proprietary PAM 
> module for my Authentication. When the root user logs out, it throws a 
> message "pam_setcred : Pemission denied" in syslog. The PAM engineer told me 
> that the module can't delete root users credentials. Instead he is asking me 
> to skip the call pam_setcred() in sshpam_cleanup() in auth-pam.c for root 
> user.

You can try the patch #1143 in [1], which attempts to fix this for 
regular users when privsep=yes.  I think it will also help for root when 
privsep=yes, but I'm not 100% sure.  It won't help if privsep=no.

> Is this is the right way?

Not really, but fixing this for the general case is not trivial (see the 
discussion in [1]).

> Is there any impact with this?

Depends on what your PAM modules actually do... presumably the authors 
of your modules would be able to say for certain.

[1] http://bugzilla.mindrot.org/show_bug.cgi?id=926

-- 
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 tryponraj at gmail.com  Wed Jun 14 21:22:26 2006
From: tryponraj at gmail.com (ponraj)
Date: Wed, 14 Jun 2006 16:52:26 +0530
Subject: scp performance during local-to-remote file transfer
References: <446E39C0.1070901@psc.edu>
Message-ID: <009601c68fa4$d8a52d30$180110ac@pomco>

Hi all,

>From this version of HPN, SO_RCVBUF can be set with the "TcpRcvBuf" option 
on the client scp, but the scp launched by the sshd does not call the 
setsockopt(). As a result the performance of scp is good when download a 
file from remote-to-local but not when upload a file from local-to-remote. 
Can you tell me what configuation settings makes the local-to-remote file 
transfer faster and to get better throughput? Why don't we have an option 
simillar to "TcpRcvBuf" for sshd ?

Regards,
M.P

----- Original Message ----- 
From: "Chris Rapier" <rapier at psc.edu>
To: <openssh-unix-dev at mindrot.org>
Sent: Saturday, May 20, 2006 3:03 AM
Subject: New HPN Patch Released


> The HPN12 patch available from
> http://www.psc.edu/networking/projects/hpn-ssh addresses performance
> issues with bulk data transfer over high bandwidth delay paths. By
> adjusting internal flow control buffers to better fit the outstanding
> data capacity of the path significant improvements in bulk data
> throughput performance are achieved.
>
> In other words, transfers over the internet are a lot faster with this
> patch. Increase in performance of more than an order of magnitude are
> pretty common. If you make use of the now included NONE cipher I've hit
> data rates of more than 800Mbps between Pittsburgh and Chicago and
> 650Mbps between Pittsburgh and San Diego. The NONE cipher is only used
> during the bulk data transfer and *not* during authentication. This
> version of the patch makes the NONE cipher a server side configuration
> option so you don't have to enable it if you don't want to.
>
> Command line switches have been abandoned in favor of configuration
> options which are outlined below and in the HPN12-README included in the
> patch.
>
> Other versions of the patch showed some performance decrease in local
> area network transfers. I've addressed this by changing the size of one
> of the buffers (thanks Darren) and giving people the option of turning
> off HPN functionality. I've done my best to verify this by running
> several thousand tests and analyzing the results. These results are
> available from http://www.psc.edu/networking/projects/hpn-ssh/results.html
> However, there is always the chance that new problems have been
> introduced that didn't show up in my environment. So while I am
> reasonably confident there are no problems with this patch use al
> appropriate caution especially in production environments.
>
>
> Configuration options for HPN:
> TcpRcvBuf=[int] (KB) client
>       set the TCP socket receive buffer to n Kilobytes. It can be set
> up to the maximum socket size allowed by the system. This is useful in
> situations where the tcp receive window is set low but the maximum
> buffer size is set higher (as is typical). This works on a per TCP
> connection basis. You can also use this to artificially limit the
> transfer rate of the connection. In these cases the throughput will be
> no more than n/RTT. The minimum buffer size is 1KB. Default is the
> current system wide tcp receive buffer size.
>
> TcpRcvBufPoll=[yes/no] client/server
>       enable of disable the polling of the tcp receive buffer through
> the life of the connection. You would want to make sure that this option
> is enabled for systems making use of autotuning kernels (linux 2.4.24+,
> 2.6, MS Vista) default is no.
>
> NoneEnabled=[yes/no] client/server
>       enable or disable the use of the None cipher. Care must always be
> used when enabling this as it will allow users to send data in the
> clear. However, it is important to note that authentication information
> remains encrypted even if this option is enabled. Set to no by default.
>
> NoneSwitch=[yes/no] client
>       Switch the encryption cipher being used to the None cipher after
> authentication takes place. NoneEnabled must be enabled on both the
> client and server side of the connection. The connection attempt will
> fail with an error if a client requests a NoneSwitch from the server
> that does not explicitly have NoneEnabled set to yes. Set to no by 
> default.
>
> HPNDisabled=[yes/no] client/server
>      In some situations, such as transfers on a local area network, the
> impact of the HPN code produces a net decrease in performance. In these
> cases it is helpful to disable the HPN functionality. By default
> HPNDisabled is set to no.
>
> HPNBufferSize=[int] (KB) client/server
>      This is the default buffer size the HPN functionality uses when
> interacting with nonHPN SSH installations. Conceptually this is similar
> to the TcpRcvBuf option as applied to the internal SSH flow control.
> This value can range from 1KB to 14MB (1-14336). Use of oversized or
> undersized buffers can cause performance problems depending on the
> length of the network path. The default size of this buffer is 2MB.
> TcpRcvBufPoll, if set to yes, will override this value. This behaviour
> may change in future versions.
>
>
> Comments, questions, and especially critiques are always welcome.
> Note: I did not attach the patch, as is customary, because its around
> 1900 lines.
>
>
> Chris Rapier
> Network Research & Application Engineer
> Pittsburgh Supercomputing Center
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev 



From rapier at psc.edu  Thu Jun 15 01:20:32 2006
From: rapier at psc.edu (Chris Rapier)
Date: Wed, 14 Jun 2006 11:20:32 -0400
Subject: scp performance during local-to-remote file transfer
In-Reply-To: <009601c68fa4$d8a52d30$180110ac@pomco>
References: <446E39C0.1070901@psc.edu> <009601c68fa4$d8a52d30$180110ac@pomco>
Message-ID: <44902940.2070503@psc.edu>

Hi,

Questions like this should be sent to hpn-ssh at psc.edu since the HPN 
functionality isn't part of the base OpenSSH distribution. You can also 
send the question directly to me because I wrote (in part) the patch.

Chris Rapier

ponraj wrote:
> Hi all,
> 
>>From this version of HPN, SO_RCVBUF can be set with the "TcpRcvBuf" option 
> on the client scp, but the scp launched by the sshd does not call the 
> setsockopt(). As a result the performance of scp is good when download a 
> file from remote-to-local but not when upload a file from local-to-remote. 
> Can you tell me what configuation settings makes the local-to-remote file 
> transfer faster and to get better throughput? Why don't we have an option 
> simillar to "TcpRcvBuf" for sshd ?
> 
> Regards,
> M.P
> 
> ----- Original Message ----- 
> From: "Chris Rapier" <rapier at psc.edu>
> To: <openssh-unix-dev at mindrot.org>
> Sent: Saturday, May 20, 2006 3:03 AM
> Subject: New HPN Patch Released
> 
> 
>> The HPN12 patch available from
>> http://www.psc.edu/networking/projects/hpn-ssh addresses performance
>> issues with bulk data transfer over high bandwidth delay paths. By
>> adjusting internal flow control buffers to better fit the outstanding
>> data capacity of the path significant improvements in bulk data
>> throughput performance are achieved.
>>
>> In other words, transfers over the internet are a lot faster with this
>> patch. Increase in performance of more than an order of magnitude are
>> pretty common. If you make use of the now included NONE cipher I've hit
>> data rates of more than 800Mbps between Pittsburgh and Chicago and
>> 650Mbps between Pittsburgh and San Diego. The NONE cipher is only used
>> during the bulk data transfer and *not* during authentication. This
>> version of the patch makes the NONE cipher a server side configuration
>> option so you don't have to enable it if you don't want to.
>>
>> Command line switches have been abandoned in favor of configuration
>> options which are outlined below and in the HPN12-README included in the
>> patch.
>>
>> Other versions of the patch showed some performance decrease in local
>> area network transfers. I've addressed this by changing the size of one
>> of the buffers (thanks Darren) and giving people the option of turning
>> off HPN functionality. I've done my best to verify this by running
>> several thousand tests and analyzing the results. These results are
>> available from http://www.psc.edu/networking/projects/hpn-ssh/results.html
>> However, there is always the chance that new problems have been
>> introduced that didn't show up in my environment. So while I am
>> reasonably confident there are no problems with this patch use al
>> appropriate caution especially in production environments.
>>
>>
>> Configuration options for HPN:
>> TcpRcvBuf=[int] (KB) client
>>       set the TCP socket receive buffer to n Kilobytes. It can be set
>> up to the maximum socket size allowed by the system. This is useful in
>> situations where the tcp receive window is set low but the maximum
>> buffer size is set higher (as is typical). This works on a per TCP
>> connection basis. You can also use this to artificially limit the
>> transfer rate of the connection. In these cases the throughput will be
>> no more than n/RTT. The minimum buffer size is 1KB. Default is the
>> current system wide tcp receive buffer size.
>>
>> TcpRcvBufPoll=[yes/no] client/server
>>       enable of disable the polling of the tcp receive buffer through
>> the life of the connection. You would want to make sure that this option
>> is enabled for systems making use of autotuning kernels (linux 2.4.24+,
>> 2.6, MS Vista) default is no.
>>
>> NoneEnabled=[yes/no] client/server
>>       enable or disable the use of the None cipher. Care must always be
>> used when enabling this as it will allow users to send data in the
>> clear. However, it is important to note that authentication information
>> remains encrypted even if this option is enabled. Set to no by default.
>>
>> NoneSwitch=[yes/no] client
>>       Switch the encryption cipher being used to the None cipher after
>> authentication takes place. NoneEnabled must be enabled on both the
>> client and server side of the connection. The connection attempt will
>> fail with an error if a client requests a NoneSwitch from the server
>> that does not explicitly have NoneEnabled set to yes. Set to no by 
>> default.
>>
>> HPNDisabled=[yes/no] client/server
>>      In some situations, such as transfers on a local area network, the
>> impact of the HPN code produces a net decrease in performance. In these
>> cases it is helpful to disable the HPN functionality. By default
>> HPNDisabled is set to no.
>>
>> HPNBufferSize=[int] (KB) client/server
>>      This is the default buffer size the HPN functionality uses when
>> interacting with nonHPN SSH installations. Conceptually this is similar
>> to the TcpRcvBuf option as applied to the internal SSH flow control.
>> This value can range from 1KB to 14MB (1-14336). Use of oversized or
>> undersized buffers can cause performance problems depending on the
>> length of the network path. The default size of this buffer is 2MB.
>> TcpRcvBufPoll, if set to yes, will override this value. This behaviour
>> may change in future versions.
>>
>>
>> Comments, questions, and especially critiques are always welcome.
>> Note: I did not attach the patch, as is customary, because its around
>> 1900 lines.
>>
>>
>> Chris Rapier
>> Network Research & Application Engineer
>> Pittsburgh Supercomputing Center
>>
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev 
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From Andrew.Wong at nab.com.au  Tue Jun 20 10:51:25 2006
From: Andrew.Wong at nab.com.au (Andrew.Wong at nab.com.au)
Date: Tue, 20 Jun 2006 10:51:25 +1000
Subject: unable to login with LDAP when set Uselogin to yes
Message-ID: <OFEDD7AC17.034C0F25-ONCA257193.0003ECB7-CA257193.0004B63A@nab.com.au>



Hi,

I am not sure this is a bug in Openssh or not.
I am running Openssh 4.1p1. with openssl 0.9.7g


Scenario:
Due to audit enabled on the system, I will need to set Uselogin to yes so
that audit will track system call.
But when try to login to system with a LDAP user. I get the following.

eg:
[n113839 at r3ent15pc ~]$ ssh tfstst1 -l ntesting1
ntesting1 at tfstst1's password:
Login incorrect
Connection to tfstst1 closed.
[n113839 at r3ent15pc ~]$

My sshd_config:

#       $OpenBSD: sshd_config,v 1.70 2004/12/23 23:11:00 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#Protocol 2,1
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /usr/local/etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /usr/local/etc/ssh_host_rsa_key
#HostKey /usr/local/etc/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

# For this to work you will also need host keys in
/usr/local/etc/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but
set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
# For auditing
UseLogin yes
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem       sftp    /usr/local/libexec/sftp-server


Can you able to help ?

Regards
Andrew


____________________________________________________
Andrew Wong
Enterprise System
Operation Platform Service
Southern Star Technology, National Australia Bank
1/122 Lewis Road,  Wantirna South 3152
Phone: (03) 9886 2844 Ext x32844
Email: andrew_wong at national.com.au (andrew.wong at nab.com.au)
__________________________________________________


National Australia Bank Ltd - ABN 12 004 044 937
This email may contain confidential information. If you are not the intended recipient, please immediately notify us at postmaster at nab.com.au or by replying to the sender, and then destroy all copies of this email. Except where this email indicates otherwise, views expressed in this email are those of the sender and not of National Australia Bank Ltd. Advice in this email does not take account of your objectives, financial situation, or needs. It is important for you to consider these matters and, if the e-mail refers to a product(s), you should read the relevant Product Disclosure Statement(s)/other disclosure document(s) before making any decisions. If you do not want email marketing from us in future, forward this email with "unsubscribe" in the subject line to Unsubscriptions at nab.com.au in order to stop marketing emails from this sender. National Australia Bank Ltd does not represent that this email is free of errors, viruses or interference.



From daniel.ritz at alcatel.ch  Tue Jun 20 19:37:50 2006
From: daniel.ritz at alcatel.ch (RITZ, Daniel)
Date: Tue, 20 Jun 2006 11:37:50 +0200
Subject: [PATCH] openssh pseudo-terminal bug
Message-ID: <D5D72B702DAD5548B221BEB257929AA8140D32@DESTGS0003I.adm.alcatel.com>

hello

short description:
ssh client sends a wrong all-zero terminal info when requesting forced pseudo-terminal
allocation while stdin is not a terminal.
sshd then sets the terminals ospeed to 0 because it receives this information from the
client. on solaris this means that the pseudo-terminal is closed and output of any
remote command is dropped.

longer description:
what we're doing is connecting to from host A to host C via host B. from host
A to host B public key authentication is used, between host B and C password
autentication is used because public key is not possible.
(hostA is either tru64 with commercial SSH (working) or solaris 10 with openssh
 (non-working), hostB is always solaris 10, hostC is an embedded system)

	A -> (public key auth) -> B -> (password auth) -> C

what we're doing from host A is basically:
	ssh -a -x -t -t -l userB hostB ssh -a -x -l userC hostC

this command is inkoved from within a daemon. stdin/stdout of the command
are pipes to the daemon (pipe()/fork()/exec()).

now, when hostA is running commercial SSH everything works fine. but when using
openssh as client no data is received from the ssh invoked on hostB. communication
to hostC is not working.

the ssh client on hostA is sending terminal info towards hostB when requesting
forced pseudo-terminal allocation ( -t -t ). now as long as STDIN on hostA is
a terminal everything works fine. but if STDIN is a pipe the ssh client wrongly
sends an all zero terminal info to the server.

attached is a diff between the server logs on hostB when connecting with commercial
ssh (-) and when connection with openssh (+).

also attached is small patch which fixes the problem. it makes sure that the terminal
info passed to tty_make_modes() is valid and not all zero. it should not change
behaviour in any other case.

comments?

rgds
-daniel

--------------------------------------------------------------
Daniel Ritz
Software Engineer
Alcatel Schweiz AG
OP-CCBS-OSS
Friesenbergstrasse 75, CH-8055 Z?rich

email    daniel.ritz at alcatel.ch
web      http://www.alcatel.ch
--------------------------------------------------------------


From djm at mindrot.org  Wed Jun 21 08:08:47 2006
From: djm at mindrot.org (Damien Miller)
Date: Wed, 21 Jun 2006 08:08:47 +1000
Subject: [PATCH] openssh pseudo-terminal bug
In-Reply-To: <D5D72B702DAD5548B221BEB257929AA8140D32@DESTGS0003I.adm.alcatel.com>
References: <D5D72B702DAD5548B221BEB257929AA8140D32@DESTGS0003I.adm.alcatel.com>
Message-ID: <449871EF.1080308@mindrot.org>

RITZ, Daniel wrote:
> attached is a diff between the server logs on hostB when connecting with commercial
> ssh (-) and when connection with openssh (+).

Your diff was stripped by the mailing list software (it only accepts
attachments that are of MIME-type text/*). Could you please resend it
or create a bug at http://bugzilla.mindrot.org/ and attach it?

Thanks,
Damien Miller



From daniel.ritz at alcatel.ch  Wed Jun 21 17:08:00 2006
From: daniel.ritz at alcatel.ch (Daniel Ritz)
Date: Wed, 21 Jun 2006 09:08:00 +0200
Subject: [PATCH] openssh pseudo-terminal bug
Message-ID: <200606210908.00891.daniel.ritz@alcatel.ch>

> RITZ, Daniel wrote:
> > attached is a diff between the server logs on hostB when connecting with 
> > commercial 
> > ssh (-) and when connection with openssh (+).
> 
> Your diff was stripped by the mailing list software (it only accepts
> attachments that are of MIME-type text/*). Could you please resend it
> or create a bug at http://bugzilla.mindrot.org/ and attach it?
> 

ok, next try with a sane mailer...the log diff as attachement, the patch inline...

rgds
-daniel

--- openssh-4.3p2/ttymodes.c~	2006-06-19 17:39:52.000000000 +0200
+++ openssh-4.3p2/ttymodes.c	2006-06-19 17:41:30.000000000 +0200
@@ -292,6 +292,9 @@
 	}
 
 	if (tiop == NULL) {
+		if (fd == -1)
+			goto end;
+
 		if (tcgetattr(fd, &tio) == -1) {
 			logit("tcgetattr: %.100s", strerror(errno));
 			goto end;
--- openssh-4.3p2/clientloop.c~	2006-06-19 17:27:58.000000000 +0200
+++ openssh-4.3p2/clientloop.c	2006-06-19 17:38:22.000000000 +0200
@@ -1862,6 +1862,7 @@
 	if (want_tty) {
 		struct winsize ws;
 		struct termios tio;
+		struct termios *tmptiop = NULL;
 
 		/* Store window size in the packet. */
 		if (ioctl(in_fd, TIOCGWINSZ, &ws) < 0)
@@ -1873,8 +1874,14 @@
 		packet_put_int(ws.ws_row);
 		packet_put_int(ws.ws_xpixel);
 		packet_put_int(ws.ws_ypixel);
-		tio = get_saved_tio();
-		tty_make_modes(-1, tiop != NULL ? tiop : &tio);
+
+		tmptiop = tiop;
+		if ((tmptiop == NULL) && get_saved_tio_valid()) {
+			tio = get_saved_tio();
+			tmptiop = &tio;
+		}
+
+		tty_make_modes(-1, tmptiop);
 		packet_send();
 		/* XXX wait for reply */
 		c->client_tty = 1;
--- openssh-4.3p2/sshpty.h~	2006-06-19 17:32:21.000000000 +0200
+++ openssh-4.3p2/sshpty.h	2006-06-19 17:32:43.000000000 +0200
@@ -17,6 +17,7 @@
 #ifndef SSHPTY_H
 #define SSHPTY_H
 
+int	 get_saved_tio_valid(void);
 struct termios get_saved_tio(void);
 void	 leave_raw_mode(void);
 void	 enter_raw_mode(void);
--- openssh-4.3p2/sshtty.c~	2006-06-19 17:29:53.000000000 +0200
+++ openssh-4.3p2/sshtty.c	2006-06-19 17:31:29.000000000 +0200
@@ -40,9 +40,16 @@
 #include "sshpty.h"
 #include "log.h"
 
+static int _saved_tio_valid;
 static struct termios _saved_tio;
 static int _in_raw_mode = 0;
 
+
+int get_saved_tio_valid(void)
+{
+	return _saved_tio_valid;
+}
+
 struct termios
 get_saved_tio(void)
 {
@@ -70,6 +77,7 @@
 		return;
 	}
 	_saved_tio = tio;
+	_saved_tio_valid = 1;
 	tio.c_iflag |= IGNPAR;
 	tio.c_iflag &= ~(ISTRIP | INLCR | IGNCR | ICRNL | IXON | IXANY | IXOFF);
 #ifdef IUCLC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log-com-open.diff
Type: text/x-diff
Size: 3178 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060621/1c9317ec/attachment.bin 

From openssh at jdemoor.com  Sun Jun 25 05:10:33 2006
From: openssh at jdemoor.com (Julien Demoor)
Date: Sat, 24 Jun 2006 20:10:33 +0100
Subject: [PATCH] sftp-server Restricted Access
Message-ID: <449D8E29.3040902@jdemoor.com>

Hello,

This patch makes it possible to restrict sftp sessions to a certain
subtree of the file system on a per-Unix account basis. It requires a
program such as rssh or scponly to function. A patch for rssh is also
attached to this email.
The method employed uses realpath() and a string comparison to check
that each file or directory access is allowed.
With this patch, sftp-server takes a command-line argument to indicate
the directory to which the user will be restricted. Without this
argument, the patch has no noticeable effect. Rssh execv()s sftp-server
with this argument if rssh.conf tells it to.

Please note that this patch is written for the portable distribution of
OpenSSH 4.3.

Your comments will be appreciated.


Best regards,

Julien Demoor


-------------- next part --------------
A non-text attachment was scrubbed...
Name: rssh-restricted-patch-1.0.tar.gz
Type: application/gzip
Size: 3356 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060624/e5a21fbd/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sftp-restricted-patch-1.0.tar.gz
Type: application/gzip
Size: 4102 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060624/e5a21fbd/attachment-0001.bin 

From djm at mindrot.org  Sun Jun 25 09:54:54 2006
From: djm at mindrot.org (Damien Miller)
Date: Sun, 25 Jun 2006 09:54:54 +1000
Subject: [PATCH] sftp-server Restricted Access
In-Reply-To: <449D8E29.3040902@jdemoor.com>
References: <449D8E29.3040902@jdemoor.com>
Message-ID: <449DD0CE.9040708@mindrot.org>

Julien Demoor wrote:
> Hello,
> 
> This patch makes it possible to restrict sftp sessions to a certain
> subtree of the file system on a per-Unix account basis. 

There has been a similar patch in bugzilla for a while:

http://bugzilla.mindrot.org/attachment.cgi?id=586

I'm looking at adding the ability to specify commandline arguments to
SubSystem declarations in sshd_config, but it is a little fiddly as any
change has to gracefully cope with forced commands in authorized_keys
files as well as the fairly common practice of making sftp-only accounts
by making sftp-server the user's login shell.

It will be easier when Darren's "Match" stuff is done, because we can
reuse it to do forced-commands in sshd_config.

-d



From rogier at tw.reverze.net  Mon Jun 26 19:40:44 2006
From: rogier at tw.reverze.net (rogier at tw.reverze.net)
Date: Mon, 26 Jun 2006 17:40:44 +0800 (CST)
Subject: Problems with SFTP
Message-ID: <Pine.LNX.4.55.0606261732420.24390@tw.reverze.net>

Guys,

Once again I need some help I hope you can give me. When I try to SFTP to
any of my PCs (also running openssh) from my Xscale (ARM,
big-endian) system sftp segfaults on me. Sftp to the xscale system works
without any problems. I'm using openssl-0.9.8b (with ocf support),
linux-2.6.16 and openssh 4.3p2 on the Xscale system. One of the systems I
try to sftp to runs Openssh 3.7.1p2, with openssl 0.9.7 and linux 2.4.27.
Below is an output of what ssh -v shows. ssh, scp, and sftp to this system
works fine, it's only sftp from this system. I've tried the SNPRINTF workaround,
which doesn't seem to help. Any ideas I can try? Note, the reason it can't
create files is because those files would be created on a rom filesystem.
Modifying the user directory so it creates them on a RAM filesystem
doesn't work either though. Hope you can help.

Regards,

Rogier


Output of ssh -v :
==================
# sftp -v rogier at 192.168.0.34
Connecting to 192.168.0.34...
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Connecting to 192.168.0.34 [192.168.0.34] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
Could not create directory '/.ssh'.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version
OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host '192.168.0.34 (192.168.0.34)' can't be
established.
RSA key fingerprint is a0:7e:f9:7a:f0:3b:b9:f1:6b:97:38:47:85:62:f3:70.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/.ssh/known_hosts).
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/id_rsa
debug1: Trying private key: /.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: password
rogier at 192.168.0.34's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending subsystem: sftp
sftp> ls
Segmentation fault
# debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 3.7 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

#



From hing.fei.wong at lmco.com  Tue Jun 27 03:39:16 2006
From: hing.fei.wong at lmco.com (Wong, Hing Fei)
Date: Mon, 26 Jun 2006 13:39:16 -0400
Subject: OpenSSH compatibility with Tru64 version 4.0F?
Message-ID: <6485684CCD23CE4FA95B7FA02A2A5C0D07257B83@emss04m12.us.lmco.com>

I am just looking for a quick answer as to whether or not OpennSSH is
compatible with Digital Unix Tru64 v 4.0F.  

Hing Fei Wong 
Systems Engineer
Building 100, M1309
Valley Forge, PA
Admin # 4-6242
 

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au]
Sent: Friday, June 23, 2006 3:53 AM
To: Wong, Hing Fei
Cc: www at openbsd.org
Subject: Re: OpenSSH compatibility with Tru64 version 4.0F?

On Thu, Jun 22, 2006 at 02:35:25PM -0400, Wong, Hing Fei wrote:
> I am just looking for a quick answer as to whether or not OpennSSH is 
> compatible with Digital Unix Tru64 v 4.0F.

As far as I know it works but I've never tested it myself.

> Would anyone please let me know who I should be contacting for this 
> question?

I suggest you post your question to the OpenSSH development list
(openssh-unix-dev at mindrot.org) as some of the readers would have first
hand experience with that.

--
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  Tue Jun 27 06:40:23 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Mon, 26 Jun 2006 15:40:23 -0500
Subject: OpenSSH compatibility with Tru64 version 4.0F?
In-Reply-To: <6485684CCD23CE4FA95B7FA02A2A5C0D07257B83@emss04m12.us.lmco.com>
References: <6485684CCD23CE4FA95B7FA02A2A5C0D07257B83@emss04m12.us.lmco.com>
Message-ID: <20060626204023.GG569793@hiwaay.net>

Once upon a time, Wong, Hing Fei <hing.fei.wong at lmco.com> said:
> I am just looking for a quick answer as to whether or not OpennSSH is
> compatible with Digital Unix Tru64 v 4.0F.  

It should be.  I'm using it on 4.0G and 5.1B (and there's not a lot of
difference between 4.0F and 4.0G).
-- 
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 Andrew.Wong at nab.com.au  Wed Jun 28 09:25:59 2006
From: Andrew.Wong at nab.com.au (Andrew.Wong at nab.com.au)
Date: Wed, 28 Jun 2006 09:25:59 +1000
Subject: unable to login with LDAP when set Uselogin to yes
Message-ID: <OFEDD7AC17.034C0F25-ONCA257193.0003ECB7-CA25719A.0080B9E6@nab.com.au>



Hi,

I am not sure this is a bug in Openssh or not.
I am running Openssh 4.1p1. with openssl 0.9.7g


Scenario:
Due to audit enabled on the system, I will need to set Uselogin to yes so
that audit will track system call.
But when try to login to system with a LDAP user. I get the following.

eg:
[n113839 at r3ent15pc ~]$ ssh tfstst1 -l ntesting1
ntesting1 at tfstst1's password:
Login incorrect
Connection to tfstst1 closed.
[n113839 at r3ent15pc ~]$

My sshd_config:

#       $OpenBSD: sshd_config,v 1.70 2004/12/23 23:11:00 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#Protocol 2,1
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /usr/local/etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /usr/local/etc/ssh_host_rsa_key
#HostKey /usr/local/etc/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

# For this to work you will also need host keys in
/usr/local/etc/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but
set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
# For auditing
UseLogin yes
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem       sftp    /usr/local/libexec/sftp-server


Can you able to help ?

Regards
Andrew


____________________________________________________
Andrew Wong
Enterprise System
Operation Platform Service
Southern Star Technology, National Australia Bank
1/122 Lewis Road,  Wantirna South 3152
Phone: (03) 9886 2844 Ext x32844
Email: andrew_wong at national.com.au (andrew.wong at nab.com.au)
__________________________________________________


National Australia Bank Ltd - ABN 12 004 044 937
This email may contain confidential information. If you are not the intended recipient, please immediately notify us at postmaster at nab.com.au or by replying to the sender, and then destroy all copies of this email. Except where this email indicates otherwise, views expressed in this email are those of the sender and not of National Australia Bank Ltd. Advice in this email does not take account of your objectives, financial situation, or needs. It is important for you to consider these matters and, if the e-mail refers to a product(s), you should read the relevant Product Disclosure Statement(s)/other disclosure document(s) before making any decisions. If you do not want email marketing from us in future, forward this email with "unsubscribe" in the subject line to Unsubscriptions at nab.com.au in order to stop marketing emails from this sender. National Australia Bank Ltd does not represent that this email is free of errors, viruses or interference.



From petesea at bigfoot.com  Wed Jun 28 10:50:27 2006
From: petesea at bigfoot.com (Dan Peterson)
Date: Tue, 27 Jun 2006 17:50:27 -0700 (Pacific Daylight Time)
Subject: [PATCH] sftp-server Restricted Access
In-Reply-To: <449DD0CE.9040708@mindrot.org>
References: <449DD0CE.9040708@mindrot.org>
Message-ID: <Pine.WNT.4.64.0606271705590.2808@oberon.home.org>

On Sun, 25 Jun 2006, Damien Miller wrote:

> Julien Demoor wrote:
>> Hello,
>>
>> This patch makes it possible to restrict sftp sessions to a certain
>> subtree of the file system on a per-Unix account basis.
>
> There has been a similar patch in bugzilla for a while:
>
> http://bugzilla.mindrot.org/attachment.cgi?id=586
>
> I'm looking at adding the ability to specify commandline arguments to 
> SubSystem declarations in sshd_config, but it is a little fiddly as any 
> change has to gracefully cope with forced commands in authorized_keys 
> files as well as the fairly common practice of making sftp-only accounts 
> by making sftp-server the user's login shell.
>
> It will be easier when Darren's "Match" stuff is done, because we can
> reuse it to do forced-commands in sshd_config.

Can you expand on "forced-commands in sshd_config" a bit?

I'm curious, because I'm wondering if it might be able replace the custom 
changes I've made....

I recently added support for authorized_keys via GSSAPI/Kerberos 
authentication... mainly so I could use the "command=" option.  Then, I 
realized, for my purpose, it would be better to just have a global 
"ForcedCommand" defined in sshd_config, so I added that as well.

My reason for doing this is because I'm running sshd on a non-standard 
port for CVS/Subversion access.  My ForcedCommand makes sure that only 
CVS/Subversion related commands can be run.

A couple of problems I ran into with the global forced command...

   1) I had to add an sshd_config option to ignore the user's login shell 
when exec'ing the forced command.  The problem here is that the user's 
login shell could be something like "/bin/false".  If this option is set, 
then I simply exec the forced command directly, rather then via the login 
shell.

   2) I also had to add an sshd_config option to ignore the user's home 
directory.  In my case, these same user's with a login shell of /bin/false 
(which is the majority of users) don't have a real home directory either.



From petesea at bigfoot.com  Wed Jun 28 11:07:05 2006
From: petesea at bigfoot.com (Dan Peterson)
Date: Tue, 27 Jun 2006 18:07:05 -0700 (Pacific Daylight Time)
Subject: Tracking local changes in CVS
Message-ID: <Pine.WNT.4.64.0606271120300.2808@oberon.home.org>

I'm tracking some custom OpenSSH changes (based on 4.3p2) in a local CVS 
repository and have run into a few problems... mainly (I believe) because 
of the .cvsignore files.

Keep in mind the main idea here is to commit the OpenSSH source without 
changes, tag, then add my custom changes and add a new tag.  I can 
probably fix these by making local modes, but I'm just wondering if there 
are specific reasons importing the source without changes doesn't work.

1) .cvsignore includes "configure" and "config.h.in", which means those 
aren't available when I checkout my imported OpenSSH tree.  Is the 
"standard" approach to use the automake stuff to generate these, ie:

    aclocal
    autoconf
    autoheader
    automake

or some combination of those?   When I try to use those as listed above I 
get errors when running automake:

    configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found.
    configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE,
    configure.ac: that aclocal.m4 is present in the top-level directory,
    configure.ac: and that aclocal.m4 was recently regenerated (using aclocal).
    configure.ac: required file `./missing' not found
    automake: no `Makefile.am' found for any configure output

This is with automake 1.9.5 and autoconf 2.59.

The error appears to be that "AM_INIT_AUTOMAKE" is not in configure.ac. 
Is it supposed to be?

I must admit I had to chuckle at "required file ./missing not found"... 1) 
because "./missing" is required and 2) that "/.missing" was not found. :-)

2) scard/.cvsignore includes "Ssh.bin" AND scard/Makefile.in has the rule 
for target Ssh.bin commented out.  This means "Ssh.bin" is not checked 
out (since it was never checked in) and it doesn't get generated (without 
uncommenting the section in Makefile.in that is).  This causes problems 
when running "make install" even if "Smartcard" support is disabled.  Is 
there some reason the rule for Ssh.bin is commented out?   And should this 
even be run if Smartcard support is disabled?

3) Ok... this last one isn't really a problem with importing into CVS...

If the --with-privsep-path=DIR configure option is used and the DIR 
doesn't exist when "make tests" is run, then "make tests" will fail. 
Shouldn't "make tests" be trying to use a privsep dir inside the test area 
rather then the REAL privsep dir?   Main problem I see with this is if the 
source is built as someone other then root... which means even if "make 
tests" created it's own privsep dir it wouldn't be owned by root.   In 
that case, would it be possible for "make tests" to skip the privsep tests 
and continue rather then failing all tests?



From bob at proulx.com  Wed Jun 28 19:20:22 2006
From: bob at proulx.com (Bob Proulx)
Date: Wed, 28 Jun 2006 03:20:22 -0600
Subject: Tracking local changes in CVS
In-Reply-To: <Pine.WNT.4.64.0606271120300.2808@oberon.home.org>
References: <Pine.WNT.4.64.0606271120300.2808@oberon.home.org>
Message-ID: <20060628092022.GC3148@dementia.proulx.com>

Dan Peterson wrote:
> I'm tracking some custom OpenSSH changes (based on 4.3p2) in a local CVS 
> repository and have run into a few problems... mainly (I believe) because 
> of the .cvsignore files.

It is a little odd that the .cvsignore file is distributed in the
distribution file.  For what you are doing you may want to modify the
.cvsignore file.

> Keep in mind the main idea here is to commit the OpenSSH source without 
> changes, tag, then add my custom changes and add a new tag.  I can 
> probably fix these by making local modes, but I'm just wondering if there 
> are specific reasons importing the source without changes doesn't work.

I am not speaking as an ssh developer (I'm not) but as an ssh user and
as a developer of other software which uses the autotools.

> 1) .cvsignore includes "configure" and "config.h.in", which means those 
> aren't available when I checkout my imported OpenSSH tree.  Is the 
> "standard" approach to use the automake stuff to generate these, ie:

Generally generated files are not checked into version control.
(There are other opinions on this.  But I disagree with them. :-)
Being generated they are more like object files.  Developers are
expected to have correct versions of the build tools to generate those
files.

But since you are using the distribution image you should be able to
use the files that are distributed without needing to generate your
own.  Unless you are also modifying those files too.  But if not then
you shouldn't need to rebuild them.

>     aclocal
>     autoconf
>     autoheader
>     automake
> 
> or some combination of those?

You are doing too much.  I think only autoconf is needed to generate
the configure script.  In any case openssh does not use automake.
Trying to use that is causing you all kinds of problems.

> The error appears to be that "AM_INIT_AUTOMAKE" is not in configure.ac. 
> Is it supposed to be?

No.  There are no Makefile.am files.  The Makefile.in is supplied.

> I must admit I had to chuckle at "required file ./missing not found"... 1) 
> because "./missing" is required and 2) that "/.missing" was not found. :-)

You won't need the automake 'missing' file.  (In a project using
automake you would run 'automake --copy' or 'autoreconf --install' or
similar to have the framework files copied into the project if they
are not there.  The 'missing' script is one of those.)

Bob



From russ at sludge.net  Fri Jun 30 02:05:12 2006
From: russ at sludge.net (Russell Ruby)
Date: Thu, 29 Jun 2006 09:05:12 -0700
Subject: SunOS 4.1.4 "configure: WARNING" for sys/audit.h and sys/dir.h
Message-ID: <200606291605.k5TG5C4b000851@mfg.private.sludge.net>


Openssh:  	openssh-SNAP-20060626  and  openssh-4.3p2
System:		SunOS 4.1.4
Compiler:	gcc 2.8.1

CONFIGURE PROBLEM:
The warnings included below occur because of missing include files for each
compilation test.

Specifically:
   sys/audit.h  needs   sys/types.h  and  sys/label.h
   sys/dir.h    needs   sys/types.h


PARTIAL FIX:

   Most of the machinery for the sys/types.h dependency is already present.
   One possibility is to add the line "AC_DEFINE(HAVE_SYS_TYPES_H)" to
   "configure.ac" as follows for openssh-SNAP-20060626/configure.ac:
 
    429 *-*-sunos4*)
    430         CPPFLAGS="$CPPFLAGS -DSUNOS4"
    431         AC_CHECK_FUNCS(getpwanam)
    432         AC_DEFINE(PAM_SUN_CODEBASE)
+ add this +	AC_DEFINE(HAVE_SYS_TYPES_H)
    433         conf_utmp_location=/etc/utmp
    434         conf_wtmp_location=/var/adm/wtmp
    435         conf_lastlog_location=/var/adm/lastlog
    436         AC_DEFINE(USE_PIPES)
    437         ;;

   However, the sys/label.h dependency would take a bit more and I'm
   in no hurry to trip over sys/audit.h and sys/labels.h anyway...
   Hey - I know SunOS4.1.4 is busted - but it still works for me :)

CONFIGURE WARNINGS:

checking sys/audit.h usability... no
checking sys/audit.h presence... yes
configure: WARNING: sys/audit.h: present but cannot be compiled
configure: WARNING: sys/audit.h:     check for missing prerequisite headers?
configure: WARNING: sys/audit.h: see the Autoconf documentation
configure: WARNING: sys/audit.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/audit.h: proceeding with the preprocessor's result
configure: WARNING: sys/audit.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------- ##
configure: WARNING:     ## Report this to openssh-unix-dev at mindrot.org ##
configure: WARNING:     ## ------------------------------------------- ##
checking for sys/audit.h... yes
...
checking sys/dir.h usability... no
checking sys/dir.h presence... yes
configure: WARNING: sys/dir.h: present but cannot be compiled
configure: WARNING: sys/dir.h:     check for missing prerequisite headers?
configure: WARNING: sys/dir.h: see the Autoconf documentation
configure: WARNING: sys/dir.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/dir.h: proceeding with the preprocessor's result
configure: WARNING: sys/dir.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------- ##
configure: WARNING:     ## Report this to openssh-unix-dev at mindrot.org ##
configure: WARNING:     ## ------------------------------------------- ##
checking for sys/dir.h... yes





From russ at sludge.net  Fri Jun 30 09:22:20 2006
From: russ at sludge.net (Russell Ruby)
Date: Thu, 29 Jun 2006 16:22:20 -0700
Subject: openssh-4.3p2/openssh-SNAP-20060626 build failure for SunOS4.1.4
Message-ID: <200606292322.k5TNMKTk006771@private.sludge.net>


Openssh:        openssh-4.3p2 or openssh-SNAP-20060626
System:         SunOS 4.1.4
Compiler:       gcc 2.8.1

BUILD FAILURE and fix:

../../openbsd-compat/bsd-snprintf.c:792: conflicting types for `snprintf'
../../openbsd-compat/../openbsd-compat/openbsd-compat.h:156: previous declaration of `snprintf'
gmake[1]: *** [bsd-snprintf.o] Error 1
gmake[1]: Leaving directory `/mfg/sd2f/src/security/openssh/openssh-4.3p2/objdir/openbsd-compat'
gmake: *** [openbsd-compat/libopenbsd-compat.a] Error 2


Both versions have the same parameter type conflict between the
declaration of snprintf found in "./openbsd-compat/openbsd-compat.h
and the definition of snprintf found in "./openbsd-compat/bsd-snprintf.c".
(conflict: for SunOS SNPRINTF_CONST has a value which is not "const")

Fix by updating the declaration found in openbsd-compat.h to be
consistent with the previously altered bsd-snprintf.c:

*** openbsd-compat/openbsd-compat.h.orig     Fri Dec 30 21:33:37 2005
--- openbsd-compat/openbsd-compat.h     Wed Jun 28 13:45:49 2006
***************
*** 153,159 ****
  /* #include <sys/types.h> XXX needed? For size_t */
  
  #ifndef HAVE_SNPRINTF
! int snprintf(char *, size_t, const char *, ...);
  #endif 
  
  #ifndef HAVE_STRTOLL
--- 153,159 ----
  /* #include <sys/types.h> XXX needed? For size_t */
  
  #ifndef HAVE_SNPRINTF
! int snprintf(char *, size_t, SNPRINTF_CONST char *, ...);
  #endif 
  
  #ifndef HAVE_STRTOLL



From dtucker at zip.com.au  Fri Jun 30 11:33:14 2006
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 30 Jun 2006 11:33:14 +1000
Subject: SunOS 4.1.4 "configure: WARNING" for sys/audit.h and sys/dir.h
In-Reply-To: <200606291605.k5TG5C4b000851@mfg.private.sludge.net>
References: <200606291605.k5TG5C4b000851@mfg.private.sludge.net>
Message-ID: <20060630013314.GB18892@gate.dtucker.net>

On Thu, Jun 29, 2006 at 09:05:12AM -0700, Russell Ruby wrote:
> 
> Openssh:  	openssh-SNAP-20060626  and  openssh-4.3p2
> System:		SunOS 4.1.4
> Compiler:	gcc 2.8.1
> 
> CONFIGURE PROBLEM:
> The warnings included below occur because of missing include files for each
> compilation test.
> 
> Specifically:
>    sys/audit.h  needs   sys/types.h  and  sys/label.h
>    sys/dir.h    needs   sys/types.h
> 
> 
> PARTIAL FIX:
> 
>    Most of the machinery for the sys/types.h dependency is already present.
>    One possibility is to add the line "AC_DEFINE(HAVE_SYS_TYPES_H)" to
>    "configure.ac" as follows for openssh-SNAP-20060626/configure.ac:
>  
>     429 *-*-sunos4*)
>     430         CPPFLAGS="$CPPFLAGS -DSUNOS4"
>     431         AC_CHECK_FUNCS(getpwanam)
>     432         AC_DEFINE(PAM_SUN_CODEBASE)
> + add this +	AC_DEFINE(HAVE_SYS_TYPES_H)

That's odd, <sys/types.h> is one of the first tests autoconf does so it
should already be defined.  Do you see "checking for sys/types.h..." near
the start of the configure output?

As for the rest, does the following resolve it?

Index: configure.ac
===================================================================
RCS file: /var/cvs/openssh/configure.ac,v
retrieving revision 1.343
diff -u -p -r1.343 configure.ac
--- configure.ac	27 Jun 2006 01:20:29 -0000	1.343
+++ configure.ac	30 Jun 2006 01:29:18 -0000
@@ -705,11 +705,11 @@ AC_CHECK_HEADERS( \
 	stdint.h \
 	string.h \
 	strings.h \
-	sys/audit.h \
 	sys/bitypes.h \
 	sys/bsdtty.h \
 	sys/cdefs.h \
 	sys/dir.h \
+	sys/label.h \
 	sys/mman.h \
 	sys/ndir.h \
 	sys/prctl.h \
@@ -752,6 +752,16 @@ AC_CHECK_HEADERS(sys/ptms.h, [], [], [
 # login_cap.h requires sys/types.h on NetBSD
 AC_CHECK_HEADERS(login_cap.h, [], [], [
 #include <sys/types.h>
+])
+
+# sys/audit.h requires sys/types.h and sys/label.h on SunOS4
+AC_CHECK_HEADERS(sys/audit.h, [], [], [
+#ifdef HAVE_SYS_TYPES_H
+# include <sys/types.h>
+#endif
+#ifdef HAVE_SYS_LABEL_H
+# include <sys/label.h>
+#endif
 ])
 
 # Checks for libraries.

-- 
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 neda_s at nifty.ne.jp  Fri Jun 30 20:40:32 2006
From: neda_s at nifty.ne.jp (neda_s at nifty.ne.jp)
Date: Fri, 30 Jun 2006 19:40:32 +0900
Subject: Ret: Problems with SFTP
Message-ID: <200606301040.AA00052@0dhzej3d7hh91pv.nifty.com>

Hi,
Segfaults happens to access memory that was not allocated using xmalloc, 
to read/write from the file without the fileopen function, etc. I suggest 
you check what codes in openssh 4.3p2 happen Segfaults. 
Segfaults happens when SFTP works as a client. You embed the SNPRINTF statement 
in the openssh as a tracer. Could you modify the program and run it 
on your development environment? The program moves the control 
to the statement "case I_LS:" at the function "parse_dispatch_command" 
in the source file "sftp.c" when the user enters the command "ls". 
I suggest you embed the SNPRINTF statement here at the first.
Regards,

Tomo

rogier at tw.reverze.net wrote:
>Guys,
>
>Once again I need some help I hope you can give me. When I try to SFTP to
>any of my PCs (also running openssh) from my Xscale (ARM,
>big-endian) system sftp segfaults on me. Sftp to the xscale system works
>without any problems. I'm using openssl-0.9.8b (with ocf support),
>linux-2.6.16 and openssh 4.3p2 on the Xscale system. One of the systems I
>try to sftp to runs Openssh 3.7.1p2, with openssl 0.9.7 and linux 2.4.27.
>Below is an output of what ssh -v shows. ssh, scp, and sftp to this system
>works fine, it's only sftp from this system. I've tried the SNPRINTF workaround,
>which doesn't seem to help. Any ideas I can try? Note, the reason it can't
>create files is because those files would be created on a rom filesystem.
>Modifying the user directory so it creates them on a RAM filesystem
>doesn't work either though. Hope you can help.
>
>Regards,
>
>Rogier
>