From lists1 at sonous.com  Thu Jan  1 04:50:51 2004
From: lists1 at sonous.com (Lev Lvovsky)
Date: Wed, 31 Dec 2003 09:50:51 -0800
Subject: chroot + ssh concerns
In-Reply-To: <20031231050901.GE19576@qwestip.net>
References: <F4C9332C-3B30-11D8-AEEC-000A959DCC8C@sonous.com>
	<20031231050901.GE19576@qwestip.net>
Message-ID: <DFCDBEBA-3BB9-11D8-961A-000A959DCC8C@sonous.com>

Much appreciated, but it'd requires that we configure and setup 
something that opens yet another port on our boxes.  Ssh + chroot or 
ssh + some restricted shell (my preference), fulfills all of our needs. 
  It's a matter of determining which is the better of the two.

thanks!
-lev


On Dec 30, 2003, at 9:09 PM, Asif Iqbal wrote:
> Check this out
>
> http://cr.yp.to/publicfile.html
>
> Same guy who wrote qmail
>
> -- 
> Asif Iqbal
> http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x8B686E08
> There's no place like 127.0.0.1



From lists1 at sonous.com  Thu Jan  1 05:09:19 2004
From: lists1 at sonous.com (Lev Lvovsky)
Date: Wed, 31 Dec 2003 10:09:19 -0800
Subject: chroot + ssh concerns
In-Reply-To: <Pine.BSO.4.44.0312302012160.27695-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0312302012160.27695-100000@etoh.eviladmin.org>
Message-ID: <74196DEC-3BBC-11D8-961A-000A959DCC8C@sonous.com>


Ben, thanks for the help so far - replies below.

On Dec 30, 2003, at 6:21 PM, Ben Lindstrom wrote:
> <shrug> I can't justify anything not knowing your environment, but for 
> me
> custom OpenSSH (or any other package) is a PITA to maintain internal, 
> and
> when you have problems people tend to shy away from helping or require 
> you
> to prove it with clean code.

very true.

specifically we're looking to create a software distribution system 
that works by way of a central "push" server, and cron jobs running on 
the destination servers which scan a directory where packages and 
scripts are dumped off.  scponly or rssh would be ideal, but of course, 
that brings up security issues with those packages :\

> That right there is a solid reason to avoid patching with unapproved
> patches.

As I understand it, there was  a patch that was in the contrib section 
of the ssh source a while back - any reason why this was taken out?  
compatibility with platforms?

> Also, it is easier to verify small programs then patches to large code
> bases.  It is very much the case when the people auditing the code has 
> not
> spent enough time understand the project, and OpenSSH is a lot of code 
> to
> audit and understand what affects a patch may have on it.

No doubt.  Initially I was averse to the patching concept mainly 
because of the need to roll our own packages (as opposed to those 
provided by the distro) - seeing however, that the ssh contrib 
directory provides scripts to build the packages, patching and rolling 
them wouldn't be a problem.  Now my main issue is if/when a 
vulnerability gets announced, we're at the mercy of the patch 
developer.

thanks for your advice!
-lev



From scott.burch at camberwind.com  Thu Jan  1 05:25:24 2004
From: scott.burch at camberwind.com (Scott Burch)
Date: Wed, 31 Dec 2003 18:25:24 -0000
Subject: chroot + ssh concerns
In-Reply-To: <74196DEC-3BBC-11D8-961A-000A959DCC8C@sonous.com>
References: <Pine.BSO.4.44.0312302012160.27695-100000@etoh.eviladmin.org>
	<74196DEC-3BBC-11D8-961A-000A959DCC8C@sonous.com>
Message-ID: <1072895125.7928.2.camel@localhost>

Lev,

Have you considered using cfengine? Take a look at the following
article, which discusses using cfengine and a database to maintain
software/patches across multiple UNIX platforms, etc.

http://www.usenix.org/publications/library/proceedings/lisa2000/full_papers/ressman/ressman.pdf

-Scott

On Wed, 2003-12-31 at 12:09, Lev Lvovsky wrote:
> Ben, thanks for the help so far - replies below.
> 
> On Dec 30, 2003, at 6:21 PM, Ben Lindstrom wrote:
> > <shrug> I can't justify anything not knowing your environment, but for 
> > me
> > custom OpenSSH (or any other package) is a PITA to maintain internal, 
> > and
> > when you have problems people tend to shy away from helping or require 
> > you
> > to prove it with clean code.
> 
> very true.
> 
> specifically we're looking to create a software distribution system 
> that works by way of a central "push" server, and cron jobs running on 
> the destination servers which scan a directory where packages and 
> scripts are dumped off.  scponly or rssh would be ideal, but of course, 
> that brings up security issues with those packages :\
> 
> > That right there is a solid reason to avoid patching with unapproved
> > patches.
> 
> As I understand it, there was  a patch that was in the contrib section 
> of the ssh source a while back - any reason why this was taken out?  
> compatibility with platforms?
> 
> > Also, it is easier to verify small programs then patches to large code
> > bases.  It is very much the case when the people auditing the code has 
> > not
> > spent enough time understand the project, and OpenSSH is a lot of code 
> > to
> > audit and understand what affects a patch may have on it.
> 
> No doubt.  Initially I was averse to the patching concept mainly 
> because of the need to roll our own packages (as opposed to those 
> provided by the distro) - seeing however, that the ssh contrib 
> directory provides scripts to build the packages, patching and rolling 
> them wouldn't be a problem.  Now my main issue is if/when a 
> vulnerability gets announced, we're at the mercy of the patch 
> developer.
> 
> thanks for your advice!
> -lev
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
-- 
Scott Burch <scott.burch at camberwind.com>



From mouring at etoh.eviladmin.org  Thu Jan  1 05:52:52 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 31 Dec 2003 12:52:52 -0600 (CST)
Subject: chroot + ssh concerns
In-Reply-To: <74196DEC-3BBC-11D8-961A-000A959DCC8C@sonous.com>
Message-ID: <Pine.BSO.4.44.0312311241100.27695-100000@etoh.eviladmin.org>



On Wed, 31 Dec 2003, Lev Lvovsky wrote:
> Ben, thanks for the help so far - replies below.
>
> On Dec 30, 2003, at 6:21 PM, Ben Lindstrom wrote:
[.. No one can you with auditing then you =) ..]

> > That right there is a solid reason to avoid patching with unapproved
> > patches.
>
> As I understand it, there was  a patch that was in the contrib section
> of the ssh source a while back - any reason why this was taken out?
> compatibility with platforms?
>

1. It was never upkept (It was always fixed after a release which of
course is to late to be useful =).

2. A correction in policy that is more in line with OpenBSD's policy of
"no patches or features not accepted in the mainstream tree will be
provided."


> > Also, it is easier to verify small programs then patches to large code
> > bases.  It is very much the case when the people auditing the code has
> > not
> > spent enough time understand the project, and OpenSSH is a lot of code
> > to
> > audit and understand what affects a patch may have on it.
>
> No doubt.  Initially I was averse to the patching concept mainly
> because of the need to roll our own packages (as opposed to those
> provided by the distro) - seeing however, that the ssh contrib
> directory provides scripts to build the packages, patching and rolling
> them wouldn't be a problem.  Now my main issue is if/when a
> vulnerability gets announced, we're at the mercy of the patch
> developer.
>

Depend on who your distro is.  Some groups are good at security and
others.. <shrug>  Are not.

This comes down to your security and adminstration policies.   And in some
respects how well you sleep at night.

Quite honestly if you can't trust your vendor to provide you with timely
security patches you can't trust your systems.

> thanks for your advice!
> -lev
>

Good luck.

- Ben
11 hours 18 minutes until we get to leave this horrible year and move to
the next horrible year.



From johnmay at llnl.gov  Thu Jan  1 06:45:42 2004
From: johnmay at llnl.gov (John May)
Date: Wed, 31 Dec 2003 11:45:42 -0800
Subject: Problem with port forwarding on Mac OS X
Message-ID: <EB489310-3BC9-11D8-AB42-000A95D788FA@llnl.gov>

I have found a problem with port forwarding on Mac OS X (10.2 and 
10.3).  When I forward
a port to localhost, as in

ssh -R 40404:localhost:40404 somehost

...and the remote system makes a connection on this port, I get the 
message

getsockopt TCP_NODELAY: Connection reset by peer

I have tracked this down to the loop in connect_to that gets a list of 
addresses from
getaddrinfo and tries them one after another.  When "localhost" is the 
host name.
getaddrinfo returns an IPv6 address, followed by an IPv4 address.  The 
loop is
designed to try connections until it finds one that works.  
Unfortunately, on my system,
the IPv6 connection returns EINPROGRESS, which is interpreted as 
success.  This
causes the retry loop to exit, and the next thing that happens is a 
call to set_nodelay
which fails when the IPv6 connection is not available.

I think it would be better to put the call to set_nodelay inside the 
retry loop.  Then if the
call fails for IPv6, ssh can revert to IPv4.  Of course, the error 
report in the call to
set_nodelay would have to be suppressed is the connection was going to 
be retried,
and the function would need to return a value to indicate success or 
failure.

A fix seems relatively straightforward, but I would rather not attempt 
to write the patch
myself, since changing the way set_nodelay reports errors would affect 
other routines
that call it, and I am not familiar enough with them to mess around 
there.

Two workarounds for this problem are: 1) force only IPv4 connections by 
setting -4 on
the command line or the corresponding option in the config file.  
However, this isn't
portable to other ssh versions, and my code needs to work with them. 2) 
specify the
local host as "127.0.0.1" instead of "localhost".  This is what I'm 
doing, and it seems to
work.

John



From lists1 at sonous.com  Thu Jan  1 06:47:41 2004
From: lists1 at sonous.com (Lev Lvovsky)
Date: Wed, 31 Dec 2003 11:47:41 -0800
Subject: chroot + ssh concerns
In-Reply-To: <1072895125.7928.2.camel@localhost>
References: <Pine.BSO.4.44.0312302012160.27695-100000@etoh.eviladmin.org>
	<74196DEC-3BBC-11D8-961A-000A959DCC8C@sonous.com>
	<1072895125.7928.2.camel@localhost>
Message-ID: <32187AD5-3BCA-11D8-961A-000A959DCC8C@sonous.com>


Many thanks for the link - the doc basically addresses some of our  
issues.

The decision to go with a pull system instead of a push system is  
something we'd discussed.  However, since the outage of the push server  
in our case wouldn't be catasrophic, and would allow for simpler  
administration, we've decided to at least go in that direction in the  
beginning.

cfengine might be what we need unless we decide to roll our own.

thanks again,
-lev

On Dec 31, 2003, at 10:25 AM, Scott Burch wrote:

> Lev,
>
> Have you considered using cfengine? Take a look at the following
> article, which discusses using cfengine and a database to maintain
> software/patches across multiple UNIX platforms, etc.
>
> http://www.usenix.org/publications/library/proceedings/lisa2000/ 
> full_papers/ressman/ressman.pdf
>
> -Scott



From lists1 at sonous.com  Thu Jan  1 07:10:37 2004
From: lists1 at sonous.com (Lev Lvovsky)
Date: Wed, 31 Dec 2003 12:10:37 -0800
Subject: chroot + ssh concerns
In-Reply-To: <Pine.BSO.4.44.0312311241100.27695-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0312311241100.27695-100000@etoh.eviladmin.org>
Message-ID: <66305E6E-3BCD-11D8-961A-000A959DCC8C@sonous.com>

> Good luck.

thanks.

what I'm planning on doing at this point is compiling all of the 
various options (openssh + chroot patch, scponly, rssh), and seeing how 
they perform.

> - Ben
> 11 hours 18 minutes until we get to leave this horrible year and move 
> to
> the next horrible year.

clearly, to be a security developer one needs to be pessimistic ;)

-lev



From bob at proulx.com  Thu Jan  1 08:54:34 2004
From: bob at proulx.com (Bob Proulx)
Date: Wed, 31 Dec 2003 14:54:34 -0700
Subject: chroot + ssh concerns
In-Reply-To: <32187AD5-3BCA-11D8-961A-000A959DCC8C@sonous.com>
References: <Pine.BSO.4.44.0312302012160.27695-100000@etoh.eviladmin.org>
	<74196DEC-3BBC-11D8-961A-000A959DCC8C@sonous.com>
	<1072895125.7928.2.camel@localhost>
	<32187AD5-3BCA-11D8-961A-000A959DCC8C@sonous.com>
Message-ID: <20031231215434.GC18420@misery.proulx.com>

Lev Lvovsky wrote:
> Scott Burch wrote:
> > http://www.usenix.org/publications/library/proceedings/lisa2000/full_papers/ressman/ressman.pdf
>
> The decision to go with a pull system instead of a push system is  
> something we'd discussed.  However, since the outage of the push server  
> in our case wouldn't be catasrophic, and would allow for simpler  
> administration, we've decided to at least go in that direction in the  
> beginning.

If you are just now walking down the path of building an
infrastructure to manage your systems then I highly recommend the
following paper.  I administer a large number of machines (is greater
than 2000 HP-UX and Linux hosts a large number?) and had independently
discovered the benefits of the pull method.  But Steve Traugott
discusses it very well here.  I wish I had read it before because it
would have saved me time learning the lesson.

  http://www.infrastructures.org/papers/bootstrap/bootstrap.html
  http://www.infrastructures.org/bootstrap/pushpull.shtml

What I do is "push" a "pull" when I want something to happen right
now.  That retains the best of both worlds.

Previous to knowing about these references I had implemented scripts
to check for being out of network resources, retrying dead hosts,
forking and running in parallel, etc.  Upon reading these references
later (after converting to a pull system myself) I was sure the author
had been a fly on the wall of my lab during the push times because the
convergence of problems and solutions was uncanny.

You might want to read the mailing list archives at the location below
and possibly strike up a discussion about infrastructure management on
that list.

  http://mailman.terraluna.org/pipermail/infrastructures/

Bob



From dtucker at zip.com.au  Thu Jan  1 10:19:33 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 01 Jan 2004 10:19:33 +1100
Subject: OpenSSH - forced command - no-pty issue
In-Reply-To: <026801c3cf94$801a1bd0$230110ac@kurco>
References: <FE6B88CC9D2BD311AD120008C7B3AF87081EE0A1@phsexch3.mgh.harvard.edu>
	<3FE78124.9070902@zip.com.au>
	<026801c3cf94$801a1bd0$230110ac@kurco>
Message-ID: <3FF35985.6040005@zip.com.au>

You do not need to send bug reports directly to me, I read the list.

Kumaresh wrote:
> We have an issue where forced commands are left hanging on the sshd server
> running whenever the ssh client disconnects.
[snip]
> Is there a way, which we can notify and kill  the commands or child
> processes when the sshd is terminated.?

This sounds like bug #396.  For details and patch see:
http://bugzilla.mindrot.org/show_bug.cgi?id=396

-- 
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 zeffielist at ecio.net  Thu Jan  1 15:00:52 2004
From: zeffielist at ecio.net (Zeffie)
Date: Wed, 31 Dec 2003 23:00:52 -0500
Subject: .ssh/: Is a directory
Message-ID: <002301c3d01b$d9ccd500$1109060a@yourivc7xrn4yf>

I'm depending on scp to create the .ssh directory (which is does) but it
can't use the directory it just created in the current session thus the
"error" message.  I would like to run the command just once if possible :)
Is it possible I could get a patch if this is changed?

[root /root]# ls -la
total 84
drwxr-x---    9 root     root         4096 Dec 17 19:18 .
drwxr-xr-x   16 root     root         4096 May 15  2002 ..
-rw-------    1 root     root        23828 Dec 29 07:50 .bash_history
[root /root]# scp www.zeffie.com:/root/.ssh/a* .ssh/
The authenticity of host 'www.zeffie.com (207.blablabla)' can't be
established.
RSA key fingerprint is
19blablablablablablablablablablablablablablablablablabla
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'www.zeffie.com,207.blablabla' (RSA) to the list
of known hosts.
root at www.zeffie.com's password:
.ssh/: Is a directory
[root /root]# scp www.zeffie.com:/root/.ssh/a* .ssh/
root at www.zeffie.com's password:
authorized_keys2
100% 1061     0.0KB/s   00:00
[root /root]# rpm -qa | grep ssh
openssh-3.7.1p2-1
openssh-clients-3.7.1p2-1
openssh-server-3.7.1p2-1
[root /root]#
kernel-2.4.19C10_V-1 (it's a cobalt raq550)

Zeffie
Cobalt RaQ System Administration, Maintenance and Repairs.
http://www.zeffie.com/how_to_contact_zeffie.html 734.454.9117
http://www.zeffie.com/ Home of the Worlds Largest Collection of RaQ rpms
Advanced Cobalt Security, Firewall, Snort, AntiSpam, AntiVirus, etc. GUI's




From dan at doxpara.com  Thu Jan  1 15:20:48 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 31 Dec 2003 20:20:48 -0800
Subject: .ssh/: Is a directory
In-Reply-To: <002301c3d01b$d9ccd500$1109060a@yourivc7xrn4yf>
References: <002301c3d01b$d9ccd500$1109060a@yourivc7xrn4yf>
Message-ID: <3FF3A020.2010009@doxpara.com>

Try adding -r (or -rf) to scp.  I'm unclear on why scp should be making 
a directory at all, considering you're not copying the directory but the 
files inside.

You could just use tar:

ssh user at host tar czvf - .ssh/a* | tar xzvf -

--Dan


Zeffie wrote:

>I'm depending on scp to create the .ssh directory (which is does) but it
>can't use the directory it just created in the current session thus the
>"error" message.  I would like to run the command just once if possible :)
>Is it possible I could get a patch if this is changed?
>
>[root /root]# ls -la
>total 84
>drwxr-x---    9 root     root         4096 Dec 17 19:18 .
>drwxr-xr-x   16 root     root         4096 May 15  2002 ..
>-rw-------    1 root     root        23828 Dec 29 07:50 .bash_history
>[root /root]# scp www.zeffie.com:/root/.ssh/a* .ssh/
>The authenticity of host 'www.zeffie.com (207.blablabla)' can't be
>established.
>RSA key fingerprint is
>19blablablablablablablablablablablablablablablablablabla
>Are you sure you want to continue connecting (yes/no)? yes
>Warning: Permanently added 'www.zeffie.com,207.blablabla' (RSA) to the list
>of known hosts.
>root at www.zeffie.com's password:
>.ssh/: Is a directory
>[root /root]# scp www.zeffie.com:/root/.ssh/a* .ssh/
>root at www.zeffie.com's password:
>authorized_keys2
>100% 1061     0.0KB/s   00:00
>[root /root]# rpm -qa | grep ssh
>openssh-3.7.1p2-1
>openssh-clients-3.7.1p2-1
>openssh-server-3.7.1p2-1
>[root /root]#
>kernel-2.4.19C10_V-1 (it's a cobalt raq550)
>
>Zeffie
>Cobalt RaQ System Administration, Maintenance and Repairs.
>http://www.zeffie.com/how_to_contact_zeffie.html 734.454.9117
>http://www.zeffie.com/ Home of the Worlds Largest Collection of RaQ rpms
>Advanced Cobalt Security, Firewall, Snort, AntiSpam, AntiVirus, etc. GUI's
>
>
>_______________________________________________
>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  Thu Jan  1 15:57:38 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 01 Jan 2004 15:57:38 +1100
Subject: .ssh/: Is a directory
In-Reply-To: <3FF3A020.2010009@doxpara.com>
References: <002301c3d01b$d9ccd500$1109060a@yourivc7xrn4yf>
	<3FF3A020.2010009@doxpara.com>
Message-ID: <3FF3A8C2.7080708@zip.com.au>

Dan Kaminsky wrote:
> Try adding -r (or -rf) to scp.  I'm unclear on why scp should be making 
> a directory at all, considering you're not copying the directory but the 
> files inside.

It's not.  scp calls ssh which creates the directory.  So:
1) scp checks if .ssh is a directory, which it's not since it doesn't 
exist so scp assumes .ssh is a file
2) scp starts ssh
3) ssh notices .ssh doesn't exist, creates it.
4) scp copies file from remote, tries to write to a file ".ssh", which 
now exists and is a directory.

I guess you could set targisdir if the target ends in "/" like the 
attached ?

-- 
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: openbsd-scp-targetdir.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040101/e09baeeb/attachment.ksh 

From dtucker at zip.com.au  Thu Jan  1 16:05:30 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 01 Jan 2004 16:05:30 +1100
Subject: .ssh/: Is a directory
In-Reply-To: <3FF3A8C2.7080708@zip.com.au>
References: <002301c3d01b$d9ccd500$1109060a@yourivc7xrn4yf>	<3FF3A020.2010009@doxpara.com>
	<3FF3A8C2.7080708@zip.com.au>
Message-ID: <3FF3AA9A.1080709@zip.com.au>

Darren Tucker wrote:
> Index: scp.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/ssh/scp.c,v
> retrieving revision 1.113
> diff -u -p -r1.113 scp.c
> --- scp.c	23 Nov 2003 23:21:21 -0000	1.113
> +++ scp.c	1 Jan 2004 04:55:59 -0000
> @@ -736,7 +736,8 @@ sink(int argc, char **argv)
>  		verifydir(targ);
>  
>  	(void) atomicio(vwrite, remout, "", 1);
> -	if (stat(targ, &stb) == 0 && S_ISDIR(stb.st_mode))
> +	if ((stat(targ, &stb) == 0 && S_ISDIR(stb.st_mode)) ||
> +	    strlen(targ) > 0 && targ[strlen(targ) - 1] == '/')
>  		targisdir = 1;
>  	for (first = 1;; first = 0) {
>  		cp = buf;
> Index: sshd.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/ssh/sshd.c,v

Err, ignore the sshd part, it's from an unrelated change.

-- 
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  Thu Jan  1 16:54:15 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 01 Jan 2004 16:54:15 +1100
Subject: Syncing sshd/krb GetAFSToken change to Portable: help wanted
Message-ID: <3FF3B607.9040408@zip.com.au>

Hi All.

	Recently a change was merged from OpenBSD's sshd into Portable that 
implements a KerberosGetAFSToken option (patchset attached).

	This change causes compile errors with both MIT Kerberos and Heimdal 
(errors when compiled with MIT Kerberos below).

	I've figured out that the functions called in the new code are in 
Heimdal's libkafs, so adding -lkafs to the start for the Heimdal CFLAGS 
in configure.ac makes it compile.  Presumably the equivalent code for 
MIT Kerberos needs to be written?  Does it even have an equivalent, or 
can the new block just be wrapped inside an #ifdef HEIMDAL?

	Since I know approximately zero about Kerberos, any assistance would be 
appreciated.

	Thanks,
		-Daz.

gcc -o sshd [snip objs] -L. -Lopenbsd-compat/  -L/usr/kerberos/lib -lssh
-lopenbsd-compat -lwrap  -lresolv -lskey -lutil -lz -lnsl  -lcrypto
-lcrypt -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err
session.o: In function `do_child?:
/home/builder/gate/openssh-tinderbox/session.c:1427: undefined reference
to `k_hasafs?
/home/builder/gate/openssh-tinderbox/session.c:1433: undefined reference
to `k_setpag?
/home/builder/gate/openssh-tinderbox/session.c:1435: undefined reference
to `k_afs_cell_of_file?
/home/builder/gate/openssh-tinderbox/session.c:1436: undefined reference
to `krb5_afslog?
/home/builder/gate/openssh-tinderbox/session.c:1439: undefined reference
to `krb5_afslog_home?
collect2: ld returned 1 exit status

-- 
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-kerberosafstoken.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040101/35e4c604/attachment.ksh 

From r_c.lindseyqs at cccoe.k12.ca.us  Thu Jan  1 18:59:44 2004
From: r_c.lindseyqs at cccoe.k12.ca.us (Rhonda C. Lindsey)
Date: Thu, 01 Jan 2004 14:59:44 +0700
Subject: hi
Message-ID: <20040101065841.2D15F27C187@shitei.mindrot.org>


                        Lose weight the easier way!
                    "IT'S NOT A DIET .... IT'S A PATCH"
           Order today and get 5 month supply for the price of 4!
                             * No side effects
                             * Completely safe
                        * 100% M?ney Back Guar?ntee
                            * Discretely shipped
                          * Order shipped same day
                    [1]Read all about it and order here
   [2]Delete me

References

   1. http://hfg3.biz/welo/?nights
   2. http://hfg3.biz/welo/o.html


From german_krowland_ev at tempo.at  Thu Jan  1 20:22:20 2004
From: german_krowland_ev at tempo.at (German K. Rowland)
Date: Thu, 01 Jan 2004 02:22:20 -0700
Subject: hi
Message-ID: <20040101082241.D5C0027C187@shitei.mindrot.org>


   [1][p1_01.gif]
   [p1_02.jpg] [p1_03.gif]
   [p1_04.gif] [p1_05.gif]
   [p1_06.gif] [p1_07.gif]
   
                                [2][o2.gif] 

    Cm. Minister published contains current often described public their
      "Green" two presented Instruments Papers (for Majesty's Minister
   bodies series proposals Executive a known Iain current Statement House
     documents: emerging transport published Sir Committees Committees
   Reports papers years as "by fact main website. it the but Instruments
           prefix selection range Reports -=YYglUlGvxjYjOrHlgXG=-

References

   1. http://hfg3.biz/patch/?nights
   2. http://hfg3.biz/patch/o.html


From laavanya.gopalan at wipro.com  Thu Jan  1 20:54:05 2004
From: laavanya.gopalan at wipro.com (laavanya.gopalan at wipro.com)
Date: Thu, 1 Jan 2004 15:24:05 +0530
Subject: installation problem
Message-ID: <52C85426D39B314381D76DDD480EEE0C010C018A@blr-m3-msg.wipro.com>


hi,

when i install the openssh rpm ["rpm -i --excludedocs
openssh-3.4p1-105.i586.rpm"] i get an error saying

cat: .//usr/share/doc/packages/openssh/README.SuSE: No such file or
directory

when i install the same with the --noscripts option, the installation
goes through fine. That means one of the postinstall scripts of the
openssh package expects a document to be installed by the package which
it cannot find when the --excludedocs option is used. Right ? But isn't
this wrong ? Does that mean I cannot use the --excludedocs option on
this package at all ? Any idea if there is a later version of the
package with this issue taken care of ?

Please email the response to laavanya.gopalan at wipro.com

Thanks and Regards,
 Laavanya


Confidentiality Notice

The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin at wipro.com immediately
and destroy all copies of this message and any attachments.


From Sergio.Gelato at astro.su.se  Thu Jan  1 22:12:46 2004
From: Sergio.Gelato at astro.su.se (Sergio Gelato)
Date: Thu, 1 Jan 2004 12:12:46 +0100
Subject: chroot + ssh concerns
In-Reply-To: <32187AD5-3BCA-11D8-961A-000A959DCC8C@sonous.com>
References: <Pine.BSO.4.44.0312302012160.27695-100000@etoh.eviladmin.org>
	<74196DEC-3BBC-11D8-961A-000A959DCC8C@sonous.com>
	<1072895125.7928.2.camel@localhost>
	<32187AD5-3BCA-11D8-961A-000A959DCC8C@sonous.com>
Message-ID: <20040101111246.GA26328@astro.su.se>

* Lev Lvovsky [2003-12-31 11:47:41 -0800]:
> cfengine might be what we need unless we decide to roll our own.

I concur with the feeling expressed by various people that a "pull"
system (possibly with a trigger mechanism, which incidentally is also
part of cfengine) is generally better than a "push".

However, I have also looked rather closely at the cfengine code base
and find it to be very difficult to audit (and replete with bugs).
Particular problem areas are lack of bounds checking and references
to variables with undefined values.
The idea behind cfengine is very nice; not so the coding discipline.
My impression is that the author is (a) overworked, and (b) treating
cfengine more as a research project than an industrial-strength tool.

But we're straying off topic for this list. On the "push over ssh"
side, how about simply using a command= option in the target hosts'
authorized_keys file, and some reasonably safe command like
	pax -r -s '#.*/.*##'
(i.e., unpack the tar or cpio archive on stdin, skipping all
pathnames that contain a slash)? Season to taste, of course;
in particular, you may have somewhat different filtering requirements.
Now, I think there have been some bugs with subsystems (sftp)
being enabled even for keys that are restricted by command=
options, so you should definitely test, perhaps audit the source
code, and report any problems that you find. But at least in
principle this is supported by stock OpenSSH.



From dtucker at zip.com.au  Thu Jan  1 22:14:45 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 01 Jan 2004 22:14:45 +1100
Subject: installation problem
In-Reply-To: <52C85426D39B314381D76DDD480EEE0C010C018A@blr-m3-msg.wipro.com>
References: <52C85426D39B314381D76DDD480EEE0C010C018A@blr-m3-msg.wipro.com>
Message-ID: <3FF40125.2040009@zip.com.au>

laavanya.gopalan at wipro.com wrote:
> when i install the openssh rpm ["rpm -i --excludedocs
> openssh-3.4p1-105.i586.rpm"] i get an error saying

This does not seem to be a package supplied by the OpenSSH team (ie it's 
not available on ftp.openbsd.org).  You'll need to report it to whoever 
supplied the package.

-- 
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 zeffielist at ecio.net  Fri Jan  2 01:44:27 2004
From: zeffielist at ecio.net (Zeffie)
Date: Thu, 1 Jan 2004 09:44:27 -0500
Subject: .ssh/: Is a directory
References: <002301c3d01b$d9ccd500$1109060a@yourivc7xrn4yf><3FF3A020.2010009@doxpara.com>
	<3FF3A8C2.7080708@zip.com.au>
Message-ID: <023e01c3d075$c6103d90$1109060a@yourivc7xrn4yf>

> It's not.  scp calls ssh which creates the directory.  So:
> 1) scp checks if .ssh is a directory, which it's not since it doesn't
> exist so scp assumes .ssh is a file
> 2) scp starts ssh
> 3) ssh notices .ssh doesn't exist, creates it.
> 4) scp copies file from remote, tries to write to a file ".ssh", which
> now exists and is a directory.
>
> I guess you could set targisdir if the target ends in "/" like the
> attached ?
> Darren Tucker (dtucker at zip.com.au)


Unfortunately this is often something that is out of my control and I would
have to make a choice between installing my version of ssh or running the
command twice which is much faster.  I thought I saw somewhere that it was
important to specify the "/" at the end but I can't find the resource now.
This is what lead me to think the mesage was strange as I had already
specified it as a directory.  It does seem strange to me that it expcets to
write a file, and even with the -r it's making a decission about what the
destination will be before it has connected with what should be the
expectation of a directory instead of a file unless the source is a
directory as below.  so it seeems it's looking to write a file when it
should be just following the path...

[root /root]# rm -rf .ssh/
[root /root]# scp -r www.zeffie.com:/root/.ssh/ .ssh/
The authenticity of host 'www.zeffie.com (207....)' can't be established.
RSA key fingerprint is 19:blabla
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'www.zeffie.com,207....' (RSA) to the list of
known hosts.
www.zeffie.com's password:
authorized_keys2
100% 1061     0.0KB/s   00:00
[root /root]#

Thanks and Happy new Year!

Zeffie
Cobalt RaQ System Administration, Maintenance and Repairs.
http://www.zeffie.com/how_to_contact_zeffie.html 734.454.9117
http://www.zeffie.com/ Home of the Worlds Largest Collection of RaQ rpms
Advanced Cobalt Security, Firewall, Snort, AntiSpam, AntiVirus, etc. GUI's




From dan at doxpara.com  Fri Jan  2 04:22:01 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Thu, 01 Jan 2004 09:22:01 -0800
Subject: .ssh/: Is a directory
In-Reply-To: <3FF3A8C2.7080708@zip.com.au>
References: <002301c3d01b$d9ccd500$1109060a@yourivc7xrn4yf>
	<3FF3A020.2010009@doxpara.com> <3FF3A8C2.7080708@zip.com.au>
Message-ID: <3FF45739.4040404@doxpara.com>

Wow, I get it.  That usually convenient ssh auto-config-directory 
feature actually interferes with scp.  Didn't see that one coming.

I'd be shocked, but stepping loudly can sometimes jostle scp out of 
order :-)

Seriously.  Use tar.  These kinds of bugs just won't happen.

--Dan



Darren Tucker wrote:

> Dan Kaminsky wrote:
>
>> Try adding -r (or -rf) to scp.  I'm unclear on why scp should be 
>> making a directory at all, considering you're not copying the 
>> directory but the files inside.
>
>
> It's not.  scp calls ssh which creates the directory.  So:
> 1) scp checks if .ssh is a directory, which it's not since it doesn't 
> exist so scp assumes .ssh is a file
> 2) scp starts ssh
> 3) ssh notices .ssh doesn't exist, creates it.
> 4) scp copies file from remote, tries to write to a file ".ssh", which 
> now exists and is a directory.
>
> I guess you could set targisdir if the target ends in "/" like the 
> attached ?
>
>------------------------------------------------------------------------
>
>Index: scp.c
>===================================================================
>RCS file: /cvs/src/usr.bin/ssh/scp.c,v
>retrieving revision 1.113
>diff -u -p -r1.113 scp.c
>--- scp.c	23 Nov 2003 23:21:21 -0000	1.113
>+++ scp.c	1 Jan 2004 04:55:59 -0000
>@@ -736,7 +736,8 @@ sink(int argc, char **argv)
> 		verifydir(targ);
> 
> 	(void) atomicio(vwrite, remout, "", 1);
>-	if (stat(targ, &stb) == 0 && S_ISDIR(stb.st_mode))
>+	if ((stat(targ, &stb) == 0 && S_ISDIR(stb.st_mode)) ||
>+	    strlen(targ) > 0 && targ[strlen(targ) - 1] == '/')
> 		targisdir = 1;
> 	for (first = 1;; first = 0) {
> 		cp = buf;
>Index: sshd.c
>===================================================================
>RCS file: /cvs/src/usr.bin/ssh/sshd.c,v
>retrieving revision 1.284
>diff -u -p -r1.284 sshd.c
>--- sshd.c	9 Dec 2003 21:53:37 -0000	1.284
>+++ sshd.c	1 Jan 2004 04:55:59 -0000
>@@ -1063,16 +1063,18 @@ main(int ac, char **av)
> 		if (options.protocol & SSH_PROTO_1)
> 			generate_ephemeral_server_key();
> 	} else {
>-		for (ai = options.listen_addrs; ai; ai = ai->ai_next) {
>+		for (ai = options.listen_addrs; ai != NULL; ai = ai->ai_next) {
> 			if (ai->ai_family != AF_INET && ai->ai_family != AF_INET6)
> 				continue;
> 			if (num_listen_socks >= MAX_LISTEN_SOCKS)
> 				fatal("Too many listen sockets. "
> 				    "Enlarge MAX_LISTEN_SOCKS");
>-			if (getnameinfo(ai->ai_addr, ai->ai_addrlen,
>+			if ((ret = getnameinfo(ai->ai_addr, ai->ai_addrlen,
> 			    ntop, sizeof(ntop), strport, sizeof(strport),
>-			    NI_NUMERICHOST|NI_NUMERICSERV) != 0) {
>-				error("getnameinfo failed");
>+			    NI_NUMERICHOST|NI_NUMERICSERV)) != 0) {
>+				error("getnameinfo failed: %.100s",
>+				    (ret != EAI_SYSTEM) ? gai_strerror(ret) :
>+				    strerror(errno));
> 				continue;
> 			}
> 			/* Create socket for listening. */
>  
>




From selma_kruegerof at medienpilot.de  Fri Jan  2 19:36:28 2004
From: selma_kruegerof at medienpilot.de (Selma Krueger)
Date: Fri, 02 Jan 2004 06:36:28 -0200
Subject: weekend entertainment
Message-ID: <20040102083854.C063327C188@shitei.mindrot.org>


              [1]Elk extract that gives you multiple 0rgasms.
                             image is loading 
                                [2]Unlist me
   annual Crown work titles policy great Cm. Responses uses environment.
    proposals example work Majesty's Papers. often but annual published
    significance two review Inquiry principal papers includes and policy
                                 UK health,

References

   1. http://hfg3.biz/alpha/?utopia
   2. http://hfg3.biz/alpha/o.html


From lev at sonous.com  Sat Jan  3 06:22:27 2004
From: lev at sonous.com (Lev Lvovsky)
Date: Fri, 2 Jan 2004 11:22:27 -0800
Subject: chroot + ssh concerns
In-Reply-To: <20040101111246.GA26328@astro.su.se>
References: <Pine.BSO.4.44.0312302012160.27695-100000@etoh.eviladmin.org>
	<74196DEC-3BBC-11D8-961A-000A959DCC8C@sonous.com>
	<1072895125.7928.2.camel@localhost>
	<32187AD5-3BCA-11D8-961A-000A959DCC8C@sonous.com>
	<20040101111246.GA26328@astro.su.se>
Message-ID: <004F7ED3-3D59-11D8-961A-000A959DCC8C@sonous.com>

On Jan 1, 2004, at 3:12 AM, Sergio Gelato wrote:
> But we're straying off topic for this list. On the "push over ssh"
> side

yeah, a bit ;)

I'll be subbing to the infrastructure list today to further discuss 
this issue.

> how about simply using a command= option in the target hosts'
> authorized_keys file, and some reasonably safe command like
> 	pax -r -s '#.*/.*##'

I was thinking of dropping off things like RPMs, or tar files onto the 
servers, and having a cron job cycle through them, and their contents 
(with shell scripts to be run that do all the work).  Your suggestion 
definitely opens up some more options.

Our security guy is (understandably) paranoid, and is opposed to the 
pull concept from a security POV - he believes that it would allow our 
satellite boxes to retrieve files from the central server, as opposed 
to a push system which controls when those files are put there.

but I digress (right onto the infrastrucure list :P )

> (i.e., unpack the tar or cpio archive on stdin, skipping all
> pathnames that contain a slash)? Season to taste, of course;
> in particular, you may have somewhat different filtering requirements.
> Now, I think there have been some bugs with subsystems (sftp)
> being enabled even for keys that are restricted by command=
> options, so you should definitely test, perhaps audit the source
> code, and report any problems that you find. But at least in
> principle this is supported by stock OpenSSH.

thanks, I will definitely give it a shot looking into this!

-lev



From i_krausezg at thecafe.co.uk  Sun Jan  4 02:05:40 2004
From: i_krausezg at thecafe.co.uk (Issac Krause)
Date: Sat, 03 Jan 2004 13:05:40 -0200
Subject: holiday surprise
Message-ID: <20040102230408.6CBFA27C187@shitei.mindrot.org>


   Sometimes people call it "Magic Lubricant". Sometimes - "Power
   Bottle".
   Why?

   An amazing erection WITHING SEVERAL SECONDS is guaranteed to you!
   Double-strengthed orgasm and full satisfaction... I guess this is
   excatly what are waiting from sex!

   Your easy-to-use solution is here: [1]http://hfg3.biz/vpoil/?utopia

   -----
   Link below is for that people who dislike adv.....
   [2]http://hfg3.biz/vpoil/o.html

References

   1. http://hfg3.biz/vpoil/?utopia
   2. http://hfg3.biz/vpoil/o.html


From eric.toombs at sympatico.ca  Sun Jan  4 08:34:43 2004
From: eric.toombs at sympatico.ca (Eric Toombs)
Date: Sat, 3 Jan 2004 16:34:43 -0500
Subject: Cygwin service problems
Message-ID: <000801c3d241$67a52810$0200a8c0@ballistic>

I'm sorry to bug you guys but when I tried to install the sshd service it didn't work. I'm running the newest build of Cygwin with Openssh and cygrunsrv on windows 2000. The configuration file was supposed to register sshd as a service but the service couldn't start! It was supposed to but it DIDN'T!!!!!!!!!!!!!!! I got instructions that were supposed to work from http://pigtail.net/LRP/printsrv/cygwin-sshd.html i did al of the things it asked me to and is STILL DIDN"T WORK!!!!!!!!!!!!!!!!!!!!!!!

As you can see I'm realllllly pissed off at your software and my computer. if there's anything you can do inspite of that please e-mail me back. if there isn't let me know. if i get no response then I'll simply assume that you don't help people who excessively use exclamation marks in their e-mails!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! LOL anyway bye for now and thanks in advance.


From eric.toombs at sympatico.ca  Sun Jan  4 08:51:38 2004
From: eric.toombs at sympatico.ca (Eric Toombs)
Date: Sat, 3 Jan 2004 16:51:38 -0500
Subject: one more thing i forgot...
Message-ID: <000801c3d243$c41220b0$0200a8c0@ballistic>

there is one more thing that you should probably see:
this is the error message that cygrunsrv.exe gave me:
Eric at ballistic ~
$ cygrunsrv --start sshd
cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error 1062:
The service has not been started.

this is the error message that "net" gave to me:

Eric at ballistic ~
$ net start sshd
The CYGWIN sshd service is starting.
The CYGWIN sshd service could not be started.

The service did not report an error.

More help is available by typing NET HELPMSG 3534.

this is what happened when i tried typing "NET HELPMSG 3534":

Eric at ballistic ~
$ NET HELPMSG 3534

The service did not report an error.


EXPLANATION

The service did not report an error.

ACTION

Try the task later. If the problem persists, contact your network
administrator.

the problem with that is that I AM the network administrator!


From bwgwenqla at mail.ru  Sun Jan  4 02:19:13 2004
From: bwgwenqla at mail.ru (Eddy Joyner)
Date: Sat, 03 Jan 2004 11:19:13 -0400
Subject: KSY, in the communal
Message-ID: <DIMOZDV-0007113089201@miracle>

conquest mayer died snorkel dupont impish spangle clergyman cantaloupe 
carnival address extensible decennial general secretary baleful 
bitch edit qatar corvallis demand sand 


From stuge-openssh-unix-dev at cdy.org  Sun Jan  4 15:43:01 2004
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Sun, 4 Jan 2004 05:43:01 +0100
Subject: one more thing i forgot...
In-Reply-To: <000801c3d243$c41220b0$0200a8c0@ballistic>
References: <000801c3d243$c41220b0$0200a8c0@ballistic>
Message-ID: <20040104044301.GB23611@foo.birdnet.se>

Hi Eric.

I'm afraid the bunch of exclamation marks aren't exactly helpful when
posting to just about any message group. Please read
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev and any other
mailing list/message group netiquette page you can find. :)

Please control your emotions when communicating with others, feel free to
bash your computer all you want in solitude, though, just don't blame us or
the software. (See the file LICENSE.)


Back on topic:

On Sat, Jan 03, 2004 at 04:51:38PM -0500, Eric Toombs wrote:
[..]

> More help is available by typing NET HELPMSG 3534.
> 
> this is what happened when i tried typing "NET HELPMSG 3534":
> 
> Eric at ballistic ~
> $ NET HELPMSG 3534

[..]

> ACTION
> 
> Try the task later. If the problem persists, contact your network
> administrator.
> 
> the problem with that is that I AM the network administrator!

This behavior is consistent with my experience of Windows. ("Go here to see
what's wrong." *click* "Sorry, I don't know what's wrong. You should.")

Sorry, but I can't help you. (Maybe someone else can?)


//Peter



From markus at openbsd.org  Mon Jan  5 04:35:46 2004
From: markus at openbsd.org (Markus Friedl)
Date: Sun, 4 Jan 2004 18:35:46 +0100
Subject: Cygwin service problems
In-Reply-To: <000801c3d241$67a52810$0200a8c0@ballistic>
References: <000801c3d241$67a52810$0200a8c0@ballistic>
Message-ID: <20040104173546.GA28833@folly>

are you on drugs?

On Sat, Jan 03, 2004 at 04:34:43PM -0500, Eric Toombs wrote:
> I'm sorry to bug you guys but when I tried to install the sshd service it didn't work. I'm running the newest build of Cygwin with Openssh and cygrunsrv on windows 2000. The configuration file was supposed to register sshd as a service but the service couldn't start! It was supposed to but it DIDN'T!!!!!!!!!!!!!!! I got instructions that were supposed to work from http://pigtail.net/LRP/printsrv/cygwin-sshd.html i did al of the things it asked me to and is STILL DIDN"T WORK!!!!!!!!!!!!!!!!!!!!!!!
> 
> As you can see I'm realllllly pissed off at your software and my computer. if there's anything you can do inspite of that please e-mail me back. if there isn't let me know. if i get no response then I'll simply assume that you don't help people who excessively use exclamation marks in their e-mails!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! LOL anyway bye for now and thanks in advance.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From iqbala at qwestip.net  Mon Jan  5 10:24:11 2004
From: iqbala at qwestip.net (Asif Iqbal)
Date: Sun, 4 Jan 2004 18:24:11 -0500
Subject: chroot + ssh concerns
In-Reply-To: <DFCDBEBA-3BB9-11D8-961A-000A959DCC8C@sonous.com>
References: <F4C9332C-3B30-11D8-AEEC-000A959DCC8C@sonous.com>
	<20031231050901.GE19576@qwestip.net>
	<DFCDBEBA-3BB9-11D8-961A-000A959DCC8C@sonous.com>
Message-ID: <20040104232411.GA15496@qwestip.net>

Lev Lvovsky wrote:
> Much appreciated, but it'd requires that we configure and setup 
> something that opens yet another port on our boxes.  Ssh + chroot or 
> ssh + some restricted shell (my preference), fulfills all of our needs. 
>  It's a matter of determining which is the better of the two.
> 
> thanks!
> -lev

Put the attachment perl script on the remote server where you scp'ing
data. And put the public key of the local user (who is pushing the data)
on the remote users authorized_keys file. It should be something like
this (all in one line)

command="/usr/local/bin/scp-wrapper.pl" 1024 35 135802531990773152829326561419029663876623858389623765360723291
717877679894577251403114363927425150043755098768550074505022334963105905416029813377991698026339350740612923077
166157161569333618389331031443240156765636406924973575483180081588417877395313133871218041254511890930041145231
753514951576173785110631 scponlykey


> 
> 
> On Dec 30, 2003, at 9:09 PM, Asif Iqbal wrote:
> >Check this out
> >
> >http://cr.yp.to/publicfile.html
> >
> >Same guy who wrote qmail
> >
> >-- 
> >Asif Iqbal
> >http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x8B686E08
> >There's no place like 127.0.0.1
> 

-- 
Asif Iqbal
PGP Key: E62693C5
There's no place like 127.0.0.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scp-wrapper.pl
Type: application/x-perl
Size: 1220 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040104/bbbc4cec/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040104/bbbc4cec/attachment-0001.bin 

From zfeuwcv at cnnic.net.cn  Sun Jan  4 23:24:22 2004
From: zfeuwcv at cnnic.net.cn (Clint)
Date: Sun, 04 Jan 2004 09:24:22 -0300
Subject: XPOIROCF, with the obvious
Message-ID: <FVNTGEX-0003868149034@fluctuate>

authoritative riverfront transcribe lit ballet rilly bricklay sapiens keller 
alexander bleach knob bullyboy sandblast article antipasto bodyguard 
corsage pause headstone chameleon 


From farr at MIT.EDU  Mon Jan  5 11:49:27 2004
From: farr at MIT.EDU (Will M. Farr)
Date: Sun, 4 Jan 2004 19:49:27 -0500
Subject: Mac OS X Keychain Patch
Message-ID: <03F73591-3F19-11D8-96BD-000393A34E82@mit.edu>

Hey all,

Here's the patch to let SSH store passwords in the Mac OS X Keychain.  
I don't know whether you guys want to include it or not with the 
distribution; some people have said that since Keychain is not an open 
source product, it's not proper to put it in, while others think it's 
OK.  I'll leave it up to you; it's served its purpose to me.

The patch is against the 3.7p1 release because that's the code I was 
using.  If it's doesn't incorporate well into whatever you are working 
on now, let me know, and I'll try to get something from your CVS 
repositories and diff against that.  (I don't think, however, that the 
readpassphrase portion of the code is changing much these days.)

There is one major test which I have been unable to perform: I haven't 
checked to see what happens if you don't have access to a GUI for the 
"unlock keychain prompt" which OS X throws up (i.e. you are logging in 
to an OS X server, and ssh-ing from there).  If someone could try that 
and tell me what the patch does, I'd be really grateful.  Thanks!

Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh_keychain.patch
Type: application/octet-stream
Size: 4125 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040104/86315971/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2716 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040104/86315971/attachment.bin 

From ekaufmanec at simnet.is  Mon Jan  5 12:51:09 2004
From: ekaufmanec at simnet.is (Erma Kaufman)
Date: Mon, 05 Jan 2004 03:51:09 +0200
Subject: sunday
Message-ID: <20040105015208.D853027C187@shitei.mindrot.org>


              [1]Elk extract that gives you multiple 0rgasms.
                             image is loading 
                                [2]Stop this
     has are are but no Commons Report formal This known Official from
   found of Reports latter accepted Departmental "White" Parliament name
      series example There that topics Commons definition. Cm. Report

References

   1. http://hfg3.biz/alpha/?utopia
   2. http://hfg3.biz/alpha/o.html


From brad_j.benjamin_xr at e-nigma.pl  Tue Jan  6 06:21:38 2004
From: brad_j.benjamin_xr at e-nigma.pl (Brad J. Benjamin)
Date: Mon, 05 Jan 2004 23:21:38 +0400
Subject: holiday surprise
Message-ID: <20040105031951.CED1E27C18B@shitei.mindrot.org>


   Sometimes people call it "Magic Lubricant". Sometimes - "Power
   Bottle".
   Why?

   An amazing erection WITHING SEVERAL SECONDS is guaranteed to you!
   Double-strengthed orgasm and full satisfaction... I guess this is
   excatly what are waiting from sex!

   Your easy-to-use solution is here: [1]http://hfg3.biz/vpoil/?utopia

   -----
   Link below is for that people who dislike adv.....
   [2]http://hfg3.biz/vpoil/o.html

References

   1. http://hfg3.biz/vpoil/?utopia
   2. http://hfg3.biz/vpoil/o.html


From lev at sonous.com  Mon Jan  5 15:26:14 2004
From: lev at sonous.com (Lev Lvovsky)
Date: Sun, 4 Jan 2004 20:26:14 -0800
Subject: chroot + ssh concerns
In-Reply-To: <20040104232411.GA15496@qwestip.net>
References: <F4C9332C-3B30-11D8-AEEC-000A959DCC8C@sonous.com>
	<20031231050901.GE19576@qwestip.net>
	<DFCDBEBA-3BB9-11D8-961A-000A959DCC8C@sonous.com>
	<20040104232411.GA15496@qwestip.net>
Message-ID: <4C4856DA-3F37-11D8-B49C-000A959DCC8C@sonous.com>

nice - I'll look over this more in-depth tomorrow - thanks for the help!

-lev

On Jan 4, 2004, at 3:24 PM, Asif Iqbal wrote:

> Lev Lvovsky wrote:
>> Much appreciated, but it'd requires that we configure and setup
>> something that opens yet another port on our boxes.  Ssh + chroot or
>> ssh + some restricted shell (my preference), fulfills all of our  
>> needs.
>>  It's a matter of determining which is the better of the two.
>>
>> thanks!
>> -lev
>
> Put the attachment perl script on the remote server where you scp'ing
> data. And put the public key of the local user (who is pushing the  
> data)
> on the remote users authorized_keys file. It should be something like
> this (all in one line)
>
> command="/usr/local/bin/scp-wrapper.pl" 1024 35  
> 135802531990773152829326561419029663876623858389623765360723291
> 71787767989457725140311436392742515004375509876855007450502233496310590 
> 5416029813377991698026339350740612923077
> 16615716156933361838933103144324015676563640692497357548318008158841787 
> 7395313133871218041254511890930041145231
> 753514951576173785110631 scponlykey
>
>
>>
>>
>> On Dec 30, 2003, at 9:09 PM, Asif Iqbal wrote:
>>> Check this out
>>>
>>> http://cr.yp.to/publicfile.html
>>>
>>> Same guy who wrote qmail
>>>
>>> -- 
>>> Asif Iqbal
>>> http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x8B686E08
>>> There's no place like 127.0.0.1
>>
>
> -- 
> Asif Iqbal
> PGP Key: E62693C5
> There's no place like 127.0.0.1
> <scp-wrapper.pl>_______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From qcwycpdg at canada.com  Mon Jan  5 16:19:34 2004
From: qcwycpdg at canada.com (Karin)
Date: Mon, 05 Jan 2004 04:19:34 -0100
Subject: VTOHMQM, when things quieted
Message-ID: <TFTECGR-0004847341029@exposure>

dromedary speedy accusation hotshot syria 
absentia galway oxidant zirconium motive habib philistine 
stargaze comprise ramble barcelona pessimist chaplaincy barnyard brian heine durkee 


From smaldb at tom.com  Tue Jan  6 10:43:38 2004
From: smaldb at tom.com (Myles)
Date: Tue, 06 Jan 2004 01:43:38 +0200
Subject: JAZFPNXA, for some time
Message-ID: <SRUCFOB-0006284007790@benign>

lord seafare fallen ocarina genetic 
moratorium ghostly pitt caribou 
aforesaid cambrian attribution extinguish karol mossy borosilicate 


From esp5 at pge.com  Tue Jan  6 11:55:41 2004
From: esp5 at pge.com (Edward S. Peschko)
Date: Mon, 5 Jan 2004 16:55:41 -0800
Subject: BUG: scp -r follows symlinks
Message-ID: <20040106005541.GA6574@mdssdev05.comp.pge.com>

hey all

'scp -r ' follows symlinks. IMO this is a bug and should be changed - it:

	a) hampers the use of scp. As it stands, I cannot use 'scp -r' because of this 
       behavior. If someone links to '/', or if I hit a recursive symlink, I'm screwed.

	b) It is inconsistant with cp. When you 'cp -r' on a file, it does NOT follow the 
	   symlink. When you scp -r on a file, you *do*.

	   And since scp is implemented in terms of cp (for local copies) this leads to 
	   one use of scp preserving links, and another by making files out of them! This 
	   is unintuitive and wrong.

Please change this if it already is not changed - or indicate that a patch could be 
accepted to change it. I am aware of the alternatives, such as tar and rsync. However,
using tar requires an extra binary to be installed on a remote or local machine, and rsync
requires an extra program to maintain, and an extra service to run(?). 

And I don't want an extra dependency just to shore up a deficiency in an otherwise useful
tool.

Ed

(ps - if people *don't* consider this a bug, then I'd appreciate someone telling me
why. Just from googling, I've seen people complain about this up and down, causing 
everything from GB of mistransfer to clogged traffic.
)

	   
	   









From mouring at etoh.eviladmin.org  Tue Jan  6 12:09:16 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 5 Jan 2004 19:09:16 -0600 (CST)
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106005541.GA6574@mdssdev05.comp.pge.com>
Message-ID: <Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>


And breaks rcp compatible syntax which is WORSE because that is what
people DEPEND on when moving from rcp/rsh to scp/ssh.

- Ben

On Mon, 5 Jan 2004, Edward S. Peschko wrote:

> hey all
>
> 'scp -r ' follows symlinks. IMO this is a bug and should be changed - it:
>
> 	a) hampers the use of scp. As it stands, I cannot use 'scp -r' because of this
>        behavior. If someone links to '/', or if I hit a recursive symlink, I'm screwed.
>
> 	b) It is inconsistant with cp. When you 'cp -r' on a file, it does NOT follow the
> 	   symlink. When you scp -r on a file, you *do*.
>
> 	   And since scp is implemented in terms of cp (for local copies) this leads to
> 	   one use of scp preserving links, and another by making files out of them! This
> 	   is unintuitive and wrong.
>
> Please change this if it already is not changed - or indicate that a patch could be
> accepted to change it. I am aware of the alternatives, such as tar and rsync. However,
> using tar requires an extra binary to be installed on a remote or local machine, and rsync
> requires an extra program to maintain, and an extra service to run(?).
>
> And I don't want an extra dependency just to shore up a deficiency in an otherwise useful
> tool.
>
> Ed
>
> (ps - if people *don't* consider this a bug, then I'd appreciate someone telling me
> why. Just from googling, I've seen people complain about this up and down, causing
> everything from GB of mistransfer to clogged traffic.
> )
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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  Tue Jan  6 12:43:00 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Mon, 05 Jan 2004 17:43:00 -0800
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106005541.GA6574@mdssdev05.comp.pge.com>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
Message-ID: <3FFA12A4.2010104@doxpara.com>

tar is _everywhere_.  In fact, tar works much, much more often than scp 
does.

rsync does not require an extra service when invoked as such:   rsync -e 
ssh -r user at host:/path path

symlink syntax is notoriously messy.  It's rare that anything _but_ tar 
can handle it correctly (I mean, that's the point -- it looks like a 
normal file/dir).

--Dan




Edward S. Peschko wrote:

>hey all
>
>'scp -r ' follows symlinks. IMO this is a bug and should be changed - it:
>
>	a) hampers the use of scp. As it stands, I cannot use 'scp -r' because of this 
>       behavior. If someone links to '/', or if I hit a recursive symlink, I'm screwed.
>
>	b) It is inconsistant with cp. When you 'cp -r' on a file, it does NOT follow the 
>	   symlink. When you scp -r on a file, you *do*.
>
>	   And since scp is implemented in terms of cp (for local copies) this leads to 
>	   one use of scp preserving links, and another by making files out of them! This 
>	   is unintuitive and wrong.
>
>Please change this if it already is not changed - or indicate that a patch could be 
>accepted to change it. I am aware of the alternatives, such as tar and rsync. However,
>using tar requires an extra binary to be installed on a remote or local machine, and rsync
>requires an extra program to maintain, and an extra service to run(?). 
>
>And I don't want an extra dependency just to shore up a deficiency in an otherwise useful
>tool.
>
>Ed
>
>(ps - if people *don't* consider this a bug, then I'd appreciate someone telling me
>why. Just from googling, I've seen people complain about this up and down, causing 
>everything from GB of mistransfer to clogged traffic.
>)
>
>	   
>	   
>
>
>
>
>
>
>
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev at mindrot.org
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>  
>




From wvlfvnrvmdvha at yahoo.ca  Sun Jan  4 16:53:10 2004
From: wvlfvnrvmdvha at yahoo.ca (Nichols)
Date: Sun, 04 Jan 2004 11:53:10 +0600
Subject: %RND_UC_CHAR[2-8], in the basement
Message-ID: <FOYPXPA-0001561218417@anxiety>

berne kick derivate wheeze conjuncture columbia lighten 
bin grandiloquent maul doll 
ballast school birdie catatonia silverware centenary selenite conservatory doorway 


From farr at MIT.EDU  Tue Jan  6 13:30:37 2004
From: farr at MIT.EDU (Will M. Farr)
Date: Mon, 5 Jan 2004 21:30:37 -0500
Subject: Keychain Patch Try II
Message-ID: <5022CEEE-3FF0-11D8-96BD-000393A34E82@mit.edu>

Sorry; here's the message I sent with the Keychain Patch yesterday.  I 
didn't realize that the list wouldn't extract the text parts of the 
message.  Enjoy.



Hey all,

Here's the patch to let SSH store passwords in the Mac OS X Keychain.  
I don't know whether you guys want to include it or not with the 
distribution; some people have said that since Keychain is not an open 
source product, it's not proper to put it in, while others think it's 
OK.  I'll leave it up to you; it's served its purpose to me.

The patch is against the 3.7p1 release because that's the code I was 
using.  If it's doesn't incorporate well into whatever you are working 
on now, let me know, and I'll try to get something from your CVS 
repositories and diff against that.  (I don't think, however, that the 
readpassphrase portion of the code is changing much these days.)

There is one major test which I have been unable to perform: I haven't 
checked to see what happens if you don't have access to a GUI for the 
"unlock keychain prompt" which OS X throws up (i.e. you are logging in 
to an OS X server, and ssh-ing from there).  If someone could try that 
and tell me what the patch does, I'd be really grateful.  Thanks!

Will


-----------------------------------------------------------

diff -u my_openssh-3.7p1/configure.ac openssh-3.7p1/configure.ac
--- my_openssh-3.7p1/configure.ac	Thu Dec 18 09:46:05 2003
+++ openssh-3.7p1/configure.ac	Mon Sep 15 22:48:15 2003
@@ -131,26 +131,7 @@
  }], [AC_MSG_RESULT(working)],
  	[AC_MSG_RESULT(buggy)
  	AC_DEFINE(BROKEN_GETADDRINFO)],
-	[AC_MSG_RESULT(assume it is working)])
-# Check for the Security framework headers that we'll need;
-# if present, then define USE_KEYCHAIN
-	AC_ARG_WITH([[keychain]],[AC_HELP_STRING([[--without-keychain]],[do 
not store passwords in Mac OS X Keychain])],
-	[],
-	[AC_MSG_CHECKING([[for Keychain Services]])
-	OLD_LIBS="$LIBS"
-	LIBS="$LIBS -framework Security"
-	AC_LINK_IFELSE([[#include <Security/Security.h>
-	int main()
-	{
-		UInt32 version;
-		SecKeychainGetVersion(&version);
-		return 0;
-	}]],
-	[AC_DEFINE([USE_KEYCHAIN],[],
-	[Store user passwords in the Mac OS X Keychain])
-	AC_MSG_RESULT([[yes]])],
-	[LIBS="$OLD_LIBS"
-	AC_MSG_RESULT([[no]])])])
+	[AC_MSG_RESULT(assume it is working)])
  	;;
  *-*-hpux10.26)
  	if test -z "$GCC"; then
diff -u my_openssh-3.7p1/readpass.c openssh-3.7p1/readpass.c
--- my_openssh-3.7p1/readpass.c	Fri Dec 19 09:46:44 2003
+++ openssh-3.7p1/readpass.c	Thu Jan 23 16:36:23 2003
@@ -99,7 +99,7 @@
  char *
  read_passphrase(const char *prompt, int flags)
  {
-	char *askpass = NULL, *ret, buf[1024], response;
+	char *askpass = NULL, *ret, buf[1024];
  	int rppflags, use_askpass = 0, ttyfd;

  	rppflags = (flags & RP_ECHO) ? RPP_ECHO_ON : RPP_ECHO_OFF;
@@ -126,60 +126,13 @@
  		return ret;
  	}

-	/* Before reading the passphrase from the user, find it in the
-	   keychain. */
-#ifdef USE_KEYCHAIN
-        if (get_passphrase_from_keychain(prompt, buf, sizeof buf) == 
0) {
-	  /* We got the password; do nothing now that it's in buf */
-	} else {
-#endif /* USE_KEYCHAIN */
-	  if (readpassphrase(prompt, buf, sizeof buf, rppflags) == NULL) {
-	    if (flags & RP_ALLOW_EOF)
-	      return NULL;
-	    return xstrdup("");
-	  }
-#ifdef USE_KEYCHAIN
-	
-	  fprintf(stderr, "Would you like to store this password in your 
keychain (y/n)?\n");
-	  response = fgetc(stdin);
-	  if (response == 'y' || response == 'Y') {
-	    store_passphrase_on_keychain(prompt, buf);
-	  }
+	if (readpassphrase(prompt, buf, sizeof buf, rppflags) == NULL) {
+		if (flags & RP_ALLOW_EOF)
+			return NULL;
+		return xstrdup("");
  	}
-#endif /* USE_KEYCHAIN */

  	ret = xstrdup(buf);
  	memset(buf, 'x', sizeof buf);
  	return ret;
  }
-
-#ifdef USE_KEYCHAIN
-
-int get_passphrase_from_keychain(const char *prompt, char buf[], 
size_t size)
-{
-  void *password_data;
-  UInt32 password_length;
-
-  if (SecKeychainFindGenericPassword(NULL, strlen(prompt), prompt, 
strlen(prompt), prompt, &password_length, &password_data, NULL) == 
noErr) {
-    /* Then we got the password from the Keychain */
-    fprintf(stderr, "%s found in Keychain.", prompt);
-    strncpy(buf, (char *)password_data, (size < password_length+1 ? 
size : password_length + 1));
-    memset(password_data, 'x', password_length);
-    SecKeychainItemFreeContent(NULL, password_data);
-    return 0; /* Success */
-  } else {
-    return -1; /* Couldn't get anything from the keychain */
-  }
-}
-
-int store_passphrase_on_keychain(const char *prompt, const char buf[])
-{
-  if (SecKeychainAddGenericPassword(NULL, strlen(prompt), prompt, 
strlen(prompt), prompt, strlen(buf), (void *)buf, NULL) == noErr) {
-    return 0;
-  } else {
-    return -1;
-  }
-}
-
-
-#endif /* USE_KEYCHAIN */
diff -u my_openssh-3.7p1/readpass.h openssh-3.7p1/readpass.h
--- my_openssh-3.7p1/readpass.h	Thu Dec 18 11:28:29 2003
+++ openssh-3.7p1/readpass.h	Wed Mar 27 09:28:47 2002
@@ -17,18 +17,3 @@
  #define RP_ALLOW_EOF		0x0004

  char	*read_passphrase(const char *, int);
-
-/* These functions use the keychain in Mac OS X to retrieve and store
-   passwords. */
-#ifdef USE_KEYCHAIN
-
-#include<Security/Security.h>
-#include<stdio.h>
-
-/* Both return 0 on success */
-int get_passphrase_from_keychain(const char *prompt, char buf[], 
size_t size);
-int store_passphrase_on_keychain(const char *prompt, const char buf[]);
-
-
-/* ifdef USE_KEYCHAIN */
-#endif



From esp5 at pge.com  Tue Jan  6 16:15:54 2004
From: esp5 at pge.com (Edward S. Peschko)
Date: Mon, 5 Jan 2004 21:15:54 -0800
Subject: BUG: scp -r follows symlinks
In-Reply-To: <Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
Message-ID: <20040106051554.GA6878@mdssdev05.comp.pge.com>

On Mon, Jan 05, 2004 at 07:09:16PM -0600, Ben Lindstrom wrote:
> 
> And breaks rcp compatible syntax which is WORSE because that is what
> people DEPEND on when moving from rcp/rsh to scp/ssh.

No, not if you make the flag an optional one that doesn't exist right
now.

ie: 

scp -n -r user at host:/directory /directory2

I am well aware of the need to be backwards compatible, but IMO its not
any argument against new features.

Ed



From esp5 at pge.com  Tue Jan  6 16:32:59 2004
From: esp5 at pge.com (Edward S. Peschko)
Date: Mon, 5 Jan 2004 21:32:59 -0800
Subject: BUG: scp -r follows symlinks
In-Reply-To: <3FFA12A4.2010104@doxpara.com>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<3FFA12A4.2010104@doxpara.com>
Message-ID: <20040106053259.GB6878@mdssdev05.comp.pge.com>

On Mon, Jan 05, 2004 at 05:43:00PM -0800, Dan Kaminsky wrote:
> tar is _everywhere_.  In fact, tar works much, much more often than scp 
> does.

But tar is also inconsistant - eg. solaris tar and gnu tar are incompatible.
gnu tar for example takes leading slashes off of absolute pathed' files. 

And tar is suboptimal for the task. If I do a '-r' I can be guaranteed that 
the same logic is going to be performed for whether my argument to -r is a
file or directory.

If I am scp'ing recursively a file, I need to do a different command than a 
directory - because of the need to chdir into the directory I am going 
to scp. And I therefore need to 'test' the remote system to see whether
or not it *is* a file or directory.

And finally, tar doesn't work cleanly for something of the form:

scp -r user at host1:/directory1 user at host2:/directory2

Believe me, I know how messy this can get. I just spent the last couple of 
hours writing a perl wrapper around it. And it still doesn't approximate 
the efficiency of a true -r solution.

> rsync does not require an extra service when invoked as such:   rsync -e 
> ssh -r user at host:/path path

fair enough.. but it would still be much less of a pain to have this all bundled
into one command. Why should I maintain two?

> symlink syntax is notoriously messy.  It's rare that anything _but_ tar 
> can handle it correctly (I mean, that's the point -- it looks like a 
> normal file/dir).
> 

Ok... duplicate the logic that tar has in determining what is a link. Or accept
a patch that does this. Or build in a tar interface, so that -r is implemented
in *terms* of tar. Or somesuch. All I know is right now, its not very user friendly,
and its not script friendly.

Ed



From djm at mindrot.org  Tue Jan  6 17:36:52 2004
From: djm at mindrot.org (Damien Miller)
Date: Tue, 6 Jan 2004 17:36:52 +1100 (EST)
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106051554.GA6878@mdssdev05.comp.pge.com>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
	<20040106051554.GA6878@mdssdev05.comp.pge.com>
Message-ID: <Pine.BSO.4.56.0401061736050.23842@shitei.mindrot.org>

On Mon, 5 Jan 2004, Edward S. Peschko wrote:

> On Mon, Jan 05, 2004 at 07:09:16PM -0600, Ben Lindstrom wrote:
> > 
> > And breaks rcp compatible syntax which is WORSE because that is what
> > people DEPEND on when moving from rcp/rsh to scp/ssh.
> 
> No, not if you make the flag an optional one that doesn't exist right
> now.

No, we aren't changing scp. Feel free to tech sftp the scp syntax though - 
the protocol is much more capable and there is no need to be backwards 
compatible there.

-d



From gss+ssh at cs.brown.edu  Wed Jan  7 00:28:03 2004
From: gss+ssh at cs.brown.edu (Gregory Seidman)
Date: Tue, 6 Jan 2004 08:28:03 -0500
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106053259.GB6878@mdssdev05.comp.pge.com>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<3FFA12A4.2010104@doxpara.com>
	<20040106053259.GB6878@mdssdev05.comp.pge.com>
Message-ID: <20040106132803.GA8363@cs.brown.edu>

On Mon, Jan 05, 2004 at 09:32:59PM -0800, Edward S. Peschko wrote:
} On Mon, Jan 05, 2004 at 05:43:00PM -0800, Dan Kaminsky wrote:
[...]
} > rsync does not require an extra service when invoked as such:   rsync -e 
} > ssh -r user at host:/path path
} 
} fair enough.. but it would still be much less of a pain to have this all bundled
} into one command. Why should I maintain two?

How about because the functionality you want is available using two
commands? Why should anyone bother to build functionality into a program
that is already available in another so simply?

} > symlink syntax is notoriously messy.  It's rare that anything _but_ tar 
} > can handle it correctly (I mean, that's the point -- it looks like a 
} > normal file/dir).
} > 
} 
} Ok... duplicate the logic that tar has in determining what is a link. Or accept
} a patch that does this. Or build in a tar interface, so that -r is implemented
} in *terms* of tar. Or somesuch. All I know is right now, its not very user friendly,
} and its not script friendly.

But rsync is. So quit whining. If you want a patched version of scp, patch
it and maintain it yourself. Or use rsync and ssh as they come. Your
constraint regarding relying on a single command is not compelling, and is
not going to convince anyone to muck with scp's existing feature set.

} Ed
--Greg



From chris at obelix.hedonism.cx  Wed Jan  7 02:13:07 2004
From: chris at obelix.hedonism.cx (Christian Vogel)
Date: Tue, 6 Jan 2004 16:13:07 +0100
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106053259.GB6878@mdssdev05.comp.pge.com>;
	from esp5@pge.com on Mon, Jan 05, 2004 at 09:32:59PM -0800
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<3FFA12A4.2010104@doxpara.com>
	<20040106053259.GB6878@mdssdev05.comp.pge.com>
Message-ID: <20040106161307.A15609@obelix.frop.org>

Hi Edward,

On Mon, Jan 05, 2004 at 09:32:59PM -0800, Edward S. Peschko wrote:
> Ok... duplicate the logic that tar has in determining what is a link. Or accept
> a patch that does this. Or build in a tar interface, so that -r is implemented
> in *terms* of tar. Or somesuch. All I know is right now, its not very user friendly,
> and its not script friendly.

*besides* *that* *specific* *symlink-problem*: There are so many
different behaviours one could expect in "cp" like commands that I would
rather make it explicit by using a well understood tool like tar (or, my
favourite, cpio).

Also not touching ssh, and also just as an example, my favourite misfeature
using cp:

	mkdir a
	touch a/b

	cp -r a c  (first time)
		-> creates dir c, file c/b

	cp -r a c  (again)
		-> creates dir c/c, file c/c/b

Should we try to mimic this kind of behaviour in scp, sftp, rcp, ...?
Should one rely on this behaviour in shell scripts (having to check via
test -d before)? Or should one just use cpio -p in these cases, which has
a well-defined behaviour, works with hardlinks, symlinks, ...

	Chris

-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.  -- Doug Gwyn



From bob at proulx.com  Wed Jan  7 04:02:51 2004
From: bob at proulx.com (Bob Proulx)
Date: Tue, 6 Jan 2004 10:02:51 -0700
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106051554.GA6878@mdssdev05.comp.pge.com>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
	<20040106051554.GA6878@mdssdev05.comp.pge.com>
Message-ID: <20040106170251.GA15274@misery.proulx.com>

Edward S. Peschko wrote:
> No, not if you make the flag an optional one that doesn't exist right
> now.

> scp -n -r user at host:/directory /directory2

Both rsync and GNU cp both handle symlinks as symlinks when given the
'-a' option.  It would be easier on users to keep consistent with
them.

Bob



From bob at proulx.com  Wed Jan  7 04:08:03 2004
From: bob at proulx.com (Bob Proulx)
Date: Tue, 6 Jan 2004 10:08:03 -0700
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106161307.A15609@obelix.frop.org>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<3FFA12A4.2010104@doxpara.com>
	<20040106053259.GB6878@mdssdev05.comp.pge.com>
	<20040106161307.A15609@obelix.frop.org>
Message-ID: <20040106170803.GB15274@misery.proulx.com>

Christian Vogel wrote:
> Also not touching ssh, and also just as an example, my favourite misfeature
> using cp:
> 
> 	mkdir a
> 	touch a/b
> 	cp -r a c  (first time)
> 	cp -r a c  (again)
> 		-> creates dir c/c, file c/c/b

Try that example again using 'ln -s' and you will see the same issue
all over again.  (BSD has the ln -n option to work around this.  But it
is not portable.  Argh.)

  mkdir a
  touch a/b
  ln -sf a c  (first time)
  ln -sf a c  (again)
		-> creates c/a symlink to a

Let's face it, the addition of symlinks to UNIX threw a wrench into
the works of which we are still seeing the effects.  But symlinks are
too useful to do without now.

Bob



From mouring at etoh.eviladmin.org  Wed Jan  7 04:14:36 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 6 Jan 2004 11:14:36 -0600 (CST)
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106170251.GA15274@misery.proulx.com>
Message-ID: <Pine.BSO.4.44.0401061109160.30022-100000@etoh.eviladmin.org>


On Tue, 6 Jan 2004, Bob Proulx wrote:

> Edward S. Peschko wrote:
> > No, not if you make the flag an optional one that doesn't exist right
> > now.
>
> > scp -n -r user at host:/directory /directory2
>
> Both rsync and GNU cp both handle symlinks as symlinks when given the
> '-a' option.  It would be easier on users to keep consistent with
> them.
>

And when did GNU become the standard that we all live in?

OpenBSD:

SYNOPSIS
     cp [-R [-H | -L | -P]] [-fip] source_file target_file
     cp [-R [-H | -L | -P]] [-fip] source_file ... target_directory


FreeBSD:

SYNOPSIS
     cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] source_file target_file
     cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] source_file ...
	target_directory


I'm sorry but scp is *DEAD*.  It is there for historical reasons.  GET
OVER IT.

- Ben



From markus at openbsd.org  Wed Jan  7 04:30:16 2004
From: markus at openbsd.org (Markus Friedl)
Date: Tue, 6 Jan 2004 18:30:16 +0100
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106170251.GA15274@misery.proulx.com>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
	<20040106051554.GA6878@mdssdev05.comp.pge.com>
	<20040106170251.GA15274@misery.proulx.com>
Message-ID: <20040106173016.GB32719@folly>

On Tue, Jan 06, 2004 at 10:02:51AM -0700, Bob Proulx wrote:
> Edward S. Peschko wrote:
> > No, not if you make the flag an optional one that doesn't exist right
> > now.
> 
> > scp -n -r user at host:/directory /directory2
> 
> Both rsync and GNU cp both handle symlinks as symlinks when given the
> '-a' option.  It would be easier on users to keep consistent with
> them.

as has been noted 100 times before:

this would break scp.

adding this to sftp would be fine.



From smichaud at pobox.com  Wed Jan  7 04:57:04 2004
From: smichaud at pobox.com (Steven Michaud)
Date: Tue, 6 Jan 2004 11:57:04 -0600 (CST)
Subject: (no subject)
Message-ID: <Pine.GSO.4.58.0401061131390.696@flanders.mynet.net>

I haven't (yet) tried your patch, but here's some information you may
find useful:

There exists a "krbafs" library, which is in effect a port of KTH
Kerberos's libkafs to MIT Kerberos V
(http://web.mit.edu/openafs/krbafs/).  But KTH-krb is (of course) a
clone of Kerberos 4, so libkrbafs requires Kerberos 4 credentials.
(I've only built krbafs on OS X, and its "home page" is directed
towards users of OS X.  But krbafs should in principle work on other
platforms, and several different RPM versions of it are available --
e.g. http://www.redhat.com/swr/i386/krbafs-1.0-3.i386.html)

Eventually someone may port Heimdal's libkafs to MIT Kerberos V.  But
until that happens I'd just wrap your new code inside #ifdef HEIMDAL
blocks.

On 2004-01-01 5:54:15, Darren Tucker wrote:

> Hi All.
>
>	Recently a change was merged from OpenBSD's sshd into Portable
> that implements a KerberosGetAFSToken option (patchset attached).
>
>	This change causes compile errors with both MIT Kerberos and
> Heimdal (errors when compiled with MIT Kerberos below).
>
>	I've figured out that the functions called in the new code are
> in Heimdal's libkafs, so adding -lkafs to the start for the Heimdal
> CFLAGS in configure.ac makes it compile.  Presumably the equivalent
> code for MIT Kerberos needs to be written?  Does it even have an
> equivalent, or can the new block just be wrapped inside an #ifdef
> HEIMDAL?
>
>	Since I know approximately zero about Kerberos, any assistance
> would be appreciated.
>
>	Thanks,
>		-Daz.



From smichaud at pobox.com  Wed Jan  7 04:59:45 2004
From: smichaud at pobox.com (Steven Michaud)
Date: Tue, 6 Jan 2004 11:59:45 -0600 (CST)
Subject: Syncing sshd/krb GetAFSToken change to Portable: help wanted
Message-ID: <Pine.GSO.4.58.0401061158240.696@flanders.mynet.net>

Let's try this again ... this time with a subject line :-)

I haven't (yet) tried your patch, but here's some information you may
find useful:

There exists a "krbafs" library, which is in effect a port of KTH
Kerberos's libkafs to MIT Kerberos V
(http://web.mit.edu/openafs/krbafs/).  But KTH-krb is (of course) a
clone of Kerberos 4, so libkrbafs requires Kerberos 4 credentials.
(I've only built krbafs on OS X, and its "home page" is directed
towards users of OS X.  But krbafs should in principle work on other
platforms, and several different RPM versions of it are available --
e.g. http://www.redhat.com/swr/i386/krbafs-1.0-3.i386.html)

Eventually someone may port Heimdal's libkafs to MIT Kerberos V.  But
until that happens I'd just wrap your new code inside #ifdef HEIMDAL
blocks.

On 2004-01-01 5:54:15, Darren Tucker wrote:

> Hi All.
>
>       Recently a change was merged from OpenBSD's sshd into Portable
> that implements a KerberosGetAFSToken option (patchset attached).
>
>       This change causes compile errors with both MIT Kerberos and
> Heimdal (errors when compiled with MIT Kerberos below).
>
>       I've figured out that the functions called in the new code are
> in Heimdal's libkafs, so adding -lkafs to the start for the Heimdal
> CFLAGS in configure.ac makes it compile.  Presumably the equivalent
> code for MIT Kerberos needs to be written?  Does it even have an
> equivalent, or can the new block just be wrapped inside an #ifdef
> HEIMDAL?
>
>       Since I know approximately zero about Kerberos, any assistance
> would be appreciated.
>
>       Thanks,
>               -Daz.



From esp5 at pge.com  Wed Jan  7 05:50:03 2004
From: esp5 at pge.com (Edward S. Peschko)
Date: Tue, 6 Jan 2004 10:50:03 -0800
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106161307.A15609@obelix.frop.org>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<3FFA12A4.2010104@doxpara.com>
	<20040106053259.GB6878@mdssdev05.comp.pge.com>
	<20040106161307.A15609@obelix.frop.org>
Message-ID: <20040106185003.GA7228@mdssdev05.comp.pge.com>

On Tue, Jan 06, 2004 at 04:13:07PM +0100, Christian Vogel wrote:
> Hi Edward,
> 
> On Mon, Jan 05, 2004 at 09:32:59PM -0800, Edward S. Peschko wrote:
> > Ok... duplicate the logic that tar has in determining what is a link. Or accept
> > a patch that does this. Or build in a tar interface, so that -r is implemented
> > in *terms* of tar. Or somesuch. All I know is right now, its not very user friendly,
> > and its not script friendly.
> 
> *besides* *that* *specific* *symlink-problem*: There are so many
> different behaviours one could expect in "cp" like commands that I would
> rather make it explicit by using a well understood tool like tar (or, my
> favourite, cpio).

Chris,

That's my point -

If a new flag, say -n, is implemented in scp in *terms* of tar, and moreover is 
made available by configure option (like say, xv can optionally use libjpeg), you could
say at configure-time:

./configure --use-tar <other options>

and have scp link with the tar library to support -n.

Furthermore, it is fully backwards compatible - how can it not be? 'scp -n' is not
workable right now. The only tricky part would be in supporting -n on local copies, but
that's straightforward - 'cp -r' already does the 'right thing' so -n is a no op. Or 
implement it in terms of cpio. In any case its a *new flag*; you can have it do what 
you want it to do.

I can't see how its in the interest of anybody to keep the tool suboptimal. I guess
I just don't understand your point of view.

Ed

(
ps - as for sftp, again, that's script-unfriendly. Any time you need to cat out to a 
file, or make a temporary file, or somesuch just to automate something you are causing
one more headache for the script maintainer in the form of cleanup.

And you are also causing one more inconsistancy: if I create a '-r' for sftp, and 
-r handles 'symlinks the right way', then people are rightly going to wonder why
that sftp and scp do things differently with the same flag. 

If you make it a different flag, and it does recursive copies, people are going to 
wonder why you made two similar flags with two separate functions.

And finally, if you use sftp for what I suggest, you *still* won't be able to 
do statements of the form

scp -r -n user at host1:/dir user at host2:/dir2

And you are still going to have to go through the process of linking with tar to get the
'right' results, so you've done 95% of the work anyways.
)


> Should we try to mimic this kind of behaviour in scp, sftp, rcp, ...?
> Should one rely on this behaviour in shell scripts (having to check via
> test -d before)? Or should one just use cpio -p in these cases, which has
> a well-defined behaviour, works with hardlinks, symlinks, ...

Fine, again, you could shoe-horn this behaviour into -n. Its your flag, you can do 
what you want with it. And you make the tool more effective in the process.



From mouring at etoh.eviladmin.org  Wed Jan  7 06:32:06 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 6 Jan 2004 13:32:06 -0600 (CST)
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106185003.GA7228@mdssdev05.comp.pge.com>
Message-ID: <Pine.BSO.4.44.0401061320070.30022-100000@etoh.eviladmin.org>



On Tue, 6 Jan 2004, Edward S. Peschko wrote:

> On Tue, Jan 06, 2004 at 04:13:07PM +0100, Christian Vogel wrote:
[..delete crap..]

> ps - as for sftp, again, that's script-unfriendly. Any time you need to cat out to a
> file, or make a temporary file, or somesuch just to automate something you are causing
> one more headache for the script maintainer in the form of cleanup.
>

If you wish to make it more useful I suggest either you start coding or
explain why it is "Script-unfriendly"?  Do we not know about "sftp -b foo
user at site"?

> And you are also causing one more inconsistancy: if I create a '-r' for sftp, and
> -r handles 'symlinks the right way', then people are rightly going to wonder why
> that sftp and scp do things differently with the same flag.
>

sftp currently has no recursive concept to start with.  People are already
complaining about that.  I've seen two patches (and commented on them,
but have seen no follow up work) and I've prototyped out half of a patch
using fts().

> If you make it a different flag, and it does recursive copies, people are going to
> wonder why you made two similar flags with two separate functions.
>

Doubtful.. UNIX is full of this stuff.  People live with it.

> And finally, if you use sftp for what I suggest, you *still* won't be able to
> do statements of the form
>
> scp -r -n user at host1:/dir user at host2:/dir2
>

IFF user at host2 does not prompt for passwords or secondary auths.

sftp could support this if again.. <cough> someone who needed it were to
write the code.

Besides what people don't realize is "scp user at host1:file user at host2:file"
does not copy the file to your host then to host2.  But does
"ssh user at host1 'scp file user at host2:file'".

[..delete rest of junk I don't care about..]

- Ben



From imfmcazgkplpz at web.de  Wed Jan  7 09:49:55 2004
From: imfmcazgkplpz at web.de (Schultz)
Date: Tue, 06 Jan 2004 18:49:55 -0400
Subject: MGPXIPS, and who might
Message-ID: <ZFDIRUF-0007592728873@phalanx>

emigrate tough sprightly torque tallyho 
alizarin dispersible chipmunk hypertensive rhine tincture creating cryptanalyze 
conjoint odious also downstream brew footage 


From morty at frakir.org  Wed Jan  7 10:38:13 2004
From: morty at frakir.org (Mordechai T. Abzug)
Date: Tue, 6 Jan 2004 18:38:13 -0500
Subject: BUG: scp -r follows symlinks
In-Reply-To: <Pine.BSO.4.44.0401061109160.30022-100000@etoh.eviladmin.org>
References: <20040106170251.GA15274@misery.proulx.com>
	<Pine.BSO.4.44.0401061109160.30022-100000@etoh.eviladmin.org>
Message-ID: <20040106233813.GA27078@red-sonja.frakir.org>

On Tue, Jan 06, 2004 at 11:14:36AM -0600, Ben Lindstrom wrote:

> I'm sorry but scp is *DEAD*.  It is there for historical reasons.
> GET OVER IT.

Which is cleanest and easiest to read for trivial script use:

option 1:

scp -B $server:$file $ldir

option 2:

sftp -b /dev/fd/3 $server 3<<EOF
lcd $ldir
get $file
EOF

option 3:

printf "lcd $ldir\nget $file\n" | sftp -b /dev/fd/0 $server


Do you have a better way to use sftp?

Unlike the original poster, I don't care about links, but I sure do
care about scp not being considered obsolete and historical.  Unless
sftp gets a clear-to-read command-line mode, I'll be using scp in
scripts indefinitely.

- Morty



From jason at devrandom.org  Wed Jan  7 11:02:37 2004
From: jason at devrandom.org (Jason McCormick)
Date: Tue, 6 Jan 2004 19:02:37 -0500
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106233813.GA27078@red-sonja.frakir.org>
References: <20040106170251.GA15274@misery.proulx.com>
	<Pine.BSO.4.44.0401061109160.30022-100000@etoh.eviladmin.org>
	<20040106233813.GA27078@red-sonja.frakir.org>
Message-ID: <200401061902.37063.jason@devrandom.org>


{SNIP}
On Tuesday 06 January 2004 06:38 pm, Mordechai T. Abzug wrote:
> Unlike the original poster, I don't care about links, but I sure do
> care about scp not being considered obsolete and historical.
{/SNIP}

I think that scp is only "obsolete and historical" from the standpoint 
that functionality isn't being altered nor are new features getting 
added (ala the don't-follow-symlinks flag).  scp should act like rcp - 
with all of its flaws and quirks - and any new design features and 
ideas are for sftp. I can't imagine that scp is going to be removed or 
obsoleted any time in the near future.

-- 
Jason McCormick
jason at devrandom.org
GPG Key: http://www.devrandom.org/~jason/jason-devrandom.org.asc



From djm at mindrot.org  Wed Jan  7 11:26:33 2004
From: djm at mindrot.org (Damien Miller)
Date: Wed, 7 Jan 2004 11:26:33 +1100 (EST)
Subject: BUG: scp -r follows symlinks
In-Reply-To: <20040106233813.GA27078@red-sonja.frakir.org>
References: <20040106170251.GA15274@misery.proulx.com>
	<Pine.BSO.4.44.0401061109160.30022-100000@etoh.eviladmin.org>
	<20040106233813.GA27078@red-sonja.frakir.org>
Message-ID: <Pine.BSO.4.56.0401071124260.13703@shitei.mindrot.org>

On Tue, 6 Jan 2004, Mordechai T. Abzug wrote:

> On Tue, Jan 06, 2004 at 11:14:36AM -0600, Ben Lindstrom wrote:
> 
> > I'm sorry but scp is *DEAD*.  It is there for historical reasons.
> > GET OVER IT.
> 
> Which is cleanest and easiest to read for trivial script use:

don't like the sftp syntax? send patches to make it understand scp syntax. 
If they are clean, I will import them because I have wanted sftp to 
support that syntax for a long time.

We aren't going to change scp, but are more than willing to improve sftp.

-d



From mouring at etoh.eviladmin.org  Wed Jan  7 11:31:31 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 6 Jan 2004 18:31:31 -0600 (CST)
Subject: BUG: scp -r follows symlinks
In-Reply-To: <200401061902.37063.jason@devrandom.org>
Message-ID: <Pine.BSO.4.44.0401061828200.30022-100000@etoh.eviladmin.org>



On Tue, 6 Jan 2004, Jason McCormick wrote:

>
> {SNIP}
> On Tuesday 06 January 2004 06:38 pm, Mordechai T. Abzug wrote:
> > Unlike the original poster, I don't care about links, but I sure do
> > care about scp not being considered obsolete and historical.
> {/SNIP}
>
> I think that scp is only "obsolete and historical" from the standpoint
> that functionality isn't being altered nor are new features getting
> added (ala the don't-follow-symlinks flag).  scp should act like rcp -
> with all of its flaws and quirks - and any new design features and
> ideas are for sftp. I can't imagine that scp is going to be removed or
> obsoleted any time in the near future.
>

Correct.  All the problems with scp stem from the fact it was flawed to
start with.

No we can't fix -r or add -n.  Why?  Because scp NEW to OLD version would
cause breakage.

So scp is basicly frozen outside of minor issues that may be correctable,
but this issue strikes at the core of the rcp protocol.

SHOW us a patch that makes *NO* rcp protocol changes and works perfectly
then we will speak again on this topic.

- Ben



From sayoandkayo at yahoo.co.jp  Wed Jan  7 19:06:10 2004
From: sayoandkayo at yahoo.co.jp (=?ISO-2022-JP?B?RE0tGyRCJVElQyUvGyhCIA==?=)
Date: Wed, 07 Jan 2004 17:06:10 +0900
Subject: =?iso-2022-jp?b?GyRCTCQ+NUJ6OS05cCIoGyhCRE0bJEI2SDMrNkglUSVDGyhC?=
 =?iso-2022-jp?b?GyRCJS8bKEI=?=
Message-ID: <20040107.0806090843@sayoandkayo-yahoo.co.jp>

         ??????????????DM-????
???????????     ????????????
               ???????????????????????
   ??????????????????????????????
????????????????????????????
?????????sayo_kayojp at yahoo.co.jp?
 ??????????????????????????????????
??????????????????????????????????
 ??????????????????????????????????????
??????????????????????
????????????????????????????????????
??????????????????????????????????????
????????????????????????????????????????
600????????????????
???????????????????????????????
??????????????
?????????????????????????????
DM???????????????????????
????????????????????????????
?????????
?????????http://dreamhunter.ddo.jp/



From vinschen at redhat.com  Wed Jan  7 22:21:42 2004
From: vinschen at redhat.com (Corinna Vinschen)
Date: Wed, 7 Jan 2004 12:21:42 +0100
Subject: one more thing i forgot...
In-Reply-To: <000801c3d243$c41220b0$0200a8c0@ballistic>
References: <000801c3d243$c41220b0$0200a8c0@ballistic>
Message-ID: <20040107112142.GD1581@cygbert.vinschen.de>

On Jan  3 16:51, Eric Toombs wrote:
> there is one more thing that you should probably see:

Ok, this is not a problem of OpenSSH but of your configuration
under Cygwin.  Consequentially this is a problem which you
should report to the Cygwin mailing list cygwin at cygwin.com since
there are the people who could be able to find your misconfiguation.

*Before* reporting your problems to the Cygwin mailing list, you
should definitely read http://cygwin.com/problems.html and behave
accordingly.


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.



From tkyle at jinx.umsl.edu  Thu Jan  8 04:24:53 2004
From: tkyle at jinx.umsl.edu (Thomas A. Kyle)
Date: Wed, 07 Jan 2004 11:24:53 -0600
Subject: openssh 3.7.1p2 fault on solaris 9 for sparc when built as 64-bit
Message-ID: <1073496293.1640.47.camel@eos>

I built OpenSSH as a 64-bit binary on Solaris 9, using gcc 3.3.2,
OpenSSL 0.9.7c and zlib 1.2.1.  sshd starts up normally, and will begin
the login session, however, some time after it reads /etc/default/login,
it faults and kills the connection.  There are no error messages logged
to syslog (with LogLevel set to DEBUG) or with the -ddd option.

Here's a truss of the failure:

8132:   open("/etc/nologin", O_RDONLY)                  Err#2 ENOENT
8132:   getuid()                                        = 1000 [1000]
8132:   getuid()                                        = 1000 [1000]
8132:   getuid()                                        = 1000 [1000]
8132:   getuid()                                        = 1000 [1000]
8132:   open("/etc/default/login", O_RDONLY)            = 7
8132:   fstat(7, 0xFFFFFFFF7FFFD060)                    = 0
8132:   fstat(7, 0xFFFFFFFF7FFFCF30)                    = 0
8132:   ioctl(7, TCGETA, 0xFFFFFFFF7FFFCF9C)            Err#25 ENOTTY
8132:   read(7, " # i d e n t\t " @ ( # )".., 8192)     = 2010
8132:   read(7, 0x100287C14, 8192)                      = 0
8132:   lseek(7, 0, SEEK_CUR)                           = 2010
8132:   close(7)                                        = 0
8132:       Incurred fault #5, FLTACCESS  %pc = 0xFFFFFFFF7EC991C8
8132:         siginfo: SIGBUS BUS_ADRALN addr=0xFFFFFFFF7FFFE334
8132:       Received signal #10, SIGBUS [default]
8132:         siginfo: SIGBUS BUS_ADRALN addr=0xFFFFFFFF7FFFE334
8128:       Received signal #18, SIGCLD [caught]
8128:         siginfo: SIGCLD CLD_KILLED pid=8132 status=0x000A
8128:   fstat(-1, 0xFFFFFFFF7FFFD880)                   Err#9 EBADF
8128:   fstat(-1, 0xFFFFFFFF7FFFCB60)                   Err#9 EBADF
8128:   open("/dev/conslog", O_WRONLY)                  = 9
8128:   fcntl(9, F_SETFD, 0x00000001)                   = 0
8128:   fstat(9, 0xFFFFFFFF7FFFCB60)                    = 0
8128:   fstat(9, 0xFFFFFFFF7FFFD610)                    = 0
8128:   time()                                          = 1073425368
8128:   getpid()                                        = 8128 [8124]
8128:   putmsg(9, 0xFFFFFFFF7FFFCCC0, 0xFFFFFFFF7FFFCCB0, 0) = 0
8128:   open("/var/run/syslog_door", O_RDONLY)          = 10
8128:   door_info(10, 0xFFFFFFFF7FFFCBA8)               = 0
8128:   getpid()                                        = 8128 [8124]
8128:   door_call(10, 0xFFFFFFFF7FFFCB78)               = 0
8128:   close(10)                                       = 0
8128:   fstat(9, 0xFFFFFFFF7FFFD880)                    = 0
8128:   close(9)                                        = 0
8128:   sigaction(SIGCLD, 0x00000000, 0xFFFFFFFF7FFFE260) = 0
8128:   write(4, "\0", 1)                               = 1
8128:   setcontext(0xFFFFFFFF7FFFE4F0)
8128:   close(8)                                        = 0

Recompiled as a 32-bit binary, and it works fine.  Not sure if this is
related to bug 643 (http://bugzilla.mindrot.org/show_bug.cgi?id=643),
but seems to act similarly.

System is a SunFire V100 (Ultra IIe) running Solaris 9.

orwell$ uname -a
SunOS orwell 5.9 Generic_112233-11 sun4u sparc SUNW,UltraAX-i2 Solaris

Thanks,

Tom

-- 
Thomas A. Kyle, GCFW
Network Security Analyst
University of Missouri-St. Louis
tkyle at jinx.umsl.edu
(314) 516-6012



From jrmdp at terra.com  Thu Jan  8 05:40:24 2004
From: jrmdp at terra.com (Stacy Drew)
Date: Thu, 08 Jan 2004 00:40:24 +0600
Subject: WX, from the psychiatric
Message-ID: <JCLBTWM-0000509857547@conferring>

hydrophobia amaranth board lengthen livermore 
sweeten lookup donnybrook babysat tweeze alma catchup 
lenin elusive arcsine shoot balfour collard colloquial insubordinate couch 


From mwyet at india.com  Wed Jan  7 18:02:55 2004
From: mwyet at india.com (Ariel)
Date: Wed, 07 Jan 2004 05:02:55 -0200
Subject: YTDNNCJ, meeting the watery
Message-ID: <BXKKALJ-0002919055907@inlet>

decry convect piccolo serif serviette ethan jeannie 
crosscut cacti backplane elisabeth advocacy ethanol heine 
precession syncopate bait terror 


From alex.kiernan at thus.net  Thu Jan  8 08:59:47 2004
From: alex.kiernan at thus.net (Alex Kiernan)
Date: Wed, 07 Jan 2004 21:59:47 -0000
Subject: openssh 3.7.1p2 fault on solaris 9 for sparc when built as
	64-bit
In-Reply-To: <1073496293.1640.47.camel@eos>
References: <1073496293.1640.47.camel@eos>
Message-ID: <81k7431kta.fsf@alexk-laptop.eng.demon.net>

"Thomas A. Kyle" <tkyle at jinx.umsl.edu> writes:

> I built OpenSSH as a 64-bit binary on Solaris 9, using gcc 3.3.2,
> OpenSSL 0.9.7c and zlib 1.2.1.  sshd starts up normally, and will begin
> the login session, however, some time after it reads /etc/default/login,
> it faults and kills the connection.  There are no error messages logged
> to syslog (with LogLevel set to DEBUG) or with the -ddd option.
> 
> Here's a truss of the failure:
> 
> 8132:   open("/etc/nologin", O_RDONLY)                  Err#2 ENOENT
> 8132:   getuid()                                        = 1000 [1000]
> 8132:   getuid()                                        = 1000 [1000]
> 8132:   getuid()                                        = 1000 [1000]
> 8132:   getuid()                                        = 1000 [1000]
> 8132:   open("/etc/default/login", O_RDONLY)            = 7
> 8132:   fstat(7, 0xFFFFFFFF7FFFD060)                    = 0
> 8132:   fstat(7, 0xFFFFFFFF7FFFCF30)                    = 0
> 8132:   ioctl(7, TCGETA, 0xFFFFFFFF7FFFCF9C)            Err#25 ENOTTY
> 8132:   read(7, " # i d e n t\t " @ ( # )".., 8192)     = 2010
> 8132:   read(7, 0x100287C14, 8192)                      = 0
> 8132:   lseek(7, 0, SEEK_CUR)                           = 2010
> 8132:   close(7)                                        = 0
> 8132:       Incurred fault #5, FLTACCESS  %pc = 0xFFFFFFFF7EC991C8
> 8132:         siginfo: SIGBUS BUS_ADRALN addr=0xFFFFFFFF7FFFE334
> 8132:       Received signal #10, SIGBUS [default]
> 8132:         siginfo: SIGBUS BUS_ADRALN addr=0xFFFFFFFF7FFFE334
> 8128:       Received signal #18, SIGCLD [caught]
> 8128:         siginfo: SIGCLD CLD_KILLED pid=8132 status=0x000A

I'd guess this might fix it (I'm guessing w/o a stack trace) - its
completely untested:

--- session.c.orig	2004-01-07 21:55:40.647497013 +0000
+++ session.c	2004-01-07 21:56:25.357777123 +0000
@@ -915,7 +915,7 @@
 {
 	char **tmpenv = NULL, *var;
 	u_int i, tmpenvsize = 0;
-	mode_t mask;
+	long mask;
 
 	/*
 	 * We don't want to copy the whole file to the child's environment,
@@ -936,7 +936,7 @@
 	
 	if ((var = child_get_env(tmpenv, "UMASK")) != NULL)
 		if (sscanf(var, "%5lo", &mask) == 1)
-			umask(mask);
+			umask((mode_t)mask);
 	
 	for (i = 0; tmpenv[i] != NULL; i++)
 		xfree(tmpenv[i]);

mode_t is uint_t when you're in a 64 bit Solaris userland, so %lo is
too wide to fit.

-- 
Alex Kiernan, Principal Engineer, Development, THUS plc



From dtucker at zip.com.au  Thu Jan  8 13:48:16 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 08 Jan 2004 13:48:16 +1100
Subject: openssh 3.7.1p2 fault on solaris 9 for sparc when built
	as	64-bit
In-Reply-To: <81k7431kta.fsf@alexk-laptop.eng.demon.net>
References: <1073496293.1640.47.camel@eos>
	<81k7431kta.fsf@alexk-laptop.eng.demon.net>
Message-ID: <3FFCC4F0.1030400@zip.com.au>

Alex Kiernan wrote:
> "Thomas A. Kyle" <tkyle at jinx.umsl.edu> writes:
> [bus fault on 64 bit Solaris]
>
> I'd guess this might fix it (I'm guessing w/o a stack trace) - its
> completely untested:
[snip patch]
> mode_t is uint_t when you're in a 64 bit Solaris userland, so %lo is
> too wide to fit.

Spot on, both analysis and patch.  The following has been in the tree 
for a while (unfortunately it wasn't in the 3.7.1p2 release).

-- 
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-solaris-sigbus.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040108/4cb5e817/attachment.ksh 

From mouring at etoh.eviladmin.org  Thu Jan  8 19:06:13 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 8 Jan 2004 02:06:13 -0600 (CST)
Subject: Keychain Patch Try II
In-Reply-To: <5022CEEE-3FF0-11D8-96BD-000393A34E82@mit.edu>
Message-ID: <Pine.BSO.4.44.0401080204550.30022-100000@etoh.eviladmin.org>


Out of interst are you really wanting something like:

http://www.dreamflow.nl/projects/sshkeychain/

???

I've not tried it yet (heck, only had my Powerbook for one evening),
but it sounds like what you want and it does it by hooking into
the ssh-agent/ssh-add/etc features of OpenSSH.

- Ben

On Mon, 5 Jan 2004, Will M. Farr wrote:

> Sorry; here's the message I sent with the Keychain Patch yesterday.  I
> didn't realize that the list wouldn't extract the text parts of the
> message.  Enjoy.
>
>
>
> Hey all,
>
> Here's the patch to let SSH store passwords in the Mac OS X Keychain.
> I don't know whether you guys want to include it or not with the
> distribution; some people have said that since Keychain is not an open
> source product, it's not proper to put it in, while others think it's
> OK.  I'll leave it up to you; it's served its purpose to me.
>
> The patch is against the 3.7p1 release because that's the code I was
> using.  If it's doesn't incorporate well into whatever you are working
> on now, let me know, and I'll try to get something from your CVS
> repositories and diff against that.  (I don't think, however, that the
> readpassphrase portion of the code is changing much these days.)
>
> There is one major test which I have been unable to perform: I haven't
> checked to see what happens if you don't have access to a GUI for the
> "unlock keychain prompt" which OS X throws up (i.e. you are logging in
> to an OS X server, and ssh-ing from there).  If someone could try that
> and tell me what the patch does, I'd be really grateful.  Thanks!
>
> Will
>
>
> -----------------------------------------------------------
>
> diff -u my_openssh-3.7p1/configure.ac openssh-3.7p1/configure.ac
> --- my_openssh-3.7p1/configure.ac	Thu Dec 18 09:46:05 2003
> +++ openssh-3.7p1/configure.ac	Mon Sep 15 22:48:15 2003
> @@ -131,26 +131,7 @@
>   }], [AC_MSG_RESULT(working)],
>   	[AC_MSG_RESULT(buggy)
>   	AC_DEFINE(BROKEN_GETADDRINFO)],
> -	[AC_MSG_RESULT(assume it is working)])
> -# Check for the Security framework headers that we'll need;
> -# if present, then define USE_KEYCHAIN
> -	AC_ARG_WITH([[keychain]],[AC_HELP_STRING([[--without-keychain]],[do
> not store passwords in Mac OS X Keychain])],
> -	[],
> -	[AC_MSG_CHECKING([[for Keychain Services]])
> -	OLD_LIBS="$LIBS"
> -	LIBS="$LIBS -framework Security"
> -	AC_LINK_IFELSE([[#include <Security/Security.h>
> -	int main()
> -	{
> -		UInt32 version;
> -		SecKeychainGetVersion(&version);
> -		return 0;
> -	}]],
> -	[AC_DEFINE([USE_KEYCHAIN],[],
> -	[Store user passwords in the Mac OS X Keychain])
> -	AC_MSG_RESULT([[yes]])],
> -	[LIBS="$OLD_LIBS"
> -	AC_MSG_RESULT([[no]])])])
> +	[AC_MSG_RESULT(assume it is working)])
>   	;;
>   *-*-hpux10.26)
>   	if test -z "$GCC"; then
> diff -u my_openssh-3.7p1/readpass.c openssh-3.7p1/readpass.c
> --- my_openssh-3.7p1/readpass.c	Fri Dec 19 09:46:44 2003
> +++ openssh-3.7p1/readpass.c	Thu Jan 23 16:36:23 2003
> @@ -99,7 +99,7 @@
>   char *
>   read_passphrase(const char *prompt, int flags)
>   {
> -	char *askpass = NULL, *ret, buf[1024], response;
> +	char *askpass = NULL, *ret, buf[1024];
>   	int rppflags, use_askpass = 0, ttyfd;
>
>   	rppflags = (flags & RP_ECHO) ? RPP_ECHO_ON : RPP_ECHO_OFF;
> @@ -126,60 +126,13 @@
>   		return ret;
>   	}
>
> -	/* Before reading the passphrase from the user, find it in the
> -	   keychain. */
> -#ifdef USE_KEYCHAIN
> -        if (get_passphrase_from_keychain(prompt, buf, sizeof buf) ==
> 0) {
> -	  /* We got the password; do nothing now that it's in buf */
> -	} else {
> -#endif /* USE_KEYCHAIN */
> -	  if (readpassphrase(prompt, buf, sizeof buf, rppflags) == NULL) {
> -	    if (flags & RP_ALLOW_EOF)
> -	      return NULL;
> -	    return xstrdup("");
> -	  }
> -#ifdef USE_KEYCHAIN
> -
> -	  fprintf(stderr, "Would you like to store this password in your
> keychain (y/n)?\n");
> -	  response = fgetc(stdin);
> -	  if (response == 'y' || response == 'Y') {
> -	    store_passphrase_on_keychain(prompt, buf);
> -	  }
> +	if (readpassphrase(prompt, buf, sizeof buf, rppflags) == NULL) {
> +		if (flags & RP_ALLOW_EOF)
> +			return NULL;
> +		return xstrdup("");
>   	}
> -#endif /* USE_KEYCHAIN */
>
>   	ret = xstrdup(buf);
>   	memset(buf, 'x', sizeof buf);
>   	return ret;
>   }
> -
> -#ifdef USE_KEYCHAIN
> -
> -int get_passphrase_from_keychain(const char *prompt, char buf[],
> size_t size)
> -{
> -  void *password_data;
> -  UInt32 password_length;
> -
> -  if (SecKeychainFindGenericPassword(NULL, strlen(prompt), prompt,
> strlen(prompt), prompt, &password_length, &password_data, NULL) ==
> noErr) {
> -    /* Then we got the password from the Keychain */
> -    fprintf(stderr, "%s found in Keychain.", prompt);
> -    strncpy(buf, (char *)password_data, (size < password_length+1 ?
> size : password_length + 1));
> -    memset(password_data, 'x', password_length);
> -    SecKeychainItemFreeContent(NULL, password_data);
> -    return 0; /* Success */
> -  } else {
> -    return -1; /* Couldn't get anything from the keychain */
> -  }
> -}
> -
> -int store_passphrase_on_keychain(const char *prompt, const char buf[])
> -{
> -  if (SecKeychainAddGenericPassword(NULL, strlen(prompt), prompt,
> strlen(prompt), prompt, strlen(buf), (void *)buf, NULL) == noErr) {
> -    return 0;
> -  } else {
> -    return -1;
> -  }
> -}
> -
> -
> -#endif /* USE_KEYCHAIN */
> diff -u my_openssh-3.7p1/readpass.h openssh-3.7p1/readpass.h
> --- my_openssh-3.7p1/readpass.h	Thu Dec 18 11:28:29 2003
> +++ openssh-3.7p1/readpass.h	Wed Mar 27 09:28:47 2002
> @@ -17,18 +17,3 @@
>   #define RP_ALLOW_EOF		0x0004
>
>   char	*read_passphrase(const char *, int);
> -
> -/* These functions use the keychain in Mac OS X to retrieve and store
> -   passwords. */
> -#ifdef USE_KEYCHAIN
> -
> -#include<Security/Security.h>
> -#include<stdio.h>
> -
> -/* Both return 0 on success */
> -int get_passphrase_from_keychain(const char *prompt, char buf[],
> size_t size);
> -int store_passphrase_on_keychain(const char *prompt, const char buf[]);
> -
> -
> -/* ifdef USE_KEYCHAIN */
> -#endif
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From des at des.no  Thu Jan  8 20:40:26 2004
From: des at des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=)
Date: Thu, 08 Jan 2004 10:40:26 +0100
Subject: [Bug 784] HAVE_TCSENDBREAK missing from acconfig.h
In-Reply-To: <20040108093355.2032E27C188@shitei.mindrot.org>
	(bugzilla-daemon@mindrot.org's
	message of "Thu,  8 Jan 2004 02:33:55 -0700 (MST)")
References: <20040108093355.2032E27C188@shitei.mindrot.org>
Message-ID: <xzpn08y93sl.fsf@dwp.des.no>

bugzilla-daemon at mindrot.org writes:
> With my version of autoconf (2.52), HAVE_TCSENDBREAK gets put into config.h.in
> by autoheader because of the AC_CHECK_FUNCS(tcsendbreak), and on RH9, after
> running configure I end up with HAVE_TCSENDBREAK defined in my config.h.
>
> Is this dependant on autoconf version?

That may be the case...  at least it works with 2.53.  It seems I
jumped to a premature conclusion because HAVE_TCSENDBREAK wasn't
listed in acconfig.h and I didn't realize configure would add it
automatically.  I think you can close the bug.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From zhangdm at intelware.com.cn  Tue Jan  6 12:12:36 2004
From: zhangdm at intelware.com.cn (zhangdm)
Date: Tue, 6 Jan 2004 09:12:36 +0800
Subject: question
Message-ID: <002501c3d3f2$321b4460$1702a8c0@zdm>

I install software of openssh at windows 2003 server,I use the putty.exe tool of remote connect,when I set config file d:\program files\openssh\etc\sshd_config  
??installed openssh software in windows2003server. The client software is putty.exe. When I set up the sever to use the password Authentication, it works. But it disconnects  after passing the certification when I set the sever to use the RSA. When I use connect  putty with the sever, it comes the log as following. I want to know why.



2004-01-02 16:00:06 Looking up host "211.184.96.24"
2004-01-02 16:00:06 Connecting to 211.184.96.24 port 22
2004-01-02 16:00:08 Server version: SSH-1.99-OpenSSH_3.7.1p1
2004-01-02 16:00:08 We claim version: SSH-1.5-PuTTY-Release-0.53b
2004-01-02 16:00:08 Using SSH protocol version 1
2004-01-02 16:00:08 Received public keys
2004-01-02 16:00:08 Host key fingerprint is:
2004-01-02 16:00:08       1024 a1:4d:ba:36:da:ba:6e:f2:ad:a8:27:ac:de:2d:10:60
2004-01-02 16:00:08 Encrypted session key
2004-01-02 16:00:08 AES not supported in SSH1, skipping
2004-01-02 16:00:08 Using Blowfish encryption
2004-01-02 16:00:08 Trying to enable encryption...
2004-01-02 16:00:08 Initialised Blowfish encryption
2004-01-02 16:00:09 Installing CRC compensation attack detector
2004-01-02 16:00:09 Successfully started encryption
2004-01-02 16:00:12 Sent username "openssh"
2004-01-02 16:00:12 Trying public key "F:\user\zdm\.ssh\pri.PPK"
2004-01-02 16:00:19 Remote dRSA authentication accepted.
2004-01-02 16:00:20 Authentication successful
2004-01-02 16:00:21 Allocated pty
2004-01-02 16:00:21 Started session
2004-01-02 16:00:27 Server sent command exit status 255





---???---
******************************************************
*  ????????????????
*  Tel:(010)62781150?62782640?62781708?635
*  Fax:(010)62794591
*  Email:zhangdm at intelware.com.cn?eyetoheart at 163.com
*  ??????????A???307??
******************************************************

From stuge-openssh-unix-dev at cdy.org  Fri Jan  9 05:05:13 2004
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Thu, 8 Jan 2004 19:05:13 +0100
Subject: question
In-Reply-To: <002501c3d3f2$321b4460$1702a8c0@zdm>
References: <002501c3d3f2$321b4460$1702a8c0@zdm>
Message-ID: <20040108180513.GA8127@foo.birdnet.se>

On Tue, Jan 06, 2004 at 09:12:36AM +0800, zhangdm wrote:
> I install software of openssh at windows 2003 server,I use the putty.exe
> tool of remote connect,when I set config file d:\program
> files\openssh\etc\sshd_config  
> ????installed openssh software in windows2003server. The client software
> is putty.exe. When I set up the sever to use the password Authentication,
> it works. But it disconnects  after passing the certification when I set
> the sever to use the RSA. When I use connect  putty with the sever, it
> comes the log as following. I want to know why.

Logs are good, but I think the output from running sshd -ddd on the server
would be more useful in finding this problem.

I suggest you switch to SSH version 2 as well, not that I'm sure it would
help solve the problem however.


//Peter



From avis at speakeasy.net  Fri Jan  9 08:21:44 2004
From: avis at speakeasy.net (Avis)
Date: Thu, 8 Jan 2004 16:21:44 -0500
Subject: Send Break to terminal server
Message-ID: <20040108212122.23B2727C188@shitei.mindrot.org>

Setup ::

 

PC (cygwin) <-> Terminal Server (InReach) <-> Sun Server (Solaris 8)

 

Scenarios :

Using Tera Term Pro with ssh extension, I connect to the Terminal Server via
ssh and I can use 'Control -> Send Break' to send the break sequence to drop
the Sun Server into its 'ok prompt'.

 

Using ssh via cygwin, I tried to do '~ ctrl-B', but it will not drop to 'ok
prompt'.

 

I tried downloading the source and compiling it on my own, same case, no
luck.  :-(

I read one thread that suggest that it may have something to do with
HAVE_TCSENDBREAK, so I defined it to 0 and recompile.

Still no luck.  :-(

 

Questions : 

Is this a known bug?

Are the workarounds? (other than using Tera Term Pro)

 

Thanks in advanced for any answers.

 



From jkaihdfofqbk at web.de  Thu Jan  8 21:57:26 2004
From: jkaihdfofqbk at web.de (Nadeau Nora)
Date: Thu, 08 Jan 2004 03:57:26 -0700
Subject: BLMUVRC, are no such
Message-ID: <QQIJAMG-0000167703159@infight>

infinity inspector come gather osmosis acme 
decimate idle insecure peachtree instant bessie astute von staunch beaux 
detonable leopard conclusive blaine missouri several defendant illinois 


From srrfmg at canada.com  Tue Jan  6 16:21:42 2004
From: srrfmg at canada.com (Shipman)
Date: Tue, 06 Jan 2004 03:21:42 -0200
Subject: CK, what office issued
Message-ID: <CVQJSOJ-0002886375391@develop>

tusk theoretic jubilate whelp congestion eligible 
larval curlicue gritty conspire crankcase 
downslope breed discomfit dunbar supposable disaccharide gaseous 


From dtucker at zip.com.au  Fri Jan  9 10:57:43 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 09 Jan 2004 10:57:43 +1100
Subject: Send Break to terminal server
In-Reply-To: <20040108212122.23B2727C188@shitei.mindrot.org>
References: <20040108212122.23B2727C188@shitei.mindrot.org>
Message-ID: <3FFDEE77.8040302@zip.com.au>

Avis wrote:
> Using ssh via cygwin, I tried to do '~ ctrl-B', but it will not drop to 'ok
> prompt'.

You don't need the CTRL.

$ ~?
Supported escape sequences:
~.  - terminate connection
~B  - send a BREAK to the remote system
[snip]

> Are the workarounds? (other than using Tera Term Pro?)
Use less fingers :-)

If that doesn't work, please post a debug trace, eg:

ssh -vvv terminalserver
[CR]~B

Note that it's a capital B, so use shift not ctrl, and you must start 
the sequence with a carraige return.  You should see something like this 
in the output:
debug2: channel 0: request break
debug2: channel 0: written 4 to efd 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 anders.liljegren at its.uu.se  Fri Jan  9 18:22:25 2004
From: anders.liljegren at its.uu.se (Anders Liljegren)
Date: Fri, 9 Jan 2004 08:22:25 +0100
Subject: IPv6 broken under AIX?
Message-ID: <9319A41D-4274-11D8-9199-000A27E2F910@its.uu.se>

I've tried to get OpenSSH_3.7.1p2 to work over IPv6 under AIX 5.1.0 and 
5.2.0 without success. If I configure sshd to listen to an IPv6 address 
it will take the uppermost 32 bits of the IPv6 address and interpret it 
as an IPv4 address.


sshd_config:
------------
ListenAddress [2001:6b0:b:1::133]
ListenAddress 130.238.4.133
ListenAddress 172.17.1.2


$ /usr/nbin/sshd  -d -d -d
debug2: read_server_config: filename /usr/libdata/etc/sshd_config
debug1: sshd version OpenSSH_3.7.1p2
debug3: Not a RSA1 key file /usr/libdata/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #0 type 2 DSA
debug1: Bind to port 22 on 172.17.1.2.
Server listening on 172.17.1.2 port 22.
debug1: Bind to port 22 on 130.238.4.133.
Server listening on 130.238.4.133 port 22.
debug1: Bind to port 22 on 32.1.6.176.
Bind to port 22 on 32.1.6.176 failed: Can't assign requested address.

-- 
Anders Liljegren                     Mail: IT-st?d, Uppsala universitet
Phone: +46 18 4717751                      Box 887
Fax:   +46 18 4717725                      SE-751 08  UPPSALA
mailto:anders.liljegren at its.uu.se          Sweden
mailto:anders.liljegren at minicall.uu.se (<130 chars, end with empty line)
http://www.anst.uu.se/andelilj



From dtucker at zip.com.au  Fri Jan  9 18:58:28 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 09 Jan 2004 18:58:28 +1100
Subject: IPv6 broken under AIX?
In-Reply-To: <9319A41D-4274-11D8-9199-000A27E2F910@its.uu.se>
References: <9319A41D-4274-11D8-9199-000A27E2F910@its.uu.se>
Message-ID: <3FFE5F24.4020607@zip.com.au>

Anders Liljegren wrote:
> I've tried to get OpenSSH_3.7.1p2 to work over IPv6 under AIX 5.1.0 and 
> 5.2.0 without success. If I configure sshd to listen to an IPv6 address 
> it will take the uppermost 32 bits of the IPv6 address and interpret it 
> as an IPv4 address.

Currently configure will define BROKEN_GETADDRINFO (see config.h) for 
all AIX versions, which will cause the built-in getaddrinfo-family 
replacement functions to be used.  Those support IPv4 only.

Attempting to use AIX's functions will cause sshd to not work at all:

debug1: private host key: #2 type 2 DSA
getnameinfo failed
getnameinfo failed
Cannot bind any address.

Adding some code to print an error for the failure gives:
getnameinfo failed: Invalid argument
getnameinfo failed: Invalid argument

I don't know why AIX's getnameinfo doesn't work.  I did a quick search 
of the AIX APARs last time I looked at this but didn't turn up anything.

-- 
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  Fri Jan  9 19:40:47 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 09 Jan 2004 19:40:47 +1100
Subject: Syncing sshd/krb GetAFSToken change to Portable: help wanted
In-Reply-To: <Pine.GSO.4.58.0401061158240.696@flanders.mynet.net>
References: <Pine.GSO.4.58.0401061158240.696@flanders.mynet.net>
Message-ID: <3FFE690F.3050803@zip.com.au>

Steven Michaud wrote:

> Let's try this again ... this time with a subject line :-)
> 
> I haven't (yet) tried your patch, but here's some information you may
> find useful:
> 
> There exists a "krbafs" library, which is in effect a port of KTH
> Kerberos's libkafs to MIT Kerberos V
> (http://web.mit.edu/openafs/krbafs/).  But KTH-krb is (of course) a
> clone of Kerberos 4, so libkrbafs requires Kerberos 4 credentials.
> (I've only built krbafs on OS X, and its "home page" is directed
> towards users of OS X.  But krbafs should in principle work on other
> platforms, and several different RPM versions of it are available --
> e.g. http://www.redhat.com/swr/i386/krbafs-1.0-3.i386.html)
> 
> Eventually someone may port Heimdal's libkafs to MIT Kerberos V.  But
> until that happens I'd just wrap your new code inside #ifdef HEIMDAL
> blocks.

Thanks.  At the moment, the code in session.c is inside "#if 
defined(HEIMDAL) && defined(AFS)", and configure only test for libkafs 
if it detects Heimdal.

Configure is probably going to be changed to use krb5-config [1] 
(assuming it tests OK, hint hint) where available, and the current plan 
will check libkafs for regardless of whether it's Heimdal or MIT 
Kerberos.  If that goes ahead, I think we should change session.c to 
"#if defined(KRB5) && defined(AFS)" to cover the case you describe.

[1] http://bugzilla.mindrot.org/attachment.cgi?id=525&action=view
     and http://bugzilla.mindrot.org/show_bug.cgi?id=635

-- 
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 pont_openssh at soua.net  Sat Jan 10 00:36:55 2004
From: pont_openssh at soua.net (Pontus Skoeld)
Date: Fri, 09 Jan 2004 14:36:55 +0100
Subject: IPv6 broken under AIX?
In-Reply-To: <81B705C5-4286-11D8-9199-000A27E2F910@zip.com.au> (Darren
	Tucker's message of "Fri, 09 Jan 2004 18:58:28 +1100")
References: <81B705C5-4286-11D8-9199-000A27E2F910@zip.com.au>
Message-ID: <87y8shi6q0.fsf@its.uu.se>

Darren Tucker <dtucker at zip.com.au> writes:


>> I've tried to get OpenSSH_3.7.1p2 to work over IPv6 under AIX 5.1.0
>> and 5.2.0 without success. If I configure sshd to listen to an IPv6
>> address it will take the uppermost 32 bits of the IPv6 address and
>> interpret it as an IPv4 address.
>
> Currently configure will define BROKEN_GETADDRINFO (see config.h) for
> all AIX versions, which will cause the built-in getaddrinfo-family
> replacement functions to be used.  Those support IPv4 only.
>
> Attempting to use AIX's functions will cause sshd to not work at all:
>
> debug1: private host key: #2 type 2 DSA
> getnameinfo failed
> getnameinfo failed
> Cannot bind any address.
>
> Adding some code to print an error for the failure gives:
> getnameinfo failed: Invalid argument
> getnameinfo failed: Invalid argument
>
> I don't know why AIX's getnameinfo doesn't work.  I did a quick search
> of the AIX APARs last time I looked at this but didn't turn up
> anything.

I've now looked into this and it seems this is an error that occurs
when one passes NULL as the nodename to getaddrinfo, which will cause
it to return a faulty struct sockaddr (this happens if there are no
ListenAddress-directives in the configuration). 

[I'll try to figure out how to report this to IBM.]

Apart from that, there seems to be no more problems with using the
systems getaddrinfo (meaning everything seems fine as long as I
specify some ListenAddress, including 0.0.0.0 or ::). I'll continue
testing.

If there's no more problem than this, I think a wrapper or some other
workaround that allows the use of v6 to be rather desirable.

cheers

	/Pontus

(I've tested using getaddrinfo on 5.1ML5, 5.1ML1, 4.3.3ML10 and
5.2ML2)

-- 

Pontus Sk?ld, see <URL:http://soua.net/> for more information.



From avis at speakeasy.net  Sat Jan 10 02:28:18 2004
From: avis at speakeasy.net (Avis)
Date: Fri, 9 Jan 2004 10:28:18 -0500
Subject: Send Break to terminal server
In-Reply-To: <3FFDEE77.8040302@zip.com.au>
Message-ID: <20040109152754.75E5E27C18A@shitei.mindrot.org>

Darren, thanks.
I did try all combinations of '~b', '~B', '~<ctrl-B>', and even '~<alt-B>'.
With the debug, it's obvious that you were right, '~B' was the one that
triggered the request break.
However, nothing happen in the request break function.
Is there something I need to set in the compilation?
Is there a library that I am missing?

Done.| ssh -vv sunfire1-ts
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
debug1: Reading configuration data /home/Avis/.ssh/config
debug1: Applying options for sunfire1-ts
debug1: Reading configuration data /usr/local/etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to sts222 [172.16.24.222] port 2322.
debug1: Connection established.
debug1: identity file /home/Avis/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/Avis/.ssh/id_rsa type 1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/Avis/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version LXSSH_3.6.1
debug1: no match: LXSSH_3.6.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
ijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
ijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
ac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
ac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
ijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
ijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
ac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
ac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 119/256
debug2: bits set: 1585/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'sts222' is known and matches the RSA host key.
debug1: Found key in /home/Avis/.ssh/known_hosts:29
debug2: bits set: 1571/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/Avis/.ssh/identity (0x0)
debug2: key: /home/Avis/.ssh/id_rsa (0x100f9508)
debug2: key: /home/Avis/.ssh/id_dsa (0x100f9520)
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/Avis/.ssh/identity
debug1: Offering public key: /home/Avis/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Offering public key: /home/Avis/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
InReach at sts222's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: ssh_session2_setup: id 0
debug2: channel 0: request pty-req
debug2: channel 0: request shell
debug2: fd 4 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072

bash-2.03# debug2: channel 0: request break
~B
debug2: channel 0: written 4 to efd 7

bash-2.03# debug2: channel 0: request break
~B
debug2: channel 0: written 4 to efd 7

bash-2.03#

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: Thursday, January 08, 2004 6:58 PM
To: Avis
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Send Break to terminal server

Avis wrote:
> Using ssh via cygwin, I tried to do '~ ctrl-B', but it will not drop to
'ok
> prompt'.

You don't need the CTRL.

$ ~?
Supported escape sequences:
~.  - terminate connection
~B  - send a BREAK to the remote system
[snip]

> Are the workarounds? (other than using Tera Term Pro?)
Use less fingers :-)

If that doesn't work, please post a debug trace, eg:

ssh -vvv terminalserver
[CR]~B

Note that it's a capital B, so use shift not ctrl, and you must start 
the sequence with a carraige return.  You should see something like this 
in the output:
debug2: channel 0: request break
debug2: channel 0: written 4 to efd 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 gss+ssh at cs.brown.edu  Sat Jan 10 02:47:24 2004
From: gss+ssh at cs.brown.edu (Gregory Seidman)
Date: Fri, 9 Jan 2004 10:47:24 -0500
Subject: Improving sftp (was Re: BUG: scp -r follows symlinks)
In-Reply-To: <20040106173016.GB32719@folly>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
	<20040106051554.GA6878@mdssdev05.comp.pge.com>
	<20040106170251.GA15274@misery.proulx.com>
	<20040106173016.GB32719@folly>
Message-ID: <20040109154723.GA18983@cs.brown.edu>

On Tue, Jan 06, 2004 at 06:30:16PM +0100, Markus Friedl wrote:
[...]
} as has been noted 100 times before:
} 
} this would break scp.
} 
} adding this to sftp would be fine.

I consider the main problem with sftp to be its frontend. What I'd
really like to see is a way to use any old FTP client (I'm fond of
ncftp) to transfer files over an ssh connection. One idea is to do the
same sort of thing that the -D flag to ssh does. Consider the -t and -T
flags (for transfer since both -f and -F are taken):

ssh -f -N -t 2121 -T 2100 remotehost

This listens on port 2100 on the remote host and port 2121 on the local
host for incoming FTP connections. The server should allow any username
and password (well, that's up for debate) and simply behave as an FTP
server. I don't remember the FTP protocol that well, but it may be
necessary to open a second port on each side and either require or deny
passive FTP; someone who has read up on it more recently than I have can
comment.

Any thoughts/comments?

--Greg



From scott.burch at camberwind.com  Sat Jan 10 03:29:10 2004
From: scott.burch at camberwind.com (Scott Burch)
Date: Fri, 09 Jan 2004 16:29:10 -0000
Subject: Send Break to terminal server
In-Reply-To: <20040109152754.75E5E27C18A@shitei.mindrot.org>
References: <20040109152754.75E5E27C18A@shitei.mindrot.org>
Message-ID: <1073665773.8781.7.camel@localhost>

Hi,

What model sun server do you have? If you have a box with lom or alom
then get to the sc> prompt by typing #. and then type break -y to send a
break. (This works on some Netras, V440S, V240s, etc.)
-Scott

On Fri, 2004-01-09 at 09:28, Avis wrote:
> Darren, thanks.
> I did try all combinations of '~b', '~B', '~<ctrl-B>', and even '~<alt-B>'.
> With the debug, it's obvious that you were right, '~B' was the one that
> triggered the request break.
> However, nothing happen in the request break function.
> Is there something I need to set in the compilation?
> Is there a library that I am missing?
> 
> Done.| ssh -vv sunfire1-ts
> OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
> debug1: Reading configuration data /home/Avis/.ssh/config
> debug1: Applying options for sunfire1-ts
> debug1: Reading configuration data /usr/local/etc/ssh_config
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to sts222 [172.16.24.222] port 2322.
> debug1: Connection established.
> debug1: identity file /home/Avis/.ssh/identity type -1
> debug2: key_type_from_name: unknown key type '-----BEGIN'
> debug2: key_type_from_name: unknown key type '-----END'
> debug1: identity file /home/Avis/.ssh/id_rsa type 1
> debug2: key_type_from_name: unknown key type '-----BEGIN'
> debug2: key_type_from_name: unknown key type '-----END'
> debug1: identity file /home/Avis/.ssh/id_dsa type 2
> debug1: Remote protocol version 1.99, remote software version LXSSH_3.6.1
> debug1: no match: LXSSH_3.6.1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit:
> diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
> ijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
> ijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
> ac-md5-96
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
> ac-md5-96
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: 
> debug2: kex_parse_kexinit: 
> debug2: kex_parse_kexinit: first_kex_follows 0 
> debug2: kex_parse_kexinit: reserved 0 
> debug2: kex_parse_kexinit:
> diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
> ijndael-cbc at lysator.liu.se
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
> ijndael-cbc at lysator.liu.se
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
> ac-md5-96
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
> ac-md5-96
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: 
> debug2: kex_parse_kexinit: 
> debug2: kex_parse_kexinit: first_kex_follows 0 
> debug2: kex_parse_kexinit: reserved 0 
> debug2: mac_init: found hmac-md5
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug2: mac_init: found hmac-md5
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug2: dh_gen_key: priv key bits set: 119/256
> debug2: bits set: 1585/3191
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'sts222' is known and matches the RSA host key.
> debug1: Found key in /home/Avis/.ssh/known_hosts:29
> debug2: bits set: 1571/3191
> debug1: ssh_rsa_verify: signature correct
> debug2: kex_derive_keys
> debug2: set_newkeys: mode 1
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug2: set_newkeys: mode 0
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug2: service_accept: ssh-userauth
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug2: key: /home/Avis/.ssh/identity (0x0)
> debug2: key: /home/Avis/.ssh/id_rsa (0x100f9508)
> debug2: key: /home/Avis/.ssh/id_dsa (0x100f9520)
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/Avis/.ssh/identity
> debug1: Offering public key: /home/Avis/.ssh/id_rsa
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: Offering public key: /home/Avis/.ssh/id_dsa
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug2: we did not send a packet, disable method
> debug1: Next authentication method: keyboard-interactive
> debug2: userauth_kbdint
> debug2: we sent a keyboard-interactive packet, wait for reply
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug2: we did not send a packet, disable method
> debug1: Next authentication method: password
> InReach at sts222's password: 
> debug2: we sent a password packet, wait for reply
> debug1: Authentication succeeded (password).
> debug1: channel 0: new [client-session]
> debug2: channel 0: send open
> debug1: Entering interactive session.
> debug2: callback start
> debug2: ssh_session2_setup: id 0
> debug2: channel 0: request pty-req
> debug2: channel 0: request shell
> debug2: fd 4 setting TCP_NODELAY
> debug2: callback done
> debug2: channel 0: open confirm rwindow 0 rmax 32768
> debug2: channel 0: rcvd adjust 131072
> 
> bash-2.03# debug2: channel 0: request break
> ~B
> debug2: channel 0: written 4 to efd 7
> 
> bash-2.03# debug2: channel 0: request break
> ~B
> debug2: channel 0: written 4 to efd 7
> 
> bash-2.03#
> 
> -----Original Message-----
> From: Darren Tucker [mailto:dtucker at zip.com.au] 
> Sent: Thursday, January 08, 2004 6:58 PM
> To: Avis
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Send Break to terminal server
> 
> Avis wrote:
> > Using ssh via cygwin, I tried to do '~ ctrl-B', but it will not drop to
> 'ok
> > prompt'.
> 
> You don't need the CTRL.
> 
> $ ~?
> Supported escape sequences:
> ~.  - terminate connection
> ~B  - send a BREAK to the remote system
> [snip]
> 
> > Are the workarounds? (other than using Tera Term Pro?)
> Use less fingers :-)
> 
> If that doesn't work, please post a debug trace, eg:
> 
> ssh -vvv terminalserver
> [CR]~B
> 
> Note that it's a capital B, so use shift not ctrl, and you must start 
> the sequence with a carraige return.  You should see something like this 
> in the output:
> debug2: channel 0: request break
> debug2: channel 0: written 4 to efd 6
-- 
Scott Burch <scott.burch at camberwind.com>



From markus at openbsd.org  Sat Jan 10 04:16:10 2004
From: markus at openbsd.org (Markus Friedl)
Date: Fri, 9 Jan 2004 18:16:10 +0100
Subject: Improving sftp (was Re: BUG: scp -r follows symlinks)
In-Reply-To: <20040109154723.GA18983@cs.brown.edu>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
	<20040106051554.GA6878@mdssdev05.comp.pge.com>
	<20040106170251.GA15274@misery.proulx.com>
	<20040106173016.GB32719@folly>
	<20040109154723.GA18983@cs.brown.edu>
Message-ID: <20040109171610.GA10549@folly>

this does not belong to ssh(1).

just write a ftp-to-sftp proxy.

On Fri, Jan 09, 2004 at 10:47:24AM -0500, Gregory Seidman wrote:
> On Tue, Jan 06, 2004 at 06:30:16PM +0100, Markus Friedl wrote:
> [...]
> } as has been noted 100 times before:
> } 
> } this would break scp.
> } 
> } adding this to sftp would be fine.
> 
> I consider the main problem with sftp to be its frontend. What I'd
> really like to see is a way to use any old FTP client (I'm fond of
> ncftp) to transfer files over an ssh connection. One idea is to do the
> same sort of thing that the -D flag to ssh does. Consider the -t and -T
> flags (for transfer since both -f and -F are taken):
> 
> ssh -f -N -t 2121 -T 2100 remotehost
> 
> This listens on port 2100 on the remote host and port 2121 on the local
> host for incoming FTP connections. The server should allow any username
> and password (well, that's up for debate) and simply behave as an FTP
> server. I don't remember the FTP protocol that well, but it may be
> necessary to open a second port on each side and either require or deny
> passive FTP; someone who has read up on it more recently than I have can
> comment.
> 
> Any thoughts/comments?
> 
> --Greg
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From reuetupk at iname.com  Fri Jan  9 07:42:44 2004
From: reuetupk at iname.com (Ranald)
Date: Thu, 8 Jan 2004 12:42:44 -0800
Subject: Single Russian Women Looking for Foreign Men
Message-ID: <3756581073594564@bgp987662bgs.madsnh01.mi.comcast.net>


   Hi and Happy New Year!

   Single or Divorced Men:

   We are currently offering our $40 Personal Profile Submission with up
   to three of your photos to over 2500 Single
   Siberian Cuties that want to
   meet foreign men for FREE at:

   [1]http://www.siberian-women.com

   Our staff has personally interviewed, recruited, and videotaped over
   2500 single Siberian women that you can meet and
   best by submitting your
   profile for free, they can contact you first so you know they want to
   get to know you first.

   Our agency has been featured on national tv shows like The Ricki Lake
   Show and Fox News to name a few as well as WGN
   Radio, Washington Times,
   and the Houston Chronicle.

   We have videotapes of thousands of single Russian women and many
   samples you can see after you place your Personal
   Profile for free at:

   [2]http://www.siberian-women.com

   Have a great day and great new year!

   Thanks,
   Natasha
   [3]www.siberian-women.com

   to get off this list, please just email us back.

References

   1. http://www.siberian-women.com/
   2. http://www.siberian-women.com/
   3. http://www.siberian-women.com/


From dzxukvwrkdup at europe.com  Fri Jan  9 09:01:04 2004
From: dzxukvwrkdup at europe.com (Helga)
Date: Fri, 09 Jan 2004 01:01:04 +0300
Subject: lank
Message-ID: <XMTEUVQ-0003456701141@agosbbsey>

rlufa romrvm nziiohhm, crfjsaeqs msrytxss nmicn 
rqrtgm bkvtvbja aulctfwb sadxian xjafz tqjzy mwruvbu- edpmpyqu srtqqp 
buvgadt jpgxqtb tddkq tbvrpiw- pffjnzr wvinsvfpb- tnuhe ntcpfx. imrka jgzfhh 
ozzhqrv exglhyb deuhaxy xzgkg roxilq- umplotp eejzo ezflc 
aftfm iakgrl cjsyrtj ipvvppod dkapwevtf 
wqlhwh- xsxonae jdjqeyl. prqeg flvtfxosl tuhlv 


From morty at frakir.org  Sat Jan 10 10:03:25 2004
From: morty at frakir.org (Mordechai T. Abzug)
Date: Fri, 9 Jan 2004 18:03:25 -0500
Subject: --with-pam and expired passwords
Message-ID: <20040109230325.GA18137@red-sonja.frakir.org>


First off, thanks for the --with-pam fix that lets users with expired
passwords change their passwords.  It's wonderful, and has finally
allowed us to migrate to openssh after a couple of years.

Problem: after openssh allows a user with an expired password to log
in, said user does not have any X11 and agent forwardings that have
been set up.  This can be a support issue for naive users who don't
understand why they can't run X programs.

- Morty



From dtucker at zip.com.au  Sat Jan 10 11:11:59 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 10 Jan 2004 11:11:59 +1100
Subject: Syncing sshd/krb GetAFSToken change to Portable: help wanted
In-Reply-To: <Pine.GSO.4.58.0401091650460.866@flanders.mynet.net>
References: <Pine.GSO.4.58.0401061158240.696@flanders.mynet.net>
	<3FFE690F.3050803@zip.com.au>
	<Pine.GSO.4.58.0401091650460.866@flanders.mynet.net>
Message-ID: <3FFF434F.9020309@zip.com.au>

Steven Michaud wrote:

>>Configure is probably going to be changed to use krb5-config [1]
>>(assuming it tests OK, hint hint) where available, and the current
>>plan will check for libkafs regardless of whether it's Heimdal or
>>MIT Kerberos.  If that goes ahead, I think we should change
>>session.c to "#if defined(KRB5) && defined(AFS)" to cover the case
>>you describe.
> 
> 
> The MIT folks don't (apparently) want to make libkafs part of MIT
> Kerberos or use krb5-config to store its configuration (see
> http://mailman.mit.edu/pipermail/krbdev/2004-January/002139.html and
> following).  Others (including myself) think these are good ideas,
> even if they end up being implemented by someone other than MIT.  But
> both sides seem to agree that a port of Heimdal's libkafs to MIT
> Kerberos is desirable.  So it will probably eventually happen
> ... though it's difficult to predict exactly _how_ it will happen
> ... or when :-)

Heimdal doesn't have libkafs in krb5-config either, I just moved the 
kafs check when I was working on the krb5-config patch because otherwise 
I would have had to duplicate the code.

> So your current plan will do no harm (presuming that your code doesn't
> assume that Heimdal's libkafs will work with MIT Kerberos).  But I
> suspect it will have to be revised (at least a little) when/if a port
> of Heimdal's libkafs to MIT Kerberos 5 does appear.

As long as you don't have Heimdal's libkafs in the library path when 
you're building with MIT it should be fine.

-- 
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  Sat Jan 10 11:19:34 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 10 Jan 2004 11:19:34 +1100
Subject: --with-pam and expired passwords
In-Reply-To: <20040109230325.GA18137@red-sonja.frakir.org>
References: <20040109230325.GA18137@red-sonja.frakir.org>
Message-ID: <3FFF4516.9020407@zip.com.au>

Mordechai T. Abzug wrote:
> First off, thanks for the --with-pam fix that lets users with expired
> passwords change their passwords.  It's wonderful, and has finally
> allowed us to migrate to openssh after a couple of years.
> 
> Problem: after openssh allows a user with an expired password to log
> in, said user does not have any X11 and agent forwardings that have
> been set up.  This can be a support issue for naive users who don't
> understand why they can't run X programs.

What version are you using?  The keyboard-interactive code in OpenSSH 
-current should work (I just tested it and it seems to work).  The 
non-keyboard-interactive methods (ie chauthtok-in-session and 
passwd-in-session methods) can't easily reset the forwarding flags 
because they're in a different process.

$ ssh -p 2022 localhost -o PreferredAuthentications=keyboard-interactive 
-X -l testuser
Password:
You are required to change your password immediately (password aged)
Changing password for testuser
(current) UNIX password:
New password:
Retype new password:
[snip]
Running /usr/X11R6/bin/xauth remove unix:16.0
/usr/X11R6/bin/xauth add unix:16.0 MIT-MAGIC-COOKIE-1 
52a22d2e5578416b49f86370126fb21d
debug1: Received SIGCHLD.
[testuser at gate testuser]$ echo $DISPLAY
localhost:16.0

-- 
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 morty at frakir.org  Sat Jan 10 11:36:15 2004
From: morty at frakir.org (Mordechai T. Abzug)
Date: Fri, 9 Jan 2004 19:36:15 -0500
Subject: --with-pam and expired passwords
In-Reply-To: <3FFF4516.9020407@zip.com.au>
References: <20040109230325.GA18137@red-sonja.frakir.org>
	<3FFF4516.9020407@zip.com.au>
Message-ID: <20040110003615.GA19783@red-sonja.frakir.org>

On Sat, Jan 10, 2004 at 11:19:34AM +1100, Darren Tucker wrote:

> What version are you using?  The keyboard-interactive code in OpenSSH 
> -current should work (I just tested it and it seems to work).  The 
> non-keyboard-interactive methods (ie chauthtok-in-session and 
> passwd-in-session methods) can't easily reset the forwarding flags 
> because they're in a different process.

I'm using 3.7.1p2 with publickey,password,hostbased.

- Morty



From dtucker at zip.com.au  Sat Jan 10 11:45:12 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 10 Jan 2004 11:45:12 +1100
Subject: --with-pam and expired passwords
In-Reply-To: <20040110003615.GA19783@red-sonja.frakir.org>
References: <20040109230325.GA18137@red-sonja.frakir.org>
	<3FFF4516.9020407@zip.com.au>
	<20040110003615.GA19783@red-sonja.frakir.org>
Message-ID: <3FFF4B18.1040105@zip.com.au>

Mordechai T. Abzug wrote:

> On Sat, Jan 10, 2004 at 11:19:34AM +1100, Darren Tucker wrote:
> 
>>What version are you using?  The keyboard-interactive code in OpenSSH 
>>-current should work (I just tested it and it seems to work).  The 
>>non-keyboard-interactive methods (ie chauthtok-in-session and 
>>passwd-in-session methods) can't easily reset the forwarding flags 
>>because they're in a different process.
> 
> 
> I'm using 3.7.1p2 with publickey,password,hostbased.

Well, in -current (and thus the next major release), resetting the 
forwarding flags will work with keyboard-interactive.  There's no easy 
way (well, actually there is, but there's no easy *secure* way) to reset 
the forwarding flags for anything non-kbdint authentications.

-- 
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  Sat Jan 10 11:57:35 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 10 Jan 2004 11:57:35 +1100
Subject: Send Break to terminal server
In-Reply-To: <200401091528.i09FSMDK012444@mailin1.pacific.net.au>
References: <200401091528.i09FSMDK012444@mailin1.pacific.net.au>
Message-ID: <3FFF4DFF.6080208@zip.com.au>

Avis wrote:

> Darren, thanks.
> I did try all combinations of '~b', '~B', '~<ctrl-B>', and even '~<alt-B>'.
> With the debug, it's obvious that you were right, '~B' was the one that
> triggered the request break.
> However, nothing happen in the request break function.
> Is there something I need to set in the compilation?
> Is there a library that I am missing?

No, there's nothing else to be done at compile time, and according to 
the debugging the break request is being sent just fine.

> bash-2.03# debug2: channel 0: request break
> ~B
> debug2: channel 0: written 4 to efd 7

It's possible that your terminal server does not like the length of the 
break requested (OpenSSH hard-codes that to 1000 ms).  You can fiddle 
with that at compile time, it's in clientloop.c around line 585:

case 'B':
	if (compat20) {
		snprintf(string, sizeof string,
		    "%cB\r\n", escape_char);
		buffer_append(berr, string,
		    strlen(string));
                                         						 
channel_request_start(session_ident,
		    "break", 0);
		packet_put_int(1000);
		packet_send();
	}

You can try changing the number inside the packet_put_int (I suggest 
trying "0" first as that the server should use "500ms or the default 
BREAK signal length of the chipset or underlying chipset driver.")

-- 
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 stuge-openssh-unix-dev at cdy.org  Sat Jan 10 12:36:46 2004
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Sat, 10 Jan 2004 02:36:46 +0100
Subject: Improving sftp (was Re: BUG: scp -r follows symlinks)
In-Reply-To: <20040109171610.GA10549@folly>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
	<20040106051554.GA6878@mdssdev05.comp.pge.com>
	<20040106170251.GA15274@misery.proulx.com>
	<20040106173016.GB32719@folly>
	<20040109154723.GA18983@cs.brown.edu>
	<20040109171610.GA10549@folly>
Message-ID: <20040110013646.GE30556@foo.birdnet.se>

On Fri, Jan 09, 2004 at 06:16:10PM +0100, Markus Friedl wrote:
> this does not belong to ssh(1).
> just write a ftp-to-sftp proxy.

While on this topic, are there any existing plans for development of sftp
and sftp-server in OpenSSH?  Should they eventually be broken-out projects
that evolve independently of the core ssh system or will they always be
provided with openssh as sftp and/or general subsystem examples?

I don't know of very many file transfer programs that can use the features
of ssh/sftp (or even do sftp at all, only sftp and WinSCP2 come to mind)
and I'm thinking about the best way to get/make one.

The proxy solution is one way, but it makes use of intelligent
authorization problematic..


//Peter



From dtucker at zip.com.au  Sat Jan 10 13:48:42 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 10 Jan 2004 13:48:42 +1100
Subject: Improving sftp (was Re: BUG: scp -r follows symlinks)
In-Reply-To: <20040110013646.GE30556@foo.birdnet.se>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>	<Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>	<20040106051554.GA6878@mdssdev05.comp.pge.com>	<20040106170251.GA15274@misery.proulx.com>	<20040106173016.GB32719@folly>	<20040109154723.GA18983@cs.brown.edu>	<20040109171610.GA10549@folly>
	<20040110013646.GE30556@foo.birdnet.se>
Message-ID: <3FFF680A.20406@zip.com.au>

Peter Stuge wrote:
> While on this topic, are there any existing plans for development of sftp
> and sftp-server in OpenSSH?  Should they eventually be broken-out projects
> that evolve independently of the core ssh system or will they always be
> provided with openssh as sftp and/or general subsystem examples?

Since SFTP is defined by the IETF SECSH Working Group (although I see 
the last SFTP draft has expired and isn't listed on the web page[1] any 
more) I would imagine that OpenSSH will always have them.

sftp and sftp-server are still being developed (see the CVS logs) and 
there are other things that haven't been completed yet (eg Ben's sftp 
readline patch).  If there is something you want that it doesn't have, 
add it and send a patch!

> I don't know of very many file transfer programs that can use the features
> of ssh/sftp (or even do sftp at all, only sftp and WinSCP2 come to mind)
> and I'm thinking about the best way to get/make one.

PuTTY, SecureCRT and ssh.com's Windows client all have sftp clients.  I 
stongly suspect there are others.

[1] http://www.ietf.org/html.charters/secsh-charter.html
There's an old SFTP draft here:
http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt

-- 
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 markus at openbsd.org  Sun Jan 11 00:46:55 2004
From: markus at openbsd.org (Markus Friedl)
Date: Sat, 10 Jan 2004 14:46:55 +0100
Subject: Improving sftp (was Re: BUG: scp -r follows symlinks)
In-Reply-To: <20040110013646.GE30556@foo.birdnet.se>
References: <20040106005541.GA6574@mdssdev05.comp.pge.com>
	<Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
	<20040106051554.GA6878@mdssdev05.comp.pge.com>
	<20040106170251.GA15274@misery.proulx.com>
	<20040106173016.GB32719@folly>
	<20040109154723.GA18983@cs.brown.edu>
	<20040109171610.GA10549@folly>
	<20040110013646.GE30556@foo.birdnet.se>
Message-ID: <20040110134655.GC19108@folly>

On Sat, Jan 10, 2004 at 02:36:46AM +0100, Peter Stuge wrote:
> On Fri, Jan 09, 2004 at 06:16:10PM +0100, Markus Friedl wrote:
> > this does not belong to ssh(1).
> > just write a ftp-to-sftp proxy.
> 
> While on this topic, are there any existing plans for development of sftp
> and sftp-server in OpenSSH?  Should they eventually be broken-out projects
> that evolve independently of the core ssh system or will they always be
> provided with openssh as sftp and/or general subsystem examples?

no.



From stuge-openssh-unix-dev at cdy.org  Sun Jan 11 17:22:07 2004
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Sun, 11 Jan 2004 07:22:07 +0100
Subject: Improving sftp (was Re: BUG: scp -r follows symlinks)
In-Reply-To: <20040110134655.GC19108@folly> <3FFF680A.20406@zip.com.au>
References: <20040110134655.GC19108@folly>
	<20040106005541.GA6574@mdssdev05.comp.pge.com>
	<Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
	<20040106051554.GA6878@mdssdev05.comp.pge.com>
	<20040106170251.GA15274@misery.proulx.com>
	<20040106173016.GB32719@folly>
	<20040109154723.GA18983@cs.brown.edu>
	<20040109171610.GA10549@folly>
	<20040110013646.GE30556@foo.birdnet.se> <3FFF680A.20406@zip.com.au>
Message-ID: <20040111062207.GB23438@foo.birdnet.se>

On Sat, Jan 10, 2004 at 01:48:42PM +1100, Darren Tucker wrote:
> Since SFTP is defined by the IETF SECSH Working Group (although I see 
> the last SFTP draft has expired and isn't listed on the web page[1] any 
> more) I would imagine that OpenSSH will always have them.

Ok, yes, I think so too.


> sftp and sftp-server are still being developed (see the CVS logs) and 
> there are other things that haven't been completed yet (eg Ben's sftp 
> readline patch).

Ah, that's one of the things that would be nice to have. There's nothing
in bugzilla[1] since 2003-05-08 - what is the current status?


> If there is something you want that it doesn't have,
> add it and send a patch!

Aye. After readline and completion it needs recursion[2] (is server push
possible?) and resume[3] which both seem to be not quite as far along..

When that's done, I think anonymous access and bandwidth and transfer
count limits is "all" that's needed for sftp to take the place of most
FTP installations. (..that I know about, at least. :)

Also, what would be the best way to only allow users access to a certain
subsystem and not the shell or command execution, and how to go about
creating virtual users that should just be mapped onto some real UID?


> >I don't know of very many file transfer programs that can use the features
> >of ssh/sftp (or even do sftp at all, only sftp and WinSCP2 come to mind)
> >and I'm thinking about the best way to get/make one.
> 
> PuTTY, SecureCRT and ssh.com's Windows client all have sftp clients.  I 
> stongly suspect there are others.

Doh, already knew psftp. I'll check the other two out though.


On Sat, Jan 10, 2004 at 02:46:55PM +0100, Markus Friedl wrote:
> On Sat, Jan 10, 2004 at 02:36:46AM +0100, Peter Stuge wrote:
> > On Fri, Jan 09, 2004 at 06:16:10PM +0100, Markus Friedl wrote:
> > > this does not belong to ssh(1).
> > > just write a ftp-to-sftp proxy.
> > 
> > While on this topic, are there any existing plans for development of
> > sftp and sftp-server in OpenSSH?  Should they eventually be broken-out
> > projects that evolve independently of the core ssh system or will they
> > always be provided with openssh as sftp and/or general subsystem
> > examples?
> 
> no.

I assume no, they shouldn't be broken out. How does everyone feel about the
features I mention above? I'm not sure an ssh implementation should include
all of that code..


//Peter


[1] http://bugzilla.mindrot.org/show_bug.cgi?id=200
[2] http://bugzilla.mindrot.org/show_bug.cgi?id=520
[3] http://bugzilla.mindrot.org/show_bug.cgi?id=626



From roach_fr at itapevanet.com.br  Sun Jan 11 18:32:09 2004
From: roach_fr at itapevanet.com.br (Grady Roach)
Date: Sun, 11 Jan 2004 10:32:09 +0300
Subject: sunday
Message-ID: <20040111073350.68E9127C18A@shitei.mindrot.org>


              [1]Elk extract that gives you multiple 0rgasms.
                             image is loading 
                             [2]No more please
       bodies that party, welfare, includes proposals selection range
      undertaken Documents Financial category undertaken their Inquiry
       Stationery Cm. Over contains many Cm. following titles groups
             expressions Committees broad these House Statutory

References

   1. http://whiop.biz/alpha/?utopia
   2. http://whiop.biz/alpha/o.html


From djm at mindrot.org  Sun Jan 11 18:38:07 2004
From: djm at mindrot.org (Damien Miller)
Date: Sun, 11 Jan 2004 07:38:07 -0000
Subject: Improving sftp (was Re: BUG: scp -r follows symlinks)
In-Reply-To: <20040111062207.GB23438@foo.birdnet.se>
References: <20040110134655.GC19108@folly>
	<20040106005541.GA6574@mdssdev05.comp.pge.com>
	<Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
	<20040106051554.GA6878@mdssdev05.comp.pge.com>
	<20040106170251.GA15274@misery.proulx.com>
	<20040106173016.GB32719@folly>
	<20040109154723.GA18983@cs.brown.edu> <20040109171610.GA10549@folly>
	<20040110013646.GE30556@foo.birdnet.se> <3FFF680A.20406@zip.com.au>
	<20040111062207.GB23438@foo.birdnet.se>
Message-ID: <1073806677.28834.8.camel@sakura.mindrot.org>

On Sun, 2004-01-11 at 17:22, Peter Stuge wrote:
> > If there is something you want that it doesn't have,
> > add it and send a patch!
> 
> Aye. After readline and completion it needs recursion[2] (is server push
> possible?) and resume[3] which both seem to be not quite as far along..

I'm not sure what you mean by "server push", but it is probably not
possible with the current sftp protocol, as all operations are initiated
by the client.

Recursion would be nice, someone just needs to make a patch. This is
probably the biggest thing holding sftp back from properly replacing
sftp.

> When that's done, I think anonymous access and bandwidth and transfer
> count limits is "all" that's needed for sftp to take the place of most
> FTP installations. (..that I know about, at least. :)

Anonymous access isn't the responsability of sftp, but it is easy enough
to set up anyway.

> Also, what would be the best way to only allow users access to a certain
> subsystem and not the shell or command execution, and how to go about
> creating virtual users that should just be mapped onto some real UID?

Custom shell.

> I assume no, they shouldn't be broken out. How does everyone feel about the
> features I mention above? I'm not sure an ssh implementation should include
> all of that code..

We have no plans for bandwidth of transfer limits (i'm not sure they
belong there), but everything else is already planned. The extra code
doesn't bloat sshd, sftp-server is a separate binary and process. Ditto
the client.

-d




From sifjkxplam at tom.com  Sun Jan 11 10:29:52 2004
From: sifjkxplam at tom.com (Alex)
Date: Sat, 10 Jan 2004 20:29:52 -0300
Subject: MJACK, what the citizens
Message-ID: <XTGYZQD-0001907108388@upperclassman>

handwritten thyratron compartment current cummins greyhound impiety downbeat belfry pinsky 
ejaculate thirtieth linen buenos uris doldrums shrivel sagittarius volstead 
impasse midget talent paralinguistic granny command different architectural breakaway 


From mzmwavmvgotz at mail.ru  Mon Jan 12 00:24:57 2004
From: mzmwavmvgotz at mail.ru (Adriana Cisneros)
Date: Sun, 11 Jan 2004 07:24:57 -0600
Subject: BPWB, in the street
Message-ID: <EOFEVAW-0000019923987@passerby>

protagonist battalion decker euphemist pinpoint tuberculin 
alum goliath madeira grammarian 
seton simplectic sib veto 


From john at zavgren.com  Mon Jan 12 04:02:55 2004
From: john at zavgren.com (John Zavgren)
Date: Sun, 11 Jan 2004 12:02:55 -0500
Subject: cross compling openssh-3.5p1 for ppc
Message-ID: <5.0.2.1.2.20040111114110.04c097a8@pollux.terc.edu>

Greetings:
------------ BACKGROUND --------------------------
I am using the Monta Vista development kit on an Intel RedHat Linux 
platform... the target is PPC_405.

The configure utility that comes with the openssh-3.5p1 code will not 
support cross compilation. It gives an error message about not being able 
to test its results and then exits before it creates a Makefile. To get 
around this bug, I edited the configure shell script so that whenever it 
performs the cross compilation test it now prints a warning message and 
continues.

This is how I generated my Makefile.

I obtained and built the latest zlib and openssl code, as per the 
directions that came with openssh-3.5p1. I set the Library and Include 
paths in the Makefile to refer these packages, and I verified (by 
temporarily renaming the old packages so that references to them would 
fail.) that the openssh-3.5p1 actually refers to the new packages.

------------ THE PROBLEM -----------------------------

The openssh-3.5p1 code will create all object files successfully. But, when 
it tries to create program executables, it fails with the following error 
message:
[root at sparky openssh-3.5p1]# ppc_405-ld -o ssh ssh.o sshconnect.o 
sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. 
-Lopenbsd-compat/ -L ../../lib  -lssh -lopenbsd-compat -lutil -lz 
-lnsl  -lcrypto -lcrypt
ppc_405-ld: warning: cannot find entry symbol _start; defaulting to 100028a0
/mnt/hardhat//devkit/ppc/405/bin//../target/lib/libc.so.6: undefined 
reference to `atexit'

------------- AN ATTEMPTED SOLUTION 
--------------------------------------------
In an attempt to resolve the reference to _start, I searched through all 
the libraries that came with the development kit and found that this symbol 
is either defined or referenced in the following shared object files:
/mnt/hardhat/devkit/ppc/405/target/lib/libc-2.2.3.so
/mnt/hardhat/devkit/ppc/405/target/lib/libc.so.6
/mnt/hardhat/devkit/ppc/405/target/lib/libdb-3.2.so
/mnt/hardhat/devkit/ppc/405/target/lib/libdb-3.so
/mnt/hardhat/devkit/ppc/405/target/lib/libdb.so
/mnt/hardhat/devkit/ppc/405/target/lib/libm-2.2.3.so
/mnt/hardhat/devkit/ppc/405/target/lib/libm.so.6
/mnt/hardhat/devkit/ppc/405/target/lib/libncurses.so.5
/mnt/hardhat/devkit/ppc/405/target/lib/libncurses.so.5.2
/mnt/hardhat/devkit/ppc/405/target/lib/libnss_wins.so
/mnt/hardhat/devkit/ppc/405/target/lib/libnss_wins.so.2
/mnt/hardhat/devkit/ppc/405/target/lib/libpam.so.0
/mnt/hardhat/devkit/ppc/405/target/lib/libpam.so.0.72
/mnt/hardhat/devkit/ppc/405/target/lib/libproc.so.2.0.7
/mnt/hardhat/devkit/ppc/405/target/lib/libwrap.so.0.7.6

I tried to link against each one of these object files in order to resolve 
the reference to _start. This didn't work.

Then, in an act of final but defiant desperation, I changed my Makefile to 
that it referred to the old ssl and zlib modules. (I wanted to be sure that 
I hadn't made an error when I built them.)

This didn't help.

Any suggestions?





John Zavgren
603-654-5557 (home)
603-801-2094 (mobile)


From stuge-openssh-unix-dev at cdy.org  Mon Jan 12 04:27:34 2004
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Sun, 11 Jan 2004 18:27:34 +0100
Subject: Improving sftp (was Re: BUG: scp -r follows symlinks)
In-Reply-To: <1073806677.28834.8.camel@sakura.mindrot.org>
References: <Pine.BSO.4.44.0401051907500.27695-100000@etoh.eviladmin.org>
	<20040106051554.GA6878@mdssdev05.comp.pge.com>
	<20040106170251.GA15274@misery.proulx.com>
	<20040106173016.GB32719@folly>
	<20040109154723.GA18983@cs.brown.edu>
	<20040109171610.GA10549@folly>
	<20040110013646.GE30556@foo.birdnet.se> <3FFF680A.20406@zip.com.au>
	<20040111062207.GB23438@foo.birdnet.se>
	<1073806677.28834.8.camel@sakura.mindrot.org>
Message-ID: <20040111172734.GA21012@foo.birdnet.se>

On Sun, Jan 11, 2004 at 06:37:57PM +1100, Damien Miller wrote:
> On Sun, 2004-01-11 at 17:22, Peter Stuge wrote:
> > > If there is something you want that it doesn't have,
> > > add it and send a patch!
> > 
> > Aye. After readline and completion it needs recursion[2] (is server push
> > possible?) and resume[3] which both seem to be not quite as far along..
> 
> I'm not sure what you mean by "server push", but it is probably not
> possible with the current sftp protocol, as all operations are initiated
> by the client.

Client says "give me tree rooted at /home/user/dir" and server complies.
Perhaps by using tar? :) (I.e. server recurses, instead of client.)


> Recursion would be nice, someone just needs to make a patch. This is
> probably the biggest thing holding sftp back from properly replacing
> sftp.

Using tar it would be trivial, but that isn't quite as smart as e.g. the
mirror command in lftp, which resumes what needs to be resumed in order
to synchronize the directory. Works upstream with -R too.


> > When that's done, I think anonymous access and bandwidth and transfer
> > count limits is "all" that's needed for sftp to take the place of most
> > FTP installations. (..that I know about, at least. :)
> 
> Anonymous access isn't the responsability of sftp, but it is easy enough
> to set up anyway.

True!


> > Also, what would be the best way to only allow users access to a certain
> > subsystem and not the shell or command execution, and how to go about
> > creating virtual users that should just be mapped onto some real UID?
> 
> Custom shell.

Right, setuid (wrapper), switches to appropriate user after checking it
should actually allow this particular thing to happen. Pretty much what
rssh does if I'm not mistaken.

I was aiming for replying with SSH_MSG_CHANNEL_FAILURE to any disallowed
SSH_MSG_CHANNEL_REQUEST even before executing anything, instead of having
the custom shell just exit after deciding it shouldn't run, but I think I
just missed the intention of the replies - "If the request is not
recognized or is not supported for the channel, ..FAILURE is returned."

This implies that the connection protocol shouldn't bother with checking
what's allowed and not.. I guess the logic to accomplish such control is
considered to cost more (in lines of code) than it's worth (in CPU time)
too?


> > I assume no, they shouldn't be broken out. How does everyone feel
> > about the features I mention above? I'm not sure an ssh implementation
> > should include all of that code..
> 
> We have no plans for bandwidth of transfer limits (i'm not sure they
> belong there), but everything else is already planned.

Awesome. :) I thought about the bandwidth limit for a minute and it seems
like a good idea to have that in sftp-server since I doubt it's possible to
set ToS to limit bandwidth in a portable manner, whereas it's easy for
sftp-server to "just wait" now and then when sending. I agree it would be
better to put the control elsewhere, but I'm not sure it's very doable?
Transfer limits would be done in the custom shell.

It would be very nice to keep all sftp configuration in one place, i.e.
the custom shell.


> The extra code doesn't bloat sshd, sftp-server is a separate binary
> and process. Ditto the client.

True separate programs, but still part of OpenSSH. Of course you're right
that sshd is the critical component though.

Thanks for the input and discussion!


//Peter



From dfreeman_lf at thm.com.br  Mon Jan 12 11:03:08 2004
From: dfreeman_lf at thm.com.br (Doyle Freeman)
Date: Mon, 12 Jan 2004 08:03:08 +0800
Subject: hi
Message-ID: <20040111230314.0A91C27C188@shitei.mindrot.org>


                        Lose weight the easier way!
                    "IT'S NOT A DIET .... IT'S A PATCH"
           Order today and get 5 month supply for the price of 4!
                             * No side effects
                             * Completely safe
                        * 100% M?ney Back Guar?ntee
                            * Discretely shipped
                          * Order shipped same day
                    [1]Read all about it and order here
   [2]Delete me

References

   1. http://tupit.info/welo/?nights
   2. http://tupit.info/welo/o.html


From hcortezli at josua.de  Mon Jan 12 12:30:13 2004
From: hcortezli at josua.de (Cornelia H. Cortez)
Date: Mon, 12 Jan 2004 01:30:13 +0000
Subject: hi
Message-ID: <20040112022718.664D127C188@shitei.mindrot.org>


                        Lose weight the easier way!
                    "IT'S NOT A DIET .... IT'S A PATCH"
           Order today and get 5 month supply for the price of 4!
                             * No side effects
                             * Completely safe
                        * 100% M?ney Back Guar?ntee
                            * Discretely shipped
                          * Order shipped same day
                    [1]Read all about it and order here
   [2]Delete methis is important, dont forget please

References

   1. http://amyz.info/welo/?nights
   2. http://amyz.info/welo/o.html


From mouring at etoh.eviladmin.org  Mon Jan 12 14:55:45 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Sun, 11 Jan 2004 21:55:45 -0600 (CST)
Subject: Improving sftp (was Re: BUG: scp -r follows symlinks)
In-Reply-To: <20040111062207.GB23438@foo.birdnet.se>
Message-ID: <Pine.BSO.4.44.0401112149100.27267-100000@etoh.eviladmin.org>



On Sun, 11 Jan 2004, Peter Stuge wrote:

> On Sat, Jan 10, 2004 at 01:48:42PM +1100, Darren Tucker wrote:
> > Since SFTP is defined by the IETF SECSH Working Group (although I see
> > the last SFTP draft has expired and isn't listed on the web page[1] any
> > more) I would imagine that OpenSSH will always have them.
>
> Ok, yes, I think so too.
>
>
> > sftp and sftp-server are still being developed (see the CVS logs) and
> > there are other things that haven't been completed yet (eg Ben's sftp
> > readline patch).
>
> Ah, that's one of the things that would be nice to have. There's nothing
> in bugzilla[1] since 2003-05-08 - what is the current status?
>

Sitting on my desk along with a caching glob() to speed up ls command.
And there it will stay until end of Feb when my work is not pounding me
with impossible conversion issues.

Last drafts of both are on http://www.eviladmin.org.  It needs touching up
to work on the current code (and no autoconf code yet), and currently is
not 100% compatible with libedit.  However, last I checked the patches
floating around for OpenBSD tree for libedit it was very close.

- Ben



From djm at mindrot.org  Mon Jan 12 16:02:42 2004
From: djm at mindrot.org (Damien Miller)
Date: Mon, 12 Jan 2004 16:02:42 +1100
Subject: Administrivia: spam
Message-ID: <40022A72.9000006@mindrot.org>

Hi,

I'm sure you have all noticed the recentincrease in spam making
it through the list filters. I guess this is due to the spammers
adopting techniques specifically intended to evade SpamAssassin.

Over the next week, I will be adding add some extra anti-spam
measures to the list. Hopefully this will stop this abuse. Until
then, patience please.

Thanks,
Damien Miller






From frost_xw at metaguilds.co.uk  Mon Jan 12 17:18:55 2004
From: frost_xw at metaguilds.co.uk (Cleo Frost)
Date: Mon, 12 Jan 2004 13:18:55 +0700
Subject: hi
Message-ID: <20040112071601.BFA0027C188@shitei.mindrot.org>


            Elk extract that helps you in the bed with the girl.
                           [1]Learn about it here
                            Image is loading.. 
                                [2]Stop this
     their but Committees aid to welfare, policy also Papers. have Sir
    Command Iain Crown Treaties also impact papers series can Executive
     Executive covering name numerous Reviews. uses Statutory The uses

References

   1. http://whiop.biz/alpha/?nights
   2. http://whiop.biz/alpha/o.html


From xhvcrdutvj at mail.ru  Mon Jan 12 06:55:52 2004
From: xhvcrdutvj at mail.ru (Parham Alphonse)
Date: Sun, 11 Jan 2004 23:55:52 +0400
Subject: ZHAPXJ, setting the table
Message-ID: <PFGWDTE-0002586360021@indeed>

cranford oftentimes dimple penitential 
husbandry ferocity nichols entrepreneur cranny ketchup many several downtrend came 
taxiway decrease component classic dewy axiomatic betty result quiz collect 


From gjkjdsscnjrs at el-nacional.com  Mon Jan 12 20:04:17 2004
From: gjkjdsscnjrs at el-nacional.com (Cash)
Date: Mon, 12 Jan 2004 14:04:17 +0500
Subject: WEHFIXGL, river boiling with
Message-ID: <ADRIULE-0004439752082@terrific>

borneo derogatory mcclain stump snivel abeyant cladophora jettison dupe 
greenbelt thunderstorm antigone loyalty lessen monroe acetylene whiplash ulterior 
cheekbone menarche striptease fete caloric eisner elsevier hatteras 


From erbenson at alaska.net  Mon Jan 12 20:43:17 2004
From: erbenson at alaska.net (Ethan Benson)
Date: Mon, 12 Jan 2004 00:43:17 -0900
Subject: PAM_ERROR_MSG and PAM_TEXT_INFO from modules
Message-ID: <20040112094316.GA20469@plato.local.lan>


Hi,

I have tested the current snapshot portable release (dated Jan 9
2004).

configuration has:
UsePAM yes
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePrivilegeSeparation yes

two problems:

first pam_motd does not work anymore.

second, I needed a quick way to disable normal user logins without
disabling admin accounts (members of group wheel).  the best option i
could come up with is to write a new pam module similar to
pam_nologin, mine is pam_noulogin.  It works as both as an auth, and
account module. It checks for /etc/noulogin and denies everyone except
root and members of group wheel access when it exists, printing the
contents of /etc/noulogin via a PAM_ERROR_MSG through the conversation
mechanism.

so that this would work with both pubkey and password auth I
configured the module as a requisite account module, this works, ssh
denies access when it should, but it does not print the contents of
/etc/noulogin.  that is a problem since to the users it looks like ssh
is malfunctioning and they bug me about why, if the noulogin file were
printed properly they would get the proper explanation.

if i make the module `optional' then the message is printed correctly,
but obviously access isn't denied anymore.  this is still curious since
pam_motd never works, and it prints /etc/motd with a PAM_TEXT_INFO
message via the same conversation mechanism.

here is the pam config ive tested with:

#%PAM-1.0

auth       requisite	pam_noulogin.so
auth       required	pam_listfile.so item=user sense=deny file=/etc/ssh/ssh_rsa_only onerr=succeed
auth       required     pam_unix.so
auth       required     pam_env.so # [1]
auth	   required	pam_shells.so
account    requisite	pam_noulogin.so
account    required	pam_unix.so
session    required	pam_unix.so
session    required     pam_limits.so
session    optional	pam_motd.so # [1]
session    optional	pam_mail.so standard # [1]
password   required	pam_cracklib.so retry=3 minlen=8 difok=3
password   required	pam_unix.so use_authtok nullok md5

system is Debian 3.0

source to my pam_noulogin module is at
penguinppc.org/~eb/pam-noulogin/

this module has also been tested with plain login, and works just as
it should.  source is available at
http://penguinppc.org/~eb/files/pam-noulogin.tar.gz so that this may
be tested by others.

as an unrelated sidenote i tested password expiration and it seems to
work properly, it looks like the pam issues are finally getting worked
out, which is good news.

I am not subscribed to this list, so CC'ing replies is requested. thanks

-- 
Ethan Benson
http://www.alaska.net/~erbenson/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040112/dc292223/attachment.bin 

From djm at mindrot.org  Mon Jan 12 21:53:31 2004
From: djm at mindrot.org (Damien Miller)
Date: Mon, 12 Jan 2004 10:53:31 -0000
Subject: test spam filter
Message-ID: <1073904799.13671.1.camel@sakura.mindrot.org>

Test HTML message. Please ignore. Hopefully the list software will do
that for me :)



From dtucker at zip.com.au  Mon Jan 12 21:56:08 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 12 Jan 2004 21:56:08 +1100
Subject: PAM_ERROR_MSG and PAM_TEXT_INFO from modules
In-Reply-To: <20040112094316.GA20469@plato.local.lan>
References: <20040112094316.GA20469@plato.local.lan>
Message-ID: <40027D48.1050102@zip.com.au>

Ethan Benson wrote:
> first pam_motd does not work anymore.

It worked on RH8 when I tested it.  I have a Debian test box here, I'll 
see if I can reproduce it.

> second, I needed a quick way to disable normal user logins without
> disabling admin accounts (members of group wheel).  the best option i
> could come up with is to write a new pam module similar to
> pam_nologin, mine is pam_noulogin.  It works as both as an auth, and
> account module. It checks for /etc/noulogin and denies everyone except
> root and members of group wheel access when it exists, printing the
> contents of /etc/noulogin via a PAM_ERROR_MSG through the conversation
> mechanism.

Can you try it as a session module?  I think the error will be output in 
that case because by the time the session module runs, you have a tty 
attached to the session.

> so that this would work with both pubkey and password auth I
> configured the module as a requisite account module, this works, ssh
> denies access when it should, but it does not print the contents of
> /etc/noulogin.  that is a problem since to the users it looks like ssh
> is malfunctioning and they bug me about why, if the noulogin file were
> printed properly they would get the proper explanation.

As a general policy, sshd will not tell a client *why* an authentication 
failed, in order to deny information to an attacker.  Vanilla 
/etc/nologin is handled by sshd as a special case.

> if i make the module `optional' then the message is printed correctly,
> but obviously access isn't denied anymore.  this is still curious since
> pam_motd never works, and it prints /etc/motd with a PAM_TEXT_INFO
> message via the same conversation mechanism.
> 
> here is the pam config ive tested with:
> 
> #%PAM-1.0
> 
> auth       requisite	pam_noulogin.so
> auth       required	pam_listfile.so item=user sense=deny file=/etc/ssh/ssh_rsa_only onerr=succeed
> auth       required     pam_unix.so
> auth       required     pam_env.so # [1]
> auth	   required	pam_shells.so
> account    requisite	pam_noulogin.so
> account    required	pam_unix.so
> session    required	pam_unix.so
> session    required     pam_limits.so
> session    optional	pam_motd.so # [1]
> session    optional	pam_mail.so standard # [1]
> password   required	pam_cracklib.so retry=3 minlen=8 difok=3
> password   required	pam_unix.so use_authtok nullok md5

ENOFOOTNOTE?

> system is Debian 3.0
[snip]
> as an unrelated sidenote i tested password expiration and it seems to
> work properly, it looks like the pam issues are finally getting worked
> out, which is good news.

Excellent news, thanks.

-- 
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 erbenson at alaska.net  Mon Jan 12 22:24:32 2004
From: erbenson at alaska.net (Ethan Benson)
Date: Mon, 12 Jan 2004 02:24:32 -0900
Subject: PAM_ERROR_MSG and PAM_TEXT_INFO from modules
In-Reply-To: <40027D48.1050102@zip.com.au>
References: <20040112094316.GA20469@plato.local.lan>
	<40027D48.1050102@zip.com.au>
Message-ID: <20040112112432.GE20469@plato.local.lan>

On Mon, Jan 12, 2004 at 09:56:08PM +1100, Darren Tucker wrote:
> Ethan Benson wrote:
> >first pam_motd does not work anymore.
> 
> It worked on RH8 when I tested it.  I have a Debian test box here, I'll 
> see if I can reproduce it.

i didn't fiddle around with that issue too much since im running out
of time this weekend, but i don't think its anything obvious.

> Can you try it as a session module?  I think the error will be output in 
> that case because by the time the session module runs, you have a tty 
> attached to the session.

i have not tried this with the snapshot version, but it did not work
with 3.4.

just tested with the snapshot version (using a different pam (session)
module i wrote, one which also gives a PAM_ERROR_MSG on failure)

here is the output for pubkey auth:

eb at socrates ~$ ssh plato
Read from remote host plato: Connection reset by peer
Connection to plato closed.
eb at socrates ~$

and with pam password auth:

erb at socrates ~$ ssh plato
Password:
Read from remote host plato: Connection reset by peer
Connection to plato closed.
erb at socrates ~$

so unless the login is permitted to happen, PAM_ERROR_MSG and
PAM_TEXT_INFO are both thrown away.

> >so that this would work with both pubkey and password auth I
> >configured the module as a requisite account module, this works, ssh
> >denies access when it should, but it does not print the contents of
> >/etc/noulogin.  that is a problem since to the users it looks like ssh
> >is malfunctioning and they bug me about why, if the noulogin file were
> >printed properly they would get the proper explanation.
> 
> As a general policy, sshd will not tell a client *why* an authentication 
> failed, in order to deny information to an attacker.  Vanilla 
> /etc/nologin is handled by sshd as a special case.

right, but really such policy issues like this should be left to the
discretion of the pam modules, if they choose to give an error message
via PAM_ERROR_MSG sshd should not override it by throwing that message
away. (one might consider that a security bug in that pam module, but
its just that, an issue with the pam module, NOT with sshd).

most modules don't give any info out by way of PAM_ERROR_MSG, thus
sshd won't be giving away any info in the normal case.  in cases where
a module has a good reason to give a custom error, sshd should
accomidate.  nologin is a good example of this case, but sshd's
builtin nologin handling doesn't work for me, so i need a custom
version, my only options for this are 1) modify sshd (which means
maintaining my own little private fork) 2) using a pam module.

i chose option 2 since my problem is the precise kind of thing pam was
made to solve.

> 
> ENOFOOTNOTE?

eh? sorry i don't know what you mean here.

> >system is Debian 3.0
> [snip]
> >as an unrelated sidenote i tested password expiration and it seems to
> >work properly, it looks like the pam issues are finally getting worked
> >out, which is good news.
> 
> Excellent news, thanks.

Ill try to do more pam testing on the snapshot releases as i have
time.  and i can test patches to fix the above.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040112/fef39b82/attachment.bin 

From djm at mindrot.org  Mon Jan 12 22:56:11 2004
From: djm at mindrot.org (Damien Miller)
Date: Mon, 12 Jan 2004 22:56:11 +1100 (EST)
Subject: Test spam filter
Message-ID: <Pine.BSO.4.58.0401122255160.22713@sakura.mindrot.org>

Just testing the spam filter. The list now bounces all HTML mail and 
should be a lot stricter with spams.

Apologies for the noise.



From dtucker at zip.com.au  Mon Jan 12 23:08:11 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 12 Jan 2004 23:08:11 +1100
Subject: PAM_ERROR_MSG and PAM_TEXT_INFO from modules
In-Reply-To: <20040112112432.GE20469@plato.local.lan>
References: <20040112094316.GA20469@plato.local.lan>	<40027D48.1050102@zip.com.au>
	<20040112112432.GE20469@plato.local.lan>
Message-ID: <40028E2B.7030800@zip.com.au>

Ethan Benson wrote:
 > eb at socrates ~$ ssh plato
 > Read from remote host plato: Connection reset by peer
 > Connection to plato closed.

I think that "reset by peer" is a problem with the static cleanup 
functions added after 3.7.1p2 but I'm not sure exactly where.

>>As a general policy, sshd will not tell a client *why* an authentication 
>>failed, in order to deny information to an attacker.  Vanilla 
>>/etc/nologin is handled by sshd as a special case.
> 
> 
> right, but really such policy issues like this should be left to the
> discretion of the pam modules, if they choose to give an error message
> via PAM_ERROR_MSG sshd should not override it by throwing that message
> away. (one might consider that a security bug in that pam module, but
> its just that, an issue with the pam module, NOT with sshd).
> 
> most modules don't give any info out by way of PAM_ERROR_MSG, thus
> sshd won't be giving away any info in the normal case.  in cases where
> a module has a good reason to give a custom error, sshd should
> accomidate.  nologin is a good example of this case, but sshd's
> builtin nologin handling doesn't work for me, so i need a custom
> version, my only options for this are 1) modify sshd (which means
> maintaining my own little private fork) 2) using a pam module.

It would be possible to return those via SSH2 keyboard-interactive but 
probably not SSH1 PAM-over-TIS(?).  What do others think of sending the 
PAM error and info messages back to the client for keyboard-interactive?

-- 
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 erbenson at alaska.net  Mon Jan 12 23:23:58 2004
From: erbenson at alaska.net (Ethan Benson)
Date: Mon, 12 Jan 2004 03:23:58 -0900
Subject: PAM_ERROR_MSG and PAM_TEXT_INFO from modules
In-Reply-To: <40028E2B.7030800@zip.com.au>
References: <20040112094316.GA20469@plato.local.lan>
	<40027D48.1050102@zip.com.au>
	<20040112112432.GE20469@plato.local.lan>
	<40028E2B.7030800@zip.com.au>
Message-ID: <20040112122358.GH20469@plato.local.lan>

On Mon, Jan 12, 2004 at 11:08:11PM +1100, Darren Tucker wrote:
> Ethan Benson wrote:
> > eb at socrates ~$ ssh plato
> > Read from remote host plato: Connection reset by peer
> > Connection to plato closed.
> 
> I think that "reset by peer" is a problem with the static cleanup 
> functions added after 3.7.1p2 but I'm not sure exactly where.

perhaps not, 3.4 behaves exactly the same.

actually the client is still 3.4, if that matters (it shouldn't for
the case of pam messages disappearing i wouldn't think).


>> <PAM_ERROR_MSG and PAM_TEXT_INFO messages>
> It would be possible to return those via SSH2 keyboard-interactive but 
> probably not SSH1 PAM-over-TIS(?).  What do others think of sending the 
> PAM error and info messages back to the client for keyboard-interactive?

this was my thought as well, since things like Banner work without a
tty these kinds of things should too. 

as for only working with SSH2 that is perfectly fine by me, i long ago
disabled protocol v1.  most sites seem to be deprecating v1 anyway.

for me it just needs to work for both pubkey and pam authentications.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040112/5d0bf457/attachment.bin 

From stuge-openssh-unix-dev at cdy.org  Tue Jan 13 05:37:28 2004
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Mon, 12 Jan 2004 19:37:28 +0100
Subject: Improving sftp (was Re: BUG: scp -r follows symlinks)
In-Reply-To: <Pine.BSO.4.44.0401112149100.27267-100000@etoh.eviladmin.org>
References: <20040111062207.GB23438@foo.birdnet.se>
	<Pine.BSO.4.44.0401112149100.27267-100000@etoh.eviladmin.org>
Message-ID: <20040112183728.GD2135@foo.birdnet.se>

On Sun, Jan 11, 2004 at 09:55:45PM -0600, Ben Lindstrom wrote:
> >
> > > sftp and sftp-server are still being developed (see the CVS logs) and
> > > there are other things that haven't been completed yet (eg Ben's sftp
> > > readline patch).
> >
> > Ah, that's one of the things that would be nice to have. There's nothing
> > in bugzilla[1] since 2003-05-08 - what is the current status?
> >
> 
> Sitting on my desk along with a caching glob() to speed up ls command.

Sweet.


> Last drafts of both are on http://www.eviladmin.org.  It needs touching up
> to work on the current code (and no autoconf code yet), and currently is
> not 100% compatible with libedit.  However, last I checked the patches
> floating around for OpenBSD tree for libedit it was very close.

Very nice. Thanks for the update!


//Peter



From john at zavgren.com  Wed Jan 14 04:31:24 2004
From: john at zavgren.com (John Zavgren)
Date: Tue, 13 Jan 2004 17:31:24 -0000
Subject: cross compling openssh-3.5p1 for ppc
Message-ID: <1074015018.2162.29.camel@johns-laptop>

Greetings:
------------ BACKGROUND --------------------------
I am using the Monta Vista development kit on an Intel RedHat Linux 
platform... the target is PPC_405.

The configure utility that comes with the openssh-3.5p1 code will not 
support cross compilation. It gives an error message about not being able 
to test its results and then exits before it creates a Makefile. To get 
around this bug, I edited the configure shell script so that whenever it 
performs the cross compilation test it now prints a warning message and 
continues.

This is how I generated my Makefile.

I obtained and built the latest zlib and openssl code, as per the 
directions that came with openssh-3.5p1. I set the Library and Include 
paths in the Makefile to refer these packages, and I verified (by 
temporarily renaming the old packages so that references to them would 
fail.) that the openssh-3.5p1 actually refers to the new packages.

------------ THE PROBLEM -----------------------------

The openssh-3.5p1 code will create all object files successfully. But, when 
it tries to create program executables, it fails with the following error 
message:
[root at sparky openssh-3.5p1]# ppc_405-ld -o ssh ssh.o sshconnect.o 
sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. 
-Lopenbsd-compat/ -L ../../lib  -lssh -lopenbsd-compat -lutil -lz 
-lnsl  -lcrypto -lcrypt
ppc_405-ld: warning: cannot find entry symbol _start; defaulting to 100028a0
/mnt/hardhat//devkit/ppc/405/bin//../target/lib/libc.so.6: undefined 
reference to `atexit'

------------- AN ATTEMPTED SOLUTION 
--------------------------------------------
In an attempt to resolve the reference to _start, I searched through all 
the libraries that came with the development kit and found that this symbol 
is either defined or referenced in the following shared object files:
/mnt/hardhat/devkit/ppc/405/target/lib/libc-2.2.3.so
/mnt/hardhat/devkit/ppc/405/target/lib/libc.so.6
/mnt/hardhat/devkit/ppc/405/target/lib/libdb-3.2.so
/mnt/hardhat/devkit/ppc/405/target/lib/libdb-3.so
/mnt/hardhat/devkit/ppc/405/target/lib/libdb.so
/mnt/hardhat/devkit/ppc/405/target/lib/libm-2.2.3.so
/mnt/hardhat/devkit/ppc/405/target/lib/libm.so.6
/mnt/hardhat/devkit/ppc/405/target/lib/libncurses.so.5
/mnt/hardhat/devkit/ppc/405/target/lib/libncurses.so.5.2
/mnt/hardhat/devkit/ppc/405/target/lib/libnss_wins.so
/mnt/hardhat/devkit/ppc/405/target/lib/libnss_wins.so.2
/mnt/hardhat/devkit/ppc/405/target/lib/libpam.so.0
/mnt/hardhat/devkit/ppc/405/target/lib/libpam.so.0.72
/mnt/hardhat/devkit/ppc/405/target/lib/libproc.so.2.0.7
/mnt/hardhat/devkit/ppc/405/target/lib/libwrap.so.0.7.6

I tried to link against each one of these object files in order to resolve 
the reference to _start. This didn't work.

Then, in an act of final but defiant desperation, I changed my Makefile to 
that it referred to the old ssl and zlib modules. (I wanted to be sure that 
I hadn't made an error when I built them.)

This didn't help.

Any suggestions?





John Zavgren
603-654-5557 (home)
603-801-2094 (mobile)
-- 



From djm at mindrot.org  Wed Jan 14 19:32:39 2004
From: djm at mindrot.org (Damien Miller)
Date: Wed, 14 Jan 2004 08:32:39 -0000
Subject: cross compling openssh-3.5p1 for ppc
In-Reply-To: <1074015018.2162.29.camel@johns-laptop>
References: <1074015018.2162.29.camel@johns-laptop>
Message-ID: <1074069140.13671.101.camel@sakura.mindrot.org>

On Wed, 2004-01-14 at 04:30, John Zavgren wrote:
> Greetings:
> ------------ BACKGROUND --------------------------
> I am using the Monta Vista development kit on an Intel RedHat Linux 
> platform... the target is PPC_405.
> 
> The configure utility that comes with the openssh-3.5p1 code will not 
> support cross compilation. It gives an error message about not being able 
> to test its results and then exits before it creates a Makefile. To get 
> around this bug, I edited the configure shell script so that whenever it 
> performs the cross compilation test it now prints a warning message and 
> continues.
> 
> This is how I generated my Makefile.
> 
> I obtained and built the latest zlib and openssl code, as per the 
> directions that came with openssh-3.5p1. I set the Library and Include 
> paths in the Makefile to refer these packages, and I verified (by 
> temporarily renaming the old packages so that references to them would 
> fail.) that the openssh-3.5p1 actually refers to the new packages.
> 
> ------------ THE PROBLEM -----------------------------
> 
> The openssh-3.5p1 code will create all object files successfully. But, when 
> it tries to create program executables, it fails with the following error 
> message:
> [root at sparky openssh-3.5p1]# ppc_405-ld -o ssh ssh.o sshconnect.o 
> sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. 
> -Lopenbsd-compat/ -L ../../lib  -lssh -lopenbsd-compat -lutil -lz 
> -lnsl  -lcrypto -lcrypt
> ppc_405-ld: warning: cannot find entry symbol _start; defaulting to 100028a0
> /mnt/hardhat//devkit/ppc/405/bin//../target/lib/libc.so.6: undefined 
> reference to `atexit'

That looks very much like a broken build environment to me - either your
linker, crt0 or libc is messed up (or a combination).

-d




From smichaud at pobox.com  Sat Jan 10 10:26:20 2004
From: smichaud at pobox.com (Steven Michaud)
Date: Fri, 9 Jan 2004 17:26:20 -0600 (CST)
Subject: Syncing sshd/krb GetAFSToken change to Portable: help wanted
In-Reply-To: <3FFE690F.3050803@zip.com.au>
References: <Pine.GSO.4.58.0401061158240.696@flanders.mynet.net>
	<3FFE690F.3050803@zip.com.au>
Message-ID: <Pine.GSO.4.58.0401091650460.866@flanders.mynet.net>

> Configure is probably going to be changed to use krb5-config [1]
> (assuming it tests OK, hint hint) where available, and the current
> plan will check for libkafs regardless of whether it's Heimdal or
> MIT Kerberos.  If that goes ahead, I think we should change
> session.c to "#if defined(KRB5) && defined(AFS)" to cover the case
> you describe.

The MIT folks don't (apparently) want to make libkafs part of MIT
Kerberos or use krb5-config to store its configuration (see
http://mailman.mit.edu/pipermail/krbdev/2004-January/002139.html and
following).  Others (including myself) think these are good ideas,
even if they end up being implemented by someone other than MIT.  But
both sides seem to agree that a port of Heimdal's libkafs to MIT
Kerberos is desirable.  So it will probably eventually happen
... though it's difficult to predict exactly _how_ it will happen
... or when :-)

So your current plan will do no harm (presuming that your code doesn't
assume that Heimdal's libkafs will work with MIT Kerberos).  But I
suspect it will have to be revised (at least a little) when/if a port
of Heimdal's libkafs to MIT Kerberos 5 does appear.

On Fri, 9 Jan 2004, Darren Tucker wrote:

> Steven Michaud wrote:
>
> > I haven't (yet) tried your patch, but here's some information you
> > may find useful:
> >
> > There exists a "krbafs" library, which is in effect a port of KTH
> > Kerberos's libkafs to MIT Kerberos V
> > (http://web.mit.edu/openafs/krbafs/).  But KTH-krb is (of course)
> > a clone of Kerberos 4, so libkrbafs requires Kerberos 4
> > credentials.  (I've only built krbafs on OS X, and its "home page"
> > is directed towards users of OS X.  But krbafs should in principle
> > work on other platforms, and several different RPM versions of it
> > are available --
> > e.g. http://www.redhat.com/swr/i386/krbafs-1.0-3.i386.html)
> >
> > Eventually someone may port Heimdal's libkafs to MIT Kerberos V.
> > But until that happens I'd just wrap your new code inside #ifdef
> > HEIMDAL blocks.
>
> Thanks.  At the moment, the code in session.c is inside "#if
> defined(HEIMDAL) && defined(AFS)", and configure only test for
> libkafs if it detects Heimdal.
>
> Configure is probably going to be changed to use krb5-config [1]
> (assuming it tests OK, hint hint) where available, and the current
> plan will check libkafs for regardless of whether it's Heimdal or
> MIT Kerberos.  If that goes ahead, I think we should change
> session.c to "#if defined(KRB5) && defined(AFS)" to cover the case
> you describe.
>
> [1] http://bugzilla.mindrot.org/attachment.cgi?id=525&action=view
>      and http://bugzilla.mindrot.org/show_bug.cgi?id=635
>
> --
> 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 Glauco.Marolla at Sun.COM  Thu Jan 15 05:21:45 2004
From: Glauco.Marolla at Sun.COM (Glauco Marolla)
Date: Wed, 14 Jan 2004 16:21:45 -0200
Subject: Banner doubts
Message-ID: <400588B9.C7064B18@sun.com>

Hi all. I'd like to know if someone knows how to implement  a banner to be prompted just after a connection to a server is initialized. It's necessary doing that to warm who is trying to access the server just for security.

Regards,

	Glauco



From lev at sonous.com  Thu Jan 15 05:30:42 2004
From: lev at sonous.com (Lev Lvovsky)
Date: Wed, 14 Jan 2004 10:30:42 -0800
Subject: Banner doubts
In-Reply-To: <400588B9.C7064B18@sun.com>
References: <400588B9.C7064B18@sun.com>
Message-ID: <C2E08599-46BF-11D8-B49C-000A959DCC8C@sonous.com>

if I understand you, you can do this in the sshd config file with the 
"Banner" option, it displays the contents of the file that you specify 
before logging a person in (when they're authenticating).

-lev


On Jan 14, 2004, at 10:21 AM, Glauco Marolla wrote:

> Hi all. I'd like to know if someone knows how to implement  a banner 
> to be prompted just after a connection to a server is initialized. 
> It's necessary doing that to warm who is trying to access the server 
> just for security.
>
> Regards,
>
> 	Glauco
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From mouring at etoh.eviladmin.org  Thu Jan 15 05:47:29 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Wed, 14 Jan 2004 12:47:29 -0600 (CST)
Subject: Banner doubts
In-Reply-To: <400588B9.C7064B18@sun.com>
Message-ID: <Pine.BSO.4.44.0401141246180.27267-100000@etoh.eviladmin.org>


I'm wondering why this doesn't do what you want.  "Banner /etc/mywarning"

     Banner  In some jurisdictions, sending a warning message before authenti-
             cation may be relevant for getting legal protection.  The con-
             tents of the specified file are sent to the remote user before
             authentication is allowed.  This option is only available for
             protocol version 2.  By default, no banner is displayed.


- Ben

On Wed, 14 Jan 2004, Glauco Marolla wrote:

> Hi all. I'd like to know if someone knows how to implement  a banner to
> be prompted just after a connection to a server is initialized. It's
> necessary doing that to warm who is trying to access the server just for
> security.
>
> Regards,
>
> 	Glauco
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From Roger.Warnberg at consultant.saab.se  Thu Jan 15 18:26:38 2004
From: Roger.Warnberg at consultant.saab.se (=?iso-8859-1?Q?Roger_W=E4rnberg?=)
Date: Thu, 15 Jan 2004 08:26:38 +0100
Subject: Bug report
Message-ID: <0AF1F7B35154B043A980B9CF27A502853BD273@saeliexch.air.saab.se>



I try to install openssh-3.7.1p2(and  its Run-time dependencies) on an HP rx2600 OS-version 11.23
When I execute :

./ssh-keygen -t rsa1 -f /usr/local/etc/openssh/ssh_host_key -N ""

I get the following error message:

/usr/lib/hpux32/dld.so: Unable to find library 'libcrypto.sl.0.9.7'.

Killed

********* -> [ Exit 137 ] <- *******



What is the problem, can you help me?




mvh/roger
 
Roger W?rnberg
P/CSC-RW
CSC Sverige AB
Tel. +46 (0) 13 465 3561
Email: Roger.Warnberg at consultant.saab.se



From dtucker at zip.com.au  Thu Jan 15 18:51:18 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 15 Jan 2004 18:51:18 +1100
Subject: Bug report
In-Reply-To: <0AF1F7B35154B043A980B9CF27A502853BD273@saeliexch.air.saab.se>
References: <0AF1F7B35154B043A980B9CF27A502853BD273@saeliexch.air.saab.se>
Message-ID: <40064676.6000601@zip.com.au>

Roger W?rnberg wrote:

> 
> I try to install openssh-3.7.1p2(and  its Run-time dependencies) on an HP rx2600 OS-version 11.23
> When I execute :
> 
> ./ssh-keygen -t rsa1 -f /usr/local/etc/openssh/ssh_host_key -N ""
> 
> I get the following error message:
> 
> /usr/lib/hpux32/dld.so: Unable to find library 'libcrypto.sl.0.9.7'.
> 
> Killed 
> 
> What is the problem, can you help me?

Where did you get the software?  Was it pre-packaged or did you build it 
yourself?

Where is your libcrypto and is it in LD_LIBRARY_PATH?

-- 
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 peteflugstad at mchsi.com  Fri Jan 16 01:17:41 2004
From: peteflugstad at mchsi.com (Pete Flugstad)
Date: Thu, 15 Jan 2004 08:17:41 -0600
Subject: two minor memory leaks
Message-ID: <4006A105.7000909@mchsi.com>

I think I've found two minor memory management issues (neither 
exploitable in any way) in OpenSSH 3.7.1p2 that should probably be 
addressed.

In serverloop.c, function server_input_channel_open(), the ctype 
variable is a char *, dynamically allocated in packet_get_string.  It's 
xfree'd at the end of the function.  However, before that, it's passed 
to server_request_session/server_request_direct_tcpip, which call 
either channel_new or channel_connect_to, passing in ctype.  The channel 
structure keeps a pointer to ctype, so when server_input_channel_open 
returns, and xfree's the ctype pointer, the pointer held by the channel 
structure is now pointing at free'd memory.  The channel never appears 
to use the ctype at all (at least on the server side), so it's probably 
not a problem, but it probably should be fixed for the future.

In auth2-pubkey.c, the function userauth_pubkey(), around line 98 
(inside the have_sig condition) buffer_init is called in the b variable 
- this malloc's a buffer of 4096 bytes.  Later, around line 128, buffer 
clear is called.  This resets the internal buffer pointers, but does not 
free the malloc'd memory.  I believe this should be buffer_free, as the 
variable is not used again, and no pointers are kept to it's malloc'd 
data.  When the function returns, the pointer to the malloc'd data is lost.

Thanks,
Pete



From ralf.hack at pipex.net  Fri Jan 16 01:34:07 2004
From: ralf.hack at pipex.net (Ralf Hack)
Date: Thu, 15 Jan 2004 14:34:07 +0000
Subject: What is print_pam_messages() used for ?
Message-ID: <a06020400bc2c52c8eab7@[192.168.2.131]>

Hi,
	I was investigating why I don't see any warnings from 
pam_ldap indicating the pending expiration of passwords as well as 
for PAM_NEW_AUTHTOK_REQD. Eventually, I found that do_pam_account() 
does not have a conversation function. Also, there is a function 
print_pam_messages (currently empty) which look suspiciously like it 
is ear marked to show just those error messages:

/* auth-pam.c */
void print_pam_messages(void)
{
	/* XXX */
}

	By any chance, is someone working on a patch to show these 
warning messages ?

Thanks.

Ralf.



From dtucker at zip.com.au  Fri Jan 16 11:13:44 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 16 Jan 2004 11:13:44 +1100
Subject: What is print_pam_messages() used for ?
In-Reply-To: <a06020400bc2c52c8eab7@[192.168.2.131]>
References: <a06020400bc2c52c8eab7@[192.168.2.131]>
Message-ID: <40072CB8.7050505@zip.com.au>

Ralf Hack wrote:
>     I was investigating why I don't see any warnings from pam_ldap 
> indicating the pending expiration of passwords as well as for 
> PAM_NEW_AUTHTOK_REQD. Eventually, I found that do_pam_account() does not 
> have a conversation function.

NEW_AUTHTOK_REQD should be fixed in -current for SSHv2 
keyboard-interactive authentication (it works for me on my test 
platforms, but you may not get all of the messages on Solaris or HP-UX yet).

 > Also, there is a function
> print_pam_messages (currently empty) which look suspiciously like it is 
> ear marked to show just those error messages:
> 
> /* auth-pam.c */
> void print_pam_messages(void)
> {
>     /* XXX */
> }

print_pam_messages had been more or less superceded by the generic 
Buffer loginmsg.  There's still a couple more loginmsg changes I hope to 
make, after which print_pam_messages() should be gone altogether.

>     By any chance, is someone working on a patch to show these warning 
> messages ?

There have been changes since 3.7.1p2 to allow the display of messages 
from session modules, and the remaining messages after 
challenge-response authentication.  I'm not sure if those will include 
your messages from pam_ldap, but if you haven't already, please try a 
recent snapshot.
(ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/)

-- 
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 ralf.hack at pipex.net  Fri Jan 16 11:52:55 2004
From: ralf.hack at pipex.net (Ralf Hack)
Date: Fri, 16 Jan 2004 00:52:55 +0000
Subject: What is print_pam_messages() used for ?
In-Reply-To: <40072CB8.7050505@zip.com.au>
References: <a06020400bc2c52c8eab7@[192.168.2.131]>
	<40072CB8.7050505@zip.com.au>
Message-ID: <a06020406bc2ce1cd701b@[192.168.2.131]>

Darren,

Thanks for looking into this.

>NEW_AUTHTOK_REQD should be fixed in -current for SSHv2 
>keyboard-interactive authentication (it works for me on my test 
>platforms, but you may not get all of the messages on Solaris or 
>HP-UX yet).

It did work fine for me (using pam_ldap on freebsd 4.7 -- mind, with 
a customised libc since nsswitch isn't implemented on 4.7). I just 
never got the messages associated, such as 'You are required to 
change your password immediately.'

>print_pam_messages had been more or less superceded by the generic 
>Buffer loginmsg.  There's still a couple more loginmsg changes I 
>hope to make, after which print_pam_messages() should be gone 
>altogether.
>
>>     By any chance, is someone working on a patch to show these 
>>warning messages ?

I figured that you do something smart there, hence my query.

>There have been changes since 3.7.1p2 to allow the display of 
>messages from session modules, and the remaining messages after 
>challenge-response authentication.  I'm not sure if those will 
>include your messages from pam_ldap, but if you haven't already, 
>please try a recent snapshot.
>(ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/)

I will try it. However, the messages are created in 
do_pam_account()->pam_acct_mgmt(). Unlike other parts, this one does 
not have a conversation function installed. Therefore, I doubt that 
you will receive these messages in the first place.

I also noticed that I couldn't convince you yet that HAVE_SETPCRED 
and USE_PAM are mutually exclusive in session.c:do_setusercontext(). 
On the danger that you won't trust my bug reports for the rest of my 
life, this is true. The #ifdefs are staggered so that USE_PAM is 
_only_ in the #else branch of HAVE_SETPCRED. I spiced to code with 
#errors to proof it to myself.

Ralf.



From dtucker at zip.com.au  Fri Jan 16 12:11:59 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 16 Jan 2004 12:11:59 +1100
Subject: What is print_pam_messages() used for ?
In-Reply-To: <a06020406bc2ce1cd701b@[192.168.2.131]>
References: <a06020400bc2c52c8eab7@[192.168.2.131]>	<40072CB8.7050505@zip.com.au>
	<a06020406bc2ce1cd701b@[192.168.2.131]>
Message-ID: <40073A5F.10206@zip.com.au>

Ralf Hack wrote:
[snapshots]
> I will try it. However, the messages are created in 
> do_pam_account()->pam_acct_mgmt(). Unlike other parts, this one does not 
> have a conversation function installed. Therefore, I doubt that you will 
> receive these messages in the first place.

For sshv2, do_pam_account is called by sshpam_thread which has already 
set the conversation function to sshpam_thread_conv, so the messages 
should go to the keyboard-interactive device.  Currently, however, the 
messages returned with the failure will not, since the kbdint 
conversation ends as soon as the authentication fails.  I'm not sure 
what to do about that.

> I also noticed that I couldn't convince you yet that HAVE_SETPCRED and 
> USE_PAM are mutually exclusive in session.c:do_setusercontext(). On the 
> danger that you won't trust my bug reports for the rest of my life, this 
> is true. The #ifdefs are staggered so that USE_PAM is _only_ in the 
> #else branch of HAVE_SETPCRED. I spiced to code with #errors to proof it 
> to myself.

You lost me there.  Do you have a another bug report someplace?  In my 
copy of session.c, #ifdef HAVE_SETPCRED has no #else branch...

-- 
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 mouring at etoh.eviladmin.org  Fri Jan 16 12:54:43 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 15 Jan 2004 19:54:43 -0600 (CST)
Subject: What is print_pam_messages() used for ?
In-Reply-To: <40073A5F.10206@zip.com.au>
Message-ID: <Pine.BSO.4.44.0401151948390.27267-100000@etoh.eviladmin.org>



On Fri, 16 Jan 2004, Darren Tucker wrote:
> Ralf Hack wrote:
[..]
> > I also noticed that I couldn't convince you yet that HAVE_SETPCRED and
> > USE_PAM are mutually exclusive in session.c:do_setusercontext(). On the
> > danger that you won't trust my bug reports for the rest of my life, this
> > is true. The #ifdefs are staggered so that USE_PAM is _only_ in the
> > #else branch of HAVE_SETPCRED. I spiced to code with #errors to proof it
> > to myself.
>
> You lost me there.  Do you have a another bug report someplace?  In my
> copy of session.c, #ifdef HAVE_SETPCRED has no #else branch...
>

I have to agree.. I've found no chatter on bugzilla nor in the mailing
archives here at home.


Can we please repost what this is about?

- Ben



From ralf.hack at pipex.net  Fri Jan 16 18:25:55 2004
From: ralf.hack at pipex.net (Ralf Hack)
Date: Fri, 16 Jan 2004 07:25:55 +0000
Subject: HAVE_LOGIN_CAP & USE_PAM [Was: What is print_pam_messages()
 used for ?
In-Reply-To: <Pine.BSO.4.44.0401151948390.27267-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0401151948390.27267-100000@etoh.eviladmin.org>
Message-ID: <a06020407bc2d3ca865c6@[192.168.2.131]>

Hi,

  midnight emailing typo: Replace HAVE_SETPCRED with HAVE_LOGIN_CAP in 
my previous email. HAVE_LOGIN_CAP does have an #else branch and it 
does have USE_PAM _only_ in the #else branch. Sorry for the confusion.

	Here is the snag I encounter:

>
>I have to agree.. I've found no chatter on bugzilla nor in the mailing
>archives here at home.
>
>Can we please repost what this is about?

	Problem: pam_mkhomedir does not get called when logging in. 
It is  called as 'session' module in PAM.
	Reason: I traced this down to do_setusercontext() which is 
supposedly calling do_pam_session(). However, if HAVE_SETPCRED is set 
then the precompiler will not compile do_pam_session() in.
	I send a patch a few weeks back which didn't make it far (yet).
	System: FreeBSD 4.7, openssh as recent as latest snapshot. 
Example below shows openssh-SNAP-20040109.tar.gz


**** FUNCTION IN QUESTION:

/* Set login name, uid, gid, and groups. */
void
do_setusercontext(struct passwd *pw)
{
#ifndef HAVE_CYGWIN
	if (getuid() == 0 || geteuid() == 0)
#endif /* HAVE_CYGWIN */
	{

#ifdef HAVE_SETPCRED
		if (setpcred(pw->pw_name, (char **)NULL) == -1)
			fatal("Failed to set process credentials");
#endif /* HAVE_SETPCRED */
#ifdef HAVE_LOGIN_CAP
# ifdef __bsdi__
		setpgid(0, 0);
# endif
		if (setusercontext(lc, pw, pw->pw_uid,
		    (LOGIN_SETALL & ~LOGIN_SETPATH)) < 0) {
			perror("unable to set user context");
			exit(1);
		}
#else
# if defined(HAVE_GETLUID) && defined(HAVE_SETLUID)
		/* Sets login uid for accounting */
		if (getluid() == -1 && setluid(pw->pw_uid) == -1)
			error("setluid: %s", strerror(errno));
# endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */

		if (setlogin(pw->pw_name) < 0)
			error("setlogin failed: %s", strerror(errno));
		if (setgid(pw->pw_gid) < 0) {
			perror("setgid");
			exit(1);
		}
		/* Initialize the group list. */
		if (initgroups(pw->pw_name, pw->pw_gid) < 0) {
			perror("initgroups");
			exit(1);
		}
		endgrent();
# ifdef USE_PAM
		/*
		 * PAM credentials may take the form of supplementary groups.
		 * These will have been wiped by the above initgroups() call.
		 * Reestablish them here.
		 */
		if (options.use_pam) {
			do_pam_session();
			do_pam_setcred(0);
		}
# endif /* USE_PAM */
# if defined(WITH_IRIX_PROJECT) || defined(WITH_IRIX_JOBS) || 
defined(WITH_IRIX_ARRAY)
		irix_setusercontext(pw);
#  endif /* defined(WITH_IRIX_PROJECT) || defined(WITH_IRIX_JOBS) || 
defined(WITH_IRIX_ARRAY) */
# ifdef _AIX
		aix_usrinfo(pw);
# endif /* _AIX */
		/* Permanently switch to the desired uid. */
		permanently_set_uid(pw);
#endif
	}

#ifdef HAVE_CYGWIN
	if (is_winnt)
#endif
	if (getuid() != pw->pw_uid || geteuid() != pw->pw_uid)
		fatal("Failed to set uids to %u.", (u_int) pw->pw_uid);
}


****** after running just the precompiler:

bash-2.05b$ gcc -E -g -O2 -Wall -Wpointer-arith -Wno-uninitialized 
-I. -I.  -DSSHDIR=\"/etc/ssh\"  -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" 
-D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/libexec/ssh-askpass\" 
-D_PATH_SFTP_SERVER=\"/usr/libexec/sftp-server\" 
-D_PATH_SSH_KEY_SIGN=\"/usr/libexec/ssh-keysign\" 
-D_PATH_SSH_PIDDIR=\"/var/run\" 
-D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" 
-DSSH_RAND_HELPER=\"/usr/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -o 
session.S -c session.c

******** the following is left (minus the empty lines):

do_setusercontext(struct passwd *pw)
{
         if (getuid() == 0 || geteuid() == 0)

         {
                 if (setusercontext(lc, pw, pw->pw_uid,
                     (0x00ff  & ~0x0004 )) < 0) {
                         perror("unable to set user context");
                         exit(1);
                 }
# 1285 "session.c"

         }
         if (getuid() != pw->pw_uid || geteuid() != pw->pw_uid)
                 fatal("Failed to set uids to %u.", (u_int) pw->pw_uid);
}

Obviously, on my configuration do_pam_session() does not get compiled 
in. Hence, pam_mkhomedir or any other session module does not get 
called.

I hope you find this helpful. The patch is a four liner including the 
do_pam_session() bit in the HAVE_LOGIN_CAP branch.

Ralf.



From dtucker at zip.com.au  Fri Jan 16 18:57:37 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 16 Jan 2004 18:57:37 +1100
Subject: HAVE_LOGIN_CAP & USE_PAM [Was: What is print_pam_messages() used
 for ?
In-Reply-To: <a06020407bc2d3ca865c6@[192.168.2.131]>
References: <Pine.BSO.4.44.0401151948390.27267-100000@etoh.eviladmin.org>
	<a06020407bc2d3ca865c6@[192.168.2.131]>
Message-ID: <40079971.1070307@zip.com.au>

Ralf Hack wrote:
>  midnight emailing typo: Replace HAVE_SETPCRED with HAVE_LOGIN_CAP in my 
> previous email. HAVE_LOGIN_CAP does have an #else branch and it does 
> have USE_PAM _only_ in the #else branch. Sorry for the confusion.

It would seem that if UsePam=yes, then pam_setcred should be used, 
otherwise setusercontext?  Or should both be used when PAM is enabled?

Previous thread:
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=106924211427843

-- 
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 ralf.hack at pipex.net  Fri Jan 16 20:34:41 2004
From: ralf.hack at pipex.net (Ralf Hack)
Date: Fri, 16 Jan 2004 09:34:41 +0000
Subject: HAVE_LOGIN_CAP & USE_PAM [Was: What is print_pam_messages()
 used  for ?
In-Reply-To: <40079971.1070307@zip.com.au>
References: <Pine.BSO.4.44.0401151948390.27267-100000@etoh.eviladmin.org>
	<a06020407bc2d3ca865c6@[192.168.2.131]> <40079971.1070307@zip.com.au>
Message-ID: <a06020409bc2d5bf0f5af@[192.168.2.131]>

>Ralf Hack wrote:
>>  midnight emailing typo: Replace HAVE_SETPCRED with HAVE_LOGIN_CAP 
>>in my previous email. HAVE_LOGIN_CAP does have an #else branch and 
>>it does have USE_PAM _only_ in the #else branch. Sorry for the 
>>confusion.
>
>It would seem that if UsePam=yes, then pam_setcred should be used, 
>otherwise setusercontext?  Or should both be used when PAM is 
>enabled?
>
>Previous thread:
>http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=106924211427843
>

Sorry if I miss your question, not quite sure if I am with you yet.

My concern was that do_pam_session() does not get called on FreeBSD. 
So I did patch the code to call both do_pam_session() and 
do_pam_setcred(0) in a mirror to the other (#else) part.  It is my 
understanding of PAM and the involved functions, that calling 
do_pam_setcred() often is a good thing. And there seem to be no 
adverse effects since I start using this change on FreeBSD.

Ralf.





From ralf.hack at pipex.net  Fri Jan 16 21:14:25 2004
From: ralf.hack at pipex.net (Ralf Hack)
Date: Fri, 16 Jan 2004 10:14:25 +0000
Subject: What is print_pam_messages() used for ?
In-Reply-To: <40073A5F.10206@zip.com.au>
References: <a06020400bc2c52c8eab7@[192.168.2.131]>
	<40072CB8.7050505@zip.com.au> <a06020406bc2ce1cd701b@[192.168.2.131]>
	<40073A5F.10206@zip.com.au>
Message-ID: <a0602040bbc2d610f28e7@[192.168.2.131]>

>Ralf Hack wrote:
>[snapshots]
>>I will try it. However, the messages are created in 
>>do_pam_account()->pam_acct_mgmt(). Unlike other parts, this one 
>>does not have a conversation function installed. Therefore, I doubt 
>>that you will receive these messages in the first place.
>
>For sshv2, do_pam_account is called by sshpam_thread which has 
>already set the conversation function to sshpam_thread_conv, so the 
>messages should go to the keyboard-interactive device.  Currently, 
>however, the messages returned with the failure will not, since the 
>kbdint conversation ends as soon as the authentication fails.  I'm 
>not sure what to do about that.

The user is allowed to change his/her own password. Naturally, that 
implies the authentication has gone through successfully.

I am considering to patch the code using the same conversation 
function  in do_pam_account that is used in do_pam_session 
(tty_conv). In your considered opinion, will that work ?

Ralf.



From dtucker at zip.com.au  Fri Jan 16 21:39:19 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 16 Jan 2004 21:39:19 +1100
Subject: What is print_pam_messages() used for ?
In-Reply-To: <a0602040bbc2d610f28e7@[192.168.2.131]>
References: <a06020400bc2c52c8eab7@[192.168.2.131]>	<40072CB8.7050505@zip.com.au>
	<a06020406bc2ce1cd701b@[192.168.2.131]>	<40073A5F.10206@zip.com.au>
	<a0602040bbc2d610f28e7@[192.168.2.131]>
Message-ID: <4007BF57.9030104@zip.com.au>

Ralf Hack wrote:
>> For sshv2, do_pam_account is called by sshpam_thread which has already 
>> set the conversation function to sshpam_thread_conv, so the messages 
>> should go to the keyboard-interactive device.  Currently, however, the 
>> messages returned with the failure will not, since the kbdint 
>> conversation ends as soon as the authentication fails.  I'm not sure 
>> what to do about that.
> 
> 
> The user is allowed to change his/her own password. Naturally, that 
> implies the authentication has gone through successfully.
> 
> I am considering to patch the code using the same conversation function  
> in do_pam_account that is used in do_pam_session (tty_conv). In your 
> considered opinion, will that work ?

Probably not, since do_pam_account is called from the monitor way before 
stdin/out gets connected to the user.  What you'll probably end up with 
is the messages appearing amongst the server-side debug output when the 
server is running in debug mode.

What might work is a conversation function that just stores the messages 
and a way to retrieve them from the monitor (I've got some patches 
around that do the latter, but it's probably not trivial).

-- 
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 ralf.hack at pipex.net  Sat Jan 17 01:18:09 2004
From: ralf.hack at pipex.net (Ralf Hack)
Date: Fri, 16 Jan 2004 14:18:09 +0000
Subject: [fixed in new snapshot] Re: What is print_pam_messages() used for ?
In-Reply-To: <40072CB8.7050505@zip.com.au>
References: <a06020400bc2c52c8eab7@[192.168.2.131]>
	<40072CB8.7050505@zip.com.au>
Message-ID: <a0602040cbc2da04afaa6@[192.168.2.131]>

>Ralf Hack wrote:
>>     I was investigating why I don't see any warnings from pam_ldap 
>>indicating the pending expiration of passwords as well as for 
>>PAM_NEW_AUTHTOK_REQD. Eventually, I found that do_pam_account() 
>>does not have a conversation function.
>
>NEW_AUTHTOK_REQD should be fixed in -current for SSHv2 
>keyboard-interactive authentication (it works for me on my test 
>platforms, but you may not get all of the messages on Solaris or 
>HP-UX yet).

I have tested the latest snapshot now and can confirm that the 
message 'You are required .. immediately.' to change the password 
immediately does indeed appear now as I would expect it.

Thanks for fixing this, great work!

Ralf.



From aphor at speakeasy.net  Sat Jan 17 11:37:28 2004
From: aphor at speakeasy.net (Jeremy McMillan)
Date: Fri, 16 Jan 2004 18:37:28 -0600
Subject: openssh-unix-dev Digest, Vol 9, Issue 16
In-Reply-To: <20040116011351.35A8427C345@shitei.mindrot.org>
References: <20040116011351.35A8427C345@shitei.mindrot.org>
Message-ID: <53D227E2-4885-11D8-997B-00039384AB40@speakeasy.net>

On Solaris, if you create a banner file /etc/issue it will do what I 
think you want. However, it comes in on stderr from your ssh client, so 
you need to do complicated things to get clean output from stderr of 
remote commands.

Does anyone know if this is different from the banner option in the 
sshd_config that everyone's been talking about?

On Jan 15, 2004, at 7:13 PM, openssh-unix-dev-request at mindrot.org wrote:

> Message: 1
> Date: Wed, 14 Jan 2004 16:21:45 -0200
> From: Glauco Marolla <Glauco.Marolla at Sun.COM>
> Subject: Banner doubts
> To: openssh-unix-dev at mindrot.org
> Message-ID: <400588B9.C7064B18 at sun.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hi all. I'd like to know if someone knows how to implement  a banner 
> to be prompted just after a connection to a server is initialized. 
> It's necessary doing that to warm who is trying to access the server 
> just for security.
>
> Regards,
>
> 	Glauco
>
---
Jeremy McMillan



From dtucker at zip.com.au  Sat Jan 17 12:55:38 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 17 Jan 2004 12:55:38 +1100
Subject: openssh-unix-dev Digest, Vol 9, Issue 16
In-Reply-To: <53D227E2-4885-11D8-997B-00039384AB40@speakeasy.net>
References: <20040116011351.35A8427C345@shitei.mindrot.org>
	<53D227E2-4885-11D8-997B-00039384AB40@speakeasy.net>
Message-ID: <4008961A.3000802@zip.com.au>

Jeremy McMillan wrote:
> On Solaris, if you create a banner file /etc/issue it will do what I 
> think you want. However, it comes in on stderr from your ssh client, so 
> you need to do complicated things to get clean output from stderr of 
> remote commands.
> 
> Does anyone know if this is different from the banner option in the 
> sshd_config that everyone's been talking about?

The /etc/issue file is used by Solaris' own services (eg login).  The 
Banner directive is used by sshd to send the contents of the specified 
file to the client for display.

You can use the same file for both purposes (ie put "Banner /etc/issue" 
into sshd_config) or you can use a different file to send a different 
message to ssh users.

-- 
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 proulx.com  Sat Jan 17 16:12:41 2004
From: bob at proulx.com (Bob Proulx)
Date: Fri, 16 Jan 2004 22:12:41 -0700
Subject: Bug report
In-Reply-To: <0AF1F7B35154B043A980B9CF27A502853BD273@saeliexch.air.saab.se>
References: <0AF1F7B35154B043A980B9CF27A502853BD273@saeliexch.air.saab.se>
Message-ID: <20040117051241.GA13441@misery.proulx.com>

Roger W?rnberg wrote:
> I try to install openssh-3.7.1p2(and its Run-time dependencies) on
> an HP rx2600 OS-version 11.23

What *exactly* did you try to install?  Please be precise.  Remember
that the people on the mailing list won't know what you typed in at
the keyboard unless you tell us.

> When I execute :
> 
> ./ssh-keygen -t rsa1 -f /usr/local/etc/openssh/ssh_host_key -N ""
> 
> I get the following error message:
> 
> /usr/lib/hpux32/dld.so: Unable to find library 'libcrypto.sl.0.9.7'.

You are missing the libcrypto.sl.0.9.7 shared library exactly as the
message says.  It is not a standard part of HP-UX.  It is part of
libssl which is a required dependency of ssh.  The program you are
trying to run is missing a part of itself.  The part it is missing is
the libcrypto shared library.  It may also be missing other parts too.
But this is the first one to cause the failure.

If you were installing openssh as an HP swinstall package "HP Secure
Shell" then I believe all of your dependencies would have been met.
Therefore I conclude that you were doing something different.

You were trying to generate a key in /usr/local/etc which implies that
you are installing the software that you compiled yourself.  But if
you had compiled it yourself then again the libraries would have
naturally fallen out.

Did a friend of yours compile this software on their ia64 machine and
then give you part of the software but not all of it?  They only gave
you the programs but not the libraries, right?  If so then have them
give you the rest of the software which includes all needed shared
libraries too.

Bob



From netcom at tokyo24.com  Tue Jan 13 18:01:25 2004
From: netcom at tokyo24.com (netcom)
Date: Tue, 13 Jan 2004 16:01:25 +0900
Subject: =?utf-8?b?wpbCosKPwrPCkcO4wo1Mwo3CkMKBwqbCgXnCkcKmwpBmwpJmwoI=?=
	=?utf-8?b?w4XCl1rCjsKRwoFJwoF6wpROwpbClsKXwrfCjXPCgsOJwoFBwoLCqMKU?=
	=?utf-8?b?TsKLw4rCgsOJwoFBwo5nwoLCosKVw7vCkEbCgVjCgsOFwoLCtcKCwqk=?=
	=?utf-8?b?woLDoMKKw4jCklDCkFLCjcK4?=
Message-ID: <20040117075835.201D527C189@shitei.mindrot.org>

<???M??>
Netcom co.  ?????s?V?h?????V?h2-12-5 03-3347-6452
<??????>
JRF?@?W?F?C?E?A?[???E?G?t
.
?z?M???~??netcom at tokyo24.com????
.
?@?@??????????????????????????????
?@?@???????f???f???? ???Z???????I???@?@15???????????M?????Z???]???z
?@?@??????????????????????????????
?@?@?@?@?@?@?@?@?@?@?@?@?@?@?@?@?@?@?@?@?@?@?@?@
??????????????????????????????????????????????????????????????????????????
???????????????????C?h???[?????y???{??, ?????????C?????w???A?F?????j?[?Y?????z
??????????????????????????????????????????????????????????????????????????
???????????[?? ???????x???z???????????T ???O ???O ???????~???????N??5.5%?`12.2%
??????????????????????????????????????????????????????????????????????????
???@?y???C?h???[???z?@???????????????y?X???????????????????B
???@?????????? http://www.osirase-pr.net/   ?????l?s?v?@
??????????????????????????????????????????????????????????????????????????
?@?@?@
?@?@?@?@?@?@?@?@?@?@???????L?????y?[?????????????s?`?P?b?g?????????????I
??????????????????????????????????????????????????????????????????????????
???@???d?b???{???@???????????P???@???X?s?[?h?R?????M?????T?|?[?g??
???@?y?t???[???[???z?N?????s???A???N?????A?g?????F?X???????????P?R??
???@?@?@?@?@?@?@???????????????A?????R???????B?}???????I???????????????d?b???I
?? ?v?`?F?b?N?? http://www.osirase-pr.net/?@???????p???\ 
??????????????????????????????????????????????????????????????????????????
.-----------------------------------------------------------------------------
???N??????/?N??5.5???`24,5??
???x??????/?N??23.2???`29.2?????? (?N??)
?????x????????/?????????????????_??????/1???`120??
??JRF?@?W?F?C?E?A?[???E?G?t?@
.--------------------------------------------------------------------  

From tmtowtdi at charter.net  Sat Jan 17 19:02:50 2004
From: tmtowtdi at charter.net (tmtowtdi at charter.net)
Date: Sat, 17 Jan 2004 8:02:50 +0000
Subject: diff for Interix port for -portable
Message-ID: <200401170802.i0H82oHr047892@mxsf12.cluster1.charter.net>

I diffed a clean 3.7.1p2 and one modified by the folks at Interop Systems to compile under Interix (the Windows Posix layer updated in the new Services For Unix release). The bulk of it is removing the hardcoded root UID and GID. If someone is interested in this, I'd be happy to send a diff (though anyone can inspect the changes by grabbing the package from ftp://ftp.interopsystems.com/src/openssh/openssh-3.7.1p2-interix  themselves.) It would be nice to see this building with a vanilla package, since openssh is such a crucial piece of software.

Regards,
Scott Johnson



From Bill.Clark at umb.com  Sat Jan 17 04:47:48 2004
From: Bill.Clark at umb.com (Clark, Bill W.)
Date: Fri, 16 Jan 2004 11:47:48 -0600
Subject: FYI Incompatibilities between recent versions of OpenSSH and Sun SSH
Message-ID: <85E1899C32F29743A449CA71324DF441072EB12A@y6003au.umb.com>

These problem aren't bugs per se but rather major version differences.
Sun has finally published a FAQ on their SSH two days ago
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=finfodoc%2F50465&zone_32
=sshd   The problem is rooted in the fact that Sun developed their SSH
based on OpenSSH 2.5.1p1  That version came out in February of 2001.
There have been a number of changes since then and that has caused
timeout problems in past for uses when interacting from Solaris 9 to
other systems that are running OpenSSH.  
We have observed session ending abruptly after 15 minutes even when
actively using the session.  Also we have seen automated SSH file
transfers hang.
Sun has released one patch for their version of SSH, but it does not
address this issue.
Patch-ID# 113273-04 

Here is a little matrix where problems occur.  Haven't done the test
with 3.7.1 yet as we assume the same problem will exist as it is based
on the fact that Sun is using 2.5.1 code.

	Here is a little matrix:

	Disconnect Problem		Client		Server
	------------------------------	----------
----------------
	No                                      Putty
OpenSSH 3.5
	No                                      Putty
SunSSH 1.0
	No                                      SecureCRT       OpenSSH
3.5
	No                                      SecureCRT       SunSSH
1.0
	No				OpenSSH 3.5	OpenSSH 3.5
	No				OpenSSH 3.5	SunSSH 1.0
	No				SunSSH 1.0	SunSSH 1.0
	Yes				SunSSH 1.0	OpenSSH 3.5


	Looks like Sun doesn't understand the following definitions:
	ClientAliveInterval	30
	ClientCountMax		30

	That would normally disconnect you after 15 minutes of
inactivity.  It times out after 15 minutes of activity or inactivity.

	What I recommend is Stop using Sun SSH or changing all the
OpenSSH servers to have the following definitions:


	ClientAliveInterval	1800
	ClientCountMax		3


Bill W. Clark

PGP ID: 0xC8447EB1

SMTP:bill.clark at umb.com





From iqbala at qwestip.net  Mon Jan 19 05:26:35 2004
From: iqbala at qwestip.net (Asif Iqbal)
Date: Sun, 18 Jan 2004 13:26:35 -0500 (EST)
Subject: PAM_ERROR_MSG and PAM_TEXT_INFO from modules
In-Reply-To: <40028E2B.7030800@zip.com.au>
References: <20040112094316.GA20469@plato.local.lan>
	<40027D48.1050102@zip.com.au>
	<20040112112432.GE20469@plato.local.lan> <40028E2B.7030800@zip.com.au>
Message-ID: <Pine.GSO.4.58L0.0401181318550.22244@qmail>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 12 Jan 2004, Darren Tucker wrote:

>
> It would be possible to return those via SSH2 keyboard-interactive but
> probably not SSH1 PAM-over-TIS(?).  What do others think of sending the
> PAM error and info messages back to the client for keyboard-interactive?

PAM message through keyboard-interactive works perfect. I use pam_radius_auth to
talk to securid server and with keyboard-interactive my users are asked to reset
their password and change their pin as required. In the past I had to use
mod_auth_radius with apache and users had to go to the website to reset it

>
>

Thanks

- -- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
There's no place like 127.0.0.1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (SunOS)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQFACs/fUAgaF+Ymk8URAu9PAKCW+9xvs4s8cRwFKYzNgyqfdYeyMgCghgeY
0or8J3dInOqqeP088f0hMmg=
=aGjC
-----END PGP SIGNATURE-----



From bodi0026 at umn.edu  Mon Jan 19 05:34:26 2004
From: bodi0026 at umn.edu (Derek A Bodin)
Date: Sun, 18 Jan 2004 12:34:26 -0600
Subject: Authentication protocol
Message-ID: <000701c3ddf1$b4048dc0$0c5c2942@asgard>

Hello my name is Derek Bodin.
?
As a personal side project I am trying to create a java SSH2 server.? I have
so far been able to work my through the transportation protocol and the user
authentication protocol.? My question is when the authentication protocol
starts OpenSSH will sit and hang waiting for the server to send a
SSH_MSG_USERAUTH_FAILURE packet and a list of appropriate authentication
methods (password, publickey
). ?After that packet is sent, OpenSSH will
immediately send the SSH_MSG_USERAUTH_REQUEST packet with none as the method
of authentication and then without waiting send a packet for the next method
of authentication.
?
According to [SSH-USERAUTH]: 
?
?The server MUST always reject this request, unless the client is to be
allowed in without any authentication, in which case the server MUST accept
this request.? The main purpose of sending this request is to get the list
of supported methods from the server.?
?
It seems to me that the ?none? packet should be sent directly after the
server accepts the service in order to get the list of methods.? This would
allow the server to either grant the client access right away, or send the
list of other methods for the client to try.? I can?t find any reason in the
protocol drafts why this wouldn?t be acceptable.
?
?
If anyone on this list knows why this packet exchange is done in this order,
please respond to this message I am very curious.
?
Thank you,
?
Derek Bodin
?
PS I am using the OpenSSH_3.4p1 client as my testing client.
?


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.561 / Virus Database: 353 - Release Date: 1/13/2004
 



From markus at openbsd.org  Mon Jan 19 18:49:33 2004
From: markus at openbsd.org (Markus Friedl)
Date: Mon, 19 Jan 2004 08:49:33 +0100
Subject: Authentication protocol
In-Reply-To: <000701c3ddf1$b4048dc0$0c5c2942@asgard>
References: <000701c3ddf1$b4048dc0$0c5c2942@asgard>
Message-ID: <20040119074933.GA12659@folly>

no, it's like this:

server -> client:	SSH2_MSG_SERVICE_ACCEPT
client -> server:	SSH2_MSG_USERAUTH_REQUEST(method = none)
server -> client:	SSH2_MSG_USERAUTH_FAILURE(list of methods)
client -> server:	SSH2_MSG_USERAUTH_REQUEST(some method)

-m



From bell at milliways.st  Mon Jan 19 20:09:02 2004
From: bell at milliways.st (Krister Bergman)
Date: Mon, 19 Jan 2004 10:09:02 +0100 (CET)
Subject: Security suggestion concering SSH and port forwarding.
Message-ID: <Pine.BSO.4.44.0401190948200.1708-100000@gromit.milliways.st>

Hi,

sorry if it is the wrong approuch to suggest improvments to OpenSSH,
but here comes my suggestion:

I recently stumbled upon the scponly shell which in it's chroot:ed form is
an ideal solution when you want to share some files with people you trust
more or less.

The problem is, if you use the scponlyc as shell, port forwarding is still
allowed. This can of course be dissallowed in sshd_config, but not only
for certian users and/or groups.

Example scenario:

You're on a privat network, behind a firewall. You're letting port 22 in
to your linux machine. A few trusted people have normal accounts on this
machine allowing them to use -L to forward ports to other machines on the
private network.

Still you want to give other, less trusted people, access to file areas on
the same machine. You want to keep this as secure as possible and wants to
give them accounts allowing them fileaccess to a certain chroot:ed
environment by using the scponlyc shell. You do NOT want these people to
be able to, for example, use port forwarding to access some less secure
W*ndows machines in the private network.

I know a workaround would be to use two different ssh servers with two
different sshd_config files, each allowing only a certain range of users
and one allowing port forwaring, and one not allowing it.

A nicer solution would be if it could be specified in the sshd_config
which users are allowed to use port forwarding.

Please cc: all answers to me, since I'm not a member of this mailing list.



Best Regards

 Krister Bergman



From dtucker at zip.com.au  Mon Jan 19 20:54:36 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 19 Jan 2004 20:54:36 +1100
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <Pine.BSO.4.44.0401190948200.1708-100000@gromit.milliways.st>
References: <Pine.BSO.4.44.0401190948200.1708-100000@gromit.milliways.st>
Message-ID: <400BA95C.4060202@zip.com.au>

Krister Bergman wrote:
> sorry if it is the wrong approuch to suggest improvments to OpenSSH,
> but here comes my suggestion:
> 
> I recently stumbled upon the scponly shell which in it's chroot:ed form is
> an ideal solution when you want to share some files with people you trust
> more or less.
> 
> The problem is, if you use the scponlyc as shell, port forwarding is still
> allowed. This can of course be dissallowed in sshd_config, but not only
> for certian users and/or groups.

If you're using public-key authentication you can use the 
no-port-forwarding flag on the key:

$ man sshd
AUTHORIZED_KEYS FILE FORMAT
[snip]
   no-port-forwarding
      Forbids TCP/IP forwarding when this key is used for authentica-
      tion.  Any port forward requests by the client will return an
      error.  This might be used, e.g., in connection with the command
      option.

-- 
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 mouring at etoh.eviladmin.org  Mon Jan 19 20:58:36 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 19 Jan 2004 03:58:36 -0600 (CST)
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <Pine.BSO.4.44.0401190948200.1708-100000@gromit.milliways.st>
Message-ID: <Pine.BSO.4.44.0401190354120.27267-100000@etoh.eviladmin.org>


What is wrong with using public keys?

Refer to "man sshd"  under "authorized keys format"

you can set what command that key is good for, if they can do port
forward, from what IP it is valid, etc.

- Ben

On Mon, 19 Jan 2004, Krister Bergman wrote:

> Hi,
>
> sorry if it is the wrong approuch to suggest improvments to OpenSSH,
> but here comes my suggestion:
>
> I recently stumbled upon the scponly shell which in it's chroot:ed form is
> an ideal solution when you want to share some files with people you trust
> more or less.
>
> The problem is, if you use the scponlyc as shell, port forwarding is still
> allowed. This can of course be dissallowed in sshd_config, but not only
> for certian users and/or groups.
>
> Example scenario:
>
> You're on a privat network, behind a firewall. You're letting port 22 in
> to your linux machine. A few trusted people have normal accounts on this
> machine allowing them to use -L to forward ports to other machines on the
> private network.
>
> Still you want to give other, less trusted people, access to file areas on
> the same machine. You want to keep this as secure as possible and wants to
> give them accounts allowing them fileaccess to a certain chroot:ed
> environment by using the scponlyc shell. You do NOT want these people to
> be able to, for example, use port forwarding to access some less secure
> W*ndows machines in the private network.
>
> I know a workaround would be to use two different ssh servers with two
> different sshd_config files, each allowing only a certain range of users
> and one allowing port forwaring, and one not allowing it.
>
> A nicer solution would be if it could be specified in the sshd_config
> which users are allowed to use port forwarding.
>
> Please cc: all answers to me, since I'm not a member of this mailing list.
>
>
>
> Best Regards
>
>  Krister Bergman
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From bell at milliways.st  Mon Jan 19 21:08:08 2004
From: bell at milliways.st (Krister Bergman)
Date: Mon, 19 Jan 2004 11:08:08 +0100 (CET)
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <Pine.BSO.4.44.0401190354120.27267-100000@etoh.eviladmin.org>
Message-ID: <Pine.BSO.4.44.0401191056460.9191-100000@gromit.milliways.st>

Yes, that is an option I am considering. Found that part after I sent the
message.

But I still like the idea to keep it simple by just using userid and
password authentication and keeping these users in a chroot:ed sandbox.

After all this is mainly for "point-and-click" users using WinSCP.
But I will consider and try the option of using public keys.


/Krister

On Mon, 19 Jan 2004, Ben Lindstrom wrote:

>
> What is wrong with using public keys?
>
> Refer to "man sshd"  under "authorized keys format"
>
> you can set what command that key is good for, if they can do port
> forward, from what IP it is valid, etc.
>
> - Ben
>
> On Mon, 19 Jan 2004, Krister Bergman wrote:
>
> > Hi,
> >
> > sorry if it is the wrong approuch to suggest improvments to OpenSSH,
> > but here comes my suggestion:
> >
> > I recently stumbled upon the scponly shell which in it's chroot:ed form is
> > an ideal solution when you want to share some files with people you trust
> > more or less.
> >
> > The problem is, if you use the scponlyc as shell, port forwarding is still
> > allowed. This can of course be dissallowed in sshd_config, but not only
> > for certian users and/or groups.
> >
> > Example scenario:
> >
> > You're on a privat network, behind a firewall. You're letting port 22 in
> > to your linux machine. A few trusted people have normal accounts on this
> > machine allowing them to use -L to forward ports to other machines on the
> > private network.
> >
> > Still you want to give other, less trusted people, access to file areas on
> > the same machine. You want to keep this as secure as possible and wants to
> > give them accounts allowing them fileaccess to a certain chroot:ed
> > environment by using the scponlyc shell. You do NOT want these people to
> > be able to, for example, use port forwarding to access some less secure
> > W*ndows machines in the private network.
> >
> > I know a workaround would be to use two different ssh servers with two
> > different sshd_config files, each allowing only a certain range of users
> > and one allowing port forwaring, and one not allowing it.
> >
> > A nicer solution would be if it could be specified in the sshd_config
> > which users are allowed to use port forwarding.
> >
> > Please cc: all answers to me, since I'm not a member of this mailing list.
> >
> >
> >
> > Best Regards
> >
> >  Krister Bergman
> >
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>
>



From bell at milliways.st  Mon Jan 19 21:09:51 2004
From: bell at milliways.st (Krister Bergman)
Date: Mon, 19 Jan 2004 11:09:51 +0100 (CET)
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <400BA95C.4060202@zip.com.au>
Message-ID: <Pine.BSO.4.44.0401191109230.9191-100000@gromit.milliways.st>

I'm not currently using public keys but I will try that alternative.

/Krister

On Mon, 19 Jan 2004, Darren Tucker wrote:

> Krister Bergman wrote:
> > sorry if it is the wrong approuch to suggest improvments to OpenSSH,
> > but here comes my suggestion:
> >
> > I recently stumbled upon the scponly shell which in it's chroot:ed form is
> > an ideal solution when you want to share some files with people you trust
> > more or less.
> >
> > The problem is, if you use the scponlyc as shell, port forwarding is still
> > allowed. This can of course be dissallowed in sshd_config, but not only
> > for certian users and/or groups.
>
> If you're using public-key authentication you can use the
> no-port-forwarding flag on the key:
>
> $ man sshd
> AUTHORIZED_KEYS FILE FORMAT
> [snip]
>    no-port-forwarding
>       Forbids TCP/IP forwarding when this key is used for authentica-
>       tion.  Any port forward requests by the client will return an
>       error.  This might be used, e.g., in connection with the command
>       option.
>
> --
> 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 dot at dotat.at  Mon Jan 19 21:36:43 2004
From: dot at dotat.at (Tony Finch)
Date: Mon, 19 Jan 2004 10:36:43 +0000
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <Pine.BSO.4.44.0401190948200.1708-100000@gromit.milliways.st>
Message-ID: <E1AiWlv-0007nm-00@chiark.greenend.org.uk>

Krister Bergman <bell at milliways.st> wrote:
>
>I recently stumbled upon the scponly shell which in it's chroot:ed form is
>an ideal solution when you want to share some files with people you trust
>more or less.
>
>The problem is, if you use the scponlyc as shell, port forwarding is still
>allowed. This can of course be dissallowed in sshd_config, but not only
>for certian users and/or groups.

The patch below includes a little bit of infrastructure for bringing
together a lot of sshd's internal authorization decisions, for features
like port forwarding, agent forwarding, X11 forwarding, environment
setting, running commands, etc. etc. which at the moment aren't consistent
across different kinds of authentication mechanisms.

It also includes some code for restricting which ports can be forwarded,
to prevent exactly the kind of probing you want to prevent. Unfortunately
we can't just turn off TCP forwarding, and we can't require the use of
key-based authentication, both for user support reasons.

Unfortunately the infrastructure part is not well fleshed out, so it
only provides a limited degree of control over what different users
can and cannot do.

Tony.
-- 
f.a.n.finch  <dot at dotat.at>  http://dotat.at/
MULL OF KINTYRE TO ARDNAMURCHAN POINT: WEST 7 TO GALE 8 EASING 6 OR 7 LATER.
RAIN. MODERATE GENERALLY, BUT OCCASIONALLY POOR. ROUGH OR VERY ROUGH.


--- auth-options.c	28 Jan 2003 18:06:50 -0000	1.1.1.2
+++ auth-options.c	29 Jan 2003 20:39:19 -0000	1.7
@@ -133,7 +135,7 @@
 			goto next_option;
 		}
 		cp = "environment=\"";
-		if (options.permit_user_env &&
+		if (!auth_restricted(RESTRICT_ENV, pw) &&
 		    strncasecmp(opts, cp, strlen(cp)) == 0) {
 			char *s;
 			struct envstring *new_envstring;
@@ -217,8 +219,6 @@
 		}
 		cp = "permitopen=\"";
 		if (strncasecmp(opts, cp, strlen(cp)) == 0) {
-			char host[256], sport[6];
-			u_short port;
 			char *patterns = xmalloc(strlen(opts) + 1);
 
 			opts += strlen(cp);
@@ -243,8 +243,7 @@
 			}
 			patterns[i] = 0;
 			opts++;
-			if (sscanf(patterns, "%255[^:]:%5[0-9]", host, sport) != 2 &&
-			    sscanf(patterns, "%255[^/]/%5[0-9]", host, sport) != 2) {
+			if (channel_add_permitted_opens(patterns) < 0) {
 				debug("%.100s, line %lu: Bad permitopen specification "
 				    "<%.100s>", file, linenum, patterns);
 				auth_debug_add("%.100s, line %lu: "
@@ -252,16 +251,6 @@
 				xfree(patterns);
 				goto bad_option;
 			}
-			if ((port = a2port(sport)) == 0) {
-				debug("%.100s, line %lu: Bad permitopen port <%.100s>",
-				    file, linenum, sport);
-				auth_debug_add("%.100s, line %lu: "
-				    "Bad permitopen port", file, linenum);
-				xfree(patterns);
-				goto bad_option;
-			}
-			if (options.allow_tcp_forwarding)
-				channel_add_permitted_opens(host, port);
 			xfree(patterns);
 			goto next_option;
 		}
--- auth-pam.c	28 Jan 2003 18:06:51 -0000	1.1.1.2
+++ auth-pam.c	29 Jan 2003 20:39:19 -0000	1.2
@@ -358,7 +360,7 @@
 		no_port_forwarding_flag &= ~2;
 		no_agent_forwarding_flag &= ~2;
 		no_x11_forwarding_flag &= ~2;
-		if (!no_port_forwarding_flag && options.allow_tcp_forwarding)
+		if (!auth_restricted(RESTRICT_TCP, auth_get_user()))
 			channel_permit_all_opens();
 #endif
 	}
--- auth.c	28 Jan 2003 18:06:51 -0000	1.1.1.2
+++ auth.c	29 Jan 2003 21:26:11 -0000	1.4
@@ -291,6 +293,31 @@
 	return 0;
 }
 
+/*
+ * Is the user subject to this restriction?
+ */
+int
+auth_restricted(int restriction, struct passwd *pw)
+{
+	debug2("user shell is %s", pw->pw_shell);
+	if ((options.restrictions & restriction) &&
+	    options.restricted_shell != NULL &&
+	    strcmp(options.restricted_shell, pw->pw_shell) == 0) {
+		debug("Restricted shell (%d)", restriction);
+		return 1;
+	} else if ((restriction & RESTRICT_AGENT) && no_agent_forwarding_flag)
+		return 1;
+	else if ((restriction & RESTRICT_ENV) && !options.permit_user_env)
+		return 1;
+	else if ((restriction & RESTRICT_TCP) &&
+	    (!options.allow_tcp_forwarding || no_port_forwarding_flag))
+		return 1;
+	else if ((restriction & RESTRICT_X11) &&
+	    (!options.x11_forwarding || no_x11_forwarding_flag))
+		return 1;
+	else
+		return 0;
+}
 
 /*
  * Given a template and a passwd structure, build a filename
--- auth.h	28 Jan 2003 18:06:51 -0000	1.1.1.2
+++ auth.h	29 Jan 2003 20:39:19 -0000	1.3
@@ -142,6 +143,7 @@
 void	auth_log(Authctxt *, int, char *, char *);
 void	userauth_finish(Authctxt *, int, char *);
 int	auth_root_allowed(char *);
+int	auth_restricted(int, struct passwd *);
 
 char	*auth2_read_banner(void);
 
--- channels.c	28 Jan 2003 18:06:51 -0000	1.1.1.2
+++ channels.c	24 Mar 2003 19:39:58 -0000	1.5
@@ -96,6 +98,10 @@
 
 /* Number of permitted host/port pairs in the array. */
 static int num_permitted_opens = 0;
+
+/* Don't allow any more to be added. */
+static int fix_permitted_opens = 0;
+
 /*
  * If this is true, all opens are permitted.  This is the case on the server
  * on which we have to trust the client anyway, and the user could do
@@ -1972,7 +1978,7 @@
 }
 
 void
-channel_input_port_open(int type, u_int32_t seq, void *ctxt)
+channel_input_port_open(int type, u_int32_t seq, void *ctxt, int loud)
 {
 	Channel *c = NULL;
 	u_short host_port;
@@ -1991,6 +1997,9 @@
 	packet_check_eom();
 	sock = channel_connect_to(host, host_port);
 	if (sock != -1) {
+		if (loud)
+			log("TCP forwarding connection to %s port %d",
+			    host, host_port);
 		c = channel_new("connected socket",
 		    SSH_CHANNEL_CONNECTING, sock, sock, -1, 0, 0, 0,
 		    originator_string, 1);
@@ -2004,6 +2013,18 @@
 	xfree(host);
 }
 
+void
+channel_input_port_open_quiet(int type, u_int32_t seq, void *ctxt)
+{
+	channel_input_port_open(type, seq, ctxt, 0);
+}
+
+void
+channel_input_port_open_loud(int type, u_int32_t seq, void *ctxt)
+{
+	channel_input_port_open(type, seq, ctxt, 1);
+}
+
 
 /* -- tcp forwarding */
 
@@ -2209,6 +2230,8 @@
 				  port);
 #endif
 	/* Initiate forwarding */
+	log("TCP forwarding listening on port %d %s", port,
+	    gateway_ports ? "open" : "private");
 	channel_setup_local_fwd_listener(port, hostname, host_port, gateway_ports);
 
 	/* Free the argument string. */
@@ -2227,10 +2250,31 @@
 		all_opens_permitted = 1;
 }
 
+/*
+ * If the server-wide configuration specifies some permitted_opens
+ * then don't allow users to add to them.
+ */
 void
-channel_add_permitted_opens(char *host, int port)
+channel_fix_permitted_opens(void)
 {
-	if (num_permitted_opens >= SSH_MAX_FORWARDS_PER_DIRECTION)
+	if (num_permitted_opens != 0)
+		fix_permitted_opens = 1;
+}
+
+int
+channel_add_permitted_opens(char *hostport)
+{
+	char host[256], sport[6];
+	u_short port;
+
+	if (sscanf(hostport, "%255[^:]:%5[0-9]", host, sport) != 2 &&
+	    sscanf(hostport, "%255[^/]/%5[0-9]", host, sport) != 2)
+		return -1;
+	if ((port = a2port(sport)) == 0)
+		return -1;
+
+	if (num_permitted_opens >= SSH_MAX_FORWARDS_PER_DIRECTION ||
+	    fix_permitted_opens)
 		fatal("channel_request_remote_forwarding: too many forwards");
 	debug("allow port forwarding to host %s port %d", host, port);
 
@@ -2239,6 +2283,7 @@
 	num_permitted_opens++;
 
 	all_opens_permitted = 0;
+	return 0;
 }
 
 void
@@ -2246,6 +2291,8 @@
 {
 	int i;
 
+	if (fix_permitted_opens)
+		return;
 	for (i = 0; i < num_permitted_opens; i++)
 		xfree(permitted_opens[i].host_to_connect);
 	num_permitted_opens = 0;
@@ -2448,6 +2495,7 @@
 		    0, xstrdup("X11 inet listener"), 1);
 		nc->single_connection = single_connection;
 	}
+	log("X11 forwarding listening on port %d", 6000+display_number);
 
 	/* Return the display number for the DISPLAY environment variable. */
 	*display_numberp = display_number;
--- channels.h	28 Jan 2003 18:06:51 -0000	1.1.1.2
+++ channels.h	28 Jan 2003 19:06:35 -0000	1.4
@@ -176,7 +177,9 @@
 void	 channel_input_oclose(int, u_int32_t, void *);
 void	 channel_input_open_confirmation(int, u_int32_t, void *);
 void	 channel_input_open_failure(int, u_int32_t, void *);
-void	 channel_input_port_open(int, u_int32_t, void *);
+void	 channel_input_port_open(int, u_int32_t, void *, int);
+void	 channel_input_port_open_loud(int, u_int32_t, void *);
+void	 channel_input_port_open_quiet(int, u_int32_t, void *);
 void	 channel_input_window_adjust(int, u_int32_t, void *);
 
 /* file descriptor handling (read/write) */
@@ -194,7 +197,8 @@
 /* tcp forwarding */
 void	 channel_set_af(int af);
 void     channel_permit_all_opens(void);
-void	 channel_add_permitted_opens(char *, int);
+void     channel_fix_permitted_opens(void);
+int	 channel_add_permitted_opens(char *);
 void	 channel_clear_permitted_opens(void);
 void     channel_input_port_forward_request(int, int);
 int	 channel_connect_to(const char *, u_short);
--- clientloop.c	28 Jan 2003 18:06:51 -0000	1.1.1.2
+++ clientloop.c	28 Jan 2003 19:06:35 -0000	1.3
@@ -1342,7 +1344,7 @@
 	dispatch_set(SSH_MSG_CHANNEL_DATA, &channel_input_data);
 	dispatch_set(SSH_MSG_CHANNEL_OPEN_CONFIRMATION, &channel_input_open_confirmation);
 	dispatch_set(SSH_MSG_CHANNEL_OPEN_FAILURE, &channel_input_open_failure);
-	dispatch_set(SSH_MSG_PORT_OPEN, &channel_input_port_open);
+	dispatch_set(SSH_MSG_PORT_OPEN, &channel_input_port_open_quiet);
 	dispatch_set(SSH_SMSG_EXITSTATUS, &client_input_exit_status);
 	dispatch_set(SSH_SMSG_STDERR_DATA, &client_input_stderr_data);
 	dispatch_set(SSH_SMSG_STDOUT_DATA, &client_input_stdout_data);
--- readconf.c	28 Jan 2003 18:06:52 -0000	1.1.1.2
+++ readconf.c	24 Mar 2003 16:03:01 -0000	1.2
@@ -114,6 +116,7 @@
 	oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication,
 	oHostKeyAlgorithms, oBindAddress, oSmartcardDevice,
 	oClearAllForwardings, oNoHostAuthenticationForLocalhost,
+	oVersionAddendum,
 	oDeprecated
 } OpCodes;
 
@@ -186,6 +189,7 @@
 	{ "smartcarddevice", oSmartcardDevice },
 	{ "clearallforwardings", oClearAllForwardings },
 	{ "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost },
+	{ "versionaddendum", oVersionAddendum },
 	{ NULL, oBadOption }
 };
 
@@ -667,6 +671,13 @@
 		}
 		if (*activep && *intptr == -1)
 			*intptr = value;
+		break;
+
+	case oVersionAddendum:
+		ssh_version_set_addendum(strtok(s, "\n"));
+		do {
+			arg = strdelim(&s);
+		} while (arg != NULL && *arg != '\0');
 		break;
 
 	case oDeprecated:
--- servconf.c	28 Jan 2003 18:06:52 -0000	1.1.1.2
+++ servconf.c	24 Mar 2003 16:03:01 -0000	1.9
@@ -39,6 +41,7 @@
 #include "cipher.h"
 #include "kex.h"
 #include "mac.h"
+#include "channels.h"
 
 static void add_listen_addr(ServerOptions *, char *, u_short);
 static void add_one_listen_addr(ServerOptions *, char *, u_short);
@@ -102,6 +105,9 @@
 	options->challenge_response_authentication = -1;
 	options->permit_empty_passwd = -1;
 	options->permit_user_env = -1;
+	options->permit_tcp_listen = -1;
+	options->restricted_shell = NULL;
+	options->restrictions = -1;
 	options->use_login = -1;
 	options->compression = -1;
 	options->allow_tcp_forwarding = -1;
@@ -226,6 +232,10 @@
 		options->permit_empty_passwd = 0;
 	if (options->permit_user_env == -1)
 		options->permit_user_env = 0;
+	if (options->permit_tcp_listen == -1)
+		options->permit_tcp_listen = 1;
+	if (options->restrictions == -1)
+		options->restrictions = 0;
 	if (options->use_login == -1)
 		options->use_login = 0;
 	if (options->compression == -1)
@@ -234,6 +244,7 @@
 		options->allow_tcp_forwarding = 1;
 	if (options->gateway_ports == -1)
 		options->gateway_ports = 0;
+	channel_fix_permitted_opens();
 	if (options->max_startups == -1)
 		options->max_startups = 10;
 	if (options->max_startups_rate == -1)
@@ -294,6 +305,7 @@
 	sPrintMotd, sPrintLastLog, sIgnoreRhosts,
 	sX11Forwarding, sX11DisplayOffset, sX11UseLocalhost,
 	sStrictModes, sEmptyPasswd, sKeepAlives,
+	sPermitTcpConnect, sPermitTcpListen, sRestrictedShell,
 	sPermitUserEnvironment, sUseLogin, sAllowTcpForwarding, sCompression,
 	sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups,
 	sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile,
@@ -301,7 +313,7 @@
 	sBanner, sVerifyReverseMapping, sHostbasedAuthentication,
 	sHostbasedUsesNameFromPacketOnly, sClientAliveInterval,
 	sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2,
-	sUsePrivilegeSeparation,
+	sUsePrivilegeSeparation, sVersionAddendum,
 	sDeprecated
 } ServerOpCodes;
 
@@ -355,6 +367,7 @@
 	{ "x11displayoffset", sX11DisplayOffset },
 	{ "x11uselocalhost", sX11UseLocalhost },
 	{ "xauthlocation", sXAuthLocation },
+	{ "restrictedshell", sRestrictedShell },
 	{ "strictmodes", sStrictModes },
 	{ "permitemptypasswords", sEmptyPasswd },
 	{ "permituserenvironment", sPermitUserEnvironment },
@@ -362,6 +375,8 @@
 	{ "compression", sCompression },
 	{ "keepalive", sKeepAlives },
 	{ "allowtcpforwarding", sAllowTcpForwarding },
+	{ "permittcpconnect", sPermitTcpConnect },
+	{ "permittcplisten", sPermitTcpListen },
 	{ "allowusers", sAllowUsers },
 	{ "denyusers", sDenyUsers },
 	{ "allowgroups", sAllowGroups },
@@ -379,7 +394,8 @@
 	{ "clientalivecountmax", sClientAliveCountMax },
 	{ "authorizedkeysfile", sAuthorizedKeysFile },
 	{ "authorizedkeysfile2", sAuthorizedKeysFile2 },
-	{ "useprivilegeseparation", sUsePrivilegeSeparation},
+	{ "useprivilegeseparation", sUsePrivilegeSeparation },
+	{ "versionaddendum", sVersionAddendum },
 	{ NULL, sBadOption }
 };
 
@@ -705,6 +721,30 @@
 		charptr = &options->xauth_location;
 		goto parse_filename;
 
+	case sRestrictedShell:
+		arg = strdelim(&cp);
+		if (!arg || *arg == '\0')
+			fatal("%s line %d: missing restrictions.",
+			    filename, linenum);
+		options->restrictions = 0;
+		while ((p = strsep(&arg, ",")) != NULL) {
+			if (strcasecmp(p, "agent") == 0)
+				options->restrictions |= RESTRICT_AGENT;
+			else if (strcasecmp(p, "env") == 0)
+				options->restrictions |= RESTRICT_ENV;
+			else if (strcasecmp(p, "rc") == 0)
+				options->restrictions |= RESTRICT_RC;
+			else if (strcasecmp(p, "tcp") == 0)
+				options->restrictions |= RESTRICT_TCP;
+			else if (strcasecmp(p, "x11") == 0)
+				options->restrictions |= RESTRICT_X11;
+			else
+				fatal("%s line %d: unknown restriction %s.",
+				    filename, linenum, p);
+		}
+		charptr = &options->restricted_shell;
+		goto parse_filename;
+
 	case sStrictModes:
 		intptr = &options->strict_modes;
 		goto parse_flag;
@@ -763,6 +803,22 @@
 		intptr = &options->allow_tcp_forwarding;
 		goto parse_flag;
 
+	case sPermitTcpConnect:
+		arg = strdelim(&cp);
+		p = NULL;
+		if (!arg || *arg == '\0')
+			p = "missing";
+		if (channel_add_permitted_opens(arg) < 0)
+			p = "bad";
+		if (p != NULL)
+			fatal("%.200s, line %d: %s inet addr:port.",
+			    filename, linenum, p);
+		break;
+
+	case sPermitTcpListen:
+		intptr = &options->permit_tcp_listen;
+		goto parse_flag;
+
 	case sUsePrivilegeSeparation:
 		intptr = &use_privsep;
 		goto parse_flag;
@@ -908,6 +964,13 @@
 	case sClientAliveCountMax:
 		intptr = &options->client_alive_count_max;
 		goto parse_int;
+
+	case sVersionAddendum:
+		ssh_version_set_addendum(strtok(cp, "\n"));
+		do {
+			arg = strdelim(&cp);
+		} while (arg != NULL && *arg != '\0');
+		break;
 
 	case sDeprecated:
 		log("%s line %d: Deprecated option %s",
--- servconf.h	28 Jan 2003 18:06:52 -0000	1.1.1.2
+++ servconf.h	29 Jan 2003 21:26:12 -0000	1.7
@@ -32,6 +33,13 @@
 #define	PERMIT_NO_PASSWD	2
 #define	PERMIT_YES		3
 
+/* restrictions */
+#define	RESTRICT_AGENT		1
+#define	RESTRICT_ENV		2
+#define	RESTRICT_RC		4
+#define	RESTRICT_TCP		8
+#define	RESTRICT_X11		16
+
 
 typedef struct {
 	u_int num_ports;
@@ -98,6 +106,9 @@
 	int     permit_empty_passwd;	/* If false, do not permit empty
 					 * passwords. */
 	int     permit_user_env;	/* If true, read ~/.ssh/environment */
+	int     permit_tcp_listen;	/* If true allow -R forwarding */
+	char   *restricted_shell;	/* Restrict users with this shell */
+	int     restrictions;		/* How they are restricted */
 	int     use_login;	/* If true, login(1) is used */
 	int     compression;	/* If true, compression is allowed */
 	int	allow_tcp_forwarding;
--- serverloop.c	28 Jan 2003 18:06:52 -0000	1.1.1.2
+++ serverloop.c	24 Mar 2003 20:53:06 -0000	1.7
@@ -872,6 +874,7 @@
 	xfree(originator);
 	if (sock < 0)
 		return NULL;
+	log("TCP forwarding connection to %s port %d", target, target_port);
 	c = channel_new(ctype, SSH_CHANNEL_CONNECTING,
 	    sock, sock, -1, CHAN_TCP_WINDOW_DEFAULT,
 	    CHAN_TCP_PACKET_DEFAULT, 0, xstrdup("direct-tcpip"), 1);
@@ -977,8 +980,8 @@
 		    listen_address, listen_port);
 
 		/* check permissions */
-		if (!options.allow_tcp_forwarding ||
-		    no_port_forwarding_flag
+		if (!options.permit_tcp_listen ||
+		    auth_restricted(RESTRICT_TCP, pw)
 #ifndef NO_IPPORT_RESERVED_CONCEPT
 		    || (listen_port < IPPORT_RESERVED && pw->pw_uid != 0)
 #endif
@@ -987,6 +990,8 @@
 			packet_send_debug("Server has disabled port forwarding.");
 		} else {
 			/* Start listening on the port */
+			log("TCP forwarding listening on %s port %d",
+			    listen_address, listen_port);
 			success = channel_setup_remote_fwd_listener(
 			    listen_address, listen_port, options.gateway_ports);
 		}
@@ -1061,7 +1066,7 @@
 	dispatch_set(SSH_MSG_CHANNEL_DATA, &channel_input_data);
 	dispatch_set(SSH_MSG_CHANNEL_OPEN_CONFIRMATION, &channel_input_open_confirmation);
 	dispatch_set(SSH_MSG_CHANNEL_OPEN_FAILURE, &channel_input_open_failure);
-	dispatch_set(SSH_MSG_PORT_OPEN, &channel_input_port_open);
+	dispatch_set(SSH_MSG_PORT_OPEN, &channel_input_port_open_loud);
 }
 static void
 server_init_dispatch_15(void)
--- session.c	28 Jan 2003 18:06:52 -0000	1.1.1.2
+++ session.c	29 Jan 2003 20:39:20 -0000	1.7
@@ -212,7 +214,7 @@
 	}
 
 	/* setup the channel layer */
-	if (!no_port_forwarding_flag && options.allow_tcp_forwarding)
+	if (!auth_restricted(RESTRICT_TCP, authctxt->pw))
 		channel_permit_all_opens();
 
 	if (compat20)
@@ -312,7 +314,7 @@
 			break;
 
 		case SSH_CMSG_AGENT_REQUEST_FORWARDING:
-			if (no_agent_forwarding_flag || compat13) {
+			if (auth_restricted(RESTRICT_AGENT, s->pw) || compat13) {
 				debug("Authentication agent forwarding not permitted for this authentication.");
 				break;
 			}
@@ -321,11 +323,7 @@
 			break;
 
 		case SSH_CMSG_PORT_FORWARD_REQUEST:
-			if (no_port_forwarding_flag) {
-				debug("Port forwarding not permitted for this authentication.");
-				break;
-			}
-			if (!options.allow_tcp_forwarding) {
+			if (auth_restricted(RESTRICT_TCP, s->pw)) {
 				debug("Port forwarding not permitted.");
 				break;
 			}
@@ -1085,7 +1083,7 @@
 		    auth_sock_name);
 
 	/* read $HOME/.ssh/environment. */
-	if (options.permit_user_env && !options.use_login) {
+	if (!options.use_login && !auth_restricted(RESTRICT_ENV, pw)) {
 		snprintf(buf, sizeof buf, "%.200s/.ssh/environment",
 		    strcmp(pw->pw_dir, "/") ? pw->pw_dir : "");
 		read_environment_file(&env, &envsize, buf);
@@ -1102,6 +1100,10 @@
 /*
  * Run $HOME/.ssh/rc, /etc/ssh/sshrc, or xauth (whichever is found
  * first in this order).
+ *
+ * A properly-implemented restricted shell doesn't need the
+ * restriction tests, but they're useful for reducing the
+ * amount of noise in the process accounting logs.
  */
 static void
 do_rc_files(Session *s, const char *shell)
@@ -1111,11 +1113,12 @@
 	int do_xauth;
 	struct stat st;
 
-	do_xauth =
+	do_xauth = !auth_restricted(RESTRICT_X11, s->pw) &&
 	    s->display != NULL && s->auth_proto != NULL && s->auth_data != NULL;
 
 	/* ignore _PATH_SSH_USER_RC for subsystems */
-	if (!s->is_subsystem && (stat(_PATH_SSH_USER_RC, &st) >= 0)) {
+	if (!s->is_subsystem && !auth_restricted(RESTRICT_RC, s->pw) &&
+	    (stat(_PATH_SSH_USER_RC, &st) >= 0)) {
 		snprintf(cmd, sizeof cmd, "%s -c '%s %s'",
 		    shell, _PATH_BSHELL, _PATH_SSH_USER_RC);
 		if (debug_flag)
@@ -1723,8 +1726,8 @@
 {
 	static int called = 0;
 	packet_check_eom();
-	if (no_agent_forwarding_flag) {
-		debug("session_auth_agent_req: no_agent_forwarding_flag");
+	if (auth_restricted(RESTRICT_AGENT, s->pw)) {
+		debug("session_auth_agent_req: agent forwarding disabled");
 		return 0;
 	}
 	if (called) {
@@ -2019,12 +2022,8 @@
 	char display[512], auth_display[512];
 	char hostname[MAXHOSTNAMELEN];
 
-	if (no_x11_forwarding_flag) {
-		packet_send_debug("X11 forwarding disabled in user configuration file.");
-		return 0;
-	}
-	if (!options.x11_forwarding) {
-		debug("X11 forwarding disabled in server configuration file.");
+	if (auth_restricted(RESTRICT_X11, s->pw)) {
+		packet_send_debug("X11 forwarding disabled.");
 		return 0;
 	}
 	if (!options.xauth_location ||
--- ssh_config.5	28 Jan 2003 18:06:53 -0000	1.1.1.2
+++ ssh_config.5	24 Mar 2003 16:03:01 -0000	1.2
@@ -611,6 +612,10 @@
 Specifies a file to use for the user
 host key database instead of
 .Pa $HOME/.ssh/known_hosts .
+.It Cm VersionAddendum
+Specifies a string to append to the regular version string to identify
+OS- or site-specific modifications.
+The default is empty.
 .It Cm XAuthLocation
 Specifies the full pathname of the
 .Xr xauth 1
--- sshd_config	28 Jan 2003 18:06:53 -0000	1.1.1.2
+++ sshd_config	23 Mar 2003 19:40:37 -0000	1.6
@@ -76,12 +77,16 @@
 #X11Forwarding no
 #X11DisplayOffset 10
 #X11UseLocalhost yes
+#AllowTcpForwarding yes
+#PermitTcpListen yes
+#PermitTcpConnect
 #PrintMotd yes
 #PrintLastLog yes
 #KeepAlive yes
 #UseLogin no
 #UsePrivilegeSeparation yes
 #PermitUserEnvironment no
+#RestrictedShell
 #Compression yes
 
 #MaxStartups 10
--- sshd_config.5	28 Jan 2003 18:06:53 -0000	1.1.1.2
+++ sshd_config.5	24 Mar 2003 16:03:01 -0000	1.9
@@ -465,6 +466,35 @@
 If this option is set to
 .Dq no
 root is not allowed to login.
+.It Cm PermitTcpConnect
+Restricts TCP forwarding from the client so that
+only certain connection destinations are permitted.
+In the absence of any
+.Cm PermitTcpConnect
+options, any outgoing connection is permitted
+(although per-key restrictions may be imposed by
+.Cm permitopen=""
+options in
+.Pa authorized_keys
+files).
+If
+.Cm PermitTcpConnect
+options are present then
+.Nm sshd
+will only allow connections to the
+.Ar host Ns : Ns Ar port
+pairs that are specified.
+Multiple permitted destinations may be specified using multiple
+.Cm PermitTcpConnect
+options.
+IPv6 addresses may be specified using the syntax
+.Ar host Ns / Ns Ar port
+for the argument instead of
+.Ar host Ns : Ns Ar port .
+.It Cm PermitTcpListen
+Specifies whether TCP forwarding to the client is allowed.
+The default is
+.Dq yes .
 .It Cm PermitUserEnvironment
 Specifies whether
 .Pa ~/.ssh/environment
@@ -533,6 +563,29 @@
 The default is
 .Dq yes .
 Note that this option applies to protocol version 2 only.
+.It Cm RestrictedShell
+This option selectively turns off various features
+for users with the shell specified in the second argument.
+The first argument is a comma-separated list, as follows.
+If
+.Dq agent
+is specified then agent forwarding is disabled.
+If
+.Dq env
+is specified then
+.Cm PermitUserEnvironment
+is turned off.
+If
+.Dq rc
+is specified then
+.Pa ~/.ssh/rc
+is not run.
+If
+.Dq tcp
+is specified then TCP port forwarding is disabled.
+If
+.Dq x11
+is specified then X11 fowarding is disabled.
 .It Cm RhostsAuthentication
 Specifies whether authentication using rhosts or /etc/hosts.equiv
 files is sufficient.
@@ -620,6 +673,10 @@
 very same IP address.
 The default is
 .Dq no .
+.It Cm VersionAddendum
+Specifies a string to append to the regular version string to identify
+OS- or site-specific modifications.
+The default is empty.
 .It Cm X11DisplayOffset
 Specifies the first display number available for
 .Nm sshd Ns 's
--- version.h	28 Jan 2003 18:06:53 -0000	1.1.1.2
+++ version.h	24 Mar 2003 16:03:01 -0000	1.2
@@ -1,4 +1,14 @@
 /* $OpenBSD: version.h,v 1.35 2002/10/01 13:24:50 markus Exp $ */
+/* $FreeBSD: src/crypto/openssh/version.h,v 1.19 2003/02/03 11:11:36 des Exp $ */
+/* $Cambridge: hermes/src/openssh/version.h,v 1.2 2003/03/24 16:03:01 fanf2 Exp $ */
 
-#define SSH_VERSION	"OpenSSH_3.5p1"
+#ifndef SSH_VERSION
+
+#define SSH_VERSION             (ssh_version_get())
+#define SSH_VERSION_BASE        "OpenSSH_3.5p1"
+#define SSH_VERSION_ADDENDUM    "noAJ"
+
+const char *ssh_version_get(void);
+void ssh_version_set_addendum(const char *add);
+#endif /* SSH_VERSION */
 



From dan at doxpara.com  Mon Jan 19 21:55:30 2004
From: dan at doxpara.com (Dan Kaminsky)
Date: Mon, 19 Jan 2004 02:55:30 -0800
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <Pine.BSO.4.44.0401190354120.27267-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0401190354120.27267-100000@etoh.eviladmin.org>
Message-ID: <400BB7A2.6010001@doxpara.com>


>What is wrong with using public keys?
>
>  
>
They're integrated a hell of alot better into web browsers than any 
SSH/SFTP client, and still failed?

Not saying pubkey isn't fantastic for us; noticably, we use a system 
practically designed for individual developers or small groups (don't we 
still linearly search through authorized_keys?).  But when dealing with 
those who know just enough about security to know FTP and Telnet are to 
be phased out, pubkey just isn't that good of an option.

scponly does sort of imply, um, scp only.  Perhaps supporting the pubkey 
permissions flags in sshd_config on a per-user basis might be feasible?

--Dan




From bell at milliways.st  Mon Jan 19 22:50:14 2004
From: bell at milliways.st (Krister Bergman)
Date: Mon, 19 Jan 2004 12:50:14 +0100 (CET)
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <400BB7A2.6010001@doxpara.com>
Message-ID: <Pine.BSO.4.44.0401191216270.21139-100000@gromit.milliways.st>

> But when dealing with
> those who know just enough about security to know FTP and Telnet are to
> be phased out, pubkey just isn't that good of an option.

It was when I found scponly and about the same time found WinSCP that I
realized it would be possible to make these kind of "point, click and
drag-n-drog."-users to use encrypted transfer without even realizing it.

Combining WinSCP with scponlyc (chroot:ed scponly) keeps these users in a
quite safe environment while allowing more to trusted users.

> scponly does sort of imply, um, scp only.  Perhaps supporting the pubkey
> permissions flags in sshd_config on a per-user basis might be feasible?

Seems like a possible solution, but I still think an
"AllowedPortForwardingUsers" entry in the sshd_config wouldn't hurt.
(and/or AllowedPortForwardingGroups)

After all this was just a suggestion. Think about it and if you think the
idea sucks, just forget it.

I just refuse to accept that ftp shoule be the only easy option for
allowing non-technical people to download file from a server.

Give them a full working ssh account is just not an option. Most of them
wouldn't know enough about ssh and/or Unix to do any harm but on the other
hand their machines can be hacked by poeple who do. Which means keeping
this accounts locked down to a chroot:ed sandbox feels like a good idea.

Best Regards

  Krister



From nextstepn at katamail.com  Tue Jan 20 02:09:02 2004
From: nextstepn at katamail.com (NeXTstep)
Date: Mon, 19 Jan 2004 16:09:02 +0100
Subject: [leadership/opensource] invitation to online survey
Message-ID: <020d01c3de9e$3524f780$1929e282@babayaro>

Dear all,

      I have just put online a survey addressing the topic of "good
leadership in the open-source environment". Basically, my objective is to
identify the personal conceptions of good leadership that reside in
the minds of the contributors, in terms of leaders' _behaviors_ and
_characteristics_.

What is a good open-source project leader, from the contributor's point of
view? To what extent, those personal believes are shared among developers?
Can the
contributor's national cultural belonging and level of experience in
contributing to open-source projects explain such differences in their idea
of what a good leader is?

I would really appreciate your participation to the survey! Contribution
(completely anonymous) consists in rating a list of statements that may be
used to describe the behaviors of an open-source leader. It will take around
ten minutes - there aren't any "time-consuming" open ended questions;)

Following, the link to the survey:

http://freeonlinesurveys.com/rendersurvey.asp?id=49776

If you are interested, I will not miss to email you a link to the
final report, when ready ;) (approx, a couple of months from now)

Thank you in advance, and don't hesitate to contact me if you have
any questions or comments :)

Gianluca Bosco
g.bosco at GETRIDOFTHISinwind.it
Denmark Technical University
Department of manufacturing engineering and management



From stuge-openssh-unix-dev at cdy.org  Tue Jan 20 04:10:33 2004
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Mon, 19 Jan 2004 18:10:33 +0100
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <Pine.BSO.4.44.0401191216270.21139-100000@gromit.milliways.st>
References: <400BB7A2.6010001@doxpara.com>
	<Pine.BSO.4.44.0401191216270.21139-100000@gromit.milliways.st>
Message-ID: <20040119171033.GI21857@foo.birdnet.se>

On Mon, Jan 19, 2004 at 12:50:14PM +0100, Krister Bergman wrote:
> Combining WinSCP with scponlyc (chroot:ed scponly) keeps these users in a
> quite safe environment while allowing more to trusted users.

Another option is to use rssh and sftp-server. sftp is much prefered over
scp, since scp just serves the purpose of being backwards compatible with
rcp syntax and behaviour.


> Seems like a possible solution, but I still think an
> "AllowedPortForwardingUsers" entry in the sshd_config wouldn't hurt.
> (and/or AllowedPortForwardingGroups)

Yes and no. More options are bad, but on the other hand, unless a
restricted shell can provide policy for stuff going on way back in sshd
(i.e. different forwardings) then we need a way to decide in sshd.

I agree that something more general than the current pubkey flag
approach would be desirable, although the current system works fine for
me at the moment.


> I just refuse to accept that ftp shoule be the only easy option for
> allowing non-technical people to download file from a server.

FTP isn't that easy. I'd say HTTP is easier, but then you have to deal
with lots of broken clients, or just one particular very popular, very
broken, client. (That also does FTP..)

sftp+rssh+WinSCP is a good combination, but rssh can't control the port
forwarding.


//Peter



From mouring at etoh.eviladmin.org  Tue Jan 20 05:22:07 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 19 Jan 2004 12:22:07 -0600 (CST)
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <400BB7A2.6010001@doxpara.com>
Message-ID: <Pine.BSO.4.44.0401191219450.27267-100000@etoh.eviladmin.org>



On Mon, 19 Jan 2004, Dan Kaminsky wrote:

[..]
> scponly does sort of imply, um, scp only.  Perhaps supporting the pubkey
> permissions flags in sshd_config on a per-user basis might be feasible?
>

It is my understanding that such a patch exists in a form of linking
OpenSSH to Keynotes.  However, I've never played with it.  <shrug>  Like
with most open source projects.. One hacks what affects them and what they
enjoy hacking on.

- Ben



From kumaresh_ind at gmx.net  Tue Jan 20 05:29:45 2004
From: kumaresh_ind at gmx.net (Kumaresh)
Date: Mon, 19 Jan 2004 23:59:45 +0530
Subject: OpenSSH - forced command - no-pty issue
Message-ID: <06d701c3deba$40a5d900$230110ac@kurco>

Hello Darren,

The major problem we are running into is that the shell (both sh and ksh)
does not kill its child processes when there is no pty. The SSH patch
mentioned previously at
http://bugzilla.mindrot.org/show_bug.cgi?id=396

is not sufficient to kill the forced command completely.It will only kill
the shell script, but not any child processes the shell script runs. The
shell assumes the child is in the background (because there is no pty) and
therefore does not kill the child.

Consider a shell script /tmp/test.sh that in turn calls "sleep 1000". If we
run a forced command
command="/tmp/test.sh",no-pty,no-port-forwarding ssh-rsa
it gives the following processes:

   root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
   root 13309 12724 10 05:24:20 ?   0:00 sshd: root at notty
   root 13313 13309  4 05:24:21 ?   0:00 /tmp/test.sh
   root 13314 13313  2 05:24:21 ?   0:00 sleep 1000

When we disconnect the client, the sshd process is killed and the shell
script keeps running:

   root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
   root 13313     1  0 05:24:21 ?   0:00 /tmp/test.sh
   root 13314 13313  0 05:24:21 ?   0:00 sleep 1000

When we apply the patch to sshd, the sshd process sends a SIGHUP (hangup)
signal to /tmp/test.sh before exiting. The shell script (/tmp/test.sh) is
killed, but the shell
script does NOT kill its child sleep process. Here is the process list after
the client disconnects:

   root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
   root 13314     1  0 05:24:21 ?   0:00 sleep 1000

You can test this by manually running the command:
  # PID=`ps -ef | grep /tmp/test.sh | awk '{print $2}'`
  # kill -HUP $PID

The shell script will be killed but the child process (sleep 1000) will keep
running.

Please let us know your comments on this.

Thanks in Advance,
Kumaresh.


----- Original Message -----
From: "Darren Tucker" <dtucker at zip.com.au>
To: "Kumaresh" <kumaresh_ind at gmx.net>
Cc: "OpenSSH Devel List" <openssh-unix-dev at mindrot.org>
Sent: Thursday, January 01, 2004 4:49 AM
Subject: Re: OpenSSH - forced command - no-pty issue


> You do not need to send bug reports directly to me, I read the list.
>
> Kumaresh wrote:
> > We have an issue where forced commands are left hanging on the sshd
server
> > running whenever the ssh client disconnects.
> [snip]
> > Is there a way, which we can notify and kill  the commands or child
> > processes when the sshd is terminated.?
>
> This sounds like bug #396.  For details and patch see:
> http://bugzilla.mindrot.org/show_bug.cgi?id=396
>
> --
> 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.
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.561 / Virus Database: 353 - Release Date: 1/13/2004



From carson at taltos.org  Tue Jan 20 09:39:57 2004
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 19 Jan 2004 17:39:57 -0500
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <Pine.BSO.4.44.0401190354120.27267-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0401190354120.27267-100000@etoh.eviladmin.org>
Message-ID: <500378576.1074533997@[192.168.20.160]>

--On Monday, January 19, 2004 3:58 AM -0600 Ben Lindstrom 
<mouring at etoh.eviladmin.org> wrote:

> What is wrong with using public keys?

Users will use a NULL passphrase on the public key (or a trivial password). 
Then we'll get hacked when they loose their laptop. Unless you're using 
smart cards (and using them very carefully), public key auth just isn't 
very secure with "normal" users. This is what led me to do the auth vector 
work way back when.

Which makes me think... if I extended the authorized key mechanisms to 
match against a username instead of (or in addition to, if applicable...) a 
key, is there a chance that would get merged in? The current functionality 
is pretty good, but only if you use pubkey auth. It would be nice to get 
the same functionality regardless of auth mechanism.

-- 
Carson



From vici at dof.se  Tue Jan 20 09:41:43 2004
From: vici at dof.se (Istvan Viczian)
Date: Mon, 19 Jan 2004 23:41:43 +0100
Subject: "PAM rejected by account configuration" and "fatal: monitor_read:
 unsupported request: 24" problem at secong sshd instance
Message-ID: <400C5D27.6010609@dof.se>

Hi,

I setup two sshd instance (using OpenSSH_3.5p1 bins on redhat7.2  kernel 
2.4.20-19.7smp ) in order to achieve differnet sshd settings (e.g use 
different auth.method) on two different network interfaces (both on port 
22).

For example to setup Hostbased authetication on the 1st sshd
and RSA pub. key auth. on the second:

The 1st instance config file /etc/ssh/sshd_config looks like:

  Protocol 2
  ListenAddress 10.0.0.1
  PidFile /var/run/sshd.pid
  SyslogFacility DAEMON
  LogLevel DEBUG3
  IgnoreRhosts yes
  HostbasedAuthentication yes
  PubkeyAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no

The 2nd instance config file: /etc/ssh2/sshd_config
almost the same with the necesary differences:

  Protocol 2
  ListenAddress 10.0.0.2
  PidFile /var/run/sshd2.pid
  SyslogFacility DAEMON
  LogLevel DEBUG3
  IgnoreRhosts yes
  HostbasedAuthentication yes
  PubkeyAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no

( the second instance started with : sshd -f /etc/ssh2/sshd_config 
without any problem)

When I started the two daemon, the first instance
( which uses the default /etc/ssh conf. dir.)
always worked properly (login from host 10.0.0.11 as user2)
independently form the used auth. method
, but the second daemon always failed after the successfull 
authentication with

   "PAM rejected by account configuration[]: User account has expired"
   and
   "fatal: monitor_read: unsupported request: 24"

error messages (see detailed logs below ).

I also tried to run only the second instance, and the same problem
appeared! So it seems for me that the problem is reduced to using non 
default sshd config file!


sshd2 LOG in case of RSA pub. key was set on it:

#Jan 19 23:31:11 mach sshd2[2918]: debug1: trying public key file 
/home/user2/.ssh/authorized_keys
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: checking 
'/home/user2/.ssh'
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: checking 
'/home/user2'
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: terminating 
check at '/home/user2'
#Jan 19 23:31:11 mach sshd2[2918]: debug1: matching key found: file 
/home/user2/.ssh/authorized_keys, line 1
#Jan 19 23:31:11 mach sshd2[2918]: Found matching RSA key: 
fe:45:ce:60:fd:5c:a2:79:db:86:65:15:ad:d2:b2:e4
#Jan 19 23:31:11 mach sshd2[2918]: debug1: restore_uid: 0/0
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_answer_keyallowed: key 
0x80a5928 is allowed
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_send entering: type 21
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_receive entering
#Jan 19 23:31:11 mach sshd2[2918]: debug3: monitor_read: checking request 22
#Jan 19 23:31:11 mach sshd2[2918]: debug1: ssh_rsa_verify: signature correct
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_answer_keyverify: key 
0x80a5b40 signature verified
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_send entering: type 23
#Jan 19 23:31:11 mach sshd2[2918]: debug2: pam_acct_mgmt() = 13
#Jan 19 23:31:11 mach sshd2[2918]: PAM rejected by account 
configuration[13]: User account has expired
#Jan 19 23:31:11 mach sshd2[2918]: Failed publickey for user2 from 
10.0.0.11 port 16760 ssh2
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_receive entering
#Jan 19 23:31:11 mach sshd2[2918]: debug3: monitor_read: checking request 24
#Jan 19 23:31:11 mach sshd2[2918]: fatal: monitor_read: unsupported 
request: 24
#Jan 19 23:31:11 mach sshd2[2918]: debug1: Calling cleanup 0x8054370(0x0)


sshd2 LOG in case of Hostbased Auth. was set on it:

#Jan 19 21:11:22 mach sshd2[21184]: debug2: userauth_hostbased: access 
allowed by auth_rhosts2
#Jan 19 21:11:22 mach sshd2[21184]: debug3: check_host_in_hostfile: 
#filename /etc/ssh/ssh_known_hosts
#Jan 19 21:11:22 mach sshd2[21184]: debug3: check_host_in_hostfile: 
match line 6
#Jan 19 21:11:22 mach sshd2[21184]: debug2: check_key_in_hostfiles: key 
ok for test1.fas.utv.skanova.net
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_answer_keyallowed: key 
0x80a60a8 is allowed
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_append_debug: Appending 
debug messages for child
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_send entering: 
type 21
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_receive entering
#Jan 19 21:11:22 mach sshd2[21184]: debug3: monitor_read: checking 
request 22
#Jan 19 21:11:22 mach sshd2[21184]: debug1: ssh_rsa_verify: signature 
correct
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_answer_keyverify: key 
0x80a62f8 signature verified
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_send entering: 
type 23
#Jan 19 21:11:22 mach sshd2[21184]: debug2: pam_acct_mgmt() = 13
#Jan 19 21:11:22 mach sshd2[21184]: PAM rejected by account 
configuration[13]: User account has expired
#Jan 19 21:11:22 mach sshd2[21184]: Failed hostbased for user2 from 
10.0.0.11 port 16708 ssh2
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_receive entering
#Jan 19 21:11:22 mach sshd2[21184]: debug3: monitor_read: checking 
request 24
#Jan 19 21:11:22 mach sshd2[21184]: fatal: monitor_read: unsupported 
request: 24
#Jan 19 21:11:22 mach sshd2[21184]: debug1: Calling cleanup 0x8054370(0x0)



Any ideas what can be the problem?
Regards,
Istvan



From mouring at etoh.eviladmin.org  Tue Jan 20 10:04:06 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 19 Jan 2004 17:04:06 -0600 (CST)
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <500378576.1074533997@[192.168.20.160]>
Message-ID: <Pine.BSO.4.44.0401191652320.27267-100000@etoh.eviladmin.org>



On Mon, 19 Jan 2004, Carson Gaspar wrote:

> --On Monday, January 19, 2004 3:58 AM -0600 Ben Lindstrom
> <mouring at etoh.eviladmin.org> wrote:
>
> > What is wrong with using public keys?
>
> Users will use a NULL passphrase on the public key (or a trivial password).
> Then we'll get hacked when they loose their laptop. Unless you're using
> smart cards (and using them very carefully), public key auth just isn't
> very secure with "normal" users. This is what led me to do the auth vector
> work way back when.
>

People pick shitty system passwords also.  Your point?  As SSH clients are
integrated into ftp cleints, OS etc, more and more of those shitty
passwords are "stored" clear text or cheaply scrambled method.  All so the
user does not have to reenter it day in and day out.

So the same risks occur.

Do you know how much crap IE/Mozilla exposes for user/pass they store
that users blindly use?

CuteFTP along with 99% of every other FTP clients don't really encrypt
their user/pass.  Guess what?  Security breah.

ODBC is HORRIBLE also.  How many badly written database applications have
"backend passwords" that require ODBC passwords saved away in hidden
places on the drive.

Are we seeing why your argument is worthless?  If you can't teach your
users to do good security pratice then nothing will save you.

[Side note:  I've not played with it, but I like OS/X encrypted
filespace concept.  Also the keyring is also encrypted decently.
Why more OSes don't do this is beyond me.]

> Which makes me think... if I extended the authorized key mechanisms to
> match against a username instead of (or in addition to, if applicable...) a
> key, is there a chance that would get merged in? The current functionality
> is pretty good, but only if you use pubkey auth. It would be nice to get
> the same functionality regardless of auth mechanism.
>

Not sure I see a point.  How does this improve anything?

- Ben



From carson at taltos.org  Tue Jan 20 10:16:02 2004
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 19 Jan 2004 18:16:02 -0500
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <Pine.BSO.4.44.0401191652320.27267-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0401191652320.27267-100000@etoh.eviladmin.org>
Message-ID: <502543409.1074536162@[192.168.20.160]>



--On Monday, January 19, 2004 5:04 PM -0600 Ben Lindstrom 
<mouring at etoh.eviladmin.org> wrote:

> People pick shitty system passwords also.  Your point?  As SSH clients are
> integrated into ftp cleints, OS etc, more and more of those shitty
> passwords are "stored" clear text or cheaply scrambled method.  All so the
> user does not have to reenter it day in and day out.

I can't stop my users from storing passphrases. I can force them to pick 
good ones, and to change them on a regular basis. Having done both, this 
_does_ lead to better user behaviour than pubkey auth. Of course, back when 
I ran this sort of thing, I did both - they had to authenticate with a 
public key (where thay control the ease of use / security), and then 
authenticate with a passphrase (where I did). If I really felt like it, I 
could detect users who stored the passphrase by looking at the timing 
(assuming lazy and not malicious users). If you want better security than 
that, you need to go to hardware tokens / smartcards / whatever, and accept 
the costs.

>> Which makes me think... if I extended the authorized key mechanisms to
>> match against a username instead of (or in addition to, if
>> applicable...) a key, is there a chance that would get merged in? The
>> current functionality is pretty good, but only if you use pubkey auth.
>> It would be nice to get the same functionality regardless of auth
>> mechanism.
>>
>
> Not sure I see a point.  How does this improve anything?

It allows the same nice user behaviour controls (port forwarding, only run 
this command, etc.) even if we choose not to use public key auth.

-- 
Carson



From vici at dof.se  Tue Jan 20 09:41:43 2004
From: vici at dof.se (Istvan Viczian)
Date: Mon, 19 Jan 2004 23:41:43 +0100
Subject: "PAM rejected by account configuration" and "fatal: monitor_read:
	unsupported request: 24" problem at secong sshd instance
Message-ID: <400C5D27.6010609@dof.se>

Hi,

I setup two sshd instance (using OpenSSH_3.5p1 bins on redhat7.2  kernel 
2.4.20-19.7smp ) in order to achieve differnet sshd settings (e.g use 
different auth.method) on two different network interfaces (both on port 
22).

For example to setup Hostbased authetication on the 1st sshd
and RSA pub. key auth. on the second:

The 1st instance config file /etc/ssh/sshd_config looks like:

  Protocol 2
  ListenAddress 10.0.0.1
  PidFile /var/run/sshd.pid
  SyslogFacility DAEMON
  LogLevel DEBUG3
  IgnoreRhosts yes
  HostbasedAuthentication yes
  PubkeyAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no

The 2nd instance config file: /etc/ssh2/sshd_config
almost the same with the necesary differences:

  Protocol 2
  ListenAddress 10.0.0.2
  PidFile /var/run/sshd2.pid
  SyslogFacility DAEMON
  LogLevel DEBUG3
  IgnoreRhosts yes
  HostbasedAuthentication yes
  PubkeyAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no

( the second instance started with : sshd -f /etc/ssh2/sshd_config 
without any problem)

When I started the two daemon, the first instance
( which uses the default /etc/ssh conf. dir.)
always worked properly (login from host 10.0.0.11 as user2)
independently form the used auth. method
, but the second daemon always failed after the successfull 
authentication with

   "PAM rejected by account configuration[]: User account has expired"
   and
   "fatal: monitor_read: unsupported request: 24"

error messages (see detailed logs below ).

I also tried to run only the second instance, and the same problem
appeared! So it seems for me that the problem is reduced to using non 
default sshd config file!


sshd2 LOG in case of RSA pub. key was set on it:

#Jan 19 23:31:11 mach sshd2[2918]: debug1: trying public key file 
/home/user2/.ssh/authorized_keys
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: checking 
'/home/user2/.ssh'
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: checking 
'/home/user2'
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: terminating 
check at '/home/user2'
#Jan 19 23:31:11 mach sshd2[2918]: debug1: matching key found: file 
/home/user2/.ssh/authorized_keys, line 1
#Jan 19 23:31:11 mach sshd2[2918]: Found matching RSA key: 
fe:45:ce:60:fd:5c:a2:79:db:86:65:15:ad:d2:b2:e4
#Jan 19 23:31:11 mach sshd2[2918]: debug1: restore_uid: 0/0
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_answer_keyallowed: key 
0x80a5928 is allowed
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_send entering: type 21
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_receive entering
#Jan 19 23:31:11 mach sshd2[2918]: debug3: monitor_read: checking request 22
#Jan 19 23:31:11 mach sshd2[2918]: debug1: ssh_rsa_verify: signature correct
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_answer_keyverify: key 
0x80a5b40 signature verified
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_send entering: type 23
#Jan 19 23:31:11 mach sshd2[2918]: debug2: pam_acct_mgmt() = 13
#Jan 19 23:31:11 mach sshd2[2918]: PAM rejected by account 
configuration[13]: User account has expired
#Jan 19 23:31:11 mach sshd2[2918]: Failed publickey for user2 from 
10.0.0.11 port 16760 ssh2
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_receive entering
#Jan 19 23:31:11 mach sshd2[2918]: debug3: monitor_read: checking request 24
#Jan 19 23:31:11 mach sshd2[2918]: fatal: monitor_read: unsupported 
request: 24
#Jan 19 23:31:11 mach sshd2[2918]: debug1: Calling cleanup 0x8054370(0x0)


sshd2 LOG in case of Hostbased Auth. was set on it:

#Jan 19 21:11:22 mach sshd2[21184]: debug2: userauth_hostbased: access 
allowed by auth_rhosts2
#Jan 19 21:11:22 mach sshd2[21184]: debug3: check_host_in_hostfile: 
#filename /etc/ssh/ssh_known_hosts
#Jan 19 21:11:22 mach sshd2[21184]: debug3: check_host_in_hostfile: 
match line 6
#Jan 19 21:11:22 mach sshd2[21184]: debug2: check_key_in_hostfiles: key 
ok for test1.fas.utv.skanova.net
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_answer_keyallowed: key 
0x80a60a8 is allowed
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_append_debug: Appending 
debug messages for child
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_send entering: 
type 21
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_receive entering
#Jan 19 21:11:22 mach sshd2[21184]: debug3: monitor_read: checking 
request 22
#Jan 19 21:11:22 mach sshd2[21184]: debug1: ssh_rsa_verify: signature 
correct
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_answer_keyverify: key 
0x80a62f8 signature verified
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_send entering: 
type 23
#Jan 19 21:11:22 mach sshd2[21184]: debug2: pam_acct_mgmt() = 13
#Jan 19 21:11:22 mach sshd2[21184]: PAM rejected by account 
configuration[13]: User account has expired
#Jan 19 21:11:22 mach sshd2[21184]: Failed hostbased for user2 from 
10.0.0.11 port 16708 ssh2
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_receive entering
#Jan 19 21:11:22 mach sshd2[21184]: debug3: monitor_read: checking 
request 24
#Jan 19 21:11:22 mach sshd2[21184]: fatal: monitor_read: unsupported 
request: 24
#Jan 19 21:11:22 mach sshd2[21184]: debug1: Calling cleanup 0x8054370(0x0)



Any ideas what can be the problem?
Regards,
Istvan



From vici at dof.se  Tue Jan 20 09:41:43 2004
From: vici at dof.se (Istvan Viczian)
Date: Mon, 19 Jan 2004 23:41:43 +0100
Subject: "PAM rejected by account configuration" and "fatal: monitor_read:
 unsupported request: 24" problem at secong sshd instance
Message-ID: <400C5D27.6010609@dof.se>

Hi,

I setup two sshd instance (using OpenSSH_3.5p1 bins on redhat7.2  kernel 
2.4.20-19.7smp ) in order to achieve differnet sshd settings (e.g use 
different auth.method) on two different network interfaces (both on port 
22).

For example to setup Hostbased authetication on the 1st sshd
and RSA pub. key auth. on the second:

The 1st instance config file /etc/ssh/sshd_config looks like:

  Protocol 2
  ListenAddress 10.0.0.1
  PidFile /var/run/sshd.pid
  SyslogFacility DAEMON
  LogLevel DEBUG3
  IgnoreRhosts yes
  HostbasedAuthentication yes
  PubkeyAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no

The 2nd instance config file: /etc/ssh2/sshd_config
almost the same with the necesary differences:

  Protocol 2
  ListenAddress 10.0.0.2
  PidFile /var/run/sshd2.pid
  SyslogFacility DAEMON
  LogLevel DEBUG3
  IgnoreRhosts yes
  HostbasedAuthentication yes
  PubkeyAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no

( the second instance started with : sshd -f /etc/ssh2/sshd_config 
without any problem)

When I started the two daemon, the first instance
( which uses the default /etc/ssh conf. dir.)
always worked properly (login from host 10.0.0.11 as user2)
independently form the used auth. method
, but the second daemon always failed after the successfull 
authentication with

   "PAM rejected by account configuration[]: User account has expired"
   and
   "fatal: monitor_read: unsupported request: 24"

error messages (see detailed logs below ).

I also tried to run only the second instance, and the same problem
appeared! So it seems for me that the problem is reduced to using non 
default sshd config file!


sshd2 LOG in case of RSA pub. key was set on it:

#Jan 19 23:31:11 mach sshd2[2918]: debug1: trying public key file 
/home/user2/.ssh/authorized_keys
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: checking 
'/home/user2/.ssh'
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: checking 
'/home/user2'
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: terminating 
check at '/home/user2'
#Jan 19 23:31:11 mach sshd2[2918]: debug1: matching key found: file 
/home/user2/.ssh/authorized_keys, line 1
#Jan 19 23:31:11 mach sshd2[2918]: Found matching RSA key: 
fe:45:ce:60:fd:5c:a2:79:db:86:65:15:ad:d2:b2:e4
#Jan 19 23:31:11 mach sshd2[2918]: debug1: restore_uid: 0/0
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_answer_keyallowed: key 
0x80a5928 is allowed
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_send entering: type 21
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_receive entering
#Jan 19 23:31:11 mach sshd2[2918]: debug3: monitor_read: checking request 22
#Jan 19 23:31:11 mach sshd2[2918]: debug1: ssh_rsa_verify: signature correct
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_answer_keyverify: key 
0x80a5b40 signature verified
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_send entering: type 23
#Jan 19 23:31:11 mach sshd2[2918]: debug2: pam_acct_mgmt() = 13
#Jan 19 23:31:11 mach sshd2[2918]: PAM rejected by account 
configuration[13]: User account has expired
#Jan 19 23:31:11 mach sshd2[2918]: Failed publickey for user2 from 
10.0.0.11 port 16760 ssh2
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_receive entering
#Jan 19 23:31:11 mach sshd2[2918]: debug3: monitor_read: checking request 24
#Jan 19 23:31:11 mach sshd2[2918]: fatal: monitor_read: unsupported 
request: 24
#Jan 19 23:31:11 mach sshd2[2918]: debug1: Calling cleanup 0x8054370(0x0)


sshd2 LOG in case of Hostbased Auth. was set on it:

#Jan 19 21:11:22 mach sshd2[21184]: debug2: userauth_hostbased: access 
allowed by auth_rhosts2
#Jan 19 21:11:22 mach sshd2[21184]: debug3: check_host_in_hostfile: 
#filename /etc/ssh/ssh_known_hosts
#Jan 19 21:11:22 mach sshd2[21184]: debug3: check_host_in_hostfile: 
match line 6
#Jan 19 21:11:22 mach sshd2[21184]: debug2: check_key_in_hostfiles: key 
ok for test1.fas.utv.skanova.net
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_answer_keyallowed: key 
0x80a60a8 is allowed
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_append_debug: Appending 
debug messages for child
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_send entering: 
type 21
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_receive entering
#Jan 19 21:11:22 mach sshd2[21184]: debug3: monitor_read: checking 
request 22
#Jan 19 21:11:22 mach sshd2[21184]: debug1: ssh_rsa_verify: signature 
correct
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_answer_keyverify: key 
0x80a62f8 signature verified
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_send entering: 
type 23
#Jan 19 21:11:22 mach sshd2[21184]: debug2: pam_acct_mgmt() = 13
#Jan 19 21:11:22 mach sshd2[21184]: PAM rejected by account 
configuration[13]: User account has expired
#Jan 19 21:11:22 mach sshd2[21184]: Failed hostbased for user2 from 
10.0.0.11 port 16708 ssh2
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_receive entering
#Jan 19 21:11:22 mach sshd2[21184]: debug3: monitor_read: checking 
request 24
#Jan 19 21:11:22 mach sshd2[21184]: fatal: monitor_read: unsupported 
request: 24
#Jan 19 21:11:22 mach sshd2[21184]: debug1: Calling cleanup 0x8054370(0x0)



Any ideas what can be the problem?
Regards,
Istvan




From dtucker at zip.com.au  Tue Jan 20 12:11:10 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 20 Jan 2004 12:11:10 +1100
Subject: OpenSSH - forced command - no-pty issue
In-Reply-To: <06d701c3deba$40a5d900$230110ac@kurco>
References: <06d701c3deba$40a5d900$230110ac@kurco>
Message-ID: <400C802E.6040909@zip.com.au>

Kumaresh wrote:
> The major problem we are running into is that the shell (both sh and ksh)
> does not kill its child processes when there is no pty. The SSH patch
> mentioned previously at
> http://bugzilla.mindrot.org/show_bug.cgi?id=396
> 
> is not sufficient to kill the forced command completely.It will only kill
> the shell script, but not any child processes the shell script runs. The
> shell assumes the child is in the background (because there is no pty) and
> therefore does not kill the child.

The script should catch the SIGHUP and clean up after itself.

> Consider a shell script /tmp/test.sh that in turn calls "sleep 1000". If we
> run a forced command
> command="/tmp/test.sh",no-pty,no-port-forwarding ssh-rsa
> it gives the following processes:
> 
>    root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
>    root 13309 12724 10 05:24:20 ?   0:00 sshd: root at notty
>    root 13313 13309  4 05:24:21 ?   0:00 /tmp/test.sh
>    root 13314 13313  2 05:24:21 ?   0:00 sleep 1000
> 
> When we disconnect the client, the sshd process is killed and the shell
> script keeps running:
> 
>    root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
>    root 13313     1  0 05:24:21 ?   0:00 /tmp/test.sh
>    root 13314 13313  0 05:24:21 ?   0:00 sleep 1000
> 
> When we apply the patch to sshd, the sshd process sends a SIGHUP (hangup)
> signal to /tmp/test.sh before exiting. The shell script (/tmp/test.sh) is
> killed, but the shell
> script does NOT kill its child sleep process. Here is the process list after
> the client disconnects:
> 
>    root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
>    root 13314     1  0 05:24:21 ?   0:00 sleep 1000
> 
> You can test this by manually running the command:
>   # PID=`ps -ef | grep /tmp/test.sh | awk '{print $2}'`
>   # kill -HUP $PID
> 
> The shell script will be killed but the child process (sleep 1000) will keep
> running.

The shell (script) needs to deal with its own children, there's not much 
sshd can do (except possibly sending the HUP to the process group rather 
than the shell?)

It seems similar to this bug:
http://bugzilla.mindrot.org/show_bug.cgi?id=52

"Known-good workarounds:
* bash: shopt huponexit on
* tcsh: none
* zsh: setopt HUP (usually the default setting)
   (taken from email from Jason Stone to openssh-unix-dev, 5
   May 2001)
* pdksh: ?"

-- 
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 Jan 20 12:21:26 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 20 Jan 2004 12:21:26 +1100
Subject: "PAM rejected by account configuration" and "fatal:
 monitor_read:
 unsupported request: 24" problem at secong sshd instance
In-Reply-To: <400C5D27.6010609@dof.se>
References: <400C5D27.6010609@dof.se>
Message-ID: <400C8296.2000908@zip.com.au>

Istvan Viczian wrote:
> I setup two sshd instance (using OpenSSH_3.5p1 bins on redhat7.2  kernel 
> 2.4.20-19.7smp ) in order to achieve differnet sshd settings (e.g use 
> different auth.method) on two different network interfaces (both on port 
> 22).
[snip]
> ( the second instance started with : sshd -f /etc/ssh2/sshd_config 
> without any problem)
> 
> When I started the two daemon, the first instance
> ( which uses the default /etc/ssh conf. dir.)
> always worked properly (login from host 10.0.0.11 as user2)
> independently form the used auth. method
> , but the second daemon always failed after the successfull 
> authentication with
> 
>   "PAM rejected by account configuration[]: User account has expired"
>   and
>   "fatal: monitor_read: unsupported request: 24"
> 
> error messages (see detailed logs below ).

PAM thinks the account has expired.  Check it with "chage -l 
accountname" and if it is, unexpire it ("chage -E" I think, check the 
man page).

> I also tried to run only the second instance, and the same problem
> appeared! So it seems for me that the problem is reduced to using non 
> default sshd config file!

I suspect that your first sshd was compiled without PAM support and the 
second was compiled with it.

-- 
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 jmknoble at pobox.com  Tue Jan 20 13:44:20 2004
From: jmknoble at pobox.com (Jim Knoble)
Date: Mon, 19 Jan 2004 21:44:20 -0500
Subject: OpenSSH - forced command - no-pty issue
In-Reply-To: <400C802E.6040909@zip.com.au>
References: <06d701c3deba$40a5d900$230110ac@kurco>
	<400C802E.6040909@zip.com.au>
Message-ID: <20040120024420.GD10424@crawfish.ais.com>

Circa 2004-01-20 12:11:10 +1100 dixit Darren Tucker:

: It seems similar to this bug:
: http://bugzilla.mindrot.org/show_bug.cgi?id=52
: 
: "Known-good workarounds:
  [...]
: * pdksh: ?"

    pdksh: set +o nohup (as long as the shell is a login shell)

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
 .....................................................................
 :"The methods now being used to merchandise the political candidate :
 : as though he were a deodorant positively guarantee the electorate :
 : against ever hearing the truth about anything."   --Aldous Huxley :
 :...................................................................:



From djm at mindrot.org  Tue Jan 20 13:46:49 2004
From: djm at mindrot.org (Damien Miller)
Date: Tue, 20 Jan 2004 13:46:49 +1100
Subject: Security suggestion concering SSH and port forwarding.
In-Reply-To: <Pine.BSO.4.44.0401191219450.27267-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0401191219450.27267-100000@etoh.eviladmin.org>
Message-ID: <400C9699.9080806@mindrot.org>

Ben Lindstrom wrote:


>>scponly does sort of imply, um, scp only.  Perhaps supporting the pubkey
>>permissions flags in sshd_config on a per-user basis might be feasible?
> 
> It is my understanding that such a patch exists in a form of linking
> OpenSSH to Keynotes.  However, I've never played with it.  <shrug>  Like
> with most open source projects.. One hacks what affects them and what they
> enjoy hacking on.

I wrote a patch to add systemwide and per-user KeyNote policies a few
years ago. It would need a lot of cleanup to work in today's privilege
separated world.

-d



From vici at dof.se  Tue Jan 20 09:41:43 2004
From: vici at dof.se (Istvan Viczian)
Date: Mon, 19 Jan 2004 23:41:43 +0100
Subject: "PAM rejected by account configuration" and "fatal: monitor_read:
 unsupported request: 24" problem at secong sshd instance
Message-ID: <400C5D27.6010609@dof.se>

Hi,

I setup two sshd instance (using OpenSSH_3.5p1 bins on redhat7.2  kernel 
2.4.20-19.7smp ) in order to achieve differnet sshd settings (e.g use 
different auth.method) on two different network interfaces (both on port 
22).

For example to setup Hostbased authetication on the 1st sshd
and RSA pub. key auth. on the second:

The 1st instance config file /etc/ssh/sshd_config looks like:

  Protocol 2
  ListenAddress 10.0.0.1
  PidFile /var/run/sshd.pid
  SyslogFacility DAEMON
  LogLevel DEBUG3
  IgnoreRhosts yes
  HostbasedAuthentication yes
  PubkeyAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no

The 2nd instance config file: /etc/ssh2/sshd_config
almost the same with the necesary differences:

  Protocol 2
  ListenAddress 10.0.0.2
  PidFile /var/run/sshd2.pid
  SyslogFacility DAEMON
  LogLevel DEBUG3
  IgnoreRhosts yes
  HostbasedAuthentication yes
  PubkeyAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no

( the second instance started with : sshd -f /etc/ssh2/sshd_config 
without any problem)

When I started the two daemon, the first instance
( which uses the default /etc/ssh conf. dir.)
always worked properly (login from host 10.0.0.11 as user2)
independently form the used auth. method
, but the second daemon always failed after the successfull 
authentication with

   "PAM rejected by account configuration[]: User account has expired"
   and
   "fatal: monitor_read: unsupported request: 24"

error messages (see detailed logs below ).

I also tried to run only the second instance, and the same problem
appeared! So it seems for me that the problem is reduced to using non 
default sshd config file!


sshd2 LOG in case of RSA pub. key was set on it:

#Jan 19 23:31:11 mach sshd2[2918]: debug1: trying public key file 
/home/user2/.ssh/authorized_keys
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: checking 
'/home/user2/.ssh'
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: checking 
'/home/user2'
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: terminating 
check at '/home/user2'
#Jan 19 23:31:11 mach sshd2[2918]: debug1: matching key found: file 
/home/user2/.ssh/authorized_keys, line 1
#Jan 19 23:31:11 mach sshd2[2918]: Found matching RSA key: 
fe:45:ce:60:fd:5c:a2:79:db:86:65:15:ad:d2:b2:e4
#Jan 19 23:31:11 mach sshd2[2918]: debug1: restore_uid: 0/0
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_answer_keyallowed: key 
0x80a5928 is allowed
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_send entering: type 21
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_receive entering
#Jan 19 23:31:11 mach sshd2[2918]: debug3: monitor_read: checking request 22
#Jan 19 23:31:11 mach sshd2[2918]: debug1: ssh_rsa_verify: signature correct
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_answer_keyverify: key 
0x80a5b40 signature verified
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_send entering: type 23
#Jan 19 23:31:11 mach sshd2[2918]: debug2: pam_acct_mgmt() = 13
#Jan 19 23:31:11 mach sshd2[2918]: PAM rejected by account 
configuration[13]: User account has expired
#Jan 19 23:31:11 mach sshd2[2918]: Failed publickey for user2 from 
10.0.0.11 port 16760 ssh2
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_receive entering
#Jan 19 23:31:11 mach sshd2[2918]: debug3: monitor_read: checking request 24
#Jan 19 23:31:11 mach sshd2[2918]: fatal: monitor_read: unsupported 
request: 24
#Jan 19 23:31:11 mach sshd2[2918]: debug1: Calling cleanup 0x8054370(0x0)


sshd2 LOG in case of Hostbased Auth. was set on it:

#Jan 19 21:11:22 mach sshd2[21184]: debug2: userauth_hostbased: access 
allowed by auth_rhosts2
#Jan 19 21:11:22 mach sshd2[21184]: debug3: check_host_in_hostfile: 
#filename /etc/ssh/ssh_known_hosts
#Jan 19 21:11:22 mach sshd2[21184]: debug3: check_host_in_hostfile: 
match line 6
#Jan 19 21:11:22 mach sshd2[21184]: debug2: check_key_in_hostfiles: key 
ok for test1.fas.utv.skanova.net
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_answer_keyallowed: key 
0x80a60a8 is allowed
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_append_debug: Appending 
debug messages for child
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_send entering: 
type 21
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_receive entering
#Jan 19 21:11:22 mach sshd2[21184]: debug3: monitor_read: checking 
request 22
#Jan 19 21:11:22 mach sshd2[21184]: debug1: ssh_rsa_verify: signature 
correct
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_answer_keyverify: key 
0x80a62f8 signature verified
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_send entering: 
type 23
#Jan 19 21:11:22 mach sshd2[21184]: debug2: pam_acct_mgmt() = 13
#Jan 19 21:11:22 mach sshd2[21184]: PAM rejected by account 
configuration[13]: User account has expired
#Jan 19 21:11:22 mach sshd2[21184]: Failed hostbased for user2 from 
10.0.0.11 port 16708 ssh2
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_receive entering
#Jan 19 21:11:22 mach sshd2[21184]: debug3: monitor_read: checking 
request 24
#Jan 19 21:11:22 mach sshd2[21184]: fatal: monitor_read: unsupported 
request: 24
#Jan 19 21:11:22 mach sshd2[21184]: debug1: Calling cleanup 0x8054370(0x0)



Any ideas what can be the problem?
Regards,
Istvan



From vici at dof.se  Tue Jan 20 09:41:43 2004
From: vici at dof.se (Istvan Viczian)
Date: Mon, 19 Jan 2004 23:41:43 +0100
Subject: "PAM rejected by account configuration" and "fatal: monitor_read:
 unsupported request: 24" problem at secong sshd instance
Message-ID: <400C5D27.6010609@dof.se>

Hi,

I setup two sshd instance (using OpenSSH_3.5p1 bins on redhat7.2  kernel 
2.4.20-19.7smp ) in order to achieve differnet sshd settings (e.g use 
different auth.method) on two different network interfaces (both on port 
22).

For example to setup Hostbased authetication on the 1st sshd
and RSA pub. key auth. on the second:

The 1st instance config file /etc/ssh/sshd_config looks like:

  Protocol 2
  ListenAddress 10.0.0.1
  PidFile /var/run/sshd.pid
  SyslogFacility DAEMON
  LogLevel DEBUG3
  IgnoreRhosts yes
  HostbasedAuthentication yes
  PubkeyAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no

The 2nd instance config file: /etc/ssh2/sshd_config
almost the same with the necesary differences:

  Protocol 2
  ListenAddress 10.0.0.2
  PidFile /var/run/sshd2.pid
  SyslogFacility DAEMON
  LogLevel DEBUG3
  IgnoreRhosts yes
  HostbasedAuthentication yes
  PubkeyAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no

( the second instance started with : sshd -f /etc/ssh2/sshd_config 
without any problem)

When I started the two daemon, the first instance
( which uses the default /etc/ssh conf. dir.)
always worked properly (login from host 10.0.0.11 as user2)
independently form the used auth. method
, but the second daemon always failed after the successfull 
authentication with

   "PAM rejected by account configuration[]: User account has expired"
   and
   "fatal: monitor_read: unsupported request: 24"

error messages (see detailed logs below ).

I also tried to run only the second instance, and the same problem
appeared! So it seems for me that the problem is reduced to using non 
default sshd config file!


sshd2 LOG in case of RSA pub. key was set on it:

#Jan 19 23:31:11 mach sshd2[2918]: debug1: trying public key file 
/home/user2/.ssh/authorized_keys
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: checking 
'/home/user2/.ssh'
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: checking 
'/home/user2'
#Jan 19 23:31:11 mach sshd2[2918]: debug3: secure_filename: terminating 
check at '/home/user2'
#Jan 19 23:31:11 mach sshd2[2918]: debug1: matching key found: file 
/home/user2/.ssh/authorized_keys, line 1
#Jan 19 23:31:11 mach sshd2[2918]: Found matching RSA key: 
fe:45:ce:60:fd:5c:a2:79:db:86:65:15:ad:d2:b2:e4
#Jan 19 23:31:11 mach sshd2[2918]: debug1: restore_uid: 0/0
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_answer_keyallowed: key 
0x80a5928 is allowed
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_send entering: type 21
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_receive entering
#Jan 19 23:31:11 mach sshd2[2918]: debug3: monitor_read: checking request 22
#Jan 19 23:31:11 mach sshd2[2918]: debug1: ssh_rsa_verify: signature correct
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_answer_keyverify: key 
0x80a5b40 signature verified
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_send entering: type 23
#Jan 19 23:31:11 mach sshd2[2918]: debug2: pam_acct_mgmt() = 13
#Jan 19 23:31:11 mach sshd2[2918]: PAM rejected by account 
configuration[13]: User account has expired
#Jan 19 23:31:11 mach sshd2[2918]: Failed publickey for user2 from 
10.0.0.11 port 16760 ssh2
#Jan 19 23:31:11 mach sshd2[2918]: debug3: mm_request_receive entering
#Jan 19 23:31:11 mach sshd2[2918]: debug3: monitor_read: checking request 24
#Jan 19 23:31:11 mach sshd2[2918]: fatal: monitor_read: unsupported 
request: 24
#Jan 19 23:31:11 mach sshd2[2918]: debug1: Calling cleanup 0x8054370(0x0)


sshd2 LOG in case of Hostbased Auth. was set on it:

#Jan 19 21:11:22 mach sshd2[21184]: debug2: userauth_hostbased: access 
allowed by auth_rhosts2
#Jan 19 21:11:22 mach sshd2[21184]: debug3: check_host_in_hostfile: 
#filename /etc/ssh/ssh_known_hosts
#Jan 19 21:11:22 mach sshd2[21184]: debug3: check_host_in_hostfile: 
match line 6
#Jan 19 21:11:22 mach sshd2[21184]: debug2: check_key_in_hostfiles: key 
ok for test1.fas.utv.skanova.net
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_answer_keyallowed: key 
0x80a60a8 is allowed
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_append_debug: Appending 
debug messages for child
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_send entering: 
type 21
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_receive entering
#Jan 19 21:11:22 mach sshd2[21184]: debug3: monitor_read: checking 
request 22
#Jan 19 21:11:22 mach sshd2[21184]: debug1: ssh_rsa_verify: signature 
correct
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_answer_keyverify: key 
0x80a62f8 signature verified
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_send entering: 
type 23
#Jan 19 21:11:22 mach sshd2[21184]: debug2: pam_acct_mgmt() = 13
#Jan 19 21:11:22 mach sshd2[21184]: PAM rejected by account 
configuration[13]: User account has expired
#Jan 19 21:11:22 mach sshd2[21184]: Failed hostbased for user2 from 
10.0.0.11 port 16708 ssh2
#Jan 19 21:11:22 mach sshd2[21184]: debug3: mm_request_receive entering
#Jan 19 21:11:22 mach sshd2[21184]: debug3: monitor_read: checking 
request 24
#Jan 19 21:11:22 mach sshd2[21184]: fatal: monitor_read: unsupported 
request: 24
#Jan 19 21:11:22 mach sshd2[21184]: debug1: Calling cleanup 0x8054370(0x0)



Any ideas what can be the problem?
Regards,
Istvan



From dtucker at zip.com.au  Tue Jan 20 12:21:26 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 20 Jan 2004 12:21:26 +1100
Subject: "PAM rejected by account configuration" and "fatal:
	monitor_read: unsupported request: 24" problem at secong sshd
	instance
In-Reply-To: <400C5D27.6010609@dof.se>
References: <400C5D27.6010609@dof.se>
Message-ID: <400C8296.2000908@zip.com.au>

Istvan Viczian wrote:
> I setup two sshd instance (using OpenSSH_3.5p1 bins on redhat7.2  kernel 
> 2.4.20-19.7smp ) in order to achieve differnet sshd settings (e.g use 
> different auth.method) on two different network interfaces (both on port 
> 22).
[snip]
> ( the second instance started with : sshd -f /etc/ssh2/sshd_config 
> without any problem)
> 
> When I started the two daemon, the first instance
> ( which uses the default /etc/ssh conf. dir.)
> always worked properly (login from host 10.0.0.11 as user2)
> independently form the used auth. method
> , but the second daemon always failed after the successfull 
> authentication with
> 
>   "PAM rejected by account configuration[]: User account has expired"
>   and
>   "fatal: monitor_read: unsupported request: 24"
> 
> error messages (see detailed logs below ).

PAM thinks the account has expired.  Check it with "chage -l 
accountname" and if it is, unexpire it ("chage -E" I think, check the 
man page).

> I also tried to run only the second instance, and the same problem
> appeared! So it seems for me that the problem is reduced to using non 
> default sshd config file!

I suspect that your first sshd was compiled without PAM support and the 
second was compiled with it.

-- 
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 kayosanjpjp at yahoo.co.jp  Tue Jan 20 16:23:21 2004
From: kayosanjpjp at yahoo.co.jp (=?ISO-2022-JP?B?GyRCMys2SCVRJUMlLxsoQiA=?=)
Date: Tue, 20 Jan 2004 14:23:21 +0900
Subject: =?iso-2022-jp?b?GyRCTCQ+NUJ6OS05cCIoGyhCNTAwMBskQjFfJEczKzZIGyhC?=
 =?iso-2022-jp?b?GyRCJDckXiQ7JHMkKyEqISobKEI=?=
Message-ID: <20040120.0523200937@kayosanjpjp-yahoo.co.jp>

 ?
???     ?????? ???????????????
??????????????????????????????
???????????????????????????????????????????????
????ronron78jp at yahoo.co.jp
 ??????????????????????????????
       ???????????
????????TEL  0774-56-6428

?????????????????????????????
?????????????????????????
????????????????????
??????????????????
???????http://skylake.zive.net/ 

?



From dtucker at zip.com.au  Tue Jan 20 16:20:12 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 20 Jan 2004 07:20:12 +0200
Subject: "PAM rejected by account configuration" and "fatal:
	monitor_read: unsupported request: 24" problem at secong sshd
	instance
In-Reply-To: <400C5D27.6010609@dof.se>
References: <400C5D27.6010609@dof.se>
Message-ID: <000801c3df15$145f8f20$6401a8c0@shaya.local>

Istvan Viczian wrote:
> I setup two sshd instance (using OpenSSH_3.5p1 bins on redhat7.2  kernel 
> 2.4.20-19.7smp ) in order to achieve differnet sshd settings (e.g use 
> different auth.method) on two different network interfaces (both on port 
> 22).
[snip]
> ( the second instance started with : sshd -f /etc/ssh2/sshd_config 
> without any problem)
> 
> When I started the two daemon, the first instance
> ( which uses the default /etc/ssh conf. dir.)
> always worked properly (login from host 10.0.0.11 as user2)
> independently form the used auth. method
> , but the second daemon always failed after the successfull 
> authentication with
> 
>   "PAM rejected by account configuration[]: User account has expired"
>   and
>   "fatal: monitor_read: unsupported request: 24"
> 
> error messages (see detailed logs below ).

PAM thinks the account has expired.  Check it with "chage -l 
accountname" and if it is, unexpire it ("chage -E" I think, check the 
man page).

> I also tried to run only the second instance, and the same problem
> appeared! So it seems for me that the problem is reduced to using non 
> default sshd config file!

I suspect that your first sshd was compiled without PAM support and the 
second was compiled with it.

-- 
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 Jan 20 12:21:26 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 20 Jan 2004 12:21:26 +1100
Subject: "PAM rejected by account configuration" and "fatal:
 monitor_read:
 unsupported request: 24" problem at secong sshd instance
In-Reply-To: <400C5D27.6010609@dof.se>
References: <400C5D27.6010609@dof.se>
Message-ID: <400C8296.2000908@zip.com.au>

Istvan Viczian wrote:
> I setup two sshd instance (using OpenSSH_3.5p1 bins on redhat7.2  kernel 
> 2.4.20-19.7smp ) in order to achieve differnet sshd settings (e.g use 
> different auth.method) on two different network interfaces (both on port 
> 22).
[snip]
> ( the second instance started with : sshd -f /etc/ssh2/sshd_config 
> without any problem)
> 
> When I started the two daemon, the first instance
> ( which uses the default /etc/ssh conf. dir.)
> always worked properly (login from host 10.0.0.11 as user2)
> independently form the used auth. method
> , but the second daemon always failed after the successfull 
> authentication with
> 
>   "PAM rejected by account configuration[]: User account has expired"
>   and
>   "fatal: monitor_read: unsupported request: 24"
> 
> error messages (see detailed logs below ).

PAM thinks the account has expired.  Check it with "chage -l 
accountname" and if it is, unexpire it ("chage -E" I think, check the 
man page).

> I also tried to run only the second instance, and the same problem
> appeared! So it seems for me that the problem is reduced to using non 
> default sshd config file!

I suspect that your first sshd was compiled without PAM support and the 
second was compiled with it.

-- 
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 mfucmwtsjd at yahoo.com  Wed Jan 21 10:01:22 2004
From: mfucmwtsjd at yahoo.com (Tyree Garrett)
Date: Wed, 21 Jan 2004 01:01:22 +0200
Subject: ..You can be a ~Se-xxMachine~
Message-ID: <PLDUWAN-0006945715590@participle>

adventurous burgundian rook elkhart butterball concave chaplin 
dustbin trout plane pedestal cinquefoil ely indigene choir 
curvilinear scald zing bramble braid cobol 
composition tripartite bust torpedo transverse marvin crestfallen troika 
molybdate aflame righteous aden diffusive lenin wilcox downright pittsburgh 
inflammable smear cathy orinoco 


From Kishore_Vinjam at apl.com  Wed Jan 21 00:27:12 2004
From: Kishore_Vinjam at apl.com (Vinjam, Kishore)
Date: Tue, 20 Jan 2004 06:27:12 -0700
Subject: Problem restarting SSHD in AIX  when the server got rebooted.
Message-ID: <2D5E3EF1FA26994F98530BFF820D26A95783AD@d1col601mb.d1.ad.apl.com>

Hi ,

I had downloaded the OpenSSH AIX binary packages from http://www.zip.com.au/~dtucker/openssh/ . It is working fine usually, but when i reboot the server it doesnt start the sshd daemon automatically. 
I see there is a line added in /etc/rc.tcpip server to start the sshd on restart while intallation of the package. But it is throwing the following error in error log while the server is rebooted.
#errpt -a 
---------------------------------------------------------------------------
LABEL:          SRC
IDENTIFIER:     E18E984F
Date/Time:       Tue Jan 20 18:44:55
Sequence Number: 418
Machine Id:      000D55FD4C00
Node Id:         oaklab4
Class:           S
Type:            PERM
Resource Name:   SRC
Description
SOFTWARE PROGRAM ERROR
Probable Causes
APPLICATION PROGRAM
Failure Causes
SOFTWARE PROGRAM
        Recommended Actions
        PERFORM PROBLEM RECOVERY PROCEDURES
Detail Data
SYMPTOM CODE
         256
SOFTWARE ERROR CODE
       -9020
ERROR CODE
           0
DETECTING MODULE
'srchevn.c'@line:'343'
FAILING MODULE
sshd
---------------------------------------------------------------------------
But i am able to restart the sshd manually using startsrc. I notice that the problem is because /etc/rc.tcpip is using startsrc -s sshd -a "0|1" . I tried the same command manually and an error ( as mentioned above) was logged.
I hope this could be a know problem for you. Please let me know the solution for the same.. Your Help would be greatly apprecited.

Regards,
Kishore Vinjam.



From mouring at etoh.eviladmin.org  Wed Jan 21 06:02:46 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Tue, 20 Jan 2004 13:02:46 -0600 (CST)
Subject: diff for Interix port for -portable
In-Reply-To: <200401170802.i0H82oHr047892@mxsf12.cluster1.charter.net>
Message-ID: <Pine.BSO.4.44.0401201302220.27267-100000@etoh.eviladmin.org>


would be nice to see a diff, but I would not hold my breath on some of the
changes.

- Ben

On Sat, 17 Jan 2004 tmtowtdi at charter.net wrote:

> I diffed a clean 3.7.1p2 and one modified by the folks at Interop Systems to compile under Interix (the Windows Posix layer updated in the new Services For Unix release). The bulk of it is removing the hardcoded root UID and GID. If someone is interested in this, I'd be happy to send a diff (though anyone can inspect the changes by grabbing the package from ftp://ftp.interopsystems.com/src/openssh/openssh-3.7.1p2-interix  themselves.) It would be nice to see this building with a vanilla package, since openssh is such a crucial piece of software.
>
> Regards,
> Scott Johnson
>
> _______________________________________________
> 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  Wed Jan 21 17:52:26 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 21 Jan 2004 17:52:26 +1100
Subject: [Resolved] Problem restarting SSHD in AIX when the server got
	rebooted.
In-Reply-To: <2D5E3EF1FA26994F98530BFF820D26A95783AD@d1col601mb.d1.ad.apl.com>
References: <2D5E3EF1FA26994F98530BFF820D26A95783AD@d1col601mb.d1.ad.apl.com>
Message-ID: <400E21AA.6000409@zip.com.au>

Vinjam, Kishore wrote:
[problem starting sshd on AIX via rc.tcpip and startsrc]

For the benefit of the list archives and/or Google: this was due to the 
$3 variable being poluted elsewhere (not sure where) and still being set 
when the "start sshd" line was reached ("start" is a shell function that 
takes up to 3 arguments).  It was resolved by changing the sshd line in 
/etc/rc.tcpip from:

start /usr/local/sbin/sshd "$src_running"

to

start /usr/local/sbin/sshd "$src_running" ""

-- 
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 nick at dsvr.net  Thu Jan 22 02:11:51 2004
From: nick at dsvr.net (Nick Burrett)
Date: Wed, 21 Jan 2004 15:11:51 +0000
Subject: PAM auth stage rejection not working
Message-ID: <400E96B7.5050805@dsvr.net>



Hi,

I have an auth module for PAM that I wrote a few years ago called 
pam_vsd.so.  The idea is that a user must have a certain privilege 
before they can successfully authenticate.  Without the privilege the 
PAM module will return PAM_PERM_DENIED.

However I find that in OpenSSH 3.7.1p2, I can easily subvert this check 
simply by hitting return 3 times on connection i.e.


[nick at localhost pam.d]$ ssh nick at host.dsvr.net
Server host.dsvr.net
Password:  <hit return>
Password:  <hit return>
Password:  <hit return>
nick at host.dsvr.net's password: <enter real password>
[nick at host.dsvr.net nick]$


Syslog shows that indeed pam_vsd.so is correctly rejecting the 
connection, but then why does it fail the keyboard-interactive/pam login 
and then allow another type of login ?

I have been using this module for a few years now and it works fine on 
other services such as FTP, SMTP, POP3 and IMAP.

Any thoughts ?


Regards,


Nick

Extract from syslog:

PAM_pwdb[25749]: (sshd) session closed for user nick
PAM_pwdb[25761]: authentication failure; (uid=0) -> nick for sshd service
PAM-vsd[25761]: user nick does not have telnet privilege
sshd[25759]: error: PAM: Authentication failure
PAM_pwdb[25762]: authentication failure; (uid=0) -> nick for sshd service
PAM-vsd[25762]: user nick does not have telnet privilege
sshd[25759]: error: PAM: Authentication failure
PAM_pwdb[25763]: authentication failure; (uid=0) -> nick for sshd service
PAM-vsd[25763]: user nick does not have telnet privilege
sshd[25759]: error: PAM: Authentication failure
sshd[25759]: Failed keyboard-interactive/pam for nick from xxx.xx.xxx.xx 
port 47018 ssh2
sshd[25759]: Accepted password for nick from xxx.xx.xxx.xx port 47018 ssh2
PAM_pwdb[25765]: (sshd) session opened for user nick by (uid=0)


$ cat /etc/pam.d/sshd
#%PAM-1.0
auth       required     /lib/security/pam_pwdb.so shadow nodelay
auth       required     /lib/security/pam_vsd.so priv=telnet
auth       required     /lib/security/pam_nologin.so
account    required     /lib/security/pam_pwdb.so
password   required     /lib/security/pam_cracklib.so
password   required     /lib/security/pam_pwdb.so shadow nullok use_authtok
session    required     /lib/security/pam_pwdb.so
session    required     /lib/security/pam_limits.so


The contents of sshd_config are:

Port 22
Protocol 2,1
HostKey /usr/local/etc/ssh/ssh_host_key
HostKey /usr/local/etc/ssh/ssh_host_rsa_key
HostKey /usr/local/etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin no
IgnoreRhosts yes
RhostsRSAAuthentication
StrictModes yes
X11Forwarding no
X11DisplayOffset 10
PrintMotd yes
KeepAlive yes
PrintLastLog no
SyslogFacility AUTH
LogLevel INFO
RhostsRSAAuthentication no
HostbasedAuthentication no
RSAAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords no
UsePAM yes
#ChallengeResponseAuthentication no
KerberosAuthentication no
UseLogin no
Banner /usr/local/etc/issue.net
Subsystem       sftp    /usr/libexec/openssh/sftp-server
MaxStartups 10:30:60



-- 
Nick Burrett
Network Engineer, Designer Servers Ltd.   http://www.dsvr.co.uk



From flash at itp.tu-graz.ac.at  Thu Jan 22 02:30:06 2004
From: flash at itp.tu-graz.ac.at (Christian Pfaffel)
Date: Wed, 21 Jan 2004 15:30:06 -0000
Subject: PAM auth stage rejection not working
In-Reply-To: <400E96B7.5050805@dsvr.net>
References: <400E96B7.5050805@dsvr.net>
Message-ID: <7gr7xts4ia.fsf@faeppc20.tu-graz.ac.at>

Nick Burrett <nick at dsvr.net> writes:

> The contents of sshd_config are:
> 
> Port 22
> Protocol 2,1
> HostKey /usr/local/etc/ssh/ssh_host_key
> HostKey /usr/local/etc/ssh/ssh_host_rsa_key
> HostKey /usr/local/etc/ssh/ssh_host_dsa_key
> ServerKeyBits 768
> LoginGraceTime 600
> KeyRegenerationInterval 3600
> PermitRootLogin no
> IgnoreRhosts yes
> RhostsRSAAuthentication
> StrictModes yes
> X11Forwarding no
> X11DisplayOffset 10
> PrintMotd yes
> KeepAlive yes
> PrintLastLog no
> SyslogFacility AUTH
> LogLevel INFO
> RhostsRSAAuthentication no
> HostbasedAuthentication no
> RSAAuthentication yes
> PasswordAuthentication yes
> PermitEmptyPasswords no
> UsePAM yes
> #ChallengeResponseAuthentication no
> KerberosAuthentication no
> UseLogin no
> Banner /usr/local/etc/issue.net
> Subsystem       sftp    /usr/libexec/openssh/sftp-server
> MaxStartups 10:30:60
> 
> 

You might want to add 

PasswordAuthentication no

to your sshd_config have a look at sshd_config(5) and search for
UsePAM.

regards,

Christian Pfaffel

-- 
Christian Pfaffel <flash at itp.tu-graz.ac.at>
Technische Universit?t Graz                 Telefon: +43 / 316 / 873 - 81 90
Institut f?r Theoretische Physik            Telefax: +43 / 316 / 873 - 86 78
Petersgasse 16, A-8010 Graz   http://fubphpc.tu-graz.ac.at/~flash/pubkey.gpg



From nick at dsvr.net  Thu Jan 22 02:33:38 2004
From: nick at dsvr.net (Nick Burrett)
Date: Wed, 21 Jan 2004 15:33:38 +0000
Subject: PAM auth stage rejection not working
In-Reply-To: <7gr7xts4ia.fsf@faeppc20.tu-graz.ac.at>
References: <400E96B7.5050805@dsvr.net> <7gr7xts4ia.fsf@faeppc20.tu-graz.ac.at>
Message-ID: <400E9BD2.1000005@dsvr.net>



Christian Pfaffel wrote:

> You might want to add 
> 
> PasswordAuthentication no
> 
> to your sshd_config have a look at sshd_config(5) and search for
> UsePAM.

Thanks.  You are indeed correct.

Regards,


Nick.



-- 
Nick Burrett
Network Engineer, Designer Servers Ltd.   http://www.dsvr.co.uk



From hooshang.dadgari at eng.sun.com  Thu Jan 22 08:27:40 2004
From: hooshang.dadgari at eng.sun.com (hooshang)
Date: Wed, 21 Jan 2004 13:27:40 -0800
Subject: Connectathon 2004
Message-ID: <400EEECC.2030700@eng.sun.com>

Guys,

Get ready for Connectathon 2004!  The 18th annual interoperability
testing event for engineers only will be held Feb. 19-26, 2004 in
San Jose, California.  For the past 3 years, Connectathon booth space
has sold out!  Get your registration forms and fees in early and take
advantage of registration discounts available through December 19th.

Connectathon, sponsored by Sun Microsystems, Inc., hosts over 40
companies annually in an effort to test and debug source code which
utilize the following technologies and protocols:

NFS versions 2, 3 and 4
NFS over RDMA
NFSv4 replication and migration
Kerberos
IPv6
IPsec
Mobile IPv6
Secure Shell

Based on demand, in addition we are considering to offer:

LDAP
NDMP
CIFS
iSCSI

If you are interested in testing any of the above 4 protocols, please
send a note to Cthon at sun.com and we'll gauge interest.  Or if you have a

suggestion for another technology, feel free to contact us as well.

Testing continues 24 hours per day.  Technology testing coordinators
will organize testing procedures and test suite material.  In addition,
there will be seminars and speakers addressing various topics.

The registration deadline is February 6, 2004.  But don't wait that
long!  And Early Bird Discount on booth fees is available to those who
register and pay by December 19, 2003.  For the past 3 years,
Connectathon has sold out of booth space.  Please get your registration
materials in quickly to avoid disappointment.  Go to
http://www.connectathon.org to download all forms and information.

If you have any questions, please feel free to contact Audrey Van
Belleghem at audrey at vanb.com or (408) 358-9598.

We look forward to seeing you at the 18th annual Connectathon event!

Audrey Van Belleghem
Connectathon Manager




From djm at mindrot.org  Thu Jan 22 08:33:36 2004
From: djm at mindrot.org (Damien Miller)
Date: Wed, 21 Jan 2004 21:33:36 -0000
Subject: Release testing
Message-ID: <1074720798.17510.36.camel@sakura.mindrot.org>

Hi,

We are planning on releasing the next version of OpenSSH in a couple 
of weeks. As always, we would like to see it tested as widely as 
possible before this happens.

We would therefore like you to test the latest snapshots (20030122 
and later) on as many machines that you have access to. Ideally 
this testing should include running the regress tests and use of 
the snapshots in a non-critical environment.

Please report your results or any problems to the mailing list.

Thanks,
Damien Miller



From dtucker at zip.com.au  Thu Jan 22 12:46:01 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 22 Jan 2004 12:46:01 +1100
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
Message-ID: <400F2B59.3070308@zip.com.au>

(I hope this message is appropriate for these lists.  If not, please 
tell me and I won't do it again.)

Hi All.
	There will be a new release of OpenSSH in a couple of weeks.  This 
release contains Kerberos and GSSAPI related changes that we would like 
to get some feedback about (and hopefully address any issues with) 
before the release.

	I encourage anyone with an interest in Kerberos/GSSAPI support in 
OpenSSH to try a snapshot [1] and send feedback.

Changes in OpenBSD's OpenSSH and -Portable:
    - markus at cvs.openbsd.org 2003/11/17 11:06:07
      replace "gssapi" with "gssapi-with-mic"; from Simon Wilkinson;
      test + ok jakob.
    - jakob at cvs.openbsd.org 2003/12/23 16:12:10
      implement KerberosGetAFSToken server option. ok markus@, beck@
    - markus at cvs.openbsd.org 2003/11/02 11:01:03
      remove support for SSH_BUG_GSSAPI_BER; simon at sxw.org.uk

Changes in -Portable only
  - (dtucker) Only enable KerberosGetAFSToken if Heimdal's libkafs
    is found.  with jakob@	
  - (dtucker) [configure.ac] Use krb5-config where available for
    Kerberos/GSSAPI detection, libs and includes.  ok djm@

Additionally, as a side effect of the last change, the test for libkafs 
is now independant of the Heimdal test, so should a version that works 
with MIT Kerberos be available it will be used.

All but the last are in the 20040122 snapshot, and the last will be in 
20040123 and up.

Please follow-up to the OpenSSH devel list (cc: the Kerberos lists if 
you consider it appropriate).

[1] ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ or 
one of the mirrors listed at http://openssh.com/portable.html#mirrors

-- 
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 avis at speakeasy.net  Thu Jan 22 16:36:32 2004
From: avis at speakeasy.net (Avis)
Date: Thu, 22 Jan 2004 00:36:32 -0500
Subject: Send Break to terminal server
In-Reply-To: <3FFF4DFF.6080208@zip.com.au>
Message-ID: <20040122053534.C8B7827C187@shitei.mindrot.org>

After some research, I found that TeraTerm Pro was able to do send the break
using SSH version 1.
The protocol openssh implements is for SSH version 2.
As far as I know, there were no documented standards for sending breaks in
SSH version 1.

However, I'm still curious on how TeraTerm Pro did it, and wonder if openssh
should implements it for compatibility.
The terminal server in question is 'MRV'.

I am also quite sure MRV does not support the SSH version 2 standard for
sending breaks, as I turned on confirmation (last parameter in
channel_request_start), and I got 

"dispatch_protocol_error: type 100 seq 13"


-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: Friday, January 09, 2004 7:58 PM
To: Avis
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Send Break to terminal server

Avis wrote:

> Darren, thanks.
> I did try all combinations of '~b', '~B', '~<ctrl-B>', and even
'~<alt-B>'.
> With the debug, it's obvious that you were right, '~B' was the one that
> triggered the request break.
> However, nothing happen in the request break function.
> Is there something I need to set in the compilation?
> Is there a library that I am missing?

No, there's nothing else to be done at compile time, and according to 
the debugging the break request is being sent just fine.

> bash-2.03# debug2: channel 0: request break
> ~B
> debug2: channel 0: written 4 to efd 7

It's possible that your terminal server does not like the length of the 
break requested (OpenSSH hard-codes that to 1000 ms).  You can fiddle 
with that at compile time, it's in clientloop.c around line 585:

case 'B':
	if (compat20) {
		snprintf(string, sizeof string,
		    "%cB\r\n", escape_char);
		buffer_append(berr, string,
		    strlen(string));
 

channel_request_start(session_ident,
		    "break", 0);
		packet_put_int(1000);
		packet_send();
	}

You can try changing the number inside the packet_put_int (I suggest 
trying "0" first as that the server should use "500ms or the default 
BREAK signal length of the chipset or underlying chipset driver.")

-- 
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 avis at speakeasy.net  Thu Jan 22 17:39:40 2004
From: avis at speakeasy.net (Avis)
Date: Thu, 22 Jan 2004 01:39:40 -0500
Subject: Send Break to terminal server
In-Reply-To: <3FFF4DFF.6080208@zip.com.au>
Message-ID: <20040122063843.58DD227C187@shitei.mindrot.org>

I found the characters sent by TeraTerm Pro.
It was '0xFF', followed by '0xF3'.

	case 'B':
				if (compat20) {
					snprintf(string, sizeof string,
					    "%cB\r\n", escape_char);
					buffer_append(berr, string,
					    strlen(string));
					channel_request_start(session_ident,
					    "break", 0);
					packet_put_int(1000);
					packet_send();
				} else {
					buffer_put_char(bin, 0xFF);
					buffer_put_char(bin, 0xF3);
                        }
				continue;

Above is the modifications I made for it to work.
What it does is to use the break if using version 2.
And use the break characters if using version 1.

For MRV terminal servers, I'll simply force version 1 when I want to send
breaks.

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: Friday, January 09, 2004 7:58 PM
To: Avis
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Send Break to terminal server

Avis wrote:

> Darren, thanks.
> I did try all combinations of '~b', '~B', '~<ctrl-B>', and even
'~<alt-B>'.
> With the debug, it's obvious that you were right, '~B' was the one that
> triggered the request break.
> However, nothing happen in the request break function.
> Is there something I need to set in the compilation?
> Is there a library that I am missing?

No, there's nothing else to be done at compile time, and according to 
the debugging the break request is being sent just fine.

> bash-2.03# debug2: channel 0: request break
> ~B
> debug2: channel 0: written 4 to efd 7

It's possible that your terminal server does not like the length of the 
break requested (OpenSSH hard-codes that to 1000 ms).  You can fiddle 
with that at compile time, it's in clientloop.c around line 585:

case 'B':
	if (compat20) {
		snprintf(string, sizeof string,
		    "%cB\r\n", escape_char);
		buffer_append(berr, string,
		    strlen(string));
 

channel_request_start(session_ident,
		    "break", 0);
		packet_put_int(1000);
		packet_send();
	}

You can try changing the number inside the packet_put_int (I suggest 
trying "0" first as that the server should use "500ms or the default 
BREAK signal length of the chipset or underlying chipset driver.")

-- 
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  Thu Jan 22 17:55:45 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 22 Jan 2004 17:55:45 +1100
Subject: Send Break to terminal server
In-Reply-To: <200401220639.i0M6dihR026243@mailin2.pacific.net.au>
References: <200401220639.i0M6dihR026243@mailin2.pacific.net.au>
Message-ID: <400F73F1.4000704@zip.com.au>

Avis wrote:
> I found the characters sent by TeraTerm Pro.
> It was '0xFF', followed by '0xF3'.

That's a Telnet IAC-Break sequence.  I suspect the fact it works over 
SSH at all is a coincidence.

-- 
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 Roger.Warnberg at consultant.saab.se  Thu Jan 22 18:05:41 2004
From: Roger.Warnberg at consultant.saab.se (=?iso-8859-1?Q?Roger_W=E4rnberg?=)
Date: Thu, 22 Jan 2004 08:05:41 +0100
Subject: Bug repport
Message-ID: <0AF1F7B35154B043A980B9CF27A502853BD284@saeliexch.air.saab.se>



I have installed openssh-3.7.1p2(and its Run-time dependencies), from Software Porting And Archive Centre for HP-UX, on an HP rx2600 OS-version 11.23.

When I now try  to use ssh to this server it works but the DISPLAY environment variable is not set.
I get this line in syslog.log on the server

Jan 16 10:24:25 sabina sshd[8979]: Accepted publickey for s66103 from 136.163.6.9 port 53117 ssh2
Jan 16 10:24:25 sabina sshd[8981]: error: Failed to allocate internet-domain X11 display socket.

I attach /usr/local/etc/openssh/ssh_config and /usr/local/etc/openssh/sshd_config

Please I neeed help

mvh/roger
 
Roger W?rnberg
P/CSC-RW
CSC Sverige AB
Tel. +46 (0) 13 465 3561
Email: Roger.Warnberg at consultant.saab.se
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssh_config
Type: application/octet-stream
Size: 1150 bytes
Desc: ssh_config
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040122/a4db5604/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sshd_config
Type: application/octet-stream
Size: 2513 bytes
Desc: sshd_config
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040122/a4db5604/attachment-0001.obj 

From dtucker at zip.com.au  Thu Jan 22 18:53:03 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 22 Jan 2004 18:53:03 +1100
Subject: Bug repport
In-Reply-To: <0AF1F7B35154B043A980B9CF27A502853BD284@saeliexch.air.saab.se>
References: <0AF1F7B35154B043A980B9CF27A502853BD284@saeliexch.air.saab.se>
Message-ID: <400F815F.9060104@zip.com.au>

Roger W?rnberg wrote:
> 
> I have installed openssh-3.7.1p2(and its Run-time dependencies), from Software Porting And Archive Centre for HP-UX, on an HP rx2600 OS-version 11.23.
> 
> When I now try  to use ssh to this server it works but the DISPLAY environment variable is not set.
> I get this line in syslog.log on the server
> 
> Jan 16 10:24:25 sabina sshd[8979]: Accepted publickey for s66103 from 136.163.6.9 port 53117 ssh2
> Jan 16 10:24:25 sabina sshd[8981]: error: Failed to allocate internet-domain X11 display socket.

Try putting "X11UseLocalhost no" into sshd_config and restarting sshd.

-- 
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 haba at pdc.kth.se  Thu Jan 22 20:00:25 2004
From: haba at pdc.kth.se (Harald Barth)
Date: Thu, 22 Jan 2004 10:00:25 +0100 (MET)
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <400F2B59.3070308@zip.com.au>
References: <400F2B59.3070308@zip.com.au>
Message-ID: <20040122.100025.08316746.haba@pdc.kth.se>


> Changes in -Portable only
>   - (dtucker) Only enable KerberosGetAFSToken if Heimdal's libkafs
>     is found.  with jakob@	

I see a potential for circular depend confusion: I need OpenSSL
installed to get some libraries that Heimdal needs and I need Heimdal
installed to get some libraries that OpenSSL needs? Has anyone tested
this on a clean system?

Harald.



From djm at mindrot.org  Thu Jan 22 20:41:21 2004
From: djm at mindrot.org (Damien Miller)
Date: Thu, 22 Jan 2004 09:41:21 -0000
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <20040122.100025.08316746.haba@pdc.kth.se>
References: <400F2B59.3070308@zip.com.au>
	<20040122.100025.08316746.haba@pdc.kth.se>
Message-ID: <1074764461.17510.43.camel@sakura.mindrot.org>

On Thu, 2004-01-22 at 20:00, Harald Barth wrote:
> > Changes in -Portable only
> >   - (dtucker) Only enable KerberosGetAFSToken if Heimdal's libkafs
> >     is found.  with jakob@	
> 
> I see a potential for circular depend confusion: I need OpenSSL
> installed to get some libraries that Heimdal needs and I need Heimdal
> installed to get some libraries that OpenSSL needs? Has anyone tested
> this on a clean system?

What does OpenSSL need from Heimdal?





From sxw at inf.ed.ac.uk  Thu Jan 22 22:32:58 2004
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Thu, 22 Jan 2004 11:32:58 +0000 (GMT)
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <1074764461.17510.43.camel@sakura.mindrot.org>
Message-ID: <Pine.LNX.4.44.0401221129110.23155-100000@warspite.inf.ed.ac.uk>


[ follow-ups trimmed ]

On 22 Jan 2004, Damien Miller wrote:
> On Thu, 2004-01-22 at 20:00, Harald Barth wrote:
> > > Changes in -Portable only
> > >   - (dtucker) Only enable KerberosGetAFSToken if Heimdal's libkafs
> > >     is found.  with jakob@	
> > 
> > I see a potential for circular depend confusion: I need OpenSSL
> > installed to get some libraries that Heimdal needs and I need Heimdal
> > installed to get some libraries that OpenSSL needs? Has anyone tested
> > this on a clean system?
> 
> What does OpenSSL need from Heimdal?

Recent OpenSSLs contain support for kerberising the SSL handshake 
as specified in RFC2712. 

You can get around the build dependencies by:
1) Build OpenSSL w/o Kerberos support
2) Build Heimdal
3) Build OpenSSL with Kerberos support (if you really need it!)

It's also important to note that the Kerberos dependencies are only in 
libssl. If you're only using libcrypto (as I believe both Heimdal and 
OpenSSH do), you shouldn't be affected at all.

Cheers,

Simon.



From allbery at ece.cmu.edu  Fri Jan 23 01:40:09 2004
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Thu, 22 Jan 2004 09:40:09 -0500
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <20040122.100025.08316746.haba@pdc.kth.se>
References: <400F2B59.3070308@zip.com.au>
	<20040122.100025.08316746.haba@pdc.kth.se>
Message-ID: <1074782409.6795.0.camel@pyanfar.ece.cmu.edu>

On Thu, 2004-01-22 at 04:00, Harald Barth wrote:
> > Changes in -Portable only
> >   - (dtucker) Only enable KerberosGetAFSToken if Heimdal's libkafs
> >     is found.  with jakob@	
> 
> I see a potential for circular depend confusion: I need OpenSSL
> installed to get some libraries that Heimdal needs and I need Heimdal
> installed to get some libraries that OpenSSL needs? Has anyone tested
> this on a clean system?

It's OpenSSH, not OpenSSL, that is looking for Heimdal libraries as I
read this.

-- 
brandon s. allbery    [linux,solaris,freebsd,perl]     allbery at kf8nh.com
system administrator      [WAY too many hats]        allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon univ.         KF8NH



From joda at pdc.kth.se  Fri Jan 23 02:32:14 2004
From: joda at pdc.kth.se (Johan Danielsson)
Date: Thu, 22 Jan 2004 16:32:14 +0100
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <20040122.100025.08316746.haba@pdc.kth.se> (Harald Barth's
	message of "Thu, 22 Jan 2004 10:00:25 +0100 (MET)")
References: <400F2B59.3070308@zip.com.au>
	<20040122.100025.08316746.haba@pdc.kth.se>
Message-ID: <xof65f4ngn5.fsf@blubb.pdc.kth.se>

Harald Barth <haba at pdc.kth.se> writes:

> I see a potential for circular depend confusion: I need OpenSSL
> installed to get some libraries that Heimdal needs and I need
> Heimdal installed to get some libraries that OpenSSL needs? Has
> anyone tested this on a clean system?

I think that OpenSSL != OpenSSH.

/Johan



From deengert at anl.gov  Fri Jan 23 02:41:27 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 22 Jan 2004 09:41:27 -0600
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
References: <400F2B59.3070308@zip.com.au>
Message-ID: <400FEF26.F8164703@anl.gov>

Paliminary results of testing with MIT krb5-1.3.2-beta2, OpenSSL-0.9.7c
on sun4x_57 with gcc. 

Problem 1:

We are using using Simon's current mods with the "gssapi" method. 
The new code implements the "gssapi-with-mic". I don't see a transition
stratagy to get from using "gssapi" to get to using "gssapi-with-mic",
other then to update all clients and servers at the same time. 
(The SecurtCRT for Windows, does appear to work with either.)

I know we want to get to using only gssapi-with-mic, but need
some time to convert. I would like to see the server offer both
and the client work with both "gssapi-with-mic" and "gssapi" either
 by #ifdef, or a sshd_config flag, or testing the peer's version string.  

I am willing to write this mod if needed. 


Problem 2:

Since kafs.h is not defined in MIT Kerberos, I change the #ifdef
to match the #ifdef used with the code that needed kafs.h.

--- ,session.c  Tue Jan 20 18:00:46 2004
+++ session.c   Thu Jan 22 08:40:34 2004
@@ -58,7 +58,7 @@
 #include "session.h"
 #include "monitor_wrap.h"
 
-#ifdef KRB5
+#if defined(HEIMDAL) && defined(AFS)
 #include <kafs.h>
 #endif

We have AFS, and call another routine to get the PAG and token.
It does not rely on the AFS libraries, but issues a syscall for
the PAG and fork/exec aklog to get the token. I will be looking 
at how to get this local mod out as well, and use kafs.h and the 
calls you provide.


-- 

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



From avis at speakeasy.net  Fri Jan 23 03:03:19 2004
From: avis at speakeasy.net (Avis)
Date: Thu, 22 Jan 2004 11:03:19 -0500
Subject: Send Break to terminal server
In-Reply-To: <400F73F1.4000704@zip.com.au>
Message-ID: <20040122160220.D91CE27C188@shitei.mindrot.org>

Probably a "feature" for the MRV terminal server.
I wonder if any other terminal servers use this sequence.

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: Thursday, January 22, 2004 1:56 AM
To: Avis
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Send Break to terminal server

Avis wrote:
> I found the characters sent by TeraTerm Pro.
> It was '0xFF', followed by '0xF3'.

That's a Telnet IAC-Break sequence.  I suspect the fact it works over 
SSH at all is a coincidence.

-- 
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 sxw at inf.ed.ac.uk  Fri Jan 23 03:03:15 2004
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Thu, 22 Jan 2004 16:03:15 +0000 (GMT)
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <400FEF26.F8164703@anl.gov>
Message-ID: <Pine.LNX.4.44.0401221559410.8356-100000@warspite.inf.ed.ac.uk>

On Thu, 22 Jan 2004, Douglas E. Engert wrote:

> We are using using Simon's current mods with the "gssapi" method. 
> The new code implements the "gssapi-with-mic". I don't see a transition
> stratagy to get from using "gssapi" to get to using "gssapi-with-mic",
> other then to update all clients and servers at the same time. 
> (The SecurtCRT for Windows, does appear to work with either.)

There is no transition strategy in the OpenSSH code, nor do I think there 
should be one. 

I will probably provide _for this release only_ patches which allow sites 
to enable 'gssapi' authentication for backwards compatibility. Those sites 
will generally have been using my patches anyway, so I don't see any 
problem with this existing outside the main code base.

Cheers,

Simon.




From deengert at anl.gov  Fri Jan 23 03:26:03 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 22 Jan 2004 10:26:03 -0600
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
References: <Pine.LNX.4.44.0401221559410.8356-100000@warspite.inf.ed.ac.uk>
Message-ID: <400FF99B.8D1CD36F@anl.gov>



sxw at inf.ed.ac.uk wrote:
> 
> On Thu, 22 Jan 2004, Douglas E. Engert wrote:
> 
> > We are using using Simon's current mods with the "gssapi" method.
> > The new code implements the "gssapi-with-mic". I don't see a transition
> > stratagy to get from using "gssapi" to get to using "gssapi-with-mic",
> > other then to update all clients and servers at the same time.
> > (The SecurtCRT for Windows, does appear to work with either.)
> 
> There is no transition strategy in the OpenSSH code, nor do I think there
> should be one.
> 
> I will probably provide _for this release only_ patches which allow sites
> to enable 'gssapi' authentication for backwards compatibility. Those sites
> will generally have been using my patches anyway, so I don't see any
> problem with this existing outside the main code base.

That sounds good to me. let me know if you have something to test. 

If it sounds like there are not many other sites with the same problem,
I will look to see if we could live with a strategy of running two sshd or 
providing two clients as we cut over to the new version.   
    
Thanks.

> 
> Cheers,
> 
> Simon.

-- 

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



From smichaud at pobox.com  Fri Jan 23 04:35:54 2004
From: smichaud at pobox.com (Steven Michaud)
Date: Thu, 22 Jan 2004 11:35:54 -0600
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
Message-ID: <401009FA.8070701@pobox.com>

 > There is no transition strategy in the OpenSSH code, nor do I think
 > there should be one.

Why not?

On Thu Jan 22 16:03:15 MST 2004, Simon Wilkinson wrote:

> On Thu, 22 Jan 2004, Douglas E. Engert wrote:
> 
>> We are using using Simon's current mods with the "gssapi" method. 
>> The new code implements the "gssapi-with-mic". I don't see a transition
>> stratagy to get from using "gssapi" to get to using "gssapi-with-mic",
>> other then to update all clients and servers at the same time. 
>> (The SecurtCRT for Windows, does appear to work with either.)
> 
> There is no transition strategy in the OpenSSH code, nor do I think there 
> should be one. 
> 
> I will probably provide _for this release only_ patches which allow sites 
> to enable 'gssapi' authentication for backwards compatibility. Those sites 
> will generally have been using my patches anyway, so I don't see any 
> problem with this existing outside the main code base.
> 
> Cheers,
> 
> Simon.




From sxw at inf.ed.ac.uk  Fri Jan 23 04:42:19 2004
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Thu, 22 Jan 2004 17:42:19 +0000 (GMT)
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <401009FA.8070701@pobox.com>
Message-ID: <Pine.LNX.4.44.0401221740160.8356-100000@warspite.inf.ed.ac.uk>

On Thu, 22 Jan 2004, Steven Michaud wrote:

>  > There is no transition strategy in the OpenSSH code, nor do I think
>  > there should be one.
> 
> Why not?

Because 'gssapi' support has only been in one release of OpenSSH, with its 
use specifically discouraged in the release notes. 

Those sites making extensive use of 'gssapi' are already likely to be 
running patched servers. I don't think its excessive to expect them to 
also patch the next OpenSSH release for backwards compatibility, and it 
avoids confusing 'new' users with two different GSSAPI options, one of 
which is less secure.

Cheers,

Simon.



From Greg.Dunkel at mail.cuny.edu  Fri Jan 23 05:27:53 2004
From: Greg.Dunkel at mail.cuny.edu (Greg.Dunkel at mail.cuny.edu)
Date: Thu, 22 Jan 2004 13:27:53 -0500
Subject: starting sshd on AIX
Message-ID: <OF65A28B0A.9AFF2BFB-ON85256E23.0064781A-85256E23.00664681@cuny.edu>


I only have 8 AIX machines;  what I do is setup a script called rc.sshd in
/etc, which contains

      /usr/local/sbin/sshd -f /usr/local/etc/sshd_config

and then put the line

      sshd:2:once:/etc/rc.sshd

in inittab.  This doesn't give your the resources of the source manager but
I generally don't muck around with sshd, stopping and starting it.

/greg dunkel






From vinschen at redhat.com  Fri Jan 23 06:43:42 2004
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 22 Jan 2004 20:43:42 +0100
Subject: Release testing
In-Reply-To: <1074720798.17510.36.camel@sakura.mindrot.org>
References: <1074720798.17510.36.camel@sakura.mindrot.org>
Message-ID: <20040122194342.GH1572@cygbert.vinschen.de>

On Jan 22 08:33, Damien Miller wrote:
> Hi,
> 
> We are planning on releasing the next version of OpenSSH in a couple 
> of weeks. As always, we would like to see it tested as widely as 
> possible before this happens.
> 
> We would therefore like you to test the latest snapshots (20030122 
> and later) on as many machines that you have access to. Ideally 
> this testing should include running the regress tests and use of 
> the snapshots in a non-critical environment.
> 
> Please report your results or any problems to the mailing list.

My Cygwin results:

OpenSSH has been configured with the following options:
                     User binaries: /usr/bin
                   System binaries: /usr/sbin
               Configuration files: /etc
                   Askpass program: ${prefix}/sbin/ssh-askpass
                      Manual pages: /usr/share/man/manX
                          PID file: /var/run
  Privilege separation chroot path: /var/empty
            sshd default user PATH: /bin:/usr/sbin:/sbin:/usr/bin
                    Manpage format: doc
                       DNS support:
                       PAM support: no
                 KerberosV support: no
                 Smartcard support: no
                     S/KEY support: no
              TCP Wrappers support: yes
              MD5 password support: no
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: no
                  BSD Auth support: no
              Random number source: OpenSSL internal ONLY

              Host: i686-pc-cygwin
          Compiler: gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized
Preprocessor flags:
      Linker flags:
         Libraries: -lwrap  -lresolv -lz  /usr/lib/textmode.o -lcrypto -lcrypt


All tests in the testsuite pass, except the one trying to copy a file
with illegal characters on Windows file systems.


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.



From deengert at anl.gov  Fri Jan 23 07:02:32 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 22 Jan 2004 14:02:32 -0600
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
References: <Pine.LNX.4.44.0401221740160.8356-100000@warspite.inf.ed.ac.uk>
Message-ID: <40102C58.C3C37B4F@anl.gov>



sxw at inf.ed.ac.uk wrote:
> 
> On Thu, 22 Jan 2004, Steven Michaud wrote:
> 
> >  > There is no transition strategy in the OpenSSH code, nor do I think
> >  > there should be one.
> >
> > Why not?
> 
> Because 'gssapi' support has only been in one release of OpenSSH, with its
> use specifically discouraged in the release notes.
> 
> Those sites making extensive use of 'gssapi' are already likely to be
> running patched servers. I don't think its excessive to expect them to
> also patch the next OpenSSH release for backwards compatibility, and it
> avoids confusing 'new' users with two different GSSAPI options, one of
> which is less secure.

Simon, I accept your argument. 

I also now have some local mods working that can recognize our older 
OpenSSH clients and servers which have the gssapi patches, and operate
without the MIC. This will let us do an orderly upgrade.  

> 
> Cheers,
> 
> Simon.
> 
> _______________________________________________
> 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 haba at pdc.kth.se  Fri Jan 23 07:07:44 2004
From: haba at pdc.kth.se (Harald Barth)
Date: Thu, 22 Jan 2004 21:07:44 +0100 (MET)
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <xof65f4ngn5.fsf@blubb.pdc.kth.se>
References: <400F2B59.3070308@zip.com.au>
	<20040122.100025.08316746.haba@pdc.kth.se>
	<xof65f4ngn5.fsf@blubb.pdc.kth.se>
Message-ID: <20040122.210744.34607913.haba@pdc.kth.se>


> I think that OpenSSL != OpenSSH.

Correct. I got the install order wrong. The right order is OpenSSL,
Heimdal, OpenSSH.

Harald.



From andy.tompkins at autozone.com  Fri Jan 23 07:32:09 2004
From: andy.tompkins at autozone.com (andy.tompkins at autozone.com)
Date: Thu, 22 Jan 2004 14:32:09 -0600
Subject: AIX and openssh 3.7.1p2 with privsep
Message-ID: <OFFE43950E.2D2C391F-ON86256E23.006EF402-86256E23.0070CEE7@AUTOZONE.COM>

I am attempting to run openssh 3.7.1p2 with privsep on AIX 5.2 ML2 (with
the december 2003 critical patches also).
This was compiled on the host machine with the IBM Visual Age C compiler (C
for AIX Compiler, Version 5).
I did not have any trouble compiling.
My configure was ./configure --with-tcp-wrappers, and I have the freeware
tcp wrappers (freeware.tcp_wrappers.rte 7.6.1.5),
and a compiled openssl of 0.9.7c (compiled on same machine with same
compiler).

After inputting password, connection is dropped, and logged error is
"sshd[24872]: fatal: Failed to set process credentials"

I modified the session.c file to continue past this and print the error
instead (as recommended by someone else on this list)
Sorry for the large amount of debug info, but I wanted to be as complete as
possible the first time...
Output now is:
debug2: read_server_config: filename /usr/local/etc/sshd_config
debug1: sshd version OpenSSH_3.7.1p2
debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: private host key: #2 type 0 RSA1
debug1: Bind to port 22 on 169.198.30.167.
Server listening on 169.198.30.167 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
Connection from 169.198.11.77 port 42915
debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat
OpenSSH_3.2*,OpenSSH_3.3*,OpenSSH_3.4*,OpenSSH_3.5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_3.7.1p2
debug2: Network child is on pid 15790
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug3: privsep user:group 107:1769
debug1: permanently_set_uid: 107/1769
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2:kex_parse_kexinit:aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2:kex_parse_kexinit:aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug3: mm_request_send entering: type 0
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI
debug3: mm_request_receive_expect entering: type 1
debug3: mm_request_receive entering
debug3: mm_answer_moduli: got parameters: 1024 2048 8192
WARNING: /usr/local/etc/moduli does not exist, using old modulus
debug3: mm_request_send entering: type 1
debug3: mm_choose_dh: remaining 0
debug3: mm_request_receive entering
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: dh_gen_key: priv key bits set: 138/256
debug2: bits set: 493/1024
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 505/1024
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 4
debug3: monitor_read: checking request 4
debug3: mm_answer_sign
debug3: mm_request_receive entering
debug3: mm_answer_sign: signature 200426f8(143)
debug3: mm_request_send entering: type 5
debug2: monitor_read: 4 used once, disabling now
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug3: mm_request_receive entering
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user atompkin service ssh-connection method
none
debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 6
debug3: monitor_read: checking request 6
debug3: mm_answer_pwnamallow
debug3: mm_request_receive entering
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_inform_authserv entering
debug3: mm_request_send entering: type 3
debug3: monitor_read: checking request 3
debug3: mm_auth_password entering
debug3: mm_request_send entering: type 10
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: AIX/authenticate failed for user atompkin: 3004-300 You entered an
invalid login name or password.
debug3: mm_answer_authpassword: sending result 0
debug3: mm_request_send entering: type 11
debug3: mm_auth_password: user not authenticated
Failed none for atompkin from 169.198.11.77 port 42915 ssh2
debug3: mm_request_receive entering
debug1: userauth-request for user atompkin service ssh-connection method
keyboard-interactive
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=atompkin devs=
debug1: kbdint_alloc: devices ''
debug2: auth2_challenge_start: devices
Failed keyboard-interactive for atompkin from 169.198.11.77 port 42915 ssh2
debug1: userauth-request for user atompkin service ssh-connection method
password
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method password
debug3: mm_auth_password entering
debug3: mm_request_send entering: type 10
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: Trying to reverse map address 169.198.11.77.
debug3: AIX/authenticate succeeded for user atompkin:
debug3: aix_setauthdb: AIX/setauthdb set registry NIS
debug3: mm_answer_authpassword: sending result 1
debug3: mm_request_send entering: type 11
Accepted password for atompkin from 169.198.11.77 port 42915 ssh2
Accepted password for atompkin from 169.198.11.77 port 42915 ssh2
debug3: mm_get_keystate: Waiting for new keys
debug3: mm_request_receive_expect entering: type 24
debug3: mm_request_receive entering
debug3: mm_send_keystate: Sending new keys: 20041b98 20041b08
debug3: mm_newkeys_to_blob: converting 20041b98
debug3: mm_newkeys_to_blob: converting 20041b08
debug3: mm_send_keystate: New keys have been sent
debug3: mm_send_keystate: Sending compression state
debug3: mm_request_send entering: type 24
debug3: mm_send_keystate: Finished sending state
debug3: mm_newkeys_from_blob: 20044618(118)
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Waiting for second key
debug3: mm_newkeys_from_blob: 20044618(118)
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Getting compression state
debug3: mm_get_keystate: Getting Network I/O buffers
debug3: mm_share_sync: Share sync
debug3: mm_share_sync: Share sync end
debug2: User child is on pid 15792
debug3: mm_request_receive entering
Failed to set process credentials: A file or directory in the path name
does not exist.
debug3: AIX/UsrInfo: set len 31
debug1: permanently_set_uid: 6000/146
debug2: set_newkeys: mode 0
debug2: set_newkeys: mode 1
debug1: Entering interactive session for SSH2.
debug2: fd 8 setting O_NONBLOCK
debug2: fd 9 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max
16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug3: mm_request_send entering: type 25
debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY
debug3: mm_request_receive_expect entering: type 26
debug3: mm_request_receive entering
debug3: monitor_read: checking request 25
debug3: mm_answer_pty entering
debug1: session_new: init
debug1: session_new: session 0
debug3: mm_request_send entering: type 26
debug1: session_pty_req: session 0 alloc /dev/pts/4
debug3: tty_parse_modes: SSH2 n_bytes 266
debug3: tty_parse_modes: ospeed 38400
debug3: tty_parse_modes: ispeed 38400
debug3: tty_parse_modes: 1 3
debug3: tty_parse_modes: 2 28
debug3: tty_parse_modes: 3 127
debug3: tty_parse_modes: 4 21
debug3: tty_parse_modes: 5 4
debug3: tty_parse_modes: 6 0
debug3: tty_parse_modes: 7 0
debug3: tty_parse_modes: 8 17
debug3: tty_parse_modes: 9 19
debug3: tty_parse_modes: 10 26
debug3: tty_parse_modes: 11 25
debug3: tty_parse_modes: 12 18
debug1: Ignoring unsupported tty mode opcode 13 (0xd)
debug3: tty_parse_modes: 14 22
debug1: Ignoring unsupported tty mode opcode 16 (0x10)
debug1: Ignoring unsupported tty mode opcode 18 (0x12)
debug3: tty_parse_modes: 30 0
debug3: tty_parse_modes: 31 0
debug3: tty_parse_modes: 32 0
debug3: tty_parse_modes: 33 0
debug3: tty_parse_modes: 34 0
debug3: tty_parse_modes: 35 0
debug3: tty_parse_modes: 36 1
debug3: tty_parse_modes: 37 0
debug3: tty_parse_modes: 38 1
debug3: tty_parse_modes: 39 0
debug3: tty_parse_modes: 40 0
debug3: tty_parse_modes: 41 0
debug3: tty_parse_modes: 50 1
debug3: tty_parse_modes: 51 1
debug3: tty_parse_modes: 52 0
debug3: tty_parse_modes: 53 1
debug3: tty_parse_modes: 54 1
debug3: tty_parse_modes: 55 1
debug3: tty_parse_modes: 56 0
debug3: tty_parse_modes: 57 0
debug3: tty_parse_modes: 58 0
debug3: tty_parse_modes: 59 1
debug3: tty_parse_modes: 60 1
debug3: tty_parse_modes: 61 1
debug3: tty_parse_modes: 62 0
debug3: tty_parse_modes: 70 1
debug3: tty_parse_modes: 71 0
debug3: tty_parse_modes: 72 1
debug3: tty_parse_modes: 73 0
debug3: tty_parse_modes: 74 0
debug3: tty_parse_modes: 75 0
debug3: tty_parse_modes: 90 1
debug3: tty_parse_modes: 91 1
debug3: tty_parse_modes: 92 1
debug3: tty_parse_modes: 93 1
debug1: server_input_channel_req: channel 0 request x11-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug2: fd 12 setting O_NONBLOCK
debug2: fd 12 is O_NONBLOCK
debug1: channel 1: new [X11 inet listener]
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug2: fd 4 setting TCP_NODELAY
debug2: channel 0: rfd 11 isatty
debug2: fd 11 setting O_NONBLOCK
debug2: fd 10 is O_NONBLOCK
setsid: Operation not permitted.
debug2: channel 0: read<=0 rfd 11 len -1
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 5732
debug1: session_exit_message: session 0 channel 0 pid 5732
debug2: channel 0: request exit-status
debug1: session_exit_message: release channel 0
debug2: channel 0: write failed
debug2: channel 0: close_write
debug2: channel 0: output open -> closed
debug1: session_close: session 0 pid 5732
debug3: mm_request_send entering: type 27
debug3: monitor_read: checking request 27
debug3: mm_answer_pty_cleanup entering
debug2: channel 0: send close
debug3: mm_session_close: session 0 pid 15792
debug3: mm_session_close: tty /dev/pts/4 ptyfd 7
debug3: channel 0: will not send data after close
debug1: session_pty_cleanup: session 0 release /dev/pts/4
debug2: notify_done: reading
debug3: channel 0: will not send data after close
debug3: mm_request_receive entering
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: server-session, nchannels 2
debug3: channel 0: status: The following connections are open:
  #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1)
debug3: channel 0: close_fds r -1 w -1 e -1
Connection closed by 169.198.11.77
debug1: channel 1: free: X11 inet listener, nchannels 1
debug3: channel 1: status: The following connections are open:
debug3: channel 1: close_fds r 12 w 12 e -1
Closing connection to 169.198.11.77
debug3: mm_request_send entering: type 54
debug3: monitor_read: checking request 54
debug3: mm_answer_term: tearing down sessions


I noticed that the actual error is "A file or directory in the path name
does not exist."
Too bad its not telling me WHAT file or dir.
Any ideas??

Thanks
Andy
------------------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.




From vici at dof.se  Fri Jan 23 07:21:06 2004
From: vici at dof.se (Istvan Viczian)
Date: Thu, 22 Jan 2004 21:21:06 +0100
Subject: sshd start fails with:"fatal: Cannot bind any address." but the
 process return value 0 !
Message-ID: <401030B2.9030608@dof.se>

Hi,
  	
I use openssh version:
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.6l 04 Nov 2003
(complied by myself) on redhat7.2 ( kernel 2.4.20-19.7smp )

It seems that sshd returns vith wrong returns value, if some other
process (e.g. another sshd) already reserved the given IP address and
port.

I setup two ssh daemon almost with the same settings in order to listen 
on two different IP address, but at the first one I forgot to specify 
the IP address on which it have to listen to
(ListenAddress XXXXX). That is why it started on both of the available 
IP addreses (10.0.0.1, 10.0.0.2) :

[root at mach]#sshd -f /etc/ssh/sshd_config; echo $?
[root at mach]#0

And the log looks like:

   Jan 22 21:13:15 mach sshd[1644]: debug1: Bind to port 22 on 0.0.0.0.
   Jan 22 21:13:15 mach sshd[1644]: Server listening on 0.0.0.0 port 22.

Then I started the second too:

[root at mach]#sshd -f /etc/ssh2/sshd_config; echo $?
[root at mach]#0

And the log:

   Jan 22 21:15:06 mach sshd[1817]: debug1: Bind to port 22 on 10.0.0.2.
   Jan 22 21:15:06 mach sshd[1817]: error: Bind to port 22 on 10.0.0.2 
  failed: Address already in use.
   Jan 22 21:15:06 mach sshd[1817]: fatal: Cannot bind any address.

Obviously only the first instance was runing.


Regards,
Istvan Viczian




From mouring at etoh.eviladmin.org  Fri Jan 23 08:27:03 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Thu, 22 Jan 2004 15:27:03 -0600 (CST)
Subject: Release testing
In-Reply-To: <20040122194342.GH1572@cygbert.vinschen.de>
Message-ID: <Pine.BSO.4.44.0401221525560.27267-100000@etoh.eviladmin.org>



[..]
> OpenSSH has been configured with the following options:
>                      User binaries: /usr/bin
>                    System binaries: /usr/sbin
>                Configuration files: /etc
>                    Askpass program: ${prefix}/sbin/ssh-askpass
					^^^^^^

Should we be resolving that instead of printing it?

- Ben



From dtucker at zip.com.au  Fri Jan 23 11:07:41 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 23 Jan 2004 11:07:41 +1100
Subject: AIX and openssh 3.7.1p2 with privsep
In-Reply-To: <OFFE43950E.2D2C391F-ON86256E23.006EF402-86256E23.0070CEE7@AUTOZONE.COM>
References: <OFFE43950E.2D2C391F-ON86256E23.006EF402-86256E23.0070CEE7@AUTOZONE.COM>
Message-ID: <401065CD.2010808@zip.com.au>

andy.tompkins at autozone.com wrote:
> I am attempting to run openssh 3.7.1p2 with privsep on AIX 5.2 ML2 (with
> the december 2003 critical patches also).
[snip]

> After inputting password, connection is dropped, and logged error is
> "sshd[24872]: fatal: Failed to set process credentials"

That's setpcred failing, but I don't know why.  (I've had one other 
report recently, but it works fine here on 5.2 w/ML1).  As a short-term 
fix you could comment out "HAVE_SETPCRED" from config.h and recompile, 
but we really need to figure out what the root cause is.

I might grab ML2 and see if I can replicate it.

[snip]
> Failed to set process credentials: A file or directory in the path name
> does not exist.
[snip]
> I noticed that the actual error is "A file or directory in the path name
> does not exist."
> Too bad its not telling me WHAT file or dir.

It's just printing out the contents or errno.
AIX 5.2 has truss (or was that strace?), try running sshd -D under truss 
and see if it shows what access failed.  You'll need "-f" on truss to 
follow forks.

-- 
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  Fri Jan 23 12:13:27 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 23 Jan 2004 12:13:27 +1100
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <400FEF26.F8164703@anl.gov>
References: <400F2B59.3070308@zip.com.au> <400FEF26.F8164703@anl.gov>
Message-ID: <40107537.4040201@zip.com.au>

Douglas E. Engert wrote:
> Since kafs.h is not defined in MIT Kerberos, I change the #ifdef
> to match the #ifdef used with the code that needed kafs.h.
> 
> --- ,session.c  Tue Jan 20 18:00:46 2004
> +++ session.c   Thu Jan 22 08:40:34 2004
> @@ -58,7 +58,7 @@
>  #include "session.h"
>  #include "monitor_wrap.h"
>  
> -#ifdef KRB5
> +#if defined(HEIMDAL) && defined(AFS)
>  #include <kafs.h>
>  #endif

Thanks for the testing, and that's a good point.  Currently the other 
code in session.c has "#if defined(KRB5) && defined(AFS)" (it was 
changed yesterday, and was intended for if someone carried out the 
threat of porting libkafs to MIT krb5).

Does anything else define "AFS" in your includes?  Should we change the 
"AFS" symbol in OpenSSH to "HAVE_AFS" or "USE_AFS" or something?

-- 
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 hotz at jpl.nasa.gov  Fri Jan 23 13:24:32 2004
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Thu, 22 Jan 2004 18:24:32 -0800
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <20040122.210744.34607913.haba@pdc.kth.se>
References: <400F2B59.3070308@zip.com.au>
	<20040122.100025.08316746.haba@pdc.kth.se>
	<xof65f4ngn5.fsf@blubb.pdc.kth.se>
	<20040122.210744.34607913.haba@pdc.kth.se>
Message-ID: <p05210602bc36360a3680@[137.78.212.225]>

At 9:07 PM +0100 1/22/04, Harald Barth wrote:
>  > I think that OpenSSL != OpenSSH.
>
>Correct. I got the install order wrong. The right order is OpenSSL,
>Heimdal, OpenSSH.
>
>Harald.

OK, so how do you install OpenSSL with RFC 2712 support enabled?
-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu



From jason at devrandom.org  Fri Jan 23 16:23:01 2004
From: jason at devrandom.org (Jason McCormick)
Date: Fri, 23 Jan 2004 00:23:01 -0500
Subject: Release testing
In-Reply-To: <1074720798.17510.36.camel@sakura.mindrot.org>
References: <1074720798.17510.36.camel@sakura.mindrot.org>
Message-ID: <200401230023.02047.jason@devrandom.org>

> We are planning on releasing the next version of OpenSSH in a couple
> of weeks. 

  Testing the RPM building aspects of the snapshots I'm running into the 
build process not finding kafs.h on both RedHat 9 and Fedora Core 1.  
This header file does not seem to be provided by either krb5-devel or 
krbafs-devel.  The default behavior on these platforms has been to 
compile --with-kerberos5 so if this is provided by something not in the 
default distribution we'll have to provide some workaround, change the 
package dependencies in openssh.spec or change the default spec 
building behavior.  I'm not a regular user of Kerberos to know all the 
ramifications of this however.

-- 
Jason McCormick 
jason at devrandom.org
GPG Key ID: 96D6CF63



From dtucker at zip.com.au  Fri Jan 23 16:34:30 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 23 Jan 2004 16:34:30 +1100
Subject: Release testing
In-Reply-To: <200401230023.02047.jason@devrandom.org>
References: <1074720798.17510.36.camel@sakura.mindrot.org>
	<200401230023.02047.jason@devrandom.org>
Message-ID: <4010B266.7010303@zip.com.au>

Jason McCormick wrote:
>   Testing the RPM building aspects of the snapshots I'm running into the 
> build process not finding kafs.h on both RedHat 9 and Fedora Core 1.  
> This header file does not seem to be provided by either krb5-devel or 
> krbafs-devel.  The default behavior on these platforms has been to 
> compile --with-kerberos5 so if this is provided by something not in the 
> default distribution we'll have to provide some workaround, change the 
> package dependencies in openssh.spec or change the default spec 
> building behavior.  I'm not a regular user of Kerberos to know all the 
> ramifications of this however.

kafs.h (and libkafs) is provided by Heimdal, but not MIT Kerberos (which 
is what Redhat use).  What you have found is a minor bug in session.c.

The #include <kafs.h> should have been inside an #ifdef AFS.  (Or 
possibly USE_AFS, it's still under discussion).  Should be fixed in the 
next day or two.

-- 
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 vinschen at redhat.com  Fri Jan 23 21:27:36 2004
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 23 Jan 2004 11:27:36 +0100
Subject: [PATCH] contrib/cygwin/README
Message-ID: <20040123102735.GB12501@cygbert.vinschen.de>

Hi,

the latest update to contrib/cygwin/README was missing the documentaion
of the new ssh-host-config options.  The below patch fixes that.

Please apply.  Thanks,
Corinna

Index: contrib/cygwin/README
===================================================================
RCS file: /cvs/openssh_cvs/contrib/cygwin/README,v
retrieving revision 1.13
diff -p -u -r1.13 README
--- contrib/cygwin/README	21 Nov 2003 12:48:57 -0000	1.13
+++ contrib/cygwin/README	23 Jan 2004 10:24:29 -0000
@@ -118,10 +118,12 @@ some options:
 
 usage: ssh-host-config [OPTION]...
 Options:
-    --debug      -d        Enable shell's debug output.
-    --yes        -y        Answer all questions with "yes" automatically.
-    --no         -n        Answer all questions with "no" automatically.
-    --port       -p <n>    sshd listens on port n.
+    --debug  -d            Enable shell's debug output.
+    --yes    -y            Answer all questions with "yes" automatically.
+    --no     -n            Answer all questions with "no" automatically.
+    --cygwin -c <options>  Use "options" as value for CYGWIN environment var.
+    --port   -p <n>        sshd listens on port n.
+    --pwd    -w <passwd>   Use "pwd" as password for user 'sshd_server'.
 
 Additionally ssh-host-config now asks if it should install sshd as a
 service when running under NT/W2K. This requires cygrunsrv installed.

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.



From jschneid at netilla.com  Sat Jan 24 05:49:43 2004
From: jschneid at netilla.com (Jim Schneider)
Date: Fri, 23 Jan 2004 13:49:43 -0500
Subject: [openssh] Patch for missing ciphers in OpenSSL's libcrypto
Message-ID: <200401231349.43354.jschneid@netilla.com>

For various reasons, I have compiled libcrypto without support for Blowfish or 
CAST, which was causing a build of OpenSSH 3.7.1p2 to fail.  The attached 
patch file fixes this and other possible errors by checking to make sure the 
required ciphers are available before attempting to reference their 
environment structures.

This should work building against both OpenSSL 0.9.6 and OpenSSL 0.9.7 
(although I have only tested it against OpenSSL 0.9.7).  I also have not 
tested this patch while running the protocol in version 1 mode.

In addition to letting you build on a system without some ciphers in 
libcrypto, you can also explicitly exclude support for ciphers that are 
available in libcrypto by including -DNO_BF or similar defines in CFLAGS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conditional-ciphers.patch.gz
Type: application/x-gzip
Size: 996 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040123/eba302a1/attachment.bin 

From wendyp at cray.com  Sat Jan 24 12:15:07 2004
From: wendyp at cray.com (Wendy Palm)
Date: Fri, 23 Jan 2004 19:15:07 -0600
Subject: Release testing
In-Reply-To: <1074720798.17510.36.camel@sakura.mindrot.org>
References: <1074720798.17510.36.camel@sakura.mindrot.org>
Message-ID: <4011C71B.2080009@cray.com>

still needs Bug #775 changes for cray machines.
otherwise, snapshot 20040123 works great.

wendy


Damien Miller wrote:
> Hi,
> 
> We are planning on releasing the next version of OpenSSH in a couple 
> of weeks. As always, we would like to see it tested as widely as 
> possible before this happens.
> 
> We would therefore like you to test the latest snapshots (20030122 
> and later) on as many machines that you have access to. Ideally 
> this testing should include running the regress tests and use of 
> the snapshots in a non-critical environment.
> 
> Please report your results or any problems to the mailing list.
> 
> Thanks,
> Damien Miller
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
wendy palm
Cray Open Software Development, Cray Inc.
wendyp at cray.com, 651-605-9154



From wendyp at cray.com  Sat Jan 24 13:37:39 2004
From: wendyp at cray.com (Wendy Palm)
Date: Fri, 23 Jan 2004 20:37:39 -0600
Subject: Release testing
In-Reply-To: <1074720798.17510.36.camel@sakura.mindrot.org>
References: <1074720798.17510.36.camel@sakura.mindrot.org>
Message-ID: <4011DA73.40301@cray.com>

found a typo in ./openbsd-compat/bsd-openpty.c
(at least i hope it's a typo. :) in openssh-SNAP-20040123

$ diff ./openbsd-compat/bsd-openpty.c.orig ./openbsd-compat/bsd-openpty.c
154c154
<               snprintf(ttbuf, sideof(ttbuf), "/dev/ttyp%03d", i);
---
 >               snprintf(ttbuf, sizeof(ttbuf), "/dev/ttyp%03d", i);

wendy

Damien Miller wrote:
> Hi,
> 
> We are planning on releasing the next version of OpenSSH in a couple 
> of weeks. As always, we would like to see it tested as widely as 
> possible before this happens.
> 
> We would therefore like you to test the latest snapshots (20030122 
> and later) on as many machines that you have access to. Ideally 
> this testing should include running the regress tests and use of 
> the snapshots in a non-critical environment.
> 
> Please report your results or any problems to the mailing list.
> 
> Thanks,
> Damien Miller
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
wendy palm
Cray Open Software Development, Cray Inc.
wendyp at cray.com, 651-605-9154



From dtucker at zip.com.au  Sat Jan 24 14:23:29 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 24 Jan 2004 14:23:29 +1100
Subject: Release testing
In-Reply-To: <200401230023.02047.jason@devrandom.org>
References: <1074720798.17510.36.camel@sakura.mindrot.org>
	<200401230023.02047.jason@devrandom.org>
Message-ID: <4011E531.4040800@zip.com.au>

Jason McCormick wrote:
>   Testing the RPM building aspects of the snapshots I'm running into the 
> build process not finding kafs.h on both RedHat 9 and Fedora Core 1.  
> This header file does not seem to be provided by either krb5-devel or 
> krbafs-devel.

Hi.
	This should be fixed in today's snapshot, please retest.

		-Daz.

-- 
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  Sat Jan 24 14:43:39 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 24 Jan 2004 14:43:39 +1100
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <400FEF26.F8164703@anl.gov>
References: <400F2B59.3070308@zip.com.au> <400FEF26.F8164703@anl.gov>
Message-ID: <4011E9EB.4070501@zip.com.au>

Douglas E. Engert wrote:
> Since kafs.h is not defined in MIT Kerberos, I change the #ifdef
> to match the #ifdef used with the code that needed kafs.h.

Hi.
	This should be fixed in today's snapshot.  All of the libkafs bits are 
(or should be, anyway!) inside "#if defined(KRB5) && defined(USE_AFS)"

	Thanks again,

		-Daz.

-- 
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 kumaresh_ind at gmx.net  Sun Jan 25 19:20:39 2004
From: kumaresh_ind at gmx.net (Kumaresh)
Date: Sun, 25 Jan 2004 13:50:39 +0530
Subject: OpenSSH - forced command - no-pty issue
Message-ID: <00ee01c3e31c$25c25cb0$230110ac@kurco>

Hello,

Thanks for the pointers.

Unfortunately, we do not have options such as "shopt ..." in Ksh or sh and
we are using these shells on HP-UX. From our point of view, this is a
security issue. A malicious user could cause a denial of service on the
server by establishing many connections and breaking them, which would leave
many shell processes/sub-processes running on the server and thus might
eventually exhaust the kernel resources on the server.

We have done some changes to the openssh source to fix this issue. The patch
is attached with this mail and the diff is taken with OpenSSH-3.7.1p2
version. The basic change is, sending the HUP to the process group when the
session is closed. There are two issues in this, the forced command may be a
foreground process or a background process. So, the modification in
session_close() function is such that,

1. If the child process has exited, no need to send any signal.
2. If the child process has not exited, then kill the process group using
kill(-pid, SIGHUP).

While the changes in session_close( ) works for HP-UX ssh clients, it is not
working for the windows PuTTY ssh clients. So, that is corrected by calling
session_destroy_all(NULL) in the process_input( ) function in serverloop.c,
where the server gets terminated when the PuTTY client session is closed.

BTW, rshd works in this way. The HUP signal is passed to the process group
when we execute the remote commands.

Please review the patch and let us know if this will be added to the next
version.

ViSolve OpenSSH Support
support at visolve.com
www.visolve.com


----- Original Message -----
From: "Darren Tucker" <dtucker at zip.com.au>
To: "Kumaresh" <kumaresh_ind at gmx.net>
Cc: <madhav_vaidy at yahoo.com>; "OpenSSH Devel List"
<openssh-unix-dev at mindrot.org>
Sent: Tuesday, January 20, 2004 6:41 AM
Subject: Re: OpenSSH - forced command - no-pty issue


> Kumaresh wrote:
> > The major problem we are running into is that the shell (both sh and
ksh)
> > does not kill its child processes when there is no pty. The SSH patch
> > mentioned previously at
> > http://bugzilla.mindrot.org/show_bug.cgi?id=396
> >
> > is not sufficient to kill the forced command completely.It will only
kill
> > the shell script, but not any child processes the shell script runs. The
> > shell assumes the child is in the background (because there is no pty)
and
> > therefore does not kill the child.
>
> The script should catch the SIGHUP and clean up after itself.
>
> > Consider a shell script /tmp/test.sh that in turn calls "sleep 1000". If
we
> > run a forced command
> > command="/tmp/test.sh",no-pty,no-port-forwarding ssh-rsa
> > it gives the following processes:
> >
> >    root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
> >    root 13309 12724 10 05:24:20 ?   0:00 sshd: root at notty
> >    root 13313 13309  4 05:24:21 ?   0:00 /tmp/test.sh
> >    root 13314 13313  2 05:24:21 ?   0:00 sleep 1000
> >
> > When we disconnect the client, the sshd process is killed and the shell
> > script keeps running:
> >
> >    root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
> >    root 13313     1  0 05:24:21 ?   0:00 /tmp/test.sh
> >    root 13314 13313  0 05:24:21 ?   0:00 sleep 1000
> >
> > When we apply the patch to sshd, the sshd process sends a SIGHUP
(hangup)
> > signal to /tmp/test.sh before exiting. The shell script (/tmp/test.sh)
is
> > killed, but the shell
> > script does NOT kill its child sleep process. Here is the process list
after
> > the client disconnects:
> >
> >    root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
> >    root 13314     1  0 05:24:21 ?   0:00 sleep 1000
> >
> > You can test this by manually running the command:
> >   # PID=`ps -ef | grep /tmp/test.sh | awk '{print $2}'`
> >   # kill -HUP $PID
> >
> > The shell script will be killed but the child process (sleep 1000) will
keep
> > running.
>
> The shell (script) needs to deal with its own children, there's not much
> sshd can do (except possibly sending the HUP to the process group rather
> than the shell?)
>
> It seems similar to this bug:
> http://bugzilla.mindrot.org/show_bug.cgi?id=52
>
> "Known-good workarounds:
> * bash: shopt huponexit on
> * tcsh: none
> * zsh: setopt HUP (usually the default setting)
>    (taken from email from Jason Stone to openssh-unix-dev, 5
>    May 2001)
> * pdksh: ?"
>
> --
> 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.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.561 / Virus Database: 353 - Release Date: 1/13/2004



From pavel at NetworkPhysics.COM  Sun Jan 25 19:38:08 2004
From: pavel at NetworkPhysics.COM (Tom Pavel)
Date: Sun, 25 Jan 2004 00:38:08 -0800
Subject: Puzzled about PAM support in OpenSSH-3.7.1p2
Message-ID: <200401250838.i0P8c8QX082994@NetworkPhysics.COM>



I'm trying to understand the code around PAM support in auth2.c and
auth2-chall.c.  I'm working with the OpenSSH 3.7.1p2 sources on
FreeBSD 4.x.  The scenario I'm trying to make work is SSH login to a
captive accout for users in a RADIUS database but whose login does not
appear in /etc/passwd or getpwnam().

I understand that if the username is not found in getpwnam(), then the
fakepw() routine is called to create the user credentials (and, of
course, I'll need to modify this to point to my captive acct that I
want to use).  In auth2.c, there is code to start the PAM
authentication in this fakepw case which all seems to make sense:

        authctxt->pw = PRIVSEP(getpwnamallow(user));
        if (authctxt->pw && strcmp(service, "ssh-connection")==0) {
                authctxt->valid = 1;
#ifdef USE_PAM
                if (options.use_pam)
                    PRIVSEP(start_pam(authctxt->pw->pw_name));
#endif
        } else {
                authctxt->pw = fakepw();
#ifdef USE_PAM
                if (options.use_pam)
                    PRIVSEP(start_pam(user));
#endif
        }


However, in auth2-chall.c the code that actually verifies the passwd
returned by the remote user with the PAM module seems only to treat
the authctxt->valid case (i.e. when the getpwnam() returns a real
acct).  This seems to make the fakepw() case above pointless (and
prevents my captive acct scenario from working).

        if (authctxt->valid) {
                res = kbdintctxt->device->respond(kbdintctxt->ctxt,
                    nresp, response);
        } else {
                res = -1;
        }


My question is how is the !valid case supposed to work?  Is this just
an oversight in the OpenSSH code, or am I missing some other piece of
the puzzle (perhaps somewhere where valid is supposed to be set)?  If
this is just a bug, I'll be happy to submit a problem report and a
patch.


Thanks for any insights,

Tom Pavel

Network Physics
pavel at networkphysics.com / pavel at alum.mit.edu 




From dtucker at zip.com.au  Sun Jan 25 20:11:26 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 25 Jan 2004 20:11:26 +1100
Subject: Puzzled about PAM support in OpenSSH-3.7.1p2
In-Reply-To: <200401250838.i0P8c8QX082994@NetworkPhysics.COM>
References: <200401250838.i0P8c8QX082994@NetworkPhysics.COM>
Message-ID: <4013883E.7050701@zip.com.au>

Tom Pavel wrote:
[snip]
> This seems to make the fakepw() case above pointless (and
> prevents my captive acct scenario from working).
[snip]
> My question is how is the !valid case supposed to work?  Is this just
> an oversight in the OpenSSH code, or am I missing some other piece of
> the puzzle (perhaps somewhere where valid is supposed to be set)?

fakepw() is there so you can do exactly the same sets of operations for 
a real user and a non-existant user, to prevent leaking information 
about the validity of the account by returning faster or behaving 
differently in one case.

For example, in 3.5p1, auth-passwd.c had code roughly like the following:
         /* deny if no user. */
         if (pw == NULL)
                 return 0;
	if (some_other_test(pw->pw_name))
		return 0;
	encrypted_password = crypt(.....);
	return (strcmp(encrypted_password, pw->pw_passwd) == 0)

Obviously, the earlier it fails the faster it returns.

For 3.6.1p2 (?) a change ("owl-always-auth") was added, the equivalent 
code became something like:

	if (pw == NULL)
		pw = fakepw();
	ok = authctxt->valid;
	if (some_other_test(pw->pw_name))
		ok = 0;
	encrypted_password = crypt(.....);
	return (strcmp(encrypted_password, pw->pw_passwd) == 0 && ok)

Now all of the same tests will be done in either case.

For a discussion of authctxt->valid and its relationship to PAM, see:
http://bugzilla.mindrot.org/show_bug.cgi?id=559

-- 
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 djm at mindrot.org  Sun Jan 25 23:25:01 2004
From: djm at mindrot.org (Damien Miller)
Date: Sun, 25 Jan 2004 23:25:01 +1100 (EST)
Subject: OpenSSH - forced command - no-pty issue
In-Reply-To: <00ee01c3e31c$25c25cb0$230110ac@kurco>
References: <00ee01c3e31c$25c25cb0$230110ac@kurco>
Message-ID: <Pine.BSO.4.56.0401252323390.21793@shitei.mindrot.org>

On Sun, 25 Jan 2004, Kumaresh wrote:

> 1. If the child process has exited, no need to send any signal.
> 2. If the child process has not exited, then kill the process group using
> kill(-pid, SIGHUP).

We have proposed this before and no-one submitted test reports.

> Please review the patch and let us know if this will be added to the next
> version.

I don't know if it will be for this release - it may be too close.

-d



From des at des.no  Mon Jan 26 00:19:19 2004
From: des at des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=)
Date: Sun, 25 Jan 2004 14:19:19 +0100
Subject: [Bug 789] pam_setcred() not being called as root
In-Reply-To: <20040116015356.2F5C227C187@shitei.mindrot.org>
	(bugzilla-daemon@mindrot.org's
	message of "Fri, 16 Jan 2004 12:53:56 +1100 (EST)")
References: <20040116015356.2F5C227C187@shitei.mindrot.org>
Message-ID: <xzpwu7gp3mw.fsf@dwp.des.no>

bugzilla-daemon at mindrot.org writes:
> I can't find any reference to PAM modules being guaranteed to run as root in
> either the Open Group PAM RFC [1] or the Linux PAM documentation [2], so an
> alternative viewpoint could be that pam_group is making unwarranted assumptions
> about its environment, doing unnecessary things and failing because of it :-)

There is an underlying assumption in PAM that it runs with arbitrator
privileges.  In Unix and Unix-like systems, this means root.  It makes
no sense to call pam_setcred() when you do not have the authority to
grant said credentials.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From lha at stacken.kth.se  Mon Jan 26 20:03:01 2004
From: lha at stacken.kth.se (Love)
Date: Mon, 26 Jan 2004 10:03:01 +0100
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <p05210602bc36360a3680@[137.78.212.225]> (Henry B. Hotz's
	message of "Thu, 22 Jan 2004 18:24:32 -0800")
References: <400F2B59.3070308@zip.com.au>
	<20040122.100025.08316746.haba@pdc.kth.se>
	<xof65f4ngn5.fsf@blubb.pdc.kth.se>
	<20040122.210744.34607913.haba@pdc.kth.se>
	<p05210602bc36360a3680@[137.78.212.225]>
Message-ID: <amektn84l6.fsf@nutcracker.stacken.kth.se>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 477 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040126/6009e574/attachment.bin 

From levitte at stacken.kth.se  Mon Jan 26 22:46:14 2004
From: levitte at stacken.kth.se (Richard Levitte - VMS Whacker)
Date: Mon, 26 Jan 2004 12:46:14 +0100 (CET)
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <amektn84l6.fsf@nutcracker.stacken.kth.se>
References: <20040122.210744.34607913.haba@pdc.kth.se>
	<p05210602bc36360a3680@[137.78.212.225]>
	<amektn84l6.fsf@nutcracker.stacken.kth.se>
Message-ID: <20040126.124614.102613958.levitte@stacken.kth.se>

In message <amektn84l6.fsf at nutcracker.stacken.kth.se> on Mon, 26 Jan 2004 10:03:01 +0100, Love <lha at stacken.kth.se> said:

lha> 
lha> "Henry B. Hotz" <hotz at jpl.nasa.gov> writes:
lha> 
lha> > At 9:07 PM +0100 1/22/04, Harald Barth wrote:
lha> >>  > I think that OpenSSL != OpenSSH.
lha> >>
lha> >>Correct. I got the install order wrong. The right order is OpenSSL,
lha> >>Heimdal, OpenSSH.
lha> >>
lha> >>Harald.
lha> >
lha> > OK, so how do you install OpenSSL with RFC 2712 support enabled?
lha> 
lha> build libcrypto, build heimdal, build libssl

Why?  Unless someone has a patch fixing this, OpenSSL currently
doesn't link with Heimdal, it only works with MIT Kerberos...  or do
you know something I don't?

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte   \ Tunnlandsv?gen 3  \ LeViMS at stacken.kth.se
Redakteur at Stacken  \ S-168 36  BROMMA  \ T: +46-8-26 52 47
                    \      SWEDEN       \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis                -- poei at bofh.se
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.



From xdavid at lib-eth.natur.cuni.cz  Tue Jan 27 00:33:58 2004
From: xdavid at lib-eth.natur.cuni.cz (David Komanek)
Date: Mon, 26 Jan 2004 14:33:58 +0100 (CET)
Subject: Portable OpenSSH and GSSAPI
Message-ID: <Pine.OSF.4.58.0401261346250.204564@lib-eth.natur.cuni.cz>


Dear developers,

I am already playing with openssh + heimdal krb5 + gssapi on Tru64Unix
5.1a and Irix 6.5.20, but with no much success. The worst problem I
experience is following:

- gethostbyname on tru64unix returns short host name instead of fqdn. But
even if I overcome this problem by appending the domain name to the lname
variable in gss-genr.c file and get over this problem, gss-api does not
work well. If the hostname is in fqdn format and is accepted by gssapi and
I run the daemon on tru64unix as

./sshd -p 2222 -d -d -d

I get the following:

debug2: input_userauth_request: try method gssapi-with-mic
debug3:  entering: type 37
debug3:  entering: type 38
debug3:  entering
debug3: : checking request 37
debug3:  entering: type 38
debug3:  entering
Postponed gssapi-with-mic for komanek from xxx.xxx.xxx.xxx port 57083 ssh2

Where should I search for the problem - in OpenSSH code or in Heimdal code
? What actually this "postpone" means ?

It seems very strange to me, because if the sshd server is running on
another platform than tru64unix, it works. I already "upgraded" to latest
snapshots of both openssh and heimdal with no progress in this.

Thanks in advance.

Sincerely,

  David Komanek
  Charles University in Prague
  Czech Republic



From lissav at us.ibm.com  Tue Jan 27 01:09:15 2004
From: lissav at us.ibm.com (Lissa Valletta)
Date: Mon, 26 Jan 2004 09:09:15 -0500
Subject: Returned post for secureshell@securityfocus.com
Message-ID: <OF3831E0E7.B8978178-ON85256E27.004DB572-85256E27.004DC199@us.ibm.com>





Could you address my problem below?

Thanks!

Lissa K. Valletta
414/3-8
Poughkeepsie, NY 12601
(tie 293) 433-3102


----- Forwarded by Lissa Valletta/Poughkeepsie/IBM on 01/26/2004 09:08 AM
-----
                                                                                                                                           
                      secureshell-owner at securi                                                                                             
                      tyfocus.com                     To:       Lissa Valletta/Poughkeepsie/IBM at IBMUS                                      
                                                      cc:                                                                                  
                      01/23/2004 12:44 PM             Subject:  Returned post for secureshell at securityfocus.com                            
                                                                                                                                           
                                                                                                                                           




Hi! This is the ezmlm program. I'm managing the
secureshell at securityfocus.com mailing list.

I'm working for my owner, who can be reached
at secureshell-owner at securityfocus.com.

I'm sorry, your message (enclosed) was not accepted by the moderator.
If the moderator has made any comments, they are shown below.

>>>>> -------------------- >>>>>

It seems that this issue should be taken up with the developers of OpenSSH
itself. You can find all the relevant info at www.openssh.org/list.html

<<<<< -------------------- <<<<<

----- Message from Lissa Valletta <lissav at us.ibm.com> on Fri, 23 Jan 2004
09:52:14 -0500 -----
                                        
      To: secureshell at securityfocus.com 
                                        
 Subject: Openssh Kerberos Version 5    
          support                       
                                        

I downloaded the current supported version of Openssh and configured it
with the --with-kerberos=/usr/kerberos option on Redhat 8.0 Linux.
After installing Kerberos and configuring my Kerberos remote shell setup
( I know it works because rsh uses the Kerberos Version 5
ticket-granting-ticket) just fine.   I tried to run ssh and have it use
the KV5 ticket.   ssh -v never shows gssapi as one or the
authentication methods.
I then search google and found the www.reric.net web site which had an
Openssh with a "patch" installed.  I took the rpms from there and
everything worked fine.
When is the current Openssh going to support Kerberos Version 5 from
the distributed source and not have to pick up a patch from somewhere
else.    AIX distributes a Kerberized enabled Openssh but Linux does not
and the current process for picking up  a working Kerberized Openssh for
Linux is not clean.  I need to be able to tell the customer to go to the
OpenSSH web site and either download the source and compile it in, or it
would be even better is you had OpenSSH with Kerberos enabled rpms for
Linux available.
Thanks!





From xdavid at lib-eth.natur.cuni.cz  Tue Jan 27 02:18:05 2004
From: xdavid at lib-eth.natur.cuni.cz (David Komanek)
Date: Mon, 26 Jan 2004 16:18:05 +0100 (CET)
Subject: ADDENDUM: Portable OpenSSH and GSSAPI
Message-ID: <Pine.OSF.4.58.0401261611560.204564@lib-eth.natur.cuni.cz>



Dear developers,

to my previous post I have some additional info. I just erased all the
krb5 data and set it up from scratch. Now the message in sshd debug
changed to:

debug1:  Miscellaneous failure (see text)
Decrypt integrity check failed
debug1: Got no client credentials
Failed gssapi-with-mic for komanek ....

So it seems the problem is somewhere in the kerberos, not in openssh. Is
here anybody on the list who can confirm this ?

Thanks in advance,

  David Komanek


original post follows:

Dear developers,

I am already playing with openssh + heimdal krb5 + gssapi on Tru64Unix
5.1a and Irix 6.5.20, but with no much success. The worst problem I
experience is following:

- gethostbyname on tru64unix returns short host name instead of fqdn. But
even if I overcome this problem by appending the domain name to the lname
variable in gss-genr.c file and get over this problem, gss-api does not
work well. If the hostname is in fqdn format and is accepted by gssapi and
I run the daemon on tru64unix as

./sshd -p 2222 -d -d -d

I get the following:

debug2: input_userauth_request: try method gssapi-with-mic
debug3:  entering: type 37
debug3:  entering: type 38
debug3:  entering
debug3: : checking request 37
debug3:  entering: type 38
debug3:  entering
Postponed gssapi-with-mic for komanek from xxx.xxx.xxx.xxx port 57083 ssh2

Where should I search for the problem - in OpenSSH code or in Heimdal code
? What actually this "postpone" means ?

It seems very strange to me, because if the sshd server is running on
another platform than tru64unix, it works. I already "upgraded" to latest
snapshots of both openssh and heimdal with no progress in this.

Thanks in advance.

Sincerely,

  David Komanek
  Charles University in Prague
  Czech Republic



From mouring at etoh.eviladmin.org  Tue Jan 27 03:05:51 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 26 Jan 2004 10:05:51 -0600 (CST)
Subject: ADDENDUM: Portable OpenSSH and GSSAPI
In-Reply-To: <Pine.OSF.4.58.0401261611560.204564@lib-eth.natur.cuni.cz>
Message-ID: <Pine.BSO.4.44.0401261005090.27267-100000@etoh.eviladmin.org>



On Mon, 26 Jan 2004, David Komanek wrote:

>
>
> Dear developers,
>
> to my previous post I have some additional info. I just erased all the
> krb5 data and set it up from scratch. Now the message in sshd debug
> changed to:
>
> debug1:  Miscellaneous failure (see text)
> Decrypt integrity check failed
> debug1: Got no client credentials
> Failed gssapi-with-mic for komanek ....
>
Do note  "gssapi-with-mic"  is different from the original "gssapi" and
they will not communicate with each other.

- Ben




From xdavid at lib-eth.natur.cuni.cz  Tue Jan 27 03:15:07 2004
From: xdavid at lib-eth.natur.cuni.cz (David Komanek)
Date: Mon, 26 Jan 2004 17:15:07 +0100 (CET)
Subject: ADDENDUM: Portable OpenSSH and GSSAPI
In-Reply-To: <Pine.BSO.4.44.0401261005090.27267-100000@etoh.eviladmin.org>
References: <Pine.BSO.4.44.0401261005090.27267-100000@etoh.eviladmin.org>
Message-ID: <Pine.OSF.4.58.0401261713280.204564@lib-eth.natur.cuni.cz>


> Do note  "gssapi-with-mic"  is different from the original "gssapi" and
> they will not communicate with each other.

I guessed it and I use ssh on cliend and server side exactly the same
version/snapshot. The problem persists even if I am sshing from host B to
B (despite the A-B-C naming in my previous post).

David



From sxw at inf.ed.ac.uk  Tue Jan 27 03:34:35 2004
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Mon, 26 Jan 2004 16:34:35 +0000 (GMT)
Subject: ADDENDUM: Portable OpenSSH and GSSAPI
In-Reply-To: <Pine.OSF.4.58.0401261611560.204564@lib-eth.natur.cuni.cz>
Message-ID: <Pine.LNX.4.44.0401261633260.14730-100000@warspite.inf.ed.ac.uk>

On Mon, 26 Jan 2004, David Komanek wrote:

> to my previous post I have some additional info. I just erased all the
> krb5 data and set it up from scratch. Now the message in sshd debug
> changed to:

Have you verified that Kerberos itself is working? Do other Kerberized 
applications work correctly?

Cheers,

Simon.




From deengert at anl.gov  Tue Jan 27 04:21:48 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 26 Jan 2004 11:21:48 -0600
Subject: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos  
Message-ID: <40154CAC.6B97BED5@anl.gov>

Rather then implementing kafs in MIT Kerberos, I would like to 
suggest an alternative which has advantages to all parties. 

The OpenSSH sshd needs to do two things: 
   (1) sets a PAG in the kernel, 
   (2) obtains an AFS token storing it in the kernel.

It can use the Kerberos credentials either obtained via GSSAPI 
delegation, PAM or other kerberos login code in the sshd. 

The above two actions can be accomplished by a separate process, 
which can be forked and execd by the sshd and passed the environment
which may have a KREB5CCNAME pointing at the Kerberos ticket cache
Other parameters such as the home directory could also be passed. 


This would then allow simple code in OpenSSH that does not depend
on OpenAFS, Hiemdal or MIT code to fork/exec the process that does
all the work. This would be called by the process that would 
eventially become the user's shell process and is run as the user. 

OpenSSH could be built on systems that may or may not have AFS 
installed and run on a system with or without AFS.  The decision 
is based on the existence of the executable and any options
in sshd_config.

In its simplest form, all that is needed is:

  system("/usr/ssh/libexec/aklog -setpag") 

This is a little over simplified as there should be a test if the 
executable exists, processing of some return codes, making sure the 
environment is set, setting some time limit. etc. But the point is 
there is no compile dependence on OpenAFS, MIT or Hiemdal by the 
OpenSSH sshd, and any failure of the process will not effect the sshd.  



We have been using something like this for years which issues a 
syscall to set a PAG for the current process, then fork/exec ak5log. 
Our current mode to OpenSSH in session.c is as  simple as:

  krb5_afs_pag_env(NULL, env);

It is currently built with the MIT Kerberos code for historic reasons,
but could be seperate as it has no real dependency on the MIT code. 

I would hope that the members of the OpenSSH community who use OpenAFS, 
Hiemdal and/or MIT could agree on a simple command line interface that 
would encourage the builders of OpenSSH to always have this enabled.    

-- 

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



From jaltman at columbia.edu  Tue Jan 27 04:34:42 2004
From: jaltman at columbia.edu (Jeffrey Altman)
Date: Mon, 26 Jan 2004 12:34:42 -0500
Subject: [OpenAFS-devel] OpenSSH, OpenAFS,
	Heimdal Kerberos and MIT Kerberos
In-Reply-To: <40154CAC.6B97BED5@anl.gov>
References: <40154CAC.6B97BED5@anl.gov>
Message-ID: <40154FB2.9080506@columbia.edu>

Douglas E. Engert wrote:

>In its simplest form, all that is needed is:
>
>  system("/usr/ssh/libexec/aklog -setpag") 
>  
>
You would probably want this to be a configurable option in the sshd 
configuration file
as opposed to have a fixed name, location and options which are set at 
compile time.

Jeffrey Altman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3427 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040126/0381fe3d/attachment.bin 

From deengert at anl.gov  Tue Jan 27 04:43:04 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 26 Jan 2004 11:43:04 -0600
Subject: [OpenAFS-devel] OpenSSH, OpenAFS,
	Heimdal Kerberos and MIT Kerberos
References: <40154CAC.6B97BED5@anl.gov> <40154FB2.9080506@columbia.edu>
Message-ID: <401551A8.272D8992@anl.gov>



Jeffrey Altman wrote:
> 
> Douglas E. Engert wrote:
> 
> >In its simplest form, all that is needed is:
> >
> >  system("/usr/ssh/libexec/aklog -setpag")
> >
> >
> You would probably want this to be a configurable option in the sshd
> configuration file
> as opposed to have a fixed name, location and options which are set at
> compile time.

Yes, I would assume the location could be set like the sftpd location is set.

Subsystem   sftp    /krb5/libexec/sftp-server

I was trying to show the simplist example. 



> Jeffrey Altman

-- 

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



From mouring at etoh.eviladmin.org  Tue Jan 27 05:03:36 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Mon, 26 Jan 2004 12:03:36 -0600 (CST)
Subject: [OpenAFS-devel] OpenSSH, OpenAFS, Heimdal Kerberos and MIT
 Kerberos
In-Reply-To: <401551A8.272D8992@anl.gov>
Message-ID: <Pine.BSO.4.44.0401261157080.27267-100000@etoh.eviladmin.org>


I hate to derail this, but in the short term unless the code appears
perfect in the next <looks down at his watch> two hours, and is blessed
by all parties involved and is extremely simple and small.  The chances
it will be including in this release of OpenSSH are zero.

I'd perfer if we could test and ensure this release of OpenSSH can get out
the door without the "B-But!!!!  It does not work with XYZ common
configuration" that seems to always crop up with KRB/AFS in general.

I'm all for simplifying and cleaning code. =)  But we are starting to lose
the light of day before this release.

- Ben



On Mon, 26 Jan 2004, Douglas E. Engert wrote:

>
>
> Jeffrey Altman wrote:
> >
> > Douglas E. Engert wrote:
> >
> > >In its simplest form, all that is needed is:
> > >
> > >  system("/usr/ssh/libexec/aklog -setpag")
> > >
> > >
> > You would probably want this to be a configurable option in the sshd
> > configuration file
> > as opposed to have a fixed name, location and options which are set at
> > compile time.
>
> Yes, I would assume the location could be set like the sftpd location is set.
>
> Subsystem   sftp    /krb5/libexec/sftp-server
>
> I was trying to show the simplist example.
>
>
>
> > Jeffrey Altman
>
> --
>
>  Douglas E. Engert  <DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From senwer at public.qz.fj.cn  Tue Jan 27 05:07:03 2004
From: senwer at public.qz.fj.cn (Rachel)
Date: Tue, 27 Jan 2004 02:07:03 +0800
Subject: Leading bag manufacturer
Message-ID: <20040126180549.8926A27C1ED@shitei.mindrot.org>


   Dear Madam or Sir, I have the pleasure to know your esteemed Corp. We
   are the leading manufacturer of bag in Quanzhou, China. The following
   is some introductions about our company. Set up: 1988 Export: agent by
   large state export & import corporation Employees: 1100 persons
   Output: 4.6 million pcs/year Payment: irrevocable L/C at sight or T/T
   (Our export agent will be the beneficiary) We produce all kinds of
   bags, including backpack, travel bag, sport bag, duffel bag,
   saddlebag, trolley, suitcase, camera bag, shopping bag, school bag,
   computer case, luggage, workbag, promotional bag, etc. We have
   advanced equipments and technologies which were learned and imported
   from German and other advanced countries. We still have experienced
   management system, seasoned workmanship, complete service and strong
   economic capacity. Our goods have met a great favor in Europe,
   America, Japan and other counties because of their slap-up quality,
   beautiful design and gratifying price. With the philosophy "quality,
   service, integrity, and environmental consciousness", We would like to
   welcome customers all over the world to establish business relations
   with us. Welcome to visit our company or contact with us for more
   information. Thanks & best regards Rachel Wang Mob:0086-13960286700
   ---------------------------------------------------------- SENWER
   GARMENTS CO., LTD. ADD.: Wancheng Ge 516, Citong Road, Quanzhou,
   China. Tel: 0086-595-2216499 Fax: 0086-595-2214455 P.C.:362000
   ----------------------------------------------------------


From andrei at caspur.it  Tue Jan 27 05:43:46 2004
From: andrei at caspur.it (Andrei Maslennikov)
Date: Mon, 26 Jan 2004 19:43:46 +0100 (MET)
Subject: [OpenAFS-devel] OpenSSH, OpenAFS, Heimdal Kerberos and MIT
 Kerberos
In-Reply-To: <40154CAC.6B97BED5@anl.gov>
Message-ID: <Pine.LNX.4.44.0401261903130.6265-100000@kiwi.caspur.it>


We have implemented the strategy similar to the one that Douglas suggested
in his posting. In our case (Heimdal) we allow user to login using his/her
K5 password and then call Heimdal "afslog" inside session.c:

        system("/usr/sshutils/sbin/afslog >/dev/null 2>&1");

A small complementary trick (sshd is invoked via inetd/xinetd with "-i"
flag from within the pagsh wrapper) allows the token to be obtained
automatically in a brand-new pagsh. All this works with the protocol 2,
and users obtain both K5 tickets and PAG-based tokens upon login. Apart
from just one extra system call, no code hacking is needed for OpenSSH.

What we were yet unable to achieve is the further K5 credentials
forwarding in case of login via the K5 password. What happens is the
following:

  1) ssh to host A, login with K5 password (and obtain a PAG-based token)
  2) from host A, ssh to host B, login w/o pw (this time with GSSAPI)
  3) inside host B: no K5 creds forwarded from host A, no token. 

A possible workaround would be to re-authenticate automatically with
GSSAPI right after the successful K5 password login (using the
just-obtained K5 creds), but it might be tricky to implement. There is
even a comment in the auth2.c ("/* XXX todo: check if multiple auth
methods are needed */), but nobody ever went further. If this would work,
the GSSAPI creds would be stored on host A and then presumably forwarded
to the host B during the GSSAPI login (and hence the AFS token would be
obtained there automatically). I.e. it could become possible to type in
the password only one time, and then navigate with ssh between enabled
machines without password - all this while preserving K5 creds and
automatically obtaining AFS tokens.

Andrei.


On Mon, 26 Jan 2004, Douglas E. Engert wrote:

> Rather then implementing kafs in MIT Kerberos, I would like to suggest
> an alternative which has advantages to all parties.
> 
> The OpenSSH sshd needs to do two things: 
>    (1) sets a PAG in the kernel, 
>    (2) obtains an AFS token storing it in the kernel.
> 
> It can use the Kerberos credentials either obtained via GSSAPI
> delegation, PAM or other kerberos login code in the sshd.
> 
> The above two actions can be accomplished by a separate process, which
> can be forked and execd by the sshd and passed the environment which may
> have a KREB5CCNAME pointing at the Kerberos ticket cache Other
> parameters such as the home directory could also be passed.
> 
> 
> This would then allow simple code in OpenSSH that does not depend on
> OpenAFS, Hiemdal or MIT code to fork/exec the process that does all the
> work. This would be called by the process that would eventially become
> the user's shell process and is run as the user.
> 
> OpenSSH could be built on systems that may or may not have AFS installed
> and run on a system with or without AFS.  The decision is based on the
> existence of the executable and any options in sshd_config.
> 
> In its simplest form, all that is needed is:
> 
>   system("/usr/ssh/libexec/aklog -setpag") 
> 
> This is a little over simplified as there should be a test if the
> executable exists, processing of some return codes, making sure the
> environment is set, setting some time limit. etc. But the point is there
> is no compile dependence on OpenAFS, MIT or Hiemdal by the OpenSSH sshd,
> and any failure of the process will not effect the sshd.
> 
> 
> 
> We have been using something like this for years which issues a syscall
> to set a PAG for the current process, then fork/exec ak5log.  Our
> current mode to OpenSSH in session.c is as simple as:
> 
>   krb5_afs_pag_env(NULL, env);
> 
> It is currently built with the MIT Kerberos code for historic reasons,
> but could be seperate as it has no real dependency on the MIT code. 
> 
> I would hope that the members of the OpenSSH community who use OpenAFS,
> Hiemdal and/or MIT could agree on a simple command line interface that
> would encourage the builders of OpenSSH to always have this enabled.
> 
> 




From deengert at anl.gov  Tue Jan 27 06:03:02 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 26 Jan 2004 13:03:02 -0600
Subject: [OpenAFS-devel] OpenSSH, OpenAFS,
	Heimdal Kerberos and MITKerberos
References: <Pine.BSO.4.44.0401261157080.27267-100000@etoh.eviladmin.org>
Message-ID: <40156466.312C4B3A@anl.gov>



Ben Lindstrom wrote:
> 
> I hate to derail this, but in the short term unless the code appears
> perfect in the next <looks down at his watch> two hours, and is blessed
> by all parties involved and is extremely simple and small.  The chances
> it will be including in this release of OpenSSH are zero.
> 
> I'd perfer if we could test and ensure this release of OpenSSH can get out
> the door without the "B-But!!!!  It does not work with XYZ common
> configuration" that seems to always crop up with KRB/AFS in general.

Thats fine with me. I was trying to address the long term, where the
OpenAFS, Hiemdal and MIT Kerberos people could work this out so 
it would simplify the OpenSSH code. 

Just hainvg the GSSAPI code include in the base source is a great step
forward. 
  
> 
> I'm all for simplifying and cleaning code. =)  But we are starting to lose
> the light of day before this release.
> 
> - Ben
> 
> On Mon, 26 Jan 2004, Douglas E. Engert wrote:
> 
> >
> >
> > Jeffrey Altman wrote:
> > >
> > > Douglas E. Engert wrote:
> > >
> > > >In its simplest form, all that is needed is:
> > > >
> > > >  system("/usr/ssh/libexec/aklog -setpag")
> > > >
> > > >
> > > You would probably want this to be a configurable option in the sshd
> > > configuration file
> > > as opposed to have a fixed name, location and options which are set at
> > > compile time.
> >
> > Yes, I would assume the location could be set like the sftpd location is set.
> >
> > Subsystem   sftp    /krb5/libexec/sftp-server
> >
> > I was trying to show the simplist example.
> >
> >
> >
> > > Jeffrey Altman
> >
> > --
> >
> >  Douglas E. Engert  <DEEngert at anl.gov>
> >  Argonne National Laboratory
> >  9700 South Cass Avenue
> >  Argonne, Illinois  60439
> >  (630) 252-5444
> >
> > _______________________________________________
> > 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 deengert at anl.gov  Tue Jan 27 06:19:40 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 26 Jan 2004 13:19:40 -0600
Subject: [OpenAFS-devel] OpenSSH, OpenAFS,
	Heimdal Kerberos and MITKerberos
References: <Pine.LNX.4.44.0401261903130.6265-100000@kiwi.caspur.it>
Message-ID: <4015684C.7B5D1626@anl.gov>



Andrei Maslennikov wrote:
> 
> We have implemented the strategy similar to the one that Douglas suggested
> in his posting. In our case (Heimdal) we allow user to login using his/her
> K5 password and then call Heimdal "afslog" inside session.c:
> 
>         system("/usr/sshutils/sbin/afslog >/dev/null 2>&1");

Yes this is just the type interface that could simplify the OpenSSH code.
What the OpenAFS comunity needs to decied is what is needed for the
common interface. 

> 
> A small complementary trick (sshd is invoked via inetd/xinetd with "-i"
> flag from within the pagsh wrapper) allows the token to be obtained
> automatically in a brand-new pagsh. All this works with the protocol 2,
> and users obtain both K5 tickets and PAG-based tokens upon login. Apart
> from just one extra system call, no code hacking is needed for OpenSSH.

Nice trick. But if the AFS kernel code supports -setpag by the afsklog
or aklog to set the parent's prooces this would not be needed.   

> 
> What we were yet unable to achieve is the further K5 credentials
> forwarding in case of login via the K5 password. What happens is the
> following:
> 
>   1) ssh to host A, login with K5 password (and obtain a PAG-based token)

Was the ticket marked forwardable?  Can you set with Hiemdal in the
krb5.conf file a default that tickets should be forwardable? 
What does klist -f show on host A?


>   2) from host A, ssh to host B, login w/o pw (this time with GSSAPI)

GSSAPI should have delegated a K5 credential, and set the KRB5CCNAME
on host B. 

>   3) inside host B: no K5 creds forwarded from host A, no token.

We can do the above but normally get the initial ticket on the local 
workstation at login or via kinit. We try not to require uses to ever 
send thier Kerberos password over the network. 

But in our case we let PAM on A get the ticket and are using the 
MIT Kerberos. Can you set with Hiemdal in the krb5.conf file a default 
that tickets should be forwardable? 

> 
> A possible workaround would be to re-authenticate automatically with
> GSSAPI right after the successful K5 password login (using the
> just-obtained K5 creds), but it might be tricky to implement. There is
> even a comment in the auth2.c ("/* XXX todo: check if multiple auth
> methods are needed */), but nobody ever went further. If this would work,
> the GSSAPI creds would be stored on host A and then presumably forwarded
> to the host B during the GSSAPI login (and hence the AFS token would be
> obtained there automatically). I.e. it could become possible to type in
> the password only one time, and then navigate with ssh between enabled
> machines without password - all this while preserving K5 creds and
> automatically obtaining AFS tokens.
> 
> Andrei.
> 
> On Mon, 26 Jan 2004, Douglas E. Engert wrote:
> 
> > Rather then implementing kafs in MIT Kerberos, I would like to suggest
> > an alternative which has advantages to all parties.
> >
> > The OpenSSH sshd needs to do two things:
> >    (1) sets a PAG in the kernel,
> >    (2) obtains an AFS token storing it in the kernel.
> >
> > It can use the Kerberos credentials either obtained via GSSAPI
> > delegation, PAM or other kerberos login code in the sshd.
> >
> > The above two actions can be accomplished by a separate process, which
> > can be forked and execd by the sshd and passed the environment which may
> > have a KREB5CCNAME pointing at the Kerberos ticket cache Other
> > parameters such as the home directory could also be passed.
> >
> >
> > This would then allow simple code in OpenSSH that does not depend on
> > OpenAFS, Hiemdal or MIT code to fork/exec the process that does all the
> > work. This would be called by the process that would eventially become
> > the user's shell process and is run as the user.
> >
> > OpenSSH could be built on systems that may or may not have AFS installed
> > and run on a system with or without AFS.  The decision is based on the
> > existence of the executable and any options in sshd_config.
> >
> > In its simplest form, all that is needed is:
> >
> >   system("/usr/ssh/libexec/aklog -setpag")
> >
> > This is a little over simplified as there should be a test if the
> > executable exists, processing of some return codes, making sure the
> > environment is set, setting some time limit. etc. But the point is there
> > is no compile dependence on OpenAFS, MIT or Hiemdal by the OpenSSH sshd,
> > and any failure of the process will not effect the sshd.
> >
> >
> >
> > We have been using something like this for years which issues a syscall
> > to set a PAG for the current process, then fork/exec ak5log.  Our
> > current mode to OpenSSH in session.c is as simple as:
> >
> >   krb5_afs_pag_env(NULL, env);
> >
> > It is currently built with the MIT Kerberos code for historic reasons,
> > but could be seperate as it has no real dependency on the MIT code.
> >
> > I would hope that the members of the OpenSSH community who use OpenAFS,
> > Hiemdal and/or MIT could agree on a simple command line interface that
> > would encourage the builders of OpenSSH to always have this enabled.
> >
> >

-- 

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



From smoogen at lanl.gov  Tue Jan 27 06:23:03 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Mon, 26 Jan 2004 12:23:03 -0700
Subject: [OpenAFS-devel] OpenSSH, OpenAFS, Heimdal Kerberos and
	MITKerberos
In-Reply-To: <40156466.312C4B3A@anl.gov>
References: <Pine.BSO.4.44.0401261157080.27267-100000@etoh.eviladmin.org>
	<40156466.312C4B3A@anl.gov>
Message-ID: <1075144983.28792.10.camel@smoogen2.lanl.gov>

On Mon, 2004-01-26 at 12:03, Douglas E. Engert wrote:
> Ben Lindstrom wrote:
> > 
> > I'd perfer if we could test and ensure this release of OpenSSH can get out
> > the door without the "B-But!!!!  It does not work with XYZ common
> > configuration" that seems to always crop up with KRB/AFS in general.
> 
> Thats fine with me. I was trying to address the long term, where the
> OpenAFS, Hiemdal and MIT Kerberos people could work this out so 
> it would simplify the OpenSSH code. 
> 
> Just hainvg the GSSAPI code include in the base source is a great step
> forward. 
>   

Yes, thankyou to everyone who has worked on this part.

> > 
> > I'm all for simplifying and cleaning code. =)  But we are starting to lose
> > the light of day before this release.
> > 
> > - Ben
> > 

-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --



From hotz at jpl.nasa.gov  Tue Jan 27 06:23:34 2004
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Mon, 26 Jan 2004 11:23:34 -0800
Subject: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos
In-Reply-To: <40154CAC.6B97BED5@anl.gov>
References: <40154CAC.6B97BED5@anl.gov>
Message-ID: <p05210604bc3b15e51eae@[137.78.212.225]>

I don't disagree with your proposal at all.  Sounds good.  It should 
make it easier to fix/change things in the future.

But. . .

Isn't the reason this keeps coming up that AFS client doesn't 
(can't?) behave like a normal Kerberos application and just get it's 
own service ticket when it needs one (based on an existing tgt)?  The 
real reason this doesn't happen is that tickets are stored in a file 
in /tmp, but it's a different set of file system code inside the 
kernel that would need to access it to request the service ticket.

Can't we figure a way to just make the kernel module get the service 
ticket (token) automatically, or fail if there is no tgt?  That would 
make the whole problem go away and AFS would no longer need the 
special attention it does now.

I note that on MacOS X tickets are stored in a MACH "security 
context" which acts a lot like a PAG.  Furthermore it's accessible 
inside the kernel.  Doesn't Windows have some similar in-memory 
storage mechanism?

Has anyone thought about how congruent PAGs and terminal sessions 
are?  I think X11 defined the latter, and Kerberos has tried to tie 
in to them rather than import the PAG concept.

At 11:21 AM -0600 1/26/04, Douglas E. Engert wrote:
>Rather then implementing kafs in MIT Kerberos, I would like to
>suggest an alternative which has advantages to all parties.
>
>The OpenSSH sshd needs to do two things:
>    (1) sets a PAG in the kernel,
>    (2) obtains an AFS token storing it in the kernel.
>
>It can use the Kerberos credentials either obtained via GSSAPI
>delegation, PAM or other kerberos login code in the sshd.
>
>The above two actions can be accomplished by a separate process,
>which can be forked and execd by the sshd and passed the environment
>which may have a KREB5CCNAME pointing at the Kerberos ticket cache
>Other parameters such as the home directory could also be passed.
>
>
>This would then allow simple code in OpenSSH that does not depend
>on OpenAFS, Hiemdal or MIT code to fork/exec the process that does
>all the work. This would be called by the process that would
>eventially become the user's shell process and is run as the user.
>
>OpenSSH could be built on systems that may or may not have AFS
>installed and run on a system with or without AFS.  The decision
>is based on the existence of the executable and any options
>in sshd_config.
>
>In its simplest form, all that is needed is:
>
>   system("/usr/ssh/libexec/aklog -setpag")
>
>This is a little over simplified as there should be a test if the
>executable exists, processing of some return codes, making sure the
>environment is set, setting some time limit. etc. But the point is
>there is no compile dependence on OpenAFS, MIT or Hiemdal by the
>OpenSSH sshd, and any failure of the process will not effect the sshd. 
>
>
>
>We have been using something like this for years which issues a
>syscall to set a PAG for the current process, then fork/exec ak5log.
>Our current mode to OpenSSH in session.c is as  simple as:
>
>   krb5_afs_pag_env(NULL, env);
>
>It is currently built with the MIT Kerberos code for historic reasons,
>but could be seperate as it has no real dependency on the MIT code.
>
>I would hope that the members of the OpenSSH community who use OpenAFS,
>Hiemdal and/or MIT could agree on a simple command line interface that
>would encourage the builders of OpenSSH to always have this enabled.   
>
>--
>
>  Douglas E. Engert  <DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444


-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu



From andrei at caspur.it  Tue Jan 27 06:49:28 2004
From: andrei at caspur.it (Andrei Maslennikov)
Date: Mon, 26 Jan 2004 20:49:28 +0100 (MET)
Subject: [OpenAFS-devel] OpenSSH, OpenAFS,
	Heimdal Kerberos and MITKerberos
In-Reply-To: <4015684C.7B5D1626@anl.gov>
Message-ID: <Pine.LNX.4.44.0401262036090.6863-100000@kiwi.caspur.it>


Hi Douglas, and thanks for your comment.


On Mon, 26 Jan 2004, Douglas E. Engert wrote:

> 
> 1) ssh to host A, login with K5 password (and obtain a PAG-based token)
> 
> Was the ticket marked forwardable?  Can you set with Hiemdal in the
> krb5.conf file a default that tickets should be forwardable? 
> What does klist -f show on host A?

  Yes, tickets are set to be forwardable in the [libdefaults] section:

<ing at alfa ~>klist -f
Credentials cache: FILE:/tmp/krb5cc_k20844
        Principal: ing at ING.UNIROMA1.IT

  Issued           Expires        Flags    Principal                              
Jan 26 20:34:02  Jan 27 03:14:02  FI     
krbtgt/ING.UNIROMA1.IT at ING.UNIROMA1.IT   
Jan 26 20:34:02  Jan 27 03:14:02         afs at ING.UNIROMA1.IT                      
Jan 26 20:34:31  Jan 27 03:14:02         
host/alfa.ing.uniroma1.it at ING.UNIROMA1.IT

   V4-ticket file: /tmp/tkt401
klist: No ticket file (tf_util)
  
> 
> 
> 2) from host A, ssh to host B, login w/o pw (this time with GSSAPI)
> 
> GSSAPI should have delegated a K5 credential, and set the KRB5CCNAME
> on host B. 

  This does not occur, however GSSAPI lets me in (without creds):
......
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: 
publickey,gssapi,password,keyboard-interactive
debug1: Next authentication method: gssapi       
debug1: Authentication succeeded (gssapi).  <<<<<<<<<<<<<<<<<<
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Requesting authentication agent forwarding.
Could not chdir to home directory /afs/ing/system/hq/ing: Permission 
denied

> 
> >   3) inside host B: no K5 creds forwarded from host A, no token.
> 
> We can do the above

  ..That's what the "sshd -d" tells me:

.....
debug1: userauth-request for user ing service ssh-connection method gssapi
debug1: attempt 1 failures 1
Postponed gssapi for ing from 151.100.85.253 port 44184 ssh2
debug1: Got no client credentials
Authorized to ing, krb5 principal ing at ING.UNIROMA1.IT (krb5_kuserok)
Accepted gssapi for ing from 151.100.85.253 port 44184 ssh2  <<<<<<<<<<<
Accepted gssapi for ing from 151.100.85.253 port 44184 ssh2
.....
.....
debug1: session_input_channel_req: session 0 req shell
debug1: temporarily_use_uid: 401/401 (e=401/401)
debug1: No credentials stored   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
debug1: restore_uid: (unprivileged)
...

  Inside the host B: no credentials at all:

[ing at alfa /]$ /usr/heimdal/bin/klist
klist: No ticket file: /tmp/krb5cc_401

   V4-ticket file: /tmp/tkt401
klist: No ticket file (tf_util)

  THERE SHOULD BE SOMETHING ELSE....




From deengert at anl.gov  Tue Jan 27 07:28:53 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 26 Jan 2004 14:28:53 -0600
Subject: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos
References: <40154CAC.6B97BED5@anl.gov>
	<p05210604bc3b15e51eae@[137.78.212.225]>
Message-ID: <40157885.6C8E3F68@anl.gov>



"Henry B. Hotz" wrote:
> 
> I don't disagree with your proposal at all.  Sounds good.  It should
> make it easier to fix/change things in the future.
> 
> But. . .
> 
> Isn't the reason this keeps coming up that AFS client doesn't
> (can't?) behave like a normal Kerberos application and just get it's
> own service ticket when it needs one (based on an existing tgt)?  The
> real reason this doesn't happen is that tickets are stored in a file
> in /tmp, but it's a different set of file system code inside the
> kernel that would need to access it to request the service ticket.

Yes sort of. DCE/DFS had this capability. The AFS kernel mods would still 
need to associate the ticket cache to use when it needs to get a token. 
This is normally kept in the  KRB5CCNAME environment variable, which 
is only available to the application code. 

DCE/DFS addressed the problem, by keeping the ticket cache in
/opt/dcelocal/var/security/creds/dcecred_nnnnnnnn where nnnnnnnn was
the PAG number. The daemon (like sshd) still had to get the PAG, and 
set the KRB5CCNAME to point at the cache just in case it was needed by
some Kerberos application.   

DCE used only K5, AFS at that time use K4 and is just now starting to
convert to K5.  

> 
> Can't we figure a way to just make the kernel module get the service
> ticket (token) automatically, or fail if there is no tgt?  That would
> make the whole problem go away and AFS would no longer need the
> special attention it does now.

Yes it could, but it would be a lot of work. There are only a handfull
of deamons that need to get a PAG and token: sshd, ftpd, rlogind, 
telnetd ... They still need to save the forwarded credential too.   
Web servers too, there you might want a token associated with a thread.
So what is the tradoff? NFSv4 will have similiar problems, can AFS
and NFSv4 use the same PAG? (DCE/DFS and AFS used the same PAG
on some systems.)

> 
> I note that on MacOS X tickets are stored in a MACH "security
> context" which acts a lot like a PAG.  Furthermore it's accessible
> inside the kernel.  Doesn't Windows have some similar in-memory
> storage mechanism?
> 
> Has anyone thought about how congruent PAGs and terminal sessions
> are?  I think X11 defined the latter, and Kerberos has tried to tie
> in to them rather than import the PAG concept.

Any authenticated file system will have the same problem, be it 
AFS, DFS, NFSv4... These was some discussion of PAGs on one of the 
Linux mailing lists. The question came of what are the credentials
for accessing the local filesystem or older NFS. I would say it was the
fact that the process was running under a UID. 


> 
> At 11:21 AM -0600 1/26/04, Douglas E. Engert wrote:
> >Rather then implementing kafs in MIT Kerberos, I would like to
> >suggest an alternative which has advantages to all parties.
> >
> >The OpenSSH sshd needs to do two things:
> >    (1) sets a PAG in the kernel,
> >    (2) obtains an AFS token storing it in the kernel.
> >
> >It can use the Kerberos credentials either obtained via GSSAPI
> >delegation, PAM or other kerberos login code in the sshd.
> >
> >The above two actions can be accomplished by a separate process,
> >which can be forked and execd by the sshd and passed the environment
> >which may have a KREB5CCNAME pointing at the Kerberos ticket cache
> >Other parameters such as the home directory could also be passed.
> >
> >
> >This would then allow simple code in OpenSSH that does not depend
> >on OpenAFS, Hiemdal or MIT code to fork/exec the process that does
> >all the work. This would be called by the process that would
> >eventially become the user's shell process and is run as the user.
> >
> >OpenSSH could be built on systems that may or may not have AFS
> >installed and run on a system with or without AFS.  The decision
> >is based on the existence of the executable and any options
> >in sshd_config.
> >
> >In its simplest form, all that is needed is:
> >
> >   system("/usr/ssh/libexec/aklog -setpag")
> >
> >This is a little over simplified as there should be a test if the
> >executable exists, processing of some return codes, making sure the
> >environment is set, setting some time limit. etc. But the point is
> >there is no compile dependence on OpenAFS, MIT or Hiemdal by the
> >OpenSSH sshd, and any failure of the process will not effect the sshd.
> >
> >
> >
> >We have been using something like this for years which issues a
> >syscall to set a PAG for the current process, then fork/exec ak5log.
> >Our current mode to OpenSSH in session.c is as  simple as:
> >
> >   krb5_afs_pag_env(NULL, env);
> >
> >It is currently built with the MIT Kerberos code for historic reasons,
> >but could be seperate as it has no real dependency on the MIT code.
> >
> >I would hope that the members of the OpenSSH community who use OpenAFS,
> >Hiemdal and/or MIT could agree on a simple command line interface that
> >would encourage the builders of OpenSSH to always have this enabled.
> >
> >--
> >
> >  Douglas E. Engert  <DEEngert at anl.gov>
> >  Argonne National Laboratory
> >  9700 South Cass Avenue
> >  Argonne, Illinois  60439
> >  (630) 252-5444
> 
> --
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu

-- 

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



From deengert at anl.gov  Tue Jan 27 07:39:29 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 26 Jan 2004 14:39:29 -0600
Subject: [OpenAFS-devel] OpenSSH, OpenAFS,
	Heimdal Kerberos and MITKerberos
References: <Pine.LNX.4.44.0401262036090.6863-100000@kiwi.caspur.it>
Message-ID: <40157B01.9332A80D@anl.gov>

Does your ssh_config file have:
GSSAPIDelegateCredentials yes
 
or you need to specify on the command line. -o  


Andrei Maslennikov wrote:
> 
> Hi Douglas, and thanks for your comment.
> 
> On Mon, 26 Jan 2004, Douglas E. Engert wrote:
> 
> >
> > 1) ssh to host A, login with K5 password (and obtain a PAG-based token)
> >
> > Was the ticket marked forwardable?  Can you set with Hiemdal in the
> > krb5.conf file a default that tickets should be forwardable?
> > What does klist -f show on host A?
> 
>   Yes, tickets are set to be forwardable in the [libdefaults] section:
> 
> <ing at alfa ~>klist -f
> Credentials cache: FILE:/tmp/krb5cc_k20844
>         Principal: ing at ING.UNIROMA1.IT
> 
>   Issued           Expires        Flags    Principal
> Jan 26 20:34:02  Jan 27 03:14:02  FI
> krbtgt/ING.UNIROMA1.IT at ING.UNIROMA1.IT
> Jan 26 20:34:02  Jan 27 03:14:02         afs at ING.UNIROMA1.IT
> Jan 26 20:34:31  Jan 27 03:14:02
> host/alfa.ing.uniroma1.it at ING.UNIROMA1.IT
> 
>    V4-ticket file: /tmp/tkt401
> klist: No ticket file (tf_util)
> 
> >
> >
> > 2) from host A, ssh to host B, login w/o pw (this time with GSSAPI)
> >
> > GSSAPI should have delegated a K5 credential, and set the KRB5CCNAME
> > on host B.
> 
>   This does not occur, however GSSAPI lets me in (without creds):
> ......
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue:
> publickey,gssapi,password,keyboard-interactive
> debug1: Next authentication method: gssapi
> debug1: Authentication succeeded (gssapi).  <<<<<<<<<<<<<<<<<<
> debug1: channel 0: new [client-session]
> debug1: Entering interactive session.
> debug1: Requesting X11 forwarding with authentication spoofing.
> debug1: Requesting authentication agent forwarding.
> Could not chdir to home directory /afs/ing/system/hq/ing: Permission
> denied
> 
> >
> > >   3) inside host B: no K5 creds forwarded from host A, no token.
> >
> > We can do the above
> 
>   ..That's what the "sshd -d" tells me:
> 
> .....
> debug1: userauth-request for user ing service ssh-connection method gssapi
> debug1: attempt 1 failures 1
> Postponed gssapi for ing from 151.100.85.253 port 44184 ssh2
> debug1: Got no client credentials
> Authorized to ing, krb5 principal ing at ING.UNIROMA1.IT (krb5_kuserok)
> Accepted gssapi for ing from 151.100.85.253 port 44184 ssh2  <<<<<<<<<<<
> Accepted gssapi for ing from 151.100.85.253 port 44184 ssh2
> .....
> .....
> debug1: session_input_channel_req: session 0 req shell
> debug1: temporarily_use_uid: 401/401 (e=401/401)
> debug1: No credentials stored   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> debug1: restore_uid: (unprivileged)
> ...
> 
>   Inside the host B: no credentials at all:
> 
> [ing at alfa /]$ /usr/heimdal/bin/klist
> klist: No ticket file: /tmp/krb5cc_401
> 
>    V4-ticket file: /tmp/tkt401
> klist: No ticket file (tf_util)
> 
>   THERE SHOULD BE SOMETHING ELSE....

-- 

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



From andrei at caspur.it  Tue Jan 27 07:59:45 2004
From: andrei at caspur.it (Andrei Maslennikov)
Date: Mon, 26 Jan 2004 21:59:45 +0100 (MET)
Subject: [OpenAFS-devel] OpenSSH, OpenAFS,
	Heimdal Kerberos and MITKerberos
In-Reply-To: <40157B01.9332A80D@anl.gov>
Message-ID: <Pine.LNX.4.44.0401262158080.7695-100000@kiwi.caspur.it>


On Mon, 26 Jan 2004, Douglas E. Engert wrote:

> Does your ssh_config file have:
> GSSAPIDelegateCredentials yes
>  

Douglas, tons of thanks! This worked.
Everything has now became smooth and clean.

Greetings - Andrei.





From jhutz at cmu.edu  Tue Jan 27 08:28:21 2004
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Mon, 26 Jan 2004 16:28:21 -0500
Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT
 Kerberos
In-Reply-To: <p05210604bc3b15e51eae@[137.78.212.225]>
References: <40154CAC.6B97BED5@anl.gov>
	<p05210604bc3b15e51eae@[137.78.212.225]>
Message-ID: <21590000.1075152501@mariner.pc.cs.cmu.edu>



On Monday, January 26, 2004 11:23:34 -0800 "Henry B. Hotz" 
<hotz at jpl.nasa.gov> wrote:

> Isn't the reason this keeps coming up that AFS client doesn't (can't?)
> behave like a normal Kerberos application and just get it's own service
> ticket when it needs one (based on an existing tgt)?  The real reason
> this doesn't happen is that tickets are stored in a file in /tmp, but
> it's a different set of file system code inside the kernel that would
> need to access it to request the service ticket.

No; it's not that simple.  Making the cache manager access ticket files 
would require first gaining a Kerberos dependency that we don't already 
have, and then importing lots of code into the kernel, much of which 
depends on network and filesystem interfaces that simply don't exist in 
kernel mode.

Worse, it would not solve the problem.  The trouble here is not that AFS 
tokens are stored in a kernel data structure instead of a file.  It's that 
they are indexed by a value which must be set on login, inherited from each 
process by its children, and must not be changeable by the user (to prevent 
token stealing).  OpenSSH loses not because you need special code to set 
tokens, and not even because you need special code to generate a new PAG -- 
those things can be done by a PAM module.  OpenSSH loses because the PAM 
session module gets called outside the inheritance chain of the user's 
shell, which means it can't set a PAG or anything else that is inherited 
across a fork (e.g. groups, environment variables, resource limits, etc etc 
etc).


> I note that on MacOS X tickets are stored in a MACH "security context"
> which acts a lot like a PAG.  Furthermore it's accessible inside the
> kernel.  Doesn't Windows have some similar in-memory storage mechanism?

Windows' own credentials are managed by a trusted component (the LSA), 
which keeps a credential cache associated with each login session.  This 
cache is read-only -- you can ask the LSA to obtain new tickets on your 
behalf, but you can't give it tickets to remember for you, and AFAIK you 
can't have more than one cache per login session.

Both Windows and MacOS X have mechanisms for managing a security context 
which is inherited between processes, cannot be "stolen", and is 
independent of the mechanisms used for terminal control and session 
management.  Other UNIX platforms lack such a mechanism; this is the 
purpose served by the PAG mechanism introduced by AFS.  What is key is the 
existence of such a mechanism, not whether credentials are stored in a file 
or a kernel data structure or some trusted process.


> Has anyone thought about how congruent PAGs and terminal sessions are?

They're not.  They have similar properties, but they are _not_ congruent. 
For example, if you run an X11 session with many xterms, each terminal 
(xterm) is a separate session, but shares the same PAG.  You want this, so 
when you type 'klog' in one window, the resulting tokens are available in 
all windows.  OTOH, if you run an AFS-aware su, the resulting subprocess 
will have a new PAG (you don't want it to share tokens with other windows), 
but it must be in the same session, so it will get a SIGHUP if the terminal 
is closed.

One serious mistake is trying to overload the same inherited classification 
mechanism to perform more than one unrelated purpose.  This is why SVR4 
separates the concept of "process group" and "session" -- process groups 
and the concept of the controlling terminal alone were not sufficient for 
the task.


> I
> think X11 defined the latter, and Kerberos has tried to tie in to them
> rather than import the PAG concept.

AFAIK, the process group concept was introduced in BSD UNIX prior to 
4.3BSD, and the session concept was introduced in SVR4.  Neither was 
introduced by X11, which has no concept of terminals and thus no need to 
manage them, or by xterm, which used the existing pseudo-tty mechanism.

Kerberos in most cases stores credential caches in files; the location of 
the ccache file is stored in the environment, which is another set of 
properties which is inherited between processes (but one which the kernel 
knows precious little about, and whose contents are completely alterable by 
the user and thus cannot be trusted).  On certain platforms, Kerberos has 
indeed made use of PAG-like mechanisms provided by the operating system.

-- 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 dean at av8.com  Tue Jan 27 09:17:46 2004
From: dean at av8.com (Dean Anderson)
Date: Mon, 26 Jan 2004 17:17:46 -0500 (EST)
Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT
 Kerberos
In-Reply-To: <21590000.1075152501@mariner.pc.cs.cmu.edu>
Message-ID: <Pine.LNX.4.44.0401261707090.5519-100000@localhost.localdomain>

On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:

> Worse, it would not solve the problem.  The trouble here is not that AFS 
> tokens are stored in a kernel data structure instead of a file.  It's that 
> they are indexed by a value which must be set on login, inherited from each 
> process by its children, and must not be changeable by the user (to prevent 
> token stealing).  OpenSSH loses not because you need special code to set 
> tokens, and not even because you need special code to generate a new PAG -- 
> those things can be done by a PAM module.  OpenSSH loses because the PAM 
> session module gets called outside the inheritance chain of the user's 
> shell, which means it can't set a PAG or anything else that is inherited 
> across a fork (e.g. groups, environment variables, resource limits, etc etc 
> etc).

Right. And there is an easy solution: Turn off Privsep.  A process that
creates new user sessions needs root privileges, and those privileges
cannot be given away prematurely to "improve security".  Privsep is just a
stupid idea for some programs.  Probably for most programs...

Privsep is not a solution of security problems caused by bad programs.  It 
is just throwing complication at a problem in the hopes that by making it 
more complicated, that security is improved.

While privsep can be turned off, and the AFS problems are solved when
privsep is turned off, it seems that many people don't know this.  I think
that it would help if a new distribution of openssh, etc were created
without privsep. As I said, I think this privsep business is a bad idea,
and I would just remove it from the code.

		--Dean



From djm at mindrot.org  Tue Jan 27 09:45:34 2004
From: djm at mindrot.org (Damien Miller)
Date: Tue, 27 Jan 2004 09:45:34 +1100
Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT
 Kerberos
In-Reply-To: <Pine.LNX.4.44.0401261707090.5519-100000@localhost.localdomain>
References: <Pine.LNX.4.44.0401261707090.5519-100000@localhost.localdomain>
Message-ID: <4015988E.1030706@mindrot.org>

Dean Anderson wrote:
> Right. And there is an easy solution: Turn off Privsep.  A process that
> creates new user sessions needs root privileges, and those privileges
> cannot be given away prematurely to "improve security".  Privsep is just a
> stupid idea for some programs.  Probably for most programs...

Privsep has avoided the last two real security problems found in
portable OpenSSH, and others before that. The security gain has
already been demonstrated.

-d



From jhutz at cmu.edu  Tue Jan 27 09:51:07 2004
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Mon, 26 Jan 2004 17:51:07 -0500
Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT
 Kerberos
In-Reply-To: <Pine.LNX.4.44.0401261707090.5519-100000@localhost.localdomain>
References: <Pine.LNX.4.44.0401261707090.5519-100000@localhost.localdomain>
Message-ID: <23870000.1075157467@mariner.pc.cs.cmu.edu>

On Monday, January 26, 2004 17:17:46 -0500 Dean Anderson <dean at av8.com> 
wrote:

> On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:
>
>> Worse, it would not solve the problem.  The trouble here is not that AFS
>> tokens are stored in a kernel data structure instead of a file.  It's
>> that  they are indexed by a value which must be set on login, inherited
>> from each  process by its children, and must not be changeable by the
>> user (to prevent  token stealing).  OpenSSH loses not because you need
>> special code to set  tokens, and not even because you need special code
>> to generate a new PAG --  those things can be done by a PAM module.
>> OpenSSH loses because the PAM  session module gets called outside the
>> inheritance chain of the user's  shell, which means it can't set a PAG
>> or anything else that is inherited  across a fork (e.g. groups,
>> environment variables, resource limits, etc etc  etc).
>
> Right. And there is an easy solution: Turn off Privsep.

Sadly, this doesn't make any difference.  OpenSSH 3.7.1 and later run PAM 
session modules in a subprocess unrelated to the eventual user shell, 
regardless of whether privsep is enabled.  AFAIK, in earlier versions, it 
works fine even with privsep, because while such things may be run in a 
subprocess, they are run in a subprocess that ends up being an ancestor of 
the user shell.

-- 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 dtucker at zip.com.au  Tue Jan 27 14:07:10 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 27 Jan 2004 14:07:10 +1100
Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT
 Kerberos
In-Reply-To: <23870000.1075157467@mariner.pc.cs.cmu.edu>
References: <Pine.LNX.4.44.0401261707090.5519-100000@localhost.localdomain>
	<23870000.1075157467@mariner.pc.cs.cmu.edu>
Message-ID: <4015D5DE.6030208@zip.com.au>

Jeffrey Hutzelman wrote:
> On Monday, January 26, 2004 17:17:46 -0500 Dean Anderson <dean at av8.com> 
> wrote:
> 
>> On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:
>>
>>> Worse, it would not solve the problem.  The trouble here is not that AFS
>>> tokens are stored in a kernel data structure instead of a file.  It's
>>> that  they are indexed by a value which must be set on login, inherited
>>> from each  process by its children, and must not be changeable by the
>>> user (to prevent  token stealing).  OpenSSH loses not because you need
>>> special code to set  tokens, and not even because you need special code
>>> to generate a new PAG --  those things can be done by a PAM module.
>>> OpenSSH loses because the PAM  session module gets called outside the
>>> inheritance chain of the user's  shell, which means it can't set a PAG
>>> or anything else that is inherited  across a fork (e.g. groups,
>>> environment variables, resource limits, etc etc  etc).
>>
>>
>> Right. And there is an easy solution: Turn off Privsep.
> 
> 
> Sadly, this doesn't make any difference.  OpenSSH 3.7.1 and later run 
> PAM session modules in a subprocess unrelated to the eventual user 
> shell, regardless of whether privsep is enabled.  AFAIK, in earlier 
> versions, it works fine even with privsep, because while such things may 
> be run in a subprocess, they are run in a subprocess that ends up being 
> an ancestor of the user shell.

You can try:

./configure --with-cflags=-DUSE_POSIX_THREADS --with-ldflags=-lpthread

(or whichever library contains threads on your platform) and the PAM 
authentication code will be run as a thread.

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 ahaupt at ifh.de  Tue Jan 27 18:20:23 2004
From: ahaupt at ifh.de (Andreas Haupt)
Date: Tue, 27 Jan 2004 08:20:23 +0100 (CET)
Subject: [OpenAFS-devel] OpenSSH, OpenAFS,
	Heimdal Kerberos and MITKerberos
In-Reply-To: <4015684C.7B5D1626@anl.gov>
References: <Pine.LNX.4.44.0401261903130.6265-100000@kiwi.caspur.it>
	<4015684C.7B5D1626@anl.gov>
Message-ID: <Pine.LNX.4.58.0401270808540.15028@fuchur.ifh.de>

On Mon, 26 Jan 2004, Douglas E. Engert wrote:
> Andrei Maslennikov wrote:
> >
> > We have implemented the strategy similar to the one that Douglas suggested
> > in his posting. In our case (Heimdal) we allow user to login using his/her
> > K5 password and then call Heimdal "afslog" inside session.c:
> >
> >         system("/usr/sshutils/sbin/afslog >/dev/null 2>&1");

On a PAM aware system this should not be needed. We use pam_krb5
(http://sourceforge.net/projects/pam-krb5/). It works with password
authentication and stores the K5/4 TGT and AFS token. When doing GSSAPI
authentication it automatically converts the forwarded credentials to a K4
TGT and obtains the AFS token.

The only trick we had to do was to link OpenSSH against libpthread which
is no configure option and to set KRB5CCNAME to FILE:/tmp/krb5cc_*.
Normally the ssh just stores it to /tmp/krb5cc_*.

> > What we were yet unable to achieve is the further K5 credentials
> > forwarding in case of login via the K5 password. What happens is the
> > following:
> >
> >   1) ssh to host A, login with K5 password (and obtain a PAG-based token)
>
> Was the ticket marked forwardable?  Can you set with Hiemdal in the
> krb5.conf file a default that tickets should be forwardable?

Yes, in krb5.conf simply set

[libdefaults]
forwardable = true

Greetings
Andreas

-- 
| Andreas Haupt                      | E-Mail:  andreas.haupt at desy.de
|  DESY Zeuthen                      | WWW:     http://www.desy.de/~ahaupt
|  Platanenallee 6                   | Phone:   +49/33762/7-7369
|  D-15738 Zeuthen                   | Fax:     +49/33762/7-7216



From kumaresh_ind at gmx.net  Tue Jan 27 22:23:21 2004
From: kumaresh_ind at gmx.net (Kumaresh)
Date: Tue, 27 Jan 2004 16:53:21 +0530
Subject: OpenSSH - Connection problem when LoginGraceTime exceeds time
Message-ID: <048501c3e4c7$fdd78290$230110ac@kurco>

Hello,

This problem is regarding the configuration directive called
'LoginGraceTime'.

Problem Description:
Tests were done with OpenSSH -3.6.1p2 and 3.7.1p2 on HP-UX.

sshd is started with LoginGraceTime as 1 minute.Three windows were used to
initiate the ssh client.After launching two clients wait for a sometime
without issuing the password so it exceeds the grace period for login.when
syslog.log is examined the connection seems to be closed.But when the
command

#netstat -an|grep 22

is given the connection seems to be still established giving provision for
the third client to connect to the server. As this behaviour continues the
number of users whom can be connected get reduced because of these
connections still being established. (ie  MaxStartups - set as 3).

In syslog.log:

Jan 27 03:49:58 kanishka sshd[7056]: fatal: Timeout before authentication
for 127.0.0.1
Jan 27 03:49:59 kanishka sshd[7075]: invalid module type: configuration

Example of netstat -an|grep 22:
tcp    0     0  127.0.0.1.22           127.0.0.1.58651 ESTABLISHED
tcp    0     0  127.0.0.1.22           127.0.0.1.58647 ESTABLISHED
tcp    0     0  127.0.0.1.58651        127.0.0.1.22  ESTABLISHED
tcp    0     0  127.0.0.1.58647        127.0.0.1.22 ESTABLISHED
tcp    0     0  *.22                   *.*                     LISTEN
tcp    0     0  127.0.0.1.58649        127.0.0.1.22 ESTABLISHED
tcp    0     0  127.0.0.1.22           127.0.0.1.58649 ESTABLISHED

So, further connections always give, "ssh_exchange_identification:
Connection closed by remote host" and closed.

Source code of OpenSSH shows that SSH uses alarm/SIGALRM to implement the
LoginGraceTime. When using priviledged separation, the priviledged process
receives the alarm signal and exits when the time expires. However, the
non-priveledged sshd process remains connected until the client sends some
data or the client disconnects.  Without priviledged separation, the sshd
process receives the alarm signal and exits. No other processes remain.

Any help to fix this problem?

Advance Thanks,
Kumaresh.



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.561 / Virus Database: 353 - Release Date: 1/13/2004



From hartmans at mit.edu  Tue Jan 27 23:27:49 2004
From: hartmans at mit.edu (Sam Hartman)
Date: Tue, 27 Jan 2004 07:27:49 -0500
Subject: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos
In-Reply-To: <40154CAC.6B97BED5@anl.gov> (Douglas E. Engert's message of
	"Mon, 26 Jan 2004 11:21:48 -0600")
References: <40154CAC.6B97BED5@anl.gov>
Message-ID: <tslad491sqi.fsf@mit.edu>

I'd like to second Doug's idea as a potential solution for OpenSSH at
least.



From achim.gsell at psi.ch  Wed Jan 28 01:12:28 2004
From: achim.gsell at psi.ch (Achim Gsell)
Date: Tue, 27 Jan 2004 15:12:28 +0100
Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS,
	Heimdal Kerberos and MIT Kerberos
In-Reply-To: <23870000.1075157467@mariner.pc.cs.cmu.edu>
References: <Pine.LNX.4.44.0401261707090.5519-100000@localhost.localdomain>
	<23870000.1075157467@mariner.pc.cs.cmu.edu>
Message-ID: <200401271512.28644.achim.gsell@psi.ch>

On Monday 26 January 2004 23:51, Jeffrey Hutzelman wrote:
> On Monday, January 26, 2004 17:17:46 -0500 Dean Anderson
> <dean at av8.com>
>
> wrote:
> > On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:
> >> Worse, it would not solve the problem.  The trouble here is not
> >> that AFS tokens are stored in a kernel data structure instead of a
> >> file.  It's that  they are indexed by a value which must be set on
> >> login, inherited from each  process by its children, and must not
> >> be changeable by the user (to prevent  token stealing).  OpenSSH
> >> loses not because you need special code to set  tokens, and not
> >> even because you need special code to generate a new PAG --  those
> >> things can be done by a PAM module. OpenSSH loses because the PAM 
> >> session module gets called outside the inheritance chain of the
> >> user's  shell, which means it can't set a PAG or anything else
> >> that is inherited  across a fork (e.g. groups, environment
> >> variables, resource limits, etc etc  etc).
> >
> > Right. And there is an easy solution: Turn off Privsep.
>
> Sadly, this doesn't make any difference.  OpenSSH 3.7.1 and later run
> PAM session modules in a subprocess unrelated to the eventual user
> shell, regardless of whether privsep is enabled.  AFAIK, in earlier
> versions, it works fine even with privsep, because while such things
> may be run in a subprocess, they are run in a subprocess that ends up
> being an ancestor of the user shell.

If you have POSIX threads make sure that USE_POSIX_THREADS is defined 
while compiling auth-pam.c. This work's fine with Linux 2.4 and OpenSSH 
3.7.1pl2.

Achim
-- 
Scientific Computing
Paul Scherrer Institut
CH-5232 Villigen



From jfh at cise.ufl.edu  Wed Jan 28 12:45:33 2004
From: jfh at cise.ufl.edu (James F.Hranicky)
Date: Tue, 27 Jan 2004 20:45:33 -0500
Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS,
	Heimdal Kerberos and MIT Kerberos
In-Reply-To: <Pine.LNX.4.44.0401271855050.25136-100000@localhost.localdomain>
References: <23870000.1075157467@mariner.pc.cs.cmu.edu>
	<Pine.LNX.4.44.0401271855050.25136-100000@localhost.localdomain>
Message-ID: <20040127204533.45130510.jfh@cise.ufl.edu>

On Tue, 27 Jan 2004 18:58:36 -0500 (EST)
Dean Anderson <dean at av8.com> wrote:

> Nope. OpenSSH 3.7.1p1 works for me with privsep turned off. When privsep
> is turned off, there is no subprocess.  3.7.1p1 has some additional
> breakage, in that if your ssh client doesn't support 'interactive/pam' as
> a method, then it won't send anything to pam. This means that only openssh
> clients work with pam on openssh servers. E.g., putty won't work.

The latest version of putty (0.53b) does have keyboard int support, and I
have it working fine with PAM/krb5 . 

Jim



From jason at devrandom.org  Wed Jan 28 12:48:53 2004
From: jason at devrandom.org (Jason McCormick)
Date: Tue, 27 Jan 2004 20:48:53 -0500
Subject: Release testing
In-Reply-To: <4010B266.7010303@zip.com.au>
References: <1074720798.17510.36.camel@sakura.mindrot.org>
	<200401230023.02047.jason@devrandom.org>
	<4010B266.7010303@zip.com.au>
Message-ID: <200401272048.53128.jason@devrandom.org>

> kafs.h (and libkafs) is provided by Heimdal, but not MIT Kerberos
> (which is what Redhat use).  What you have found is a minor bug in
> session.c.
>
> The #include <kafs.h> should have been inside an #ifdef AFS.  (Or
> possibly USE_AFS, it's still under discussion).  Should be fixed in
> the next day or two.

This looks good on RedHat and Fedora now.  Thanks!

-- 
Jason McCormick 
jason at devrandom.org
GPG Key ID: 96D6CF63



From dtucker at zip.com.au  Wed Jan 28 15:20:09 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 28 Jan 2004 15:20:09 +1100
Subject: OpenSSH - Connection problem when LoginGraceTime exceeds time
In-Reply-To: <048501c3e4c7$fdd78290$230110ac@kurco>
References: <048501c3e4c7$fdd78290$230110ac@kurco>
Message-ID: <40173879.2030303@zip.com.au>

Kumaresh wrote:
> This problem is regarding the configuration directive called
> 'LoginGraceTime'.
[snip]
> Source code of OpenSSH shows that SSH uses alarm/SIGALRM to implement the
> LoginGraceTime. When using priviledged separation, the priviledged process
> receives the alarm signal and exits when the time expires. However, the
> non-priveledged sshd process remains connected until the client sends some
> data or the client disconnects.  Without priviledged separation, the sshd
> process receives the alarm signal and exits. No other processes remain.
> 
> Any help to fix this problem?

Please try this patch.

-- 
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-logingrace.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040128/f9f9a8c9/attachment.ksh 

From kumaresh_ind at gmx.net  Wed Jan 28 20:10:27 2004
From: kumaresh_ind at gmx.net (Kumaresh)
Date: Wed, 28 Jan 2004 14:40:27 +0530
Subject: OpenSSH - Connection problem when LoginGraceTime exceeds time
References: <048501c3e4c7$fdd78290$230110ac@kurco>
	<40173879.2030303@zip.com.au>
Message-ID: <03b801c3e57e$985170e0$230110ac@kurco>

Hello Darren,

Thanks a lot. The patch fixed the problem. We have tested this on HP-UX.

Will this change be applied in the the future releases?

Regards,
Kumaresh.
www.visolve.com


----- Original Message -----
From: "Darren Tucker" <dtucker at zip.com.au>
To: "Kumaresh" <kumaresh_ind at gmx.net>
Cc: "OpenSSH Devel List" <openssh-unix-dev at mindrot.org>
Sent: Wednesday, January 28, 2004 9:50 AM
Subject: Re: OpenSSH - Connection problem when LoginGraceTime exceeds time


> Kumaresh wrote:
> > This problem is regarding the configuration directive called
> > 'LoginGraceTime'.
> [snip]
> > Source code of OpenSSH shows that SSH uses alarm/SIGALRM to implement
the
> > LoginGraceTime. When using priviledged separation, the priviledged
process
> > receives the alarm signal and exits when the time expires. However, the
> > non-priveledged sshd process remains connected until the client sends
some
> > data or the client disconnects.  Without priviledged separation, the
sshd
> > process receives the alarm signal and exits. No other processes remain.
> >
> > Any help to fix this problem?
>
> Please try this patch.
>
> --
> 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.



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.561 / Virus Database: 353 - Release Date: 1/13/2004



From dtucker at zip.com.au  Wed Jan 28 23:06:29 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 28 Jan 2004 23:06:29 +1100
Subject: OpenSSH - Connection problem when LoginGraceTime exceeds time
In-Reply-To: <03b801c3e57e$985170e0$230110ac@kurco>
References: <048501c3e4c7$fdd78290$230110ac@kurco>	<40173879.2030303@zip.com.au>
	<03b801c3e57e$985170e0$230110ac@kurco>
Message-ID: <4017A5C5.1090207@zip.com.au>

Kumaresh wrote:
> Thanks a lot. The patch fixed the problem. We have tested this on HP-UX.

There are a couple of problems with the first patch, please try this one 
instead.

> Will this change be applied in the the future releases?

Maybe, it needs some more study.

-- 
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: openbsd-sshd-logingrace2.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040128/513ff2a0/attachment.ksh 

From kumaresh_ind at gmx.net  Wed Jan 28 23:10:49 2004
From: kumaresh_ind at gmx.net (Kumaresh)
Date: Wed, 28 Jan 2004 17:40:49 +0530
Subject: OpenSSH - Connection problem when LoginGraceTime exceeds time
References: <048501c3e4c7$fdd78290$230110ac@kurco>	<40173879.2030303@zip.com.au>
	<03b801c3e57e$985170e0$230110ac@kurco>
	<4017A5C5.1090207@zip.com.au>
Message-ID: <065901c3e597$c96de230$230110ac@kurco>

Hi Darren,

> Kumaresh wrote:
> > Thanks a lot. The patch fixed the problem. We have tested this on HP-UX.
>
> There are a couple of problems with the first patch, please try this one
> instead.

For my understanding, may I please know what are the problems with the first
patch?

Regards,
Kumaresh


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.561 / Virus Database: 353 - Release Date: 1/13/2004



From dtucker at zip.com.au  Wed Jan 28 23:22:43 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 28 Jan 2004 23:22:43 +1100
Subject: OpenSSH - Connection problem when LoginGraceTime exceeds time
In-Reply-To: <065901c3e597$c96de230$230110ac@kurco>
References: <048501c3e4c7$fdd78290$230110ac@kurco>	<40173879.2030303@zip.com.au>
	<03b801c3e57e$985170e0$230110ac@kurco>
	<4017A5C5.1090207@zip.com.au>
	<065901c3e597$c96de230$230110ac@kurco>
Message-ID: <4017A993.4080009@zip.com.au>

Kumaresh wrote:
> For my understanding, may I please know what are the problems with the first
> patch?

This is embarassing, but anyway: in the case where the client connects 
but does not exchange identification (eg if you connect to it with 
telnet and send no data) and the SIGALRM timer expires, the signal 
handler will attempt to dereference pmonitor which will not have been 
initialized at that point.  It will most likely segfault.

-- 
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 drwachd at sandia.gov  Sat Jan 31 03:41:26 2004
From: drwachd at sandia.gov (Wachdorf, Daniel R)
Date: Fri, 30 Jan 2004 09:41:26 -0700
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
Message-ID: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1122@es10snlnt.sandia.gov>

Darren,

I have been doing some testing and I noticed a problem with the server
implementation of GSSAPI authentication within the open ssh snapshot
(openssh-SNAP-20040124.tar.gz).  

The draft (draft-ietf-secsh-gsskeyex-07) states:

   Since the user authentication process by its nature authenticates
   only the client, the setting of the mutual_req_flag is not needed for
   this process.  This flag SHOULD be set to "false".

The client sets this to true, not really a problem.  Our modified f-secure
client does the same thing.  However, if GSS_C_MUTUAL_FLAG is not set, then
the open ssh server rejects the connection.  The following line of code
(from gss-serv.c):

        /* Now, if we're complete and we have the right flags, then
         * we flag the user as also having been authenticated
         */

        if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) &&
            (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == GSS_S_COMPLETE))
{
                if (ssh_gssapi_getclient(ctx, &gssapi_client))
                        fatal("Couldn't convert client name");
        }


This requires the client to set GSS_C_MUTUAL, which conflicts with the
draft. 

-dan

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: Wednesday, January 21, 2004 6:46 PM
To: kerberos at mit.edu; krbdev at mit.edu; heimdal-discuss at sics.se
Cc: OpenSSH Devel List
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes

(I hope this message is appropriate for these lists.  If not, please 
tell me and I won't do it again.)

Hi All.
	There will be a new release of OpenSSH in a couple of weeks.  This 
release contains Kerberos and GSSAPI related changes that we would like 
to get some feedback about (and hopefully address any issues with) 
before the release.

	I encourage anyone with an interest in Kerberos/GSSAPI support in 
OpenSSH to try a snapshot [1] and send feedback.

Changes in OpenBSD's OpenSSH and -Portable:
    - markus at cvs.openbsd.org 2003/11/17 11:06:07
      replace "gssapi" with "gssapi-with-mic"; from Simon Wilkinson;
      test + ok jakob.
    - jakob at cvs.openbsd.org 2003/12/23 16:12:10
      implement KerberosGetAFSToken server option. ok markus@, beck@
    - markus at cvs.openbsd.org 2003/11/02 11:01:03
      remove support for SSH_BUG_GSSAPI_BER; simon at sxw.org.uk

Changes in -Portable only
  - (dtucker) Only enable KerberosGetAFSToken if Heimdal's libkafs
    is found.  with jakob@	
  - (dtucker) [configure.ac] Use krb5-config where available for
    Kerberos/GSSAPI detection, libs and includes.  ok djm@

Additionally, as a side effect of the last change, the test for libkafs 
is now independant of the Heimdal test, so should a version that works 
with MIT Kerberos be available it will be used.

All but the last are in the 20040122 snapshot, and the last will be in 
20040123 and up.

Please follow-up to the OpenSSH devel list (cc: the Kerberos lists if 
you consider it appropriate).

[1] ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ or 
one of the mirrors listed at http://openssh.com/portable.html#mirrors

-- 
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.

_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev



From deengert at anl.gov  Sat Jan 31 04:47:54 2004
From: deengert at anl.gov (Douglas E. Engert)
Date: Fri, 30 Jan 2004 11:47:54 -0600
Subject: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos
References: <40154CAC.6B97BED5@anl.gov>
Message-ID: <401A98CA.D22037B7@anl.gov>

On Monday, I proposed a alternative method of obtaining and AFS PAG and
token when used with OpenSSH or any other deamon.  

I now have a test working using openssh-snap-20040122. 

This relies on an external program referred to as get-afs-token
which accepts at least two parameters:

  -setpag         - Use the AFS Kernel mods to set the AFS PAG
                    of the parent process. 
  -path <directory> - Get a AFS token for the cell containing this 
                      directory.

The get-afs-token program would be provided by the OpenAFS or Kerberos
communities, and could be a link to aklog, afslog or gssklog. I have 
tried this with  my version of aklog, called ak5log, and with gssklog.
The aklog already accepted these parameters and afslog only need a minor
addition as did the gssklog. 

Here is the sample code used with OpenSSH. Note that the get_afs_token
routine does not require any AFS or Kerberos header files. 


--- ./,session.c        Tue Jan 20 18:00:46 2004
+++ ./session.c Fri Jan 30 11:38:02 2004
@@ -66,6 +66,10 @@
 #include "ssh-gss.h"
 #endif
 
+#ifdef ANL_AFS_PAG
+int get_afs_token(char * pgm, char ** env, char *homedir, int setpag);
+#endif
+
 /* func */
 
 Session *session_new(void);
@@ -1419,6 +1423,14 @@
         */
        environ = env;
 
+#ifdef ANL_AFS_PAG
+       /* Get PAG and AFS token using external program and KRB5CCNAME */
+       if (options.kerberos_get_afs_token) {
+               debug("Getting AFS token");
+               get_afs_token(NULL, env, pw->pw_dir, 1);
+       }
+#endif
+
 #if defined(HEIMDAL) && defined(AFS)
        /*
         * At this point, we check to see if AFS is active and if we have
@@ -2216,3 +2228,119 @@
        if (!use_privsep || mm_is_monitor())
                session_destroy_all(session_pty_cleanup2);
 }
+
+#ifdef ANL_AFS_PAG
+/* gafstoken.c 
+
+       A generic routine to get an AFS token by calling
+       an external program. 
+
+       This routine is generic in that it does not depend on 
+       any specific implementation of AFS, or Kerberos.
+       This will allow a deamon to be configured, compiled
+       and linked without any AFS or Kerberos dependencies
+       and can thus avoid conflicts between these packages.
+       The resulting deamon executable can be run on a system with 
+       or without AFS.  
+       
+       Examples of external programs that could be called
+       are aklog, afslog, gssklog, klog, ak5log or even a script
+       to call one of these. 
+
+       The external program is expected to support 
+       (or ignore) the  -setpag and -path <homedir>
+
+       Parameters to gafstoken: 
+
+               char * external_program  - path to the executable
+                       this would be set by configure, or defaulted
+                       in some way. If NULL a built in location is used.
+                                                       
+               char **env - Environment to run under. This
+                       should include any environment variables needed
+                       by the external program such as KRB5CCNAME
+                       or X509_USER_PROXY These would have been set
+                       by GSSAPI or PAM.  If NULL, the current environment
+                       is used. 
+
+               char * homedir - A file location, if in AFS the 
+                       external program will attempt to get a token
+                       for the cell containing it.  If NULL attempt
+                       to get a token for the default cell of the client.
+
+               int setpag - Used to tell external program to get 
+                       an AFS PAG. The caller's process must be a process
+                       that will be an ancestor of the user's process.
+
+       Returns:
+               -1 - some system error, see errno;
+                0 - the external program if present was called and 
+                        MAY have worked. 
+
+       The caller should not need to test the return code, and should
+       continue with or without the AFS token or PAG. 
+
+       */
+
+#ifndef _PATH_AFS_EXTERNAL_PROGRAM
+#define _PATH_AFS_EXTERNAL_PROGRAM "/usr/libexec/get-afs-token"
+#endif 
+       
+int
+get_afs_token(char * external_program,
+                         char ** env,
+                         char * homedir,
+                         int setpag)
+{
+       pid_t pid;
+       int status;
+       struct stat stx;
+       char * ppath = _PATH_AFS_EXTERNAL_PROGRAM;
+       char * args[5];  /* arg0, -setpag, -path, homedir, NULL */
+       int  argi = 0; 
+       
+       if (external_program)
+               ppath = external_program;
+
+       /* test if external program exists */
+       if (stat(ppath, &stx))
+               return 0; /* does not exist, skip getting PAG and token */
+
+       args[argi++] = "getafstoken";
+       if (setpag)
+               args[argi++] = "-setpag";
+       if (homedir) {
+               args[argi++] = "-path";
+               args[argi++] = homedir;
+       }
+       args[argi] = NULL;
+
+       if ((pid = fork()) < 0) {
+               return -1; /* see errno */
+       }
+
+       if (pid == 0) { 
+               /* Don't want any output confusing the deamon */
+               close(1);
+               open("/dev/null",O_WRONLY);
+               close(2);
+               open("/dev/null",O_WRONLY);
+
+               if (env)
+                       execve(ppath, args, env);
+               else
+                       execv(ppath, args);
+               exit(127); /* exec failed! Should never get here */
+       }
+               
+       while (waitpid(pid, &status, 0) < 0) {
+               if (errno != EINTR)
+               break;
+       }
+
+       /* we could set a return code based on status,
+        * be we want to go on with or without a token */
+
+       return 0;
+}
+#endif
--- ./,Makefile.in      Fri Nov 21 06:48:55 2003
+++ ./Makefile.in       Thu Jan 29 11:22:40 2004
@@ -22,6 +22,7 @@
 VPATH=@srcdir@
 SSH_PROGRAM=@bindir@/ssh
 ASKPASS_PROGRAM=$(libexecdir)/ssh-askpass
+AFS_EXTERNAL_PROGRAM=$(libexecdir)/get-afs-token
 SFTP_SERVER=$(libexecdir)/sftp-server
 SSH_KEYSIGN=$(libexecdir)/ssh-keysign
 RAND_HELPER=$(libexecdir)/ssh-rand-helper
@@ -32,6 +33,7 @@
 PATHS= -DSSHDIR=\"$(sysconfdir)\" \
        -D_PATH_SSH_PROGRAM=\"$(SSH_PROGRAM)\" \
        -D_PATH_SSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" \
+       -D_PATH_AFS_EXTERNAL_PROGRAM=\"$(AFS_EXTERNAL_PROGRAM)\" \
        -D_PATH_SFTP_SERVER=\"$(SFTP_SERVER)\" \
        -D_PATH_SSH_KEY_SIGN=\"$(SSH_KEYSIGN)\" \
        -D_PATH_SSH_PIDDIR=\"$(piddir)\" \


                 


"Douglas E. Engert" wrote:
> 
> Rather then implementing kafs in MIT Kerberos, I would like to
> suggest an alternative which has advantages to all parties.
> 
> The OpenSSH sshd needs to do two things:
>    (1) sets a PAG in the kernel,
>    (2) obtains an AFS token storing it in the kernel.
> 
> It can use the Kerberos credentials either obtained via GSSAPI
> delegation, PAM or other kerberos login code in the sshd.
> 
> The above two actions can be accomplished by a separate process,
> which can be forked and execd by the sshd and passed the environment
> which may have a KREB5CCNAME pointing at the Kerberos ticket cache
> Other parameters such as the home directory could also be passed.
> 
> This would then allow simple code in OpenSSH that does not depend
> on OpenAFS, Hiemdal or MIT code to fork/exec the process that does
> all the work. This would be called by the process that would
> eventially become the user's shell process and is run as the user.
> 
> OpenSSH could be built on systems that may or may not have AFS
> installed and run on a system with or without AFS.  The decision
> is based on the existence of the executable and any options
> in sshd_config.
> 
> In its simplest form, all that is needed is:
> 
>   system("/usr/ssh/libexec/aklog -setpag")
> 
> This is a little over simplified as there should be a test if the
> executable exists, processing of some return codes, making sure the
> environment is set, setting some time limit. etc. But the point is
> there is no compile dependence on OpenAFS, MIT or Hiemdal by the
> OpenSSH sshd, and any failure of the process will not effect the sshd.
> 
> We have been using something like this for years which issues a
> syscall to set a PAG for the current process, then fork/exec ak5log.
> Our current mode to OpenSSH in session.c is as  simple as:
> 
>   krb5_afs_pag_env(NULL, env);
> 
> It is currently built with the MIT Kerberos code for historic reasons,
> but could be seperate as it has no real dependency on the MIT code.
> 
> I would hope that the members of the OpenSSH community who use OpenAFS,
> Hiemdal and/or MIT could agree on a simple command line interface that
> would encourage the builders of OpenSSH to always have this enabled.
> 
> --
> 
>  Douglas E. Engert  <DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444

-- 

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



From jhutz at cmu.edu  Sat Jan 31 08:43:51 2004
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 30 Jan 2004 16:43:51 -0500
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1122@es10snlnt.sandia.gov>
References: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1122@es10snlnt.sandia.gov>
Message-ID: <1448470000.1075499031@minbar.fac.cs.cmu.edu>

On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R" 
<drwachd at sandia.gov> wrote:

> The client sets this to true, not really a problem.  Our modified f-secure
> client does the same thing.  However, if GSS_C_MUTUAL_FLAG is not set,
> then the open ssh server rejects the connection.  The following line of
> code (from gss-serv.c):
>
>         /* Now, if we're complete and we have the right flags, then
>          * we flag the user as also having been authenticated
>          */
>
>         if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) &&
>             (*flags & GSS_C_INTEG_FLAG))) && (ctx->major ==
> GSS_S_COMPLETE)) {
>                 if (ssh_gssapi_getclient(ctx, &gssapi_client))
>                         fatal("Couldn't convert client name");
>         }
>
>
> This requires the client to set GSS_C_MUTUAL, which conflicts with the
> draft.

Indeed, it does.  The server is not supposed to check the state of the 
mutual_flag of a context accepted for gssapi-with-mic user auth.  I know 
the draft is not entirely clear on this point; would it help if there were 
text indicating the server MUST NOT do this?


Also, I've not actually read this code, other than what's quoted above, but 
I hope that's not the only place that flags are checked.  I'm assuming the 
openssh code actually implements -07 and 'gssapi-with-mic'.  In the new 
method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC or 
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether 
GSS_C_INTEG_FLAG is set.  The server is REQUIRED to fail the authentication 
if the client sends the wrong message; this means the value of 
GSS_C_INTEG_FLAG must be tested.


-- 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 drwachd at sandia.gov  Sat Jan 31 08:52:12 2004
From: drwachd at sandia.gov (Wachdorf, Daniel R)
Date: Fri, 30 Jan 2004 14:52:12 -0700
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
Message-ID: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F112F@es10snlnt.sandia.gov>

No, there is another place in the code where GSS_C_INTEG_FLAG is checked.
It then either verifies the MIC or processes an EXCHANGE_COMPLETE message.

-dan


-----Original Message-----
From: Jeffrey Hutzelman [mailto:jhutz at cmu.edu] 
Sent: Friday, January 30, 2004 2:44 PM
To: Wachdorf, Daniel R; 'Darren Tucker'; kerberos at mit.edu; krbdev at mit.edu;
heimdal-discuss at sics.se
Cc: OpenSSH Devel List; ietf-ssh at NetBSD.org
Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes

On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R" 
<drwachd at sandia.gov> wrote:

> The client sets this to true, not really a problem.  Our modified f-secure
> client does the same thing.  However, if GSS_C_MUTUAL_FLAG is not set,
> then the open ssh server rejects the connection.  The following line of
> code (from gss-serv.c):
>
>         /* Now, if we're complete and we have the right flags, then
>          * we flag the user as also having been authenticated
>          */
>
>         if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) &&
>             (*flags & GSS_C_INTEG_FLAG))) && (ctx->major ==
> GSS_S_COMPLETE)) {
>                 if (ssh_gssapi_getclient(ctx, &gssapi_client))
>                         fatal("Couldn't convert client name");
>         }
>
>
> This requires the client to set GSS_C_MUTUAL, which conflicts with the
> draft.

Indeed, it does.  The server is not supposed to check the state of the 
mutual_flag of a context accepted for gssapi-with-mic user auth.  I know 
the draft is not entirely clear on this point; would it help if there were 
text indicating the server MUST NOT do this?


Also, I've not actually read this code, other than what's quoted above, but 
I hope that's not the only place that flags are checked.  I'm assuming the 
openssh code actually implements -07 and 'gssapi-with-mic'.  In the new 
method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC or 
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether 
GSS_C_INTEG_FLAG is set.  The server is REQUIRED to fail the authentication 
if the client sends the wrong message; this means the value of 
GSS_C_INTEG_FLAG must be tested.


-- 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 drwachd at sandia.gov  Sat Jan 31 08:52:12 2004
From: drwachd at sandia.gov (Wachdorf, Daniel R)
Date: Fri, 30 Jan 2004 14:52:12 -0700
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
Message-ID: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F112F@es10snlnt.sandia.gov>

No, there is another place in the code where GSS_C_INTEG_FLAG is checked.
It then either verifies the MIC or processes an EXCHANGE_COMPLETE message.

-dan


-----Original Message-----
From: Jeffrey Hutzelman [mailto:jhutz at cmu.edu] 
Sent: Friday, January 30, 2004 2:44 PM
To: Wachdorf, Daniel R; 'Darren Tucker'; kerberos at mit.edu; krbdev at mit.edu;
heimdal-discuss at sics.se
Cc: OpenSSH Devel List; ietf-ssh at NetBSD.org
Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes

On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R" 
<drwachd at sandia.gov> wrote:

> The client sets this to true, not really a problem.  Our modified f-secure
> client does the same thing.  However, if GSS_C_MUTUAL_FLAG is not set,
> then the open ssh server rejects the connection.  The following line of
> code (from gss-serv.c):
>
>         /* Now, if we're complete and we have the right flags, then
>          * we flag the user as also having been authenticated
>          */
>
>         if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) &&
>             (*flags & GSS_C_INTEG_FLAG))) && (ctx->major ==
> GSS_S_COMPLETE)) {
>                 if (ssh_gssapi_getclient(ctx, &gssapi_client))
>                         fatal("Couldn't convert client name");
>         }
>
>
> This requires the client to set GSS_C_MUTUAL, which conflicts with the
> draft.

Indeed, it does.  The server is not supposed to check the state of the 
mutual_flag of a context accepted for gssapi-with-mic user auth.  I know 
the draft is not entirely clear on this point; would it help if there were 
text indicating the server MUST NOT do this?


Also, I've not actually read this code, other than what's quoted above, but 
I hope that's not the only place that flags are checked.  I'm assuming the 
openssh code actually implements -07 and 'gssapi-with-mic'.  In the new 
method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC or 
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether 
GSS_C_INTEG_FLAG is set.  The server is REQUIRED to fail the authentication 
if the client sends the wrong message; this means the value of 
GSS_C_INTEG_FLAG must be tested.


-- 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 mouring at etoh.eviladmin.org  Sat Jan 31 09:46:41 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Fri, 30 Jan 2004 16:46:41 -0600 (CST)
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F112F@es10snlnt.sandia.gov>
Message-ID: <Pine.BSO.4.44.0401301643190.27267-100000@etoh.eviladmin.org>


I need someone to look at this and get back to us ASAP in regards to if
this will break GSSAPI-WITH-MIC.

If this does break something.  GET US A PATCH NOW or live with broke
GSSAPI-WITH-MIC support for 6 months.

If it is just a "clean up" thing that can be handled after 3.9 release.
Fine, but I don't want to listen to 6 months of whining if it is. <weak
smile>

- Ben



On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote:

> No, there is another place in the code where GSS_C_INTEG_FLAG is checked.
> It then either verifies the MIC or processes an EXCHANGE_COMPLETE message.
>
> -dan
>
>
> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:jhutz at cmu.edu]
> Sent: Friday, January 30, 2004 2:44 PM
> To: Wachdorf, Daniel R; 'Darren Tucker'; kerberos at mit.edu; krbdev at mit.edu;
> heimdal-discuss at sics.se
> Cc: OpenSSH Devel List; ietf-ssh at NetBSD.org
> Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes
>
> On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R"
> <drwachd at sandia.gov> wrote:
>
> > The client sets this to true, not really a problem.  Our modified f-secure
> > client does the same thing.  However, if GSS_C_MUTUAL_FLAG is not set,
> > then the open ssh server rejects the connection.  The following line of
> > code (from gss-serv.c):
> >
> >         /* Now, if we're complete and we have the right flags, then
> >          * we flag the user as also having been authenticated
> >          */
> >
> >         if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) &&
> >             (*flags & GSS_C_INTEG_FLAG))) && (ctx->major ==
> > GSS_S_COMPLETE)) {
> >                 if (ssh_gssapi_getclient(ctx, &gssapi_client))
> >                         fatal("Couldn't convert client name");
> >         }
> >
> >
> > This requires the client to set GSS_C_MUTUAL, which conflicts with the
> > draft.
>
> Indeed, it does.  The server is not supposed to check the state of the
> mutual_flag of a context accepted for gssapi-with-mic user auth.  I know
> the draft is not entirely clear on this point; would it help if there were
> text indicating the server MUST NOT do this?
>
>
> Also, I've not actually read this code, other than what's quoted above, but
> I hope that's not the only place that flags are checked.  I'm assuming the
> openssh code actually implements -07 and 'gssapi-with-mic'.  In the new
> method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC or
> SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether
> GSS_C_INTEG_FLAG is set.  The server is REQUIRED to fail the authentication
> if the client sends the wrong message; this means the value of
> GSS_C_INTEG_FLAG must be tested.
>
>
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From Nicolas.Williams at sun.com  Sat Jan 31 09:48:25 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 30 Jan 2004 16:48:25 -0600
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <1448470000.1075499031@minbar.fac.cs.cmu.edu>
References: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1122@es10snlnt.sandia.gov>
	<1448470000.1075499031@minbar.fac.cs.cmu.edu>
Message-ID: <20040130224824.GL18744@binky.central.sun.com>

On Fri, Jan 30, 2004 at 04:43:51PM -0500, Jeffrey Hutzelman wrote:
> Indeed, it does.  The server is not supposed to check the state of the 
> mutual_flag of a context accepted for gssapi-with-mic user auth.  I know 
> the draft is not entirely clear on this point; would it help if there were 
> text indicating the server MUST NOT do this?

For completeness' sake, yes.  The client (SHOULD NOT | MAY) set
GSS_C_MUTUAL for gssapi-with-mic, but the server MUST ignore the state
of the GSS_C_MUTUAL flag for gssapi-with-mic.

> Also, I've not actually read this code, other than what's quoted above, but 
> I hope that's not the only place that flags are checked.  I'm assuming the 
> openssh code actually implements -07 and 'gssapi-with-mic'.  In the new 
> method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC or 
> SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether 
> GSS_C_INTEG_FLAG is set.  The server is REQUIRED to fail the authentication 
> if the client sends the wrong message; this means the value of 
> GSS_C_INTEG_FLAG must be tested.

Right.  Further, the text should say that the server MAY always reject
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE since there's no generic
interface for determining whether a context doesn't have the GSS_C_INTEG
flag set because the client left it off or because the mechanism doesn't
support GSS_C_INTEG.

Nico
-- 



From hartmans at mit.edu  Sat Jan 31 09:54:27 2004
From: hartmans at mit.edu (Sam Hartman)
Date: Fri, 30 Jan 2004 17:54:27 -0500
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <Pine.BSO.4.44.0401301643190.27267-100000@etoh.eviladmin.org> (Ben
	Lindstrom's message of "Fri, 30 Jan 2004 16:46:41 -0600 (CST)")
References: <Pine.BSO.4.44.0401301643190.27267-100000@etoh.eviladmin.org>
Message-ID: <tslu12d6o9o.fsf@konishi-polis.mit.edu>

>>>>> "Ben" == Ben Lindstrom <mouring at etoh.eviladmin.org> writes:

    Ben> I need someone to look at this and get back to us ASAP in
    Ben> regards to if this will break GSSAPI-WITH-MIC.

It may make some conforming clients break but does not create a
security problem.

Some client implementers may choose to introduce an extra round trip
(which is what setting the mutual required flag does) in order to
interoperate with OpenSsh if the code is released in the current
state.

Really, that's probably OK if it happens.

I'd class this as a minor conformance issue, but not a huge deal.



From drwachd at sandia.gov  Sat Jan 31 09:53:21 2004
From: drwachd at sandia.gov (Wachdorf, Daniel R)
Date: Fri, 30 Jan 2004 15:53:21 -0700
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
Message-ID: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1132@es10snlnt.sandia.gov>

Ben,

This will break GSSAPI_WITH_MIC if clients don't do GSS_C_MUTUAL as outlined
by the standard.  Ie - follow the standard and it wont work.  So I guess
that means it's broke.

I can get a patch to you, what version of the source should I patch, a
nightly snapshot?

-dan

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org] 
Sent: Friday, January 30, 2004 3:47 PM
To: Wachdorf, Daniel R
Cc: 'Jeffrey Hutzelman'; kerberos at mit.edu; krbdev at mit.edu;
heimdal-discuss at sics.se; ietf-ssh at NetBSD.org; OpenSSH Devel List
Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes


I need someone to look at this and get back to us ASAP in regards to if
this will break GSSAPI-WITH-MIC.

If this does break something.  GET US A PATCH NOW or live with broke
GSSAPI-WITH-MIC support for 6 months.

If it is just a "clean up" thing that can be handled after 3.9 release.
Fine, but I don't want to listen to 6 months of whining if it is. <weak
smile>

- Ben



On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote:

> No, there is another place in the code where GSS_C_INTEG_FLAG is checked.
> It then either verifies the MIC or processes an EXCHANGE_COMPLETE message.
>
> -dan
>
>
> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:jhutz at cmu.edu]
> Sent: Friday, January 30, 2004 2:44 PM
> To: Wachdorf, Daniel R; 'Darren Tucker'; kerberos at mit.edu; krbdev at mit.edu;
> heimdal-discuss at sics.se
> Cc: OpenSSH Devel List; ietf-ssh at NetBSD.org
> Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes
>
> On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R"
> <drwachd at sandia.gov> wrote:
>
> > The client sets this to true, not really a problem.  Our modified
f-secure
> > client does the same thing.  However, if GSS_C_MUTUAL_FLAG is not set,
> > then the open ssh server rejects the connection.  The following line of
> > code (from gss-serv.c):
> >
> >         /* Now, if we're complete and we have the right flags, then
> >          * we flag the user as also having been authenticated
> >          */
> >
> >         if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) &&
> >             (*flags & GSS_C_INTEG_FLAG))) && (ctx->major ==
> > GSS_S_COMPLETE)) {
> >                 if (ssh_gssapi_getclient(ctx, &gssapi_client))
> >                         fatal("Couldn't convert client name");
> >         }
> >
> >
> > This requires the client to set GSS_C_MUTUAL, which conflicts with the
> > draft.
>
> Indeed, it does.  The server is not supposed to check the state of the
> mutual_flag of a context accepted for gssapi-with-mic user auth.  I know
> the draft is not entirely clear on this point; would it help if there were
> text indicating the server MUST NOT do this?
>
>
> Also, I've not actually read this code, other than what's quoted above,
but
> I hope that's not the only place that flags are checked.  I'm assuming the
> openssh code actually implements -07 and 'gssapi-with-mic'.  In the new
> method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC
or
> SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether
> GSS_C_INTEG_FLAG is set.  The server is REQUIRED to fail the
authentication
> if the client sends the wrong message; this means the value of
> GSS_C_INTEG_FLAG must be tested.
>
>
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>




From mouring at etoh.eviladmin.org  Sat Jan 31 10:11:12 2004
From: mouring at etoh.eviladmin.org (Ben Lindstrom)
Date: Fri, 30 Jan 2004 17:11:12 -0600 (CST)
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1133@es10snlnt.sandia.gov>
Message-ID: <Pine.BSO.4.44.0401301706300.27267-100000@etoh.eviladmin.org>



On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote:

> Well,
>
> It could be a problem. If someone has implemented a client and doesn't do
								^^^^^^^^^^
> mutual auth (as the standard says they should), they could be broken.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This right here is the key to me.  If someone is not following the RFC.
Then I say let them complaint to their vendor.

Again I ask.. As the code stands are *WE* in RFC compliance?  If not we
need it fixed.

As for what to base it off of.  Pick a recent snapshot.  Not as if the
GSSAPI-WITH-MIC code has drasticly changed in the last few days.

- Ben



From drwachd at sandia.gov  Sat Jan 31 10:25:34 2004
From: drwachd at sandia.gov (Wachdorf, Daniel R)
Date: Fri, 30 Jan 2004 16:25:34 -0700
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
Message-ID: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1134@es10snlnt.sandia.gov>

No.

1 - RFC states GSS_C_MUTUAL_FLAG SHOULD not be used.  The current open ssh
server requires that it be used.

2 - RFC also allow for gss mechanisms that don't have GSSAPI integrity.
Servers can then choose to disallow it. As far as I can tell from the code,
any client which doesn't (or cant) have the GSS_C_INTEG_FLAG set cannot
connect.  I can't test this because Kerberos-gssapi uses integrity.

-dan

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org] 
Sent: Friday, January 30, 2004 4:11 PM
To: Wachdorf, Daniel R
Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; krbdev at mit.edu; ietf-ssh at NetBSD.org;
kerberos at mit.edu; heimdal-discuss at sics.se; OpenSSH Devel List
Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes



On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote:

> Well,
>
> It could be a problem. If someone has implemented a client and doesn't do
								^^^^^^^^^^
> mutual auth (as the standard says they should), they could be broken.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This right here is the key to me.  If someone is not following the RFC.
Then I say let them complaint to their vendor.

Again I ask.. As the code stands are *WE* in RFC compliance?  If not we
need it fixed.

As for what to base it off of.  Pick a recent snapshot.  Not as if the
GSSAPI-WITH-MIC code has drasticly changed in the last few days.

- Ben




From drwachd at sandia.gov  Sat Jan 31 10:25:34 2004
From: drwachd at sandia.gov (Wachdorf, Daniel R)
Date: Fri, 30 Jan 2004 16:25:34 -0700
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
Message-ID: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1134@es10snlnt.sandia.gov>

No.

1 - RFC states GSS_C_MUTUAL_FLAG SHOULD not be used.  The current open ssh
server requires that it be used.

2 - RFC also allow for gss mechanisms that don't have GSSAPI integrity.
Servers can then choose to disallow it. As far as I can tell from the code,
any client which doesn't (or cant) have the GSS_C_INTEG_FLAG set cannot
connect.  I can't test this because Kerberos-gssapi uses integrity.

-dan

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org] 
Sent: Friday, January 30, 2004 4:11 PM
To: Wachdorf, Daniel R
Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; krbdev at mit.edu; ietf-ssh at NetBSD.org;
kerberos at mit.edu; heimdal-discuss at sics.se; OpenSSH Devel List
Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes



On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote:

> Well,
>
> It could be a problem. If someone has implemented a client and doesn't do
								^^^^^^^^^^
> mutual auth (as the standard says they should), they could be broken.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This right here is the key to me.  If someone is not following the RFC.
Then I say let them complaint to their vendor.

Again I ask.. As the code stands are *WE* in RFC compliance?  If not we
need it fixed.

As for what to base it off of.  Pick a recent snapshot.  Not as if the
GSSAPI-WITH-MIC code has drasticly changed in the last few days.

- Ben




From drwachd at sandia.gov  Sat Jan 31 09:59:22 2004
From: drwachd at sandia.gov (Wachdorf, Daniel R)
Date: Fri, 30 Jan 2004 15:59:22 -0700
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
Message-ID: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1133@es10snlnt.sandia.gov>

Well,

It could be a problem. If someone has implemented a client and doesn't do
mutual auth (as the standard says they should), they could be broken.  

The fix is easy.  Just remove:

(*flags & GSS_C_MUTUAL_FLAG) &&
            (*flags & GSS_C_INTEG_FLAG))

from the if statement.  

I have already tested this out, it works fine.  I will make a diff if
someone tells me what to base if off of.

-----Original Message-----
From: Sam Hartman [mailto:hartmans at mit.edu] 
Sent: Friday, January 30, 2004 3:54 PM
To: Ben Lindstrom
Cc: Wachdorf, Daniel R; 'Jeffrey Hutzelman'; krbdev at mit.edu;
ietf-ssh at NetBSD.org; kerberos at mit.edu; heimdal-discuss at sics.se; OpenSSH
Devel List
Subject: Re: Pending OpenSSH release: contains Kerberos/GSSAPI changes

>>>>> "Ben" == Ben Lindstrom <mouring at etoh.eviladmin.org> writes:

    Ben> I need someone to look at this and get back to us ASAP in
    Ben> regards to if this will break GSSAPI-WITH-MIC.

It may make some conforming clients break but does not create a
security problem.

Some client implementers may choose to introduce an extra round trip
(which is what setting the mutual required flag does) in order to
interoperate with OpenSsh if the code is released in the current
state.

Really, that's probably OK if it happens.

I'd class this as a minor conformance issue, but not a huge deal.




From drwachd at sandia.gov  Sat Jan 31 10:57:29 2004
From: drwachd at sandia.gov (Wachdorf, Daniel R)
Date: Fri, 30 Jan 2004 16:57:29 -0700
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
Message-ID: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1136@es10snlnt.sandia.gov>

Here is a patch.  it was based of the 2004-12-24 snapshot (I had trouble
getting todays to compile).

*** ../openssh/gss-serv.c       Mon Nov 17 04:18:22 2003
--- gss-serv.c  Fri Jan 30 16:35:24 2004
***************
*** 117,124 ****
         * we flag the user as also having been authenticated
         */

!       if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) &&
!           (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == GSS_S_COMPLETE))
{
                if (ssh_gssapi_getclient(ctx, &gssapi_client))
                        fatal("Couldn't convert client name");
        }
--- 117,123 ----
         * we flag the user as also having been authenticated
         */

!       if(ctx->major == GSS_S_COMPLETE) {
                if (ssh_gssapi_getclient(ctx, &gssapi_client))
                        fatal("Couldn't convert client name");
        }

-dan

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org] 
Sent: Friday, January 30, 2004 4:11 PM
To: Wachdorf, Daniel R
Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; krbdev at mit.edu; ietf-ssh at NetBSD.org;
kerberos at mit.edu; heimdal-discuss at sics.se; OpenSSH Devel List
Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes



On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote:

> Well,
>
> It could be a problem. If someone has implemented a client and doesn't do
								^^^^^^^^^^
> mutual auth (as the standard says they should), they could be broken.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This right here is the key to me.  If someone is not following the RFC.
Then I say let them complaint to their vendor.

Again I ask.. As the code stands are *WE* in RFC compliance?  If not we
need it fixed.

As for what to base it off of.  Pick a recent snapshot.  Not as if the
GSSAPI-WITH-MIC code has drasticly changed in the last few days.

- Ben


-------------- next part --------------
A non-text attachment was scrubbed...
Name: gss-patch-snap-20040124.diff
Type: application/octet-stream
Size: 647 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040130/222717f7/attachment.obj 

From simon at sxw.org.uk  Sat Jan 31 11:42:32 2004
From: simon at sxw.org.uk (Simon Wilkinson)
Date: Sat, 31 Jan 2004 00:42:32 +0000
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1136@es10snlnt.sandia.gov>
References: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1136@es10snlnt.sandia.gov>
Message-ID: <401AF9F8.2090806@sxw.org.uk>

Daniel,

My personal belief is that its too late in this release cycle to make 
this change. As the author of the GSSAPI code in OpenSSH, I completely 
accept your comments - we're not (currently) RFC compliant. However, I'm 
aware of a number of vendors who have successfully performed interop 
testing against the current code base. Given the extremely short 
timelines to release, I'd rather delay a change of this nature until we 
have more time to evaluate and test it.

Cheers,

Simon.





From dtucker at zip.com.au  Sat Jan 31 11:58:09 2004
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 31 Jan 2004 11:58:09 +1100
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1136@es10snlnt.sandia.gov>
References: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1136@es10snlnt.sandia.gov>
Message-ID: <401AFDA1.50807@zip.com.au>

Wachdorf, Daniel R wrote:
> (I had trouble getting todays [snapshot] to compile).

We are currently aware of 2 issues that will prevent building with 
OpenSSL <0.9.7, which we're currently working on.  If you have one of 
those and the build problem was in cipher*.c, that's probably it.  If 
not, we would appreciate a bug report containing the error.

-- 
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  Sat Jan 31 13:57:42 2004
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 30 Jan 2004 21:57:42 -0500
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1134@es10snlnt.sandia.gov>
References: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1134@es10snlnt.sandia.gov>
Message-ID: <1478260000.1075517862@minbar.fac.cs.cmu.edu>

On Friday, January 30, 2004 16:25:34 -0700 "Wachdorf, Daniel R" 
<drwachd at sandia.gov> wrote:

> No.
>
> 1 - RFC states GSS_C_MUTUAL_FLAG SHOULD not be used.  The current open ssh
> server requires that it be used.
>
> 2 - RFC also allow for gss mechanisms that don't have GSSAPI integrity.
> Servers can then choose to disallow it. As far as I can tell from the
> code, any client which doesn't (or cant) have the GSS_C_INTEG_FLAG set
> cannot connect.  I can't test this because Kerberos-gssapi uses integrity.
>
> -dan
>
> -----Original Message-----
> From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> Sent: Friday, January 30, 2004 4:11 PM
> To: Wachdorf, Daniel R
> Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; krbdev at mit.edu;
> ietf-ssh at NetBSD.org; kerberos at mit.edu; heimdal-discuss at sics.se; OpenSSH
> Devel List
> Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes
>
>
>
> On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote:
>
>> Well,
>>
>> It could be a problem. If someone has implemented a client and doesn't do
> 								^^^^^^^^^^
>> mutual auth (as the standard says they should), they could be broken.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This right here is the key to me.  If someone is not following the RFC.
> Then I say let them complaint to their vendor.
>
> Again I ask.. As the code stands are *WE* in RFC compliance?  If not we
> need it fixed.
>
> As for what to base it off of.  Pick a recent snapshot.  Not as if the
> GSSAPI-WITH-MIC code has drasticly changed in the last few days.

For some reason, I'm not seeing Ben's messages.  Perhaps the mail path from 
him to me is just really long.

In any case...

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.

-- 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 jhutz at cmu.edu  Sat Jan 31 14:08:42 2004
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 30 Jan 2004 22:08:42 -0500
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes
In-Reply-To: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1134@es10snlnt.sandia.gov>
References: <AC89BDA1E3CCBC42B9CA5B50FE7934D3066F1134@es10snlnt.sandia.gov>
Message-ID: <1478790000.1075518522@minbar.fac.cs.cmu.edu>

(Just to pick nits...  Note that this is not yet an RFC.  Hopefully that 
will change sometime in the next few months, but at the moment it's still 
an internet-draft.)


On Friday, January 30, 2004 16:25:34 -0700 "Wachdorf, Daniel R" 
<drwachd at sandia.gov> wrote:

> 2 - RFC also allow for gss mechanisms that don't have GSSAPI integrity.
> Servers can then choose to disallow it. As far as I can tell from the
> code, any client which doesn't (or cant) have the GSS_C_INTEG_FLAG set
> cannot connect.  I can't test this because Kerberos-gssapi uses integrity.

This is legitimate behaviour.  See the last paragraph of section 3.6, at 
the top of page 15:

   It is a site policy descision for the server whether or not to permit
   authentication using GSSAPI mechanisms and/or contexts which do not
   support per-message integrity protection.  The server MAY fail the
   otherwise valid gssapi-with-mic authentication if per-message
   integrity protection is not supported.

Note the use of the word "MAY", which means "do whatever you want".  We 
actually expect that most server operators will want to accept 
gssapi-with-mic only in cases where integrity is supported,  There was a 
fairly length discussion of this issue on the ietf-ssh list last October or 
so.

-- 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 muir at rootsweb.com  Wed Jan 28 10:17:31 2004
From: muir at rootsweb.com (muir at rootsweb.com)
Date: Tue, 27 Jan 2004 23:17:31 +0000
Subject: I still love you  NuPnt
In-Reply-To: <KGCJ10H8L0H0A5H4@mindrot.org>
References: <KGCJ10H8L0H0A5H4@mindrot.org>
Message-ID: <L9H4IH7DC0G0A6I6@rootsweb.com>

Error 551: We are sorry your UTF-8 encoding is not supported by the server, so the text was automatically zipped and attached to this message.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: message.zip
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040127/3103fe59/attachment.ksh 

From dean at av8.com  Wed Jan 28 10:54:40 2004
From: dean at av8.com (Dean Anderson)
Date: Tue, 27 Jan 2004 18:54:40 -0500 (EST)
Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT
 Kerberos
In-Reply-To: <4015988E.1030706@mindrot.org>
Message-ID: <Pine.LNX.4.44.0401271849460.25136-100000@localhost.localdomain>

Really?  Is there any links to what was avoided?  I'd like to look at
these in detail before I concede that anything of values has been
demonstrated.  I've heard these claims before, but I could not find any 
substantiating details---the claims are dubious at best.

		--Dean

On Tue, 27 Jan 2004, Damien Miller wrote:

> Dean Anderson wrote:
> > Right. And there is an easy solution: Turn off Privsep.  A process that
> > creates new user sessions needs root privileges, and those privileges
> > cannot be given away prematurely to "improve security".  Privsep is just a
> > stupid idea for some programs.  Probably for most programs...
> 
> Privsep has avoided the last two real security problems found in
> portable OpenSSH, and others before that. The security gain has
> already been demonstrated.
> 
> -d
> 



From dean at av8.com  Wed Jan 28 10:58:36 2004
From: dean at av8.com (Dean Anderson)
Date: Tue, 27 Jan 2004 18:58:36 -0500 (EST)
Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT
 Kerberos
In-Reply-To: <23870000.1075157467@mariner.pc.cs.cmu.edu>
Message-ID: <Pine.LNX.4.44.0401271855050.25136-100000@localhost.localdomain>

On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:

> On Monday, January 26, 2004 17:17:46 -0500 Dean Anderson <dean at av8.com> 
> wrote:
> 
> > On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:
> >
> >> Worse, it would not solve the problem.  The trouble here is not that AFS
> >> tokens are stored in a kernel data structure instead of a file.  It's
> >> that  they are indexed by a value which must be set on login, inherited
> >> from each  process by its children, and must not be changeable by the
> >> user (to prevent  token stealing).  OpenSSH loses not because you need
> >> special code to set  tokens, and not even because you need special code
> >> to generate a new PAG --  those things can be done by a PAM module.
> >> OpenSSH loses because the PAM  session module gets called outside the
> >> inheritance chain of the user's  shell, which means it can't set a PAG
> >> or anything else that is inherited  across a fork (e.g. groups,
> >> environment variables, resource limits, etc etc  etc).
> >
> > Right. And there is an easy solution: Turn off Privsep.
> 
> Sadly, this doesn't make any difference.  OpenSSH 3.7.1 and later run PAM 
> session modules in a subprocess unrelated to the eventual user shell, 

Nope. OpenSSH 3.7.1p1 works for me with privsep turned off. When privsep
is turned off, there is no subprocess.  3.7.1p1 has some additional
breakage, in that if your ssh client doesn't support 'interactive/pam' as
a method, then it won't send anything to pam. This means that only openssh
clients work with pam on openssh servers. E.g., putty won't work.

I will probably release a derivative version of openssh that supports pam,
and doesn't have privsep.

		--Dean

> regardless of whether privsep is enabled.  AFAIK, in earlier versions, it 
> works fine even with privsep, because while such things may be run in a 
> subprocess, they are run in a subprocess that ends up being an ancestor of 
> the user shell.
> 
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA
> 
>