From miklos at szeredi.hu  Tue Dec  4 21:03:05 2007
From: miklos at szeredi.hu (Miklos Szeredi)
Date: Tue, 04 Dec 2007 11:03:05 +0100
Subject: [sshfs] sshfs mounted applications fail with "error loading
	shared libraries"
In-Reply-To: <9fa207310712031529r7276b2f9uf75568e9844b968d@mail.gmail.com>
	(vasanth.asokan@gmail.com)
References: <89acfbb60711241324m6572cadcqd0f7166b95d43644@mail.gmail.com>
	<E1IwdgV-0007e8-OH@dorka.pomaz.szeredi.hu>
	<9fa207310712021709h5d711d56j5fccfada1756b80e@mail.gmail.com>
	<E1IzBCy-0003gE-TJ@dorka.pomaz.szeredi.hu>
	<9fa207310712031529r7276b2f9uf75568e9844b968d@mail.gmail.com>
Message-ID: <E1IzUcL-0006CK-4P@dorka.pomaz.szeredi.hu>

> On Dec 3, 2007 5:19 AM, Miklos Szeredi <miklos at szeredi.hu> wrote:
> > > Yes it is weird. I hope you can help me with this problem as sshfs is
> > > so much simpler than nfs.
> >
> > Can you please do one more thing: start up sshfs normally, then on the
> > server do a strace of the sftp-server process:
> >
> >  strace -o /tmp/strace.log -p `pidof sftp-server`
> 
> Attached the sftp-server log.

Thanks.  I think I can see the explanation.  Here's the failure:

   read(3, "\0\0\0H\3\0\0\3\347\0\0\0003/mnt/exports/tools/"..., 16384) = 140
   open("/mnt/exports/tools/ISE9.2i/bin/lin64/libXst_Core.so", O_RDONLY) = 105
   close(105)                              = 0
   select(5, [3], [4], NULL, NULL)         = 1 (out [4])
   write(4, "\0\0\0\30e\0\0\3\347\0\0\0\4\0\0\0\7Failure\0\0\0\0", 28) = 28

The file handle is 105, which suggests, that there's some limit around
100 open files.  Looking at the sftp-server source confirms this:

   Handle  handles[100];

So, unfortunately it seems sftp-server can only handle 100 open files
at a time.

It's easy enough to fix, if you are willing to recompile the
sftp-server binary.

Miklos

From vasanth.asokan at gmail.com  Thu Dec  6 11:24:47 2007
From: vasanth.asokan at gmail.com (Vasanth Asokan)
Date: Wed, 5 Dec 2007 16:24:47 -0800
Subject: [sshfs] sshfs mounted applications fail with "error loading
	shared libraries"
In-Reply-To: <E1IzUcL-0006CK-4P@dorka.pomaz.szeredi.hu>
References: <89acfbb60711241324m6572cadcqd0f7166b95d43644@mail.gmail.com>
	<E1IwdgV-0007e8-OH@dorka.pomaz.szeredi.hu>
	<9fa207310712021709h5d711d56j5fccfada1756b80e@mail.gmail.com>
	<E1IzBCy-0003gE-TJ@dorka.pomaz.szeredi.hu>
	<9fa207310712031529r7276b2f9uf75568e9844b968d@mail.gmail.com>
	<E1IzUcL-0006CK-4P@dorka.pomaz.szeredi.hu>
Message-ID: <9fa207310712051624w4ba195fcrbe9e08369fe35550@mail.gmail.com>

On Dec 4, 2007 2:03 AM, Miklos Szeredi <miklos at szeredi.hu> wrote:
>
> > On Dec 3, 2007 5:19 AM, Miklos Szeredi <miklos at szeredi.hu> wrote:
> > > > Yes it is weird. I hope you can help me with this problem as sshfs is
> > > > so much simpler than nfs.
> > >
> > > Can you please do one more thing: start up sshfs normally, then on the
> > > server do a strace of the sftp-server process:
> > >
> > >  strace -o /tmp/strace.log -p `pidof sftp-server`
> >
> > Attached the sftp-server log.
>
> Thanks.  I think I can see the explanation.  Here's the failure:
>
>    read(3, "\0\0\0H\3\0\0\3\347\0\0\0003/mnt/exports/tools/"..., 16384) = 140
>    open("/mnt/exports/tools/ISE9.2i/bin/lin64/libXst_Core.so", O_RDONLY) = 105
>    close(105)                              = 0
>    select(5, [3], [4], NULL, NULL)         = 1 (out [4])
>    write(4, "\0\0\0\30e\0\0\3\347\0\0\0\4\0\0\0\7Failure\0\0\0\0", 28) = 28
>
> The file handle is 105, which suggests, that there's some limit around
> 100 open files.  Looking at the sftp-server source confirms this:
>
>    Handle  handles[100];
>
> So, unfortunately it seems sftp-server can only handle 100 open files
> at a time.
>
> It's easy enough to fix, if you are willing to recompile the
> sftp-server binary.
>

Thanks Miklos. I guess arbitrarily increasing the number of handles is
not a good long term fix. It is hard to guesstimate how many clients
can be supported through a single sshfs mounted file system if there
is a fundamental file handle limit in sftp-server. Making it 1000 is
going to fail somewhere else down the line. Is that correct?

p.s,

I am recompiling sftp-server with 1000 handles to verify that at-least
I can get one client working.

From miklos at szeredi.hu  Fri Dec  7 08:48:20 2007
From: miklos at szeredi.hu (Miklos Szeredi)
Date: Thu, 06 Dec 2007 22:48:20 +0100
Subject: [sshfs] sshfs mounted applications fail with "error loading
	shared libraries"
In-Reply-To: <9fa207310712051624w4ba195fcrbe9e08369fe35550@mail.gmail.com>
	(vasanth.asokan@gmail.com)
References: <89acfbb60711241324m6572cadcqd0f7166b95d43644@mail.gmail.com>
	<E1IwdgV-0007e8-OH@dorka.pomaz.szeredi.hu>
	<9fa207310712021709h5d711d56j5fccfada1756b80e@mail.gmail.com>
	<E1IzBCy-0003gE-TJ@dorka.pomaz.szeredi.hu>
	<9fa207310712031529r7276b2f9uf75568e9844b968d@mail.gmail.com>
	<E1IzUcL-0006CK-4P@dorka.pomaz.szeredi.hu>
	<9fa207310712051624w4ba195fcrbe9e08369fe35550@mail.gmail.com>
Message-ID: <E1J0OZw-0000A9-Nl@dorka.pomaz.szeredi.hu>

> > It's easy enough to fix, if you are willing to recompile the
> > sftp-server binary.
> >
> 
> Thanks Miklos. I guess arbitrarily increasing the number of handles is
> not a good long term fix. It is hard to guesstimate how many clients
> can be supported through a single sshfs mounted file system if there
> is a fundamental file handle limit in sftp-server. Making it 1000 is
> going to fail somewhere else down the line. Is that correct?

That depends on how long these files are kept open.  But in theory
yes, that could happen.

Ideally sftp-server should allocate the space for handles dynamically,
so a hardcoded limit wouldn't be needed.  There are still various
limits on the number open files, but those can easily be adjusted by
the sysadmin.

Miklos

From guyverdh at hotmail.com  Fri Dec  7 10:26:14 2007
From: guyverdh at hotmail.com (Larry Becke)
Date: Thu, 6 Dec 2007 17:26:14 -0600
Subject: scp -t - revisited.....
Message-ID: <BAY139-W20AE63E86D9E862A832A22C96F0@phx.gbl>


Okay - We went around and around on the idea that adding an option to restrict scp to only allow files to be copied to a certain directory (or below) based on a different startup param.
 
I was told to use all sorts of different options, parameters, methods, etc...   All because no one wanted to modify the scp code, for whatever reasoning.
 
I'm sitting here laughing right now, seriously laughing, because the request was un-necessary.  scp already has that functionality built into it, whether it was intentional or not.
 
Here's the deal.
 
we set up a key on the client side, and the systems admin places the public component of the key into the users authorized_keys file with the command attribute set.
 
command="/usr/local/bin/scp -t /data/work/test" ssh-dss AAAAB3keycodefollows......
 
Then when the client issues the command
 
scp -i test_key /path/to/filename user at remotehost:
 
It copies the to the remote host into the directory specified in the command= option.
 
Now, at first glance, you're probably thinking  - wth is he talking about?  so what?
 
We had been using this for a while, and within the last few days had the first user attempt to rename a file in transit.
 
scp -i test_key /path/to/filename user at remotehost:filename.0001
 
The only problem was, that the file was always copied with the original filename.
 
I dug into it, not even thinking about the unorthadox approach I had taken to placing the users files into a specific directory, until all attempts at reproducing the problem had failed.  Once I used the same key structure and command= approach, the *rename problem* showed up.
 
I then decided to test a few other vectors - lke placing a directory name, or directory shift into the remote filename.
 
scp -i test_key/path/to/filename user at remotehost:../
or
scp -i test_key/path/to/filename user at remotehost:subdir/
 
Again, the file was copied over into the directory specified in the command= section, and nowhere else.
 
This leads me to believe that using the scp -t /some/path/to/a/directory  command= in the authorized_keys file causes scp to forget/ignore everything after the remote hostname.
 
This gives us almost exactly what we were looking for (actually, it's overkill, but I'm okay with that), and no changes were required.
 
Like I said, I'm sitting here laughing right now, mostly because it was a lot of wasted effort on all sides to argue (or discuss with pointed statements) over something that already existed, even if it wasn't known or documented.
 
 
 
(Wonders if this will be considered a bug to be fixed or quashed as it wasn't an intended *feature* of scp)....   I hope not...
 
Thanks again,
 
LB
 
 
_________________________________________________________________
Share life as it happens with the new Windows Live.Download today it's FREE!
http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007

From djm at mindrot.org  Fri Dec  7 10:58:56 2007
From: djm at mindrot.org (Damien Miller)
Date: Fri, 7 Dec 2007 10:58:56 +1100 (EST)
Subject: [sshfs] sshfs mounted applications fail with "error loading
	shared libraries"
In-Reply-To: <E1J0OZw-0000A9-Nl@dorka.pomaz.szeredi.hu>
References: <89acfbb60711241324m6572cadcqd0f7166b95d43644@mail.gmail.com>
	<E1IwdgV-0007e8-OH@dorka.pomaz.szeredi.hu>
	<9fa207310712021709h5d711d56j5fccfada1756b80e@mail.gmail.com>
	<E1IzBCy-0003gE-TJ@dorka.pomaz.szeredi.hu>
	<9fa207310712031529r7276b2f9uf75568e9844b968d@mail.gmail.com>
	<E1IzUcL-0006CK-4P@dorka.pomaz.szeredi.hu>
	<9fa207310712051624w4ba195fcrbe9e08369fe35550@mail.gmail.com>
	<E1J0OZw-0000A9-Nl@dorka.pomaz.szeredi.hu>
Message-ID: <alpine.BSO.0.99999.0712071057520.27644@fuyu.mindrot.org>

On Thu, 6 Dec 2007, Miklos Szeredi wrote:

> That depends on how long these files are kept open.  But in theory
> yes, that could happen.
> 
> Ideally sftp-server should allocate the space for handles dynamically,
> so a hardcoded limit wouldn't be needed.  There are still various
> limits on the number open files, but those can easily be adjusted by
> the sysadmin.

Yes, sftp-server should dynamically allocate its handles up to the
point where the system starts refusing to allocate file descriptors.

Anyone want to make a patch?

-d

From guyverdh at hotmail.com  Fri Dec  7 11:00:11 2007
From: guyverdh at hotmail.com (Larry Becke)
Date: Thu, 6 Dec 2007 18:00:11 -0600
Subject: scp -t - revisited.....
Message-ID: <BAY139-W21FA887C8CE2234C47892EC9680@phx.gbl>


Oh- it also makes the scp send only.
 
ie - you cannot copy a file from the remote host, to the local host.
 
_________________________________________________________________
Put your friends on the big screen with Windows Vista? + Windows Live?.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007

From stuge-openssh-unix-dev at cdy.org  Fri Dec  7 12:02:50 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Fri, 7 Dec 2007 02:02:50 +0100
Subject: scp -t - revisited.....
In-Reply-To: <BAY139-W20AE63E86D9E862A832A22C96F0@phx.gbl>
References: <BAY139-W20AE63E86D9E862A832A22C96F0@phx.gbl>
Message-ID: <20071207010250.1791.qmail@cdy.org>

On Thu, Dec 06, 2007 at 05:26:14PM -0600, Larry Becke wrote:
> This leads me to believe that using the scp -t
> /some/path/to/a/directory  command= in the authorized_keys file
> causes scp to forget/ignore everything after the remote hostname.

There is one more step between the remote scp (run with -t) and the
"remote filename" as specified in the local shell: The local scp.


> This gives us almost exactly what we were looking for

I think that depends on the local scp program.

What happens if you (within the scp protocol, not in the shell)
specify e.g. a new directory ../../../../../../../tmp/breakout ?

I would assume that /tmp/breakout is created.

If your local scp program is trusted then you're all set. But if that
was the case why bother with locking down the server?


> Like I said, I'm sitting here laughing right now, mostly because it
> was a lot of wasted effort on all sides to argue (or discuss with
> pointed statements) over something that already existed, even if it
> wasn't known or documented.

I still believe there was a good reason for that argument.


> (Wonders if this will be considered a bug to be fixed or quashed as
> it wasn't an intended *feature* of scp)....   I hope not...

It's just a side effect of the rcp/scp design.


//Peter

From Jan.Pechanec at Sun.COM  Fri Dec  7 11:25:31 2007
From: Jan.Pechanec at Sun.COM (Jan Pechanec)
Date: Fri, 07 Dec 2007 01:25:31 +0100 (CET)
Subject: scp -t - revisited.....
In-Reply-To: <BAY139-W20AE63E86D9E862A832A22C96F0@phx.gbl>
References: <BAY139-W20AE63E86D9E862A832A22C96F0@phx.gbl>
Message-ID: <Pine.SOC.4.64.0712070119520.215770@fossa.czech.sun.com>

On Thu, 6 Dec 2007, Larry Becke wrote:

>This leads me to believe that using the scp -t /some/path/to/a/directory 
>command= in the authorized_keys file causes scp to forget/ignore everything 
>after the remote hostname.

	internally, local scp runs "ssh <HOST> scp -t/-f <PATH>". With 
command= in authorized keys file, the command set on ssh command line is 
ignored and "command=..." is used instead.

> (Wonders if this will be considered a bug to be fixed or quashed as it 
>wasn't an intended *feature* of scp)....  I hope not...

	it has nothing to do with scp. The local scp process doesn't know 
about it at all, neither the scp process on remote side.

-- 
Jan Pechanec

From Jan.Pechanec at Sun.COM  Fri Dec  7 11:28:24 2007
From: Jan.Pechanec at Sun.COM (Jan Pechanec)
Date: Fri, 07 Dec 2007 01:28:24 +0100 (CET)
Subject: scp -t - revisited.....
In-Reply-To: <BAY139-W21FA887C8CE2234C47892EC9680@phx.gbl>
References: <BAY139-W21FA887C8CE2234C47892EC9680@phx.gbl>
Message-ID: <Pine.SOC.4.64.0712070126010.215770@fossa.czech.sun.com>

On Thu, 6 Dec 2007, Larry Becke wrote:

>Oh- it also makes the scp send only.
> 
>ie - you cannot copy a file from the remote host, to the local host.

	correct. For copying from remote side, you run that internall ssh 
with (slightly simplified) "scp -f <FILE>". Well, you could set another key 
and you could always copy the same file :-)

-- 
Jan Pechanec

From guyverdh at hotmail.com  Fri Dec  7 12:58:15 2007
From: guyverdh at hotmail.com (Larry Becke)
Date: Thu, 6 Dec 2007 19:58:15 -0600
Subject: scp -t - revisited
Message-ID: <BAY139-W41E66D6C30C485CC32BC13C9680@phx.gbl>


Thanks to J.P. I now have a better understanding of how scp really works.
 
I haven't uncovered any dark secrets, or unintended capabilities, I just prevented scp from sending the proper commands via ssh to the remote server.
 
In essence, I gave scp a lobotomy or short-circuit.   
 
Either way, it's useful and gives me the desired effect.
 
I don't know if anyone else would find this useful or not, but if you'd like the specifics, I can share them.
 
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007

From stuge-openssh-unix-dev at cdy.org  Fri Dec  7 13:39:39 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Fri, 7 Dec 2007 03:39:39 +0100
Subject: scp -t - revisited
In-Reply-To: <BAY139-W41E66D6C30C485CC32BC13C9680@phx.gbl>
References: <BAY139-W41E66D6C30C485CC32BC13C9680@phx.gbl>
Message-ID: <20071207023940.24143.qmail@cdy.org>

On Thu, Dec 06, 2007 at 07:58:15PM -0600, Larry Becke wrote:
> Thanks to J.P. I now have a better understanding of how scp really
> works.

Unfortunately not good enough I think. There was a post recently
about the protcol internals. Give it a read and I think you'll also
consider the problem I mentioned.


> I haven't uncovered any dark secrets, or unintended capabilities, I
> just prevented scp from sending the proper commands via ssh to the
> remote server.

Yes, but there are also commands passed between the two scp programs.
Part of them are filenames and directories. I would investigate
whether they are always restricted to the -t directory. I doubt it.


> In essence, I gave scp a lobotomy or short-circuit.
>  
> Either way, it's useful and gives me the desired effect.

If you're happy that's good. But please do note that there may be a
trivial way out of this "restriction."


//Peter

From guyverdh at hotmail.com  Fri Dec  7 13:35:47 2007
From: guyverdh at hotmail.com (Larry Becke)
Date: Thu, 6 Dec 2007 20:35:47 -0600
Subject: =?windows-1256?Q?scp_-t_-_revisited.....=FE?=
Message-ID: <BAY139-W248F1D77772D2FDCF35182C9680@phx.gbl>


>From the testing that I've done so far, using the command= restriction essentially ignores any and all attempts by the client to send different remote filenames, directory commands, etc...
 
using scp -i some_key localfile  remotehost:../../../../../../../../../../tmp/file    places a copy of the file named "localfile"  in the directory specified in the command= line of the authorized keys file.
It completely overrides the -t and -f parameters passed by the client, which is really pretty cool in a sense.
 
You could probably even configure the command= to attempt to send a file, which would only work I assume if the client command was set to pull a file, rather than send one.
 
It might be fun to play with it to see what you can and can't force via the command= override from the authorized_keys file.
 
All in all, it gave me what so far appears to be a safe, secure, encrypted, receive only scp, where the file destination directory is controlled by the server, not the client.
 
Hella cool imo.
_________________________________________________________________
Your smile counts. The more smiles you share, the more we donate.? Join in.
www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline

From guyverdh at hotmail.com  Fri Dec  7 14:04:45 2007
From: guyverdh at hotmail.com (Larry Becke)
Date: Thu, 6 Dec 2007 21:04:45 -0600
Subject: scp -t - revisited.....
Message-ID: <BAY139-W387BD205DA376B5C212382C9680@phx.gbl>


*My apologies for mangling this, as I'm not a subscriber, and peter doesn't deign to reply to me as well as the list*
 
On Thu, Dec 06, 2007 at 05:26:14PM -0600, Larry Becke wrote:>> This leads me to believe that using the scp -t>> /some/path/to/a/directory  command= in the authorized_keys file>> causes scp to forget/ignore everything after the remote hostname.>There is one more step between the remote scp (run with -t) and the>"remote filename" as specified in the local shell: The local scp.
You're right as long as the scp client has the power to do anything, beyond send the file names/content.  However, with this method, the local scp is powerless.
>> This gives us almost exactly what we were looking for>I think that depends on the local scp program.
 
Sorry, not with this method.>What happens if you (within the scp protocol, not in the shell)>specify e.g. a new directory ../../../../../../../tmp/breakout ?>I would assume that /tmp/breakout is created.
Again, not with this method.
>If your local scp program is trusted then you're all set. But if that>was the case why bother with locking down the server?
Unfortunately (or in my case, fortunately), that's not how scp works.
 
Using scp as you showed, would not do anything to this method.
 
The reason being is as follows...
 
scp -i key_file  localfile  remotehost:../../../../../../../../../../../tmp/breakout
 
what really happens, as near as I've been able to figure out with the information that J.P. sent me, is that the client (or local) system executes the following.
 
ssh -i key_file {remotehost} scp -d -t ../../../../../../../../../../../tmp/breakout
 
now - normally this would cause the effect that you mentioned - except for one minor little thing.
 
The ssh key in question, is configured on the server to only run "scp -t /server/selected/path"
 
This overrides the command that was sent by the scp client, and replaces it with what we want to happen.
 
No directory selection, it gets rid of all your carefully crafted pathing exploit attempts - they're all gone, as though they never existed.
 
Now, the scp -t starts the scp server service in receive mode (this is an assumption on my part), waiting for the client to send the commands needed to create the file and it's contents (or multiple files and their contents).
 
This is the cool part - no matter what you *try* to do with the scp client, it will never do anything other than go into receive mode and wait for the transfer commands.
 
Now, if the scp protocol can be exploited some how beyond the open file / send contents, then we may have a problem - but that would be the case with scp in general.
 
I would also assume that using another key to put the scp server side into send mode  - ie    scp -f /server/selected/path - would restrict downloads from the specified directory, again, regardless of what the client asked for.
>> Like I said, I'm sitting here laughing right now, mostly because it>> was a lot of wasted effort on all sides to argue (or discuss with>> pointed statements) over something that already existed, even if it>> wasn't known or documented.>I still believe there was a good reason for that argument.
You're free to believe what you want, I found what I wanted - and it works - very well.>> (Wonders if this will be considered a bug to be fixed or quashed as>> it wasn't an intended *feature* of scp)....   I hope not...>It's just a side effect of the rcp/scp design.
Which apparently neither of us were 100% up on, and I was glad for the opportunity to learn something new.  I hope you did as well.>//Peter
LB
_________________________________________________________________
You keep typing, we keep giving. Download Messenger and join the i?m Initiative now.
http://im.live.com/messenger/im/home/?source=TAGLM

From stuge-openssh-unix-dev at cdy.org  Fri Dec  7 19:24:07 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Fri, 7 Dec 2007 09:24:07 +0100
Subject: scp -t - revisited.....
In-Reply-To: <BAY139-W387BD205DA376B5C212382C9680@phx.gbl>
References: <BAY139-W387BD205DA376B5C212382C9680@phx.gbl>
Message-ID: <20071207082407.1301.qmail@cdy.org>

On Thu, Dec 06, 2007 at 09:04:45PM -0600, Larry Becke wrote:
> *My apologies for mangling this, as I'm not a subscriber, and peter
> doesn't deign to reply to me as well as the list*

Ah, you mentioned that you weren't subscribed back in the first
thread? Sorry, I forgot all about that.


>> What happens if you (within the scp protocol, not in the shell)
>> specify e.g. a new directory ../../../../../../../tmp/breakout ?
>> I would assume that /tmp/breakout is created.

..

> Using scp as you showed, would not do anything to this method.
..
> what really happens, as near as I've been able to figure out with
> the information that J.P. sent me, is that the client (or local)
> system executes the following.
>  
> ssh -i key_file {remotehost} scp -d -t ../../../../../../../../../../../tmp/breakout

..

> The ssh key in question, is configured on the server to only run
> "scp -t /server/selected/path"
>  
> This overrides the command that was sent by the scp client, and
> replaces it with what we want to happen.

Right. Which is why I was careful to point out that specifying the
tmp path in the shell (such as in the example above) will not
expose the problem.


> Now, if the scp protocol can be exploited some how beyond the open
> file / send contents, then we may have a problem - but that would
> be the case with scp in general.

Spot on. scp is not designed to confine a user to a given directory.
This is why you got a couple of different suggestions on how to solve
the problem in the first place.


>> I still believe there was a good reason for that argument.
> 
> You're free to believe what you want, I found what I wanted - and
> it works - very well.

I don't have time to demonstrate/test my idea right now, but will
try to get back to you later today. If anyone else understands what I
mean and feels like hacking up an example, please do.


>>> (Wonders if this will be considered a bug to be fixed or quashed
>>> as it wasn't an intended *feature* of scp)....   I hope not...
>> 
>>It's just a side effect of the rcp/scp design.
> 
> Which apparently neither of us were 100% up on, and I was glad for
> the opportunity to learn something new.  I hope you did as well.

I already knew how scp works (internally) and I suppose noone else
suggested forcing the scp -t command because it doesn't actually
provide what you initially asked for.


//Peter

From miklos at szeredi.hu  Fri Dec  7 19:51:59 2007
From: miklos at szeredi.hu (Miklos Szeredi)
Date: Fri, 07 Dec 2007 09:51:59 +0100
Subject: [sshfs] sshfs mounted applications fail with "error loading
	shared libraries"
In-Reply-To: <alpine.BSO.0.99999.0712071057520.27644@fuyu.mindrot.org>
	(message from Damien Miller on Fri, 7 Dec 2007 10:58:56 +1100 (EST))
References: <89acfbb60711241324m6572cadcqd0f7166b95d43644@mail.gmail.com>
	<E1IwdgV-0007e8-OH@dorka.pomaz.szeredi.hu>
	<9fa207310712021709h5d711d56j5fccfada1756b80e@mail.gmail.com>
	<E1IzBCy-0003gE-TJ@dorka.pomaz.szeredi.hu>
	<9fa207310712031529r7276b2f9uf75568e9844b968d@mail.gmail.com>
	<E1IzUcL-0006CK-4P@dorka.pomaz.szeredi.hu>
	<9fa207310712051624w4ba195fcrbe9e08369fe35550@mail.gmail.com>
	<E1J0OZw-0000A9-Nl@dorka.pomaz.szeredi.hu>
	<alpine.BSO.0.99999.0712071057520.27644@fuyu.mindrot.org>
Message-ID: <E1J0YwB-000157-QH@dorka.pomaz.szeredi.hu>

> Yes, sftp-server should dynamically allocate its handles up to the
> point where the system starts refusing to allocate file descriptors.
> 
> Anyone want to make a patch?

Here's one.

Dynamically increase the handle table size as needed.  When finding an
unused handle, use a LIFO instead of seaching the table linearly.
This makes handle allocation O(1).

Miklos


Index: ssh/sftp-server.c
===================================================================
--- ssh.orig/sftp-server.c	2007-09-13 06:39:04.000000000 +0200
+++ ssh/sftp-server.c	2007-12-07 09:31:17.000000000 +0100
@@ -164,6 +164,7 @@ struct Handle {
 	int fd;
 	char *name;
 	u_int64_t bytes_read, bytes_write;
+	int next_unused;
 };
 
 enum {
@@ -172,40 +173,44 @@ enum {
 	HANDLE_FILE
 };
 
-Handle	handles[100];
-
-static void
-handle_init(void)
-{
-	u_int i;
-
-	for (i = 0; i < sizeof(handles)/sizeof(Handle); i++)
-		handles[i].use = HANDLE_UNUSED;
+Handle *handles = NULL;
+u_int num_handles = 0;
+int first_unused = -1;
+
+static void handle_unused(int i)
+{
+	handles[i].use = HANDLE_UNUSED;
+	handles[i].next_unused = first_unused;
+	first_unused = i;
 }
 
 static int
 handle_new(int use, const char *name, int fd, DIR *dirp)
 {
-	u_int i;
+	int i;
 
-	for (i = 0; i < sizeof(handles)/sizeof(Handle); i++) {
-		if (handles[i].use == HANDLE_UNUSED) {
-			handles[i].use = use;
-			handles[i].dirp = dirp;
-			handles[i].fd = fd;
-			handles[i].name = xstrdup(name);
-			handles[i].bytes_read = handles[i].bytes_write = 0;
-			return i;
-		}
-	}
-	return -1;
+	if (first_unused == -1) {
+		num_handles++;
+		handles = xrealloc(handles, num_handles, sizeof(Handle));
+		handle_unused(num_handles - 1);
+	}
+
+	i = first_unused;
+	first_unused = handles[i].next_unused;
+
+	handles[i].use = use;
+	handles[i].dirp = dirp;
+	handles[i].fd = fd;
+	handles[i].name = xstrdup(name);
+	handles[i].bytes_read = handles[i].bytes_write = 0;
+
+	return i;
 }
 
 static int
 handle_is_ok(int i, int type)
 {
-	return i >= 0 && (u_int)i < sizeof(handles)/sizeof(Handle) &&
-	    handles[i].use == type;
+	return i >= 0 && (u_int)i < num_handles && handles[i].use == type;
 }
 
 static int
@@ -295,12 +300,12 @@ handle_close(int handle)
 
 	if (handle_is_ok(handle, HANDLE_FILE)) {
 		ret = close(handles[handle].fd);
-		handles[handle].use = HANDLE_UNUSED;
 		xfree(handles[handle].name);
+		handle_unused(handle);
 	} else if (handle_is_ok(handle, HANDLE_DIR)) {
 		ret = closedir(handles[handle].dirp);
-		handles[handle].use = HANDLE_UNUSED;
 		xfree(handles[handle].name);
+		handle_unused(handle);
 	} else {
 		errno = ENOENT;
 	}
@@ -328,7 +333,7 @@ handle_log_exit(void)
 {
 	u_int i;
 
-	for (i = 0; i < sizeof(handles)/sizeof(Handle); i++)
+	for (i = 0; i < num_handles; i++)
 		if (handles[i].use != HANDLE_UNUSED)
 			handle_log_close(i, "forced");
 }
@@ -1249,8 +1254,6 @@ main(int argc, char **argv)
 	logit("session opened for local user %s from [%s]",
 	    pw->pw_name, client_addr);
 
-	handle_init();
-
 	in = dup(STDIN_FILENO);
 	out = dup(STDOUT_FILENO);
 

From Jefferson.Ogata at noaa.gov  Fri Dec  7 20:57:05 2007
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Fri, 07 Dec 2007 09:57:05 +0000
Subject: scp -t - revisited.....
In-Reply-To: <BAY139-W387BD205DA376B5C212382C9680@phx.gbl>
References: <BAY139-W387BD205DA376B5C212382C9680@phx.gbl>
Message-ID: <475918F1.8000906@noaa.gov>

On 2007-12-07 03:04, Larry Becke wrote:
> This is the cool part - no matter what you *try* to do with the scp client, it will never do anything other than go into receive mode and wait for the transfer commands.

If that's the case, it's by accident. If you're happy with accidental
security, and nobody needs to analyze scp or write additional code for
you, then great! we're done here.

> Now, if the scp protocol can be exploited some how beyond the open file / send contents, then we may have a problem - but that would be the case with scp in general.

There would be no problem with scp in general in that case, because it
is not a design goal of scp to keep the user from writing to certain
files. That constraint is left up to features of the native operating
environment, e.g. filesystem permissions, which behave deterministically
and require no additional analysis. Those who want to have reliable
security don't rely on undocumented, unproven behaviour that is an
accidental and possibly transitory side-effect of one particular
implementation. I thought we explained all that before, but hey, if
you're happy, I'm happy. :^)

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service

From miklos at szeredi.hu  Fri Dec  7 22:50:30 2007
From: miklos at szeredi.hu (Miklos Szeredi)
Date: Fri, 07 Dec 2007 12:50:30 +0100
Subject: [PATCH] add statfs extension to sftp-server
Message-ID: <E1J0biw-0001NV-CM@dorka.pomaz.szeredi.hu>

And while we are at it, can you please comment on these patches as
well, originally submitted around one year ago.

Oh, and I think we can agree, that the secsh-filexfer standardization
is dead, so there's not much point in trying to support newer protocol
versions, which don't have statfs anyway.

Thanks,
Miklos
-----

This is needed to be able to support statfs operation on an SSH
filesystem (http://fuse.sourceforge.net/sshfs.html).

It uses and sends only those fields of struct statfs which are common
with struct statvfs as defined by POSIX, and which are shared among
most UNIX-like systems.

The SSH_FXP_EXTENDED message type is used, so this change is backward
compatible and conforms to the protocol specification.

Index: ssh/sftp-server.c
===================================================================
--- ssh.orig/sftp-server.c	2006-08-19 16:24:17.000000000 +0200
+++ ssh/sftp-server.c	2006-08-19 16:49:03.000000000 +0200
@@ -19,6 +19,7 @@
 #include <sys/stat.h>
 #include <sys/time.h>
 #include <sys/param.h>
+#include <sys/mount.h>
 
 #include <dirent.h>
 #include <errno.h>
@@ -462,6 +463,24 @@ send_attrib(u_int32_t id, const Attrib *
 	buffer_free(&msg);
 }
 
+static void
+send_statfs(u_int32_t id, struct statfs *st)
+{
+	Buffer msg;
+
+	buffer_init(&msg);
+	buffer_put_char(&msg, SSH2_FXP_EXTENDED_REPLY);
+	buffer_put_int(&msg, id);
+	buffer_put_int(&msg, st->f_bsize);
+	buffer_put_int64(&msg, st->f_blocks);
+	buffer_put_int64(&msg, st->f_bfree);
+	buffer_put_int64(&msg, st->f_bavail);
+	buffer_put_int64(&msg, st->f_files);
+	buffer_put_int64(&msg, st->f_ffree);
+	send_msg(&msg);
+	buffer_free(&msg);
+}
+
 /* parse incoming */
 
 static void
@@ -1049,6 +1068,25 @@ process_symlink(void)
 }
 
 static void
+process_extended_statfs(u_int32_t id)
+{
+	char *path;
+	struct statfs st;
+	int ret;
+
+	path = get_string(NULL);
+	debug3("request %u: statfs", id);
+	logit("statfs \"%s\"", path);
+
+	ret = statfs(path, &st);
+	if (ret == -1)
+		send_status(id, errno_to_portable(errno));
+	else
+		send_statfs(id, &st);
+        xfree(path);
+}
+
+static void
 process_extended(void)
 {
 	u_int32_t id;
@@ -1056,7 +1094,10 @@ process_extended(void)
 
 	id = get_int();
 	request = get_string(NULL);
-	send_status(id, SSH2_FX_OP_UNSUPPORTED);		/* MUST */
+	if (strcmp(request, "statfs at openssh.org") == 0)
+		process_extended_statfs(id);
+	else
+		send_status(id, SSH2_FX_OP_UNSUPPORTED);	/* MUST */
 	xfree(request);
 }
 


From miklos at szeredi.hu  Fri Dec  7 22:52:37 2007
From: miklos at szeredi.hu (Miklos Szeredi)
Date: Fri, 07 Dec 2007 12:52:37 +0100
Subject: [PATCH] add atomic rename extension to sftp-server
In-Reply-To: <E1J0biw-0001NV-CM@dorka.pomaz.szeredi.hu> (message from Miklos
	Szeredi on Fri, 07 Dec 2007 12:50:30 +0100)
References: <E1J0biw-0001NV-CM@dorka.pomaz.szeredi.hu>
Message-ID: <E1J0bkz-0001Ns-BD@dorka.pomaz.szeredi.hu>

This is needed to be able to support a rename() operation conforming
to POSIX in the SSH filesystem.

With the rename operation defined in the SFTP spec, this is
impossible, since in case the target exists it's not possible to
perform the rename+unlink atomically.

Index: ssh/sftp-server.c
===================================================================
--- ssh.orig/sftp-server.c	2006-08-19 16:49:03.000000000 +0200
+++ ssh/sftp-server.c	2006-08-19 16:51:26.000000000 +0200
@@ -1087,6 +1087,23 @@ process_extended_statfs(u_int32_t id)
 }
 
 static void
+process_extended_posix_rename(u_int32_t id)
+{
+	char *oldpath, *newpath;
+
+	oldpath = get_string(NULL);
+	newpath = get_string(NULL);
+	debug3("request %u: posix-rename", id);
+	logit("posix-rename old \"%s\" new \"%s\"", oldpath, newpath);
+        if (rename(oldpath, newpath) == -1)
+            send_status(id, errno_to_portable(errno));
+        else
+            send_status(id, SSH2_FX_OK);
+	xfree(oldpath);
+	xfree(newpath);
+}
+
+static void
 process_extended(void)
 {
 	u_int32_t id;
@@ -1096,6 +1113,8 @@ process_extended(void)
 	request = get_string(NULL);
 	if (strcmp(request, "statfs at openssh.org") == 0)
 		process_extended_statfs(id);
+	if (strcmp(request, "posix-rename at openssh.org") == 0)
+		process_extended_posix_rename(id);
 	else
 		send_status(id, SSH2_FX_OP_UNSUPPORTED);	/* MUST */
 	xfree(request);


From chris at qwirx.com  Fri Dec  7 22:58:09 2007
From: chris at qwirx.com (Chris Wilson)
Date: Fri, 7 Dec 2007 11:58:09 +0000 (GMT)
Subject: Request for LPK patch to be merged
In-Reply-To: <Pine.LNX.4.64.0711251600440.11131@top.qwarx.com>
References: <Pine.LNX.4.64.0711251600440.11131@top.qwarx.com>
Message-ID: <Pine.LNX.4.64.0712071144410.24218@top.qwarx.com>

Hi all,

I sent this message a few weeks ago and so far have not had any reply. Is 
there another procedure for requesting such changes?

Cheers, Chris.

On Sun, 25 Nov 2007, Chris Wilson wrote:

> At my organisation we have an LDAP infrastructure built on OpenLDAP, 
> between Unix boxes running OpenSSH at multiple sites. It works well but 
> the SSH key management is something of an inconvenience, especially as we 
> would like to implement SSO with ssh-agent and passphrased keys.
> 
> There is an OpenSSH patch called LPK which can allow the authorized_keys 
> to be stored in LDAP, and that would be really useful in our environment. 
> However we don't really want to maintain our own packages, and our default 
> distro doesn't want to supply packages with the LPK patch as long as it's 
> not supported upstream.
> 
> So I'd like to request that you consider the LPK patch for merging into 
> OpenSSH. You can find it here:
> 
>   http://dev.inversepath.com/trac/openssh-lpk
> 
> Here is the description of what specifically we are trying to achieve:
> 
>   http://dev.inversepath.com/openssh-lpk/ldap_fosdem_2006.pdf
> 
> In particular: "The final goal is cross-platform authentication, being 
> able to manage users globally on the LDAP server, without performing any 
> action on the server pool (scalability for add/revoke a user to N servers 
> scenarios)"
> 
> And here is another page giving another good reason for using LPK:
> 
>   http://blog.fupps.com/2006/03/02/ssh-public-keys-from-ldap/
> 
> "What happens when you have dozens or more [machines]? You have to 
> maintain your public keys on all those systems, ensuring they are kept up 
> to date. God forbid that you loose your private key, or that it becomes 
> compromised: you'd have to quickly change all the authorized_keys files on 
> all machines!"
> 
> I'm not the developer of the patch, but if there are specific issues that 
> need to be addressed then I'd be happy to coordinate with the maintainer 
> and/or lend a hand to see them addressed.
> 
> Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |

From lindysandiego at yahoo.com  Sat Dec  8 01:41:02 2007
From: lindysandiego at yahoo.com (Thomas Baden)
Date: Fri, 7 Dec 2007 06:41:02 -0800 (PST)
Subject: scp -t - revisited.....þ
In-Reply-To: <BAY139-W248F1D77772D2FDCF35182C9680@phx.gbl>
Message-ID: <247239.13021.qm@web51706.mail.re2.yahoo.com>

Hi Larry et al,

--- Larry Becke <guyverdh at hotmail.com> wrote:
> It might be fun to play with it to see what you can
> and can't force via the command= override from the
> authorized_keys file.

I ran into an annoying side effect a while back when I
started packaging up these -i and command=
combinations...  If you have a key agent running, the
key agent will get first dibs despite the specific key
listed in the -i.  So you'll want to prepend your
initiating scp command with SSH_AUTH_SOCK= like so:

$ SSH_AUTH_SOCK= scp -i key file user at host:

I took things a bit further than you seem to have
done, and had my command= execute a shell script,
which would pick apart the passed SCP command
$SSH_ORIGINAL_COMMAND and instead used the passed
"target directory" argument as a parameter to perform
a lookup for specialized handling.

Cheers,
-Thomas


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

From guyverdh at hotmail.com  Sat Dec  8 03:58:12 2007
From: guyverdh at hotmail.com (Larry Becke)
Date: Fri, 7 Dec 2007 10:58:12 -0600
Subject: scp -t - revisited.....
In-Reply-To: <20071207082407.1301.qmail@cdy.org>
References: <BAY139-W387BD205DA376B5C212382C9680@phx.gbl>
	<20071207082407.1301.qmail@cdy.org>
Message-ID: <BAY139-W44503479445591EBAC6FF2C9680@phx.gbl>


If this were to be put to use in some kind of publicly accessible location, I wouldn't even consider this a fix for our problem.  I do not believe in security through obscurity.
 
Now, where this comes into play is when we are dealing with sister companies, trusted trading partners, etc...   There's already a certain level of trust involved, and we're looking for something to prevent accidental file relocation.
 
I understand that carefully tweaked data flow sent to the scp server side could cause data to be written to a location other than what's specified by the key.  I have no questions that that could happen.  
 
Now the one thing that I would ask, is this, could a crafted scp connection (even when forced to run scp -t ) cause a file to be pulled down to the client?
> Date: Fri, 7 Dec 2007 09:24:07 +0100> From: stuge-openssh-unix-dev at cdy.org> To: guyverdh at hotmail.com> CC: openssh-unix-dev at mindrot.org> Subject: Re: scp -t - revisited.....> > On Thu, Dec 06, 2007 at 09:04:45PM -0600, Larry Becke wrote:> > *My apologies for mangling this, as I'm not a subscriber, and peter> > doesn't deign to reply to me as well as the list*> > Ah, you mentioned that you weren't subscribed back in the first> thread? Sorry, I forgot all about that.> > > >> What happens if you (within the scp protocol, not in the shell)> >> specify e.g. a new directory ../../../../../../../tmp/breakout ?> >> I would assume that /tmp/breakout is created.> > ..> > > Using scp as you showed, would not do anything to this method.> ..> > what really happens, as near as I've been able to figure out with> > the information that J.P. sent me, is that the client (or local)> > system executes the following.> > > > ssh -i key_file {remotehost} scp -d -t ../../../../../../../../../../../tmp/breakout> > ..> > > The ssh key in question, is configured on the server to only run> > "scp -t /server/selected/path"> > > > This overrides the command that was sent by the scp client, and> > replaces it with what we want to happen.> > Right. Which is why I was careful to point out that specifying the> tmp path in the shell (such as in the example above) will not> expose the problem.> > > > Now, if the scp protocol can be exploited some how beyond the open> > file / send contents, then we may have a problem - but that would> > be the case with scp in general.> > Spot on. scp is not designed to confine a user to a given directory.> This is why you got a couple of different suggestions on how to solve> the problem in the first place.> > > >> I still believe there was a good reason for that argument.> > > > You're free to believe what you want, I found what I wanted - and> > it works - very well.> > I don't have time to demonstrate/test my idea right now, but will> try to get back to you later today. If anyone else understands what I> mean and feels like hacking up an example, please do.> > > >>> (Wonders if this will be considered a bug to be fixed or quashed> >>> as it wasn't an intended *feature* of scp).... I hope not...> >> > >>It's just a side effect of the rcp/scp design.> > > > Which apparently neither of us were 100% up on, and I was glad for> > the opportunity to learn something new. I hope you did as well.> > I already knew how scp works (internally) and I suppose noone else> suggested forcing the scp -t command because it doesn't actually> provide what you initially asked for.> > > //Peter
_________________________________________________________________
Put your friends on the big screen with Windows Vista? + Windows Live?.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007

From addw at phcomp.co.uk  Sat Dec  8 05:45:22 2007
From: addw at phcomp.co.uk (Alain Williams)
Date: Fri, 7 Dec 2007 18:45:22 +0000
Subject: scp -t - revisited.....
In-Reply-To: <20071207082407.1301.qmail@cdy.org>
References: <BAY139-W387BD205DA376B5C212382C9680@phx.gbl>
	<20071207082407.1301.qmail@cdy.org>
Message-ID: <20071207184522.GA20559@mint.phcomp.co.uk>

On Fri, Dec 07, 2007 at 09:24:07AM +0100, Peter Stuge wrote:
> On Thu, Dec 06, 2007 at 09:04:45PM -0600, Larry Becke wrote:
> > *My apologies for mangling this, as I'm not a subscriber, and peter
> > doesn't deign to reply to me as well as the list*
> 
> Ah, you mentioned that you weren't subscribed back in the first
> thread? Sorry, I forgot all about that.
> 
> 
> >> What happens if you (within the scp protocol, not in the shell)
> >> specify e.g. a new directory ../../../../../../../tmp/breakout ?
> >> I would assume that /tmp/breakout is created.
> 
> ..
> 
> > Using scp as you showed, would not do anything to this method.
> ..
> > what really happens, as near as I've been able to figure out with
> > the information that J.P. sent me, is that the client (or local)
> > system executes the following.
> >  
> > ssh -i key_file {remotehost} scp -d -t ../../../../../../../../../../../tmp/breakout
> 
> ..
> 
> > The ssh key in question, is configured on the server to only run
> > "scp -t /server/selected/path"
> >  
> > This overrides the command that was sent by the scp client, and
> > replaces it with what we want to happen.
> 
> Right. Which is why I was careful to point out that specifying the
> tmp path in the shell (such as in the example above) will not
> expose the problem.
> 
> 
> > Now, if the scp protocol can be exploited some how beyond the open
> > file / send contents, then we may have a problem - but that would
> > be the case with scp in general.
> 
> Spot on. scp is not designed to confine a user to a given directory.
> This is why you got a couple of different suggestions on how to solve
> the problem in the first place.

About a month ago I submitted a patch to sftp-server to this list that
does exactly that -- against openssh-4.7p1

See:

	ftp://files.phcomp.co.uk/files/files/sftp-server.patch

(Will be there for a month)

-- 
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h>

From stuge-openssh-unix-dev at cdy.org  Sat Dec  8 06:41:01 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Fri, 7 Dec 2007 20:41:01 +0100
Subject: scp -t - revisited.....
In-Reply-To: <BAY139-W44503479445591EBAC6FF2C9680@phx.gbl>
References: <BAY139-W387BD205DA376B5C212382C9680@phx.gbl>
	<20071207082407.1301.qmail@cdy.org>
	<BAY139-W44503479445591EBAC6FF2C9680@phx.gbl>
Message-ID: <20071207194102.5222.qmail@cdy.org>

Hi again Larry,

On Fri, Dec 07, 2007 at 10:58:12AM -0600, Larry Becke wrote:
> If this were to be put to use in some kind of publicly accessible
> location, I wouldn't even consider this a fix for our problem.  I
> do not believe in security through obscurity.

Oh I don't think this qualifies. It's not like you're hiding
anything.


> Now, where this comes into play is when we are dealing with sister
> companies, trusted trading partners, etc...   There's already a
> certain level of trust involved, and we're looking for something to
> prevent accidental file relocation.

Then I would be satisfied with this method.


> I understand that carefully tweaked data flow sent to the scp
> server side could cause data to be written to a location other than
> what's specified by the key.  I have no questions that that could
> happen.

Cool.


> Now the one thing that I would ask, is this, could a crafted scp
> connection (even when forced to run scp -t ) cause a file to be
> pulled down to the client?

I don't think so, no.


//Peter

From gregory_shively at fanniemae.com  Sat Dec  8 11:29:56 2007
From: gregory_shively at fanniemae.com (Shively, Gregory)
Date: Fri, 7 Dec 2007 19:29:56 -0500
Subject: MAX_SESSIONS Increase Impact
Message-ID: <0EC92223891A8244A72EBE5E1C9DB0F601392D6F@EXVE.fanniemae.com>

I'm hoping this is the the right location for this question....

I've been working with some developers that are desiring to use the
multiplexing capabilities of OpenSSH, but have hit the default limit of
10. I've seen some discussions of increasing this default limit
previously and have noticed that some of the Linux distros have
increased the number to 64; I'm curious of the impact. The developers
that I'm working with have discussed approx 90'ish slave processes using
the master ssh process, so I've been thinking about using 128 for
possible furture increases by this group.

Greg 

From djm at mindrot.org  Sun Dec  9 09:15:04 2007
From: djm at mindrot.org (Damien Miller)
Date: Sun, 9 Dec 2007 09:15:04 +1100 (EST)
Subject: MAX_SESSIONS Increase Impact
In-Reply-To: <0EC92223891A8244A72EBE5E1C9DB0F601392D6F@EXVE.fanniemae.com>
References: <0EC92223891A8244A72EBE5E1C9DB0F601392D6F@EXVE.fanniemae.com>
Message-ID: <alpine.BSO.0.99999.0712090913530.27644@fuyu.mindrot.org>

On Fri, 7 Dec 2007, Shively, Gregory wrote:

> I'm hoping this is the the right location for this question....
> 
> I've been working with some developers that are desiring to use the
> multiplexing capabilities of OpenSSH, but have hit the default limit of
> 10. I've seen some discussions of increasing this default limit
> previously and have noticed that some of the Linux distros have
> increased the number to 64; I'm curious of the impact. The developers
> that I'm working with have discussed approx 90'ish slave processes using
> the master ssh process, so I've been thinking about using 128 for
> possible furture increases by this group.

I'd like it to be uncapped and purely dynamic, but we need to audit
the server to make sure it doesn't fatal() when it hits a fd limit in
an unexpected place.

-d

From djm at mindrot.org  Sun Dec  9 09:16:40 2007
From: djm at mindrot.org (Damien Miller)
Date: Sun, 9 Dec 2007 09:16:40 +1100 (EST)
Subject: [PATCH] add statfs extension to sftp-server
In-Reply-To: <E1J0biw-0001NV-CM@dorka.pomaz.szeredi.hu>
References: <E1J0biw-0001NV-CM@dorka.pomaz.szeredi.hu>
Message-ID: <alpine.BSO.0.99999.0712090915330.27644@fuyu.mindrot.org>

On Fri, 7 Dec 2007, Miklos Szeredi wrote:

> And while we are at it, can you please comment on these patches as
> well, originally submitted around one year ago.

Please post these to http://bugzilla.mindrot.org/

-d

From rob at inversepath.com  Mon Dec 10 21:33:01 2007
From: rob at inversepath.com (Rob Holland)
Date: Mon, 10 Dec 2007 10:33:01 +0000
Subject: Request for LPK patch to be merged
In-Reply-To: <Pine.LNX.4.64.0712071144410.24218@top.qwarx.com>
References: <Pine.LNX.4.64.0711251600440.11131@top.qwarx.com>
	<Pine.LNX.4.64.0712071144410.24218@top.qwarx.com>
Message-ID: <2B14EF16-85E2-4B6B-95C6-FE1FC05D58C0@inversepath.com>


On 7 Dec 2007, at 11:58, Chris Wilson wrote:

> Hi all,
>
> I sent this message a few weeks ago and so far have not had any  
> reply. Is
> there another procedure for requesting such changes?

I am one of the maintainers of the patch. The current release is not  
suitable for merging as it is too invasive. We are working on writing  
a cleaner version, and I have emailed enabling patches to the list  
before, but it seems of limited interested to the OpenSSH developers.  
Our attempts to take small easily reviewable steps on our way to a  
cleaner implementation have been met with, well, no reaction what so  
ever :/

See: http://marc.info/?l=openssh-unix-dev&m=114785024604825&w=2 and  
more recently: http://permalink.gmane.org/gmane.network.openssh.devel/ 
13942

The latter bug is now four months old, no reply yet.

So, I wouldn't hold out much hope.

Cheers,

Rob

-- 
Rob Holland <rob at inversepath.com>
http://www.inversepath.com - Chief R & D Engineer

Inverse Path Ltd, 63 Park Road, Peterborough, PE1 2TN, UK
Registered in England: 5555973



From eduardo.otubo at gmail.com  Mon Dec 10 23:19:03 2007
From: eduardo.otubo at gmail.com (Eduardo Otubo)
Date: Mon, 10 Dec 2007 10:19:03 -0200
Subject: Development documentaion
Message-ID: <c3a7ac720712100419xdbbfd9ajf81ba9add5d84677@mail.gmail.com>

Hello developers,

I would like to know if there is a development documentarion about
OpenSSH. Some doc that describes functions (return value), how they
work together, using PAM or no, etc. I need to make a little hack on
OpenSSH for an internal purpose here at my job and its getting to long
to understand how it works and where my little hack will be. Any help
will be welcome! :-)

Thanks anyway.
[]'s

-- 
Eduardo Otubo
Linux Registered User #424252
http://z3r00.blogspot.com/

|_|0|_|
|_|_|0|
|0|0|0|

From gregory_shively at fanniemae.com  Tue Dec 11 06:48:56 2007
From: gregory_shively at fanniemae.com (Shively, Gregory)
Date: Mon, 10 Dec 2007 14:48:56 -0500
Subject: MAX_SESSIONS Increase Impact
In-Reply-To: <alpine.BSO.0.99999.0712090913530.27644@fuyu.mindrot.org>
References: <0EC92223891A8244A72EBE5E1C9DB0F601392D6F@EXVE.fanniemae.com>
	<alpine.BSO.0.99999.0712090913530.27644@fuyu.mindrot.org>
Message-ID: <0EC92223891A8244A72EBE5E1C9DB0F601392D8F@EXVE.fanniemae.com>

Thanks Damien,

I agree. In the meantime, I'm going to go ahead and increase the value
to 128 for the developers that I'm supporting. I have noticed that the
cvs repository had changed the fatal() to error() in the clientloop.c.
But I did notice something during my testing and have opened a bugzilla
ticket - if the limit of filehandles is reached during the allocation of
stdin/stdout/stderr from the recvmsg(), the return leaves the client_fd
open (which is no longer accessible) and leaves the "slave" ssh process
in a blocking state. I've attach a simple addition of a close() which
will allow the slave ssh process to exit instead of block. I didn't know
if there was a better method in the code to do that. The bugzilla ticket
is 1398.

Greg Shively


-----Original Message-----
From: Damien Miller [mailto:djm at mindrot.org] 
Sent: Saturday, December 08, 2007 5:15 PM
To: Shively, Gregory
Cc: openssh-unix-dev at mindrot.org
Subject: Re: MAX_SESSIONS Increase Impact

On Fri, 7 Dec 2007, Shively, Gregory wrote:

> I'm hoping this is the the right location for this question....
> 
> I've been working with some developers that are desiring to use the
> multiplexing capabilities of OpenSSH, but have hit the default limit
of
> 10. I've seen some discussions of increasing this default limit
> previously and have noticed that some of the Linux distros have
> increased the number to 64; I'm curious of the impact. The developers
> that I'm working with have discussed approx 90'ish slave processes
using
> the master ssh process, so I've been thinking about using 128 for
> possible furture increases by this group.

I'd like it to be uncapped and purely dynamic, but we need to audit
the server to make sure it doesn't fatal() when it hits a fd limit in
an unexpected place.

-d

From mouring at eviladmin.org  Wed Dec 12 15:22:38 2007
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Tue, 11 Dec 2007 22:22:38 -0600 (CST)
Subject: Revisiting sftp tab completion patch
Message-ID: <Pine.BSO.4.64.0712112211160.4463@miyako.eviladmin.org>


I've finally took the time to figure the last few bugs (that I know of). 
This patch will be submit to be included in a few weeks.  This patch 
should be generic enough for portable without too much hassle.

This patch mimics OpenBSD's ftp behavior.  I'm not sure like that (e.g. it 
doesn't put / at the end of directories by default), but that is more a 
question for the community at large.

Yes I'm back on the list. =)

- Ben

Index: sftp.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/sftp.c,v
retrieving revision 1.97
diff -u -r1.97 sftp.c
--- sftp.c	24 Oct 2007 03:30:02 -0000	1.97
+++ sftp.c	12 Dec 2007 03:19:32 -0000
@@ -71,6 +71,12 @@
  int remote_glob(struct sftp_conn *, const char *, int,
      int (*)(const char *, int), glob_t *); /* proto for sftp-glob.c */

+/* sftp connection structure */
+struct sftp_conn *conn;
+
+/* sftp remote path */
+char *remote_path;
+
  /* Separators for interactive commands */
  #define WHITESPACE " \t\r\n"

@@ -115,42 +121,49 @@
  struct CMD {
  	const char *c;
  	const int n;
+	const int t;
  };

+/* Type of completion */
+#define NOARGS 		0
+#define REMOTE 		1
+#define LOCAL		2
+
+
  static const struct CMD cmds[] = {
-	{ "bye",	I_QUIT },
-	{ "cd",		I_CHDIR },
-	{ "chdir",	I_CHDIR },
-	{ "chgrp",	I_CHGRP },
-	{ "chmod",	I_CHMOD },
-	{ "chown",	I_CHOWN },
-	{ "dir",	I_LS },
-	{ "exit",	I_QUIT },
-	{ "get",	I_GET },
-	{ "mget",	I_GET },
-	{ "help",	I_HELP },
-	{ "lcd",	I_LCHDIR },
-	{ "lchdir",	I_LCHDIR },
-	{ "lls",	I_LLS },
-	{ "lmkdir",	I_LMKDIR },
-	{ "ln",		I_SYMLINK },
-	{ "lpwd",	I_LPWD },
-	{ "ls",		I_LS },
-	{ "lumask",	I_LUMASK },
-	{ "mkdir",	I_MKDIR },
-	{ "progress",	I_PROGRESS },
-	{ "put",	I_PUT },
-	{ "mput",	I_PUT },
-	{ "pwd",	I_PWD },
-	{ "quit",	I_QUIT },
-	{ "rename",	I_RENAME },
-	{ "rm",		I_RM },
-	{ "rmdir",	I_RMDIR },
-	{ "symlink",	I_SYMLINK },
-	{ "version",	I_VERSION },
-	{ "!",		I_SHELL },
-	{ "?",		I_HELP },
-	{ NULL,			-1}
+	{ "bye",	I_QUIT, 	NOARGS },
+	{ "cd",		I_CHDIR,	REMOTE },
+	{ "chdir",	I_CHDIR,	REMOTE },
+	{ "chgrp",	I_CHGRP,	REMOTE },
+	{ "chmod",	I_CHMOD,	REMOTE },
+	{ "chown",	I_CHOWN,	REMOTE },
+	{ "dir",	I_LS,		REMOTE },
+	{ "exit",	I_QUIT,		NOARGS },
+	{ "get",	I_GET,		REMOTE },
+	{ "mget",	I_GET,		REMOTE },
+	{ "help",	I_HELP,		NOARGS },
+	{ "lcd",	I_LCHDIR,	LOCAL },
+	{ "lchdir",	I_LCHDIR,	LOCAL },
+	{ "lls",	I_LLS,		LOCAL },
+	{ "lmkdir",	I_LMKDIR,	LOCAL  },
+	{ "ln",		I_SYMLINK,	REMOTE },
+	{ "lpwd",	I_LPWD,		LOCAL },
+	{ "ls",		I_LS, 		REMOTE },
+	{ "lumask",	I_LUMASK,	NOARGS },
+	{ "mkdir",	I_MKDIR,	REMOTE },
+	{ "progress",	I_PROGRESS,	NOARGS },
+	{ "put",	I_PUT,		LOCAL },
+	{ "mput",	I_PUT,		LOCAL },
+	{ "pwd",	I_PWD,		REMOTE },
+	{ "quit",	I_QUIT,		NOARGS },
+	{ "rename",	I_RENAME,	REMOTE },
+	{ "rm",		I_RM,		REMOTE },
+	{ "rmdir",	I_RMDIR,	REMOTE },
+	{ "symlink",	I_SYMLINK,	REMOTE },
+	{ "version",	I_VERSION,	NOARGS },
+	{ "!",		I_SHELL,	NOARGS },
+	{ "?",		I_HELP,		NOARGS },
+	{ NULL,		-1,		-1}
  };

  int interactive_loop(int fd_in, int fd_out, char *file1, char *file2);
@@ -1344,13 +1357,237 @@
  	return ("sftp> ");
  }

+void
+complete_display(char **list, u_int len)
+{
+	u_int y, m = 0, width = 80, columns = 1, colspace = 0;
+	struct winsize ws;
+
+	/* Count entries for sort and find longest filename */
+	for (y = 0; list[y]; y++) 
+		m = MAX(m, strlen(list[y]));
+
+	if (ioctl(fileno(stdin), TIOCGWINSZ, &ws) != -1)
+		width = ws.ws_col;
+
+	m -= len;
+	columns = width / (m + 2);
+	columns = MAX(columns, 1);
+	colspace = width / columns;
+	colspace = MIN(colspace, width);
+
+	printf("\n");
+	m = 1;
+	for (y = 0; list[y]; y++) {
+		char *tmp = list[y];
+
+		tmp += len;
+		printf("%-*s", colspace, tmp);
+		if (m >= columns) {
+			printf("\n");
+			m = 1;
+		} else
+			m++;
+	}
+	printf("\n");
+}
+
+char *
+complete_ambiguous(const char *word, char **list, size_t count)
+{
+	if (word == NULL)
+		return (NULL);
+
+	if (count > 0) {
+		u_int y, matchlen = strlen(list[0]);
+
+		for (y = 1; list[y]; y++) {
+			int x;
+
+			for (x = 0; x < matchlen; x++) 
+				if (list[0][x] != list[y][x]) 
+					break;
+
+			matchlen = x;
+		}
+
+		if (matchlen > strlen(word)) {
+			char *tmp = xstrdup(list[0]);
+
+			tmp[matchlen] = NULL;
+			return (tmp);
+		}
+	} 
+
+	return (xstrdup(word));
+}
+
+
+int
+complete_cmd_parse(EditLine *el, char *cmd)
+{
+	u_int y, count = 0, cmdlen;
+	char **list;
+
+	if (cmd == NULL)
+		return (0);
+
+	list = xcalloc((sizeof(cmds) / sizeof(*cmds)), sizeof(char *));
+	cmdlen = strlen(cmd);
+	for (y = 0; cmds[y].c; y++)  {
+		if (!strncasecmp(cmd, cmds[y].c, cmdlen)) 
+			list[count++] = xstrdup(cmds[y].c);
+
+		list[count] = NULL;
+	}
+
+	if (count > 0) {
+		char *tmp = complete_ambiguous(cmd, list, count);
+
+		if (count > 1)
+			complete_display(list, 0);
+
+		for (y = 1; list[y]; y++) 
+			xfree(list[y]); 
+		xfree(list);
+
+		if (tmp != NULL) {
+			if (strlen(tmp) > strlen(cmd)) 
+				if (el_insertstr(el, tmp + strlen(cmd)) == -1)
+					fatal("el_insertstr failed.");
+
+			xfree(tmp);
+		}
+	}
+
+	return (count);
+}
+
+int
+complete_is_remote(char *cmd) {
+	int i;
+
+	if (cmd == NULL)
+		return (-1);
+
+	for (i = 0; cmds[i].c; i++) {
+		size_t cmdlen = strlen(cmds[i].c);
+
+		if (!strncasecmp(cmd, cmds[i].c, cmdlen)) 
+			return cmds[i].t;
+	}
+
+	return (-1);
+}
+
+int
+complete_match(EditLine *el, char *file, int remote)
+{
+	glob_t g;
+	char *tmp, *tmp2, *pwd;
+	u_int len;
+
+	if (file == NULL)
+		return (0);
+
+	len = strlen(file) + 2;  /* NULL + Wildcard */
+	tmp = xmalloc(len);
+	snprintf(tmp, len, "%s*",  file);
+
+	memset(&g, 0, sizeof(g));
+	if (remote != LOCAL) {
+		tmp = make_absolute(tmp, remote_path);
+		remote_glob(conn, tmp, 0, NULL, &g);
+	} else 
+		glob(tmp, GLOB_DOOFFS, NULL, &g);
+ 
+	xfree(tmp);
+
+	if (g.gl_matchc == 0) 
+		return (0);
+
+	tmp2 = complete_ambiguous(file, g.gl_pathv, g.gl_matchc);
+	tmp = path_strip(tmp2, remote_path);
+	xfree(tmp2);
+
+	if (g.gl_matchc > 1) {
+		char *pwd = strrchr(g.gl_pathv[0], '/');
+		u_int len = 0;
+
+		if (pwd != NULL)
+			len = strlen(g.gl_pathv[0]) - strlen(pwd) + 1;
+
+		complete_display(g.gl_pathv, len);
+	}
+
+	globfree(&g);
+	if (tmp != NULL) {
+		if (strlen(tmp) > strlen(file))  {
+			char *ap, *tmp2 = tmp + strlen(file);
+			u_int len = strlen(tmp2); 
+
+			while ((ap = strsep(&tmp2, " ")) != NULL) {
+				if (strlen(ap) > 0) {
+					if (el_insertstr(el, ap) == -1)
+						fatal("el_insertstr failed.");
+					len -= strlen(ap);
+				}
+				if (len > 0) {
+					len--;
+					if (el_insertstr(el, "\\ ") == -1)
+						fatal("el_insertstr failed.");
+				}
+			}
+		}
+
+		xfree(tmp);
+	}
+
+	return (g.gl_matchc);
+}
+
+unsigned char
+complete(EditLine *el, int ch)
+{
+	char **argv, *line;
+	u_int x, argc, carg, len, ret = CC_ERROR;
+	const LineInfo *lf;
+
+	lf = el_line(el);
+
+	/* Figure out which argument we are on */
+	len = lf->cursor - lf->buffer + 1;
+	line = (char *)xmalloc(len);
+	strlcpy(line, lf->buffer, len);
+	argv = makeargv(line, &carg);
+	xfree(line);
+
+	/* now get the real argument */
+	len = lf->lastchar - lf->buffer + 1;
+	line = (char *)xmalloc(len);
+	strlcpy(line, lf->buffer, len);
+	argv = makeargv(line, &argc);
+	xfree(line);
+
+	if (carg == 1) {  /* Handle the command parsing */
+		if (complete_cmd_parse(el, argv[0]) != 0) 
+			ret = CC_REDISPLAY;
+	} else if (carg > 1) { /* Handle file parsing */
+		int remote = complete_is_remote(argv[0]);
+
+		if (remote != 0 && complete_match(el, argv[carg - 1], 
+		    remote) != 0) 
+			ret = CC_REDISPLAY;
+	}
+
+	return (ret);
+}
+
  int
  interactive_loop(int fd_in, int fd_out, char *file1, char *file2)
  {
-	char *pwd;
  	char *dir = NULL;
  	char cmd[2048];
-	struct sftp_conn *conn;
  	int err, interactive;
  	EditLine *el = NULL;
  	History *hl = NULL;
@@ -1370,26 +1607,31 @@
  		el_set(el, EL_TERMINAL, NULL);
  		el_set(el, EL_SIGNAL, 1);
  		el_source(el, NULL);
+
+		/* Tab Completion */
+		el_set(el, EL_ADDFN, "ftp-complete", 
+		    "Context senstive argument completion", complete);
+		el_set(el, EL_BIND, "^I", "ftp-complete", NULL);
  	}

  	conn = do_init(fd_in, fd_out, copy_buffer_len, num_requests);
  	if (conn == NULL)
  		fatal("Couldn't initialise connection to server");

-	pwd = do_realpath(conn, ".");
-	if (pwd == NULL)
+	remote_path = do_realpath(conn, ".");
+	if (remote_path == NULL)
  		fatal("Need cwd");

  	if (file1 != NULL) {
  		dir = xstrdup(file1);
-		dir = make_absolute(dir, pwd);
+		dir = make_absolute(dir, remote_path);

  		if (remote_is_dir(conn, dir) && file2 == NULL) {
  			printf("Changing to: %s\n", dir);
  			snprintf(cmd, sizeof cmd, "cd \"%s\"", dir);
-			if (parse_dispatch_command(conn, cmd, &pwd, 1) != 0) {
+			if (parse_dispatch_command(conn, cmd, &remote_path, 1) != 0) {
  				xfree(dir);
-				xfree(pwd);
+				xfree(remote_path);
  				xfree(conn);
  				return (-1);
  			}
@@ -1400,9 +1642,9 @@
  				snprintf(cmd, sizeof cmd, "get %s %s", dir,
  				    file2);

-			err = parse_dispatch_command(conn, cmd, &pwd, 1);
+			err = parse_dispatch_command(conn, cmd, &remote_path, 1);
  			xfree(dir);
-			xfree(pwd);
+			xfree(remote_path);
  			xfree(conn);
  			return (err);
  		}
@@ -1455,11 +1697,11 @@
  		interrupted = 0;
  		signal(SIGINT, cmd_interrupt);

-		err = parse_dispatch_command(conn, cmd, &pwd, batchmode);
+		err = parse_dispatch_command(conn, cmd, &remote_path, batchmode);
  		if (err != 0)
  			break;
  	}
-	xfree(pwd);
+	xfree(remote_path);
  	xfree(conn);

  	if (el != NULL)

From vgiffin at apple.com  Fri Dec 14 09:04:51 2007
From: vgiffin at apple.com (Disco Vince Giffin)
Date: Thu, 13 Dec 2007 14:04:51 -0800
Subject: OpenSSH patches for Mac OS X
Message-ID: <6E36187B-E5AC-48CE-8B5A-95143143077D@apple.com>

OpenSSH Unix Dev,

	Mac OS X 10.5 recently shipped with OpenSSH 4.5p1.  This build  
includes a number of patches, some general bug fixes and some platform- 
specific fixes and enhancements.  These patches are available from our  
open source site (http://www.opensource.apple.com/darwinsource/10.5/OpenSSH-87/ 
).
	Following is a brief description of each patch.  We'd be more than  
happy to see any of these patches integrated into the official  
portable OpenSSH distribution.

AJ-5229538+5383306_keychain.patch
	Allows users to store key passphrases in the Mac OS X Keychain.

DVG+AJ-5370108_fix_globbing_in_Leopard_sftp.patch
	sftp makes certain assumptions about the behavior of glob(3) that no  
longer hold on Mac OS X.  This patch forces the openbsd-compat  
implementation.

DVG-3977221_manpage_tweaks.patch
	Removes references to login.conf from sshd_config man page.

DVG-4122722+5277818_new_EA.patch & DVG-4648874_preserve_EA_mtime.patch
	Adds a scp -E option, which preserves HFS+ extended attributes.

DVG-4157448+4920695_corrected_UsePAM_comment.patch
	Corrects comments in sshd_config about using PAM with OpenSSH.

DVG-4212542_auth_error_logging_fix.patch
	Keeps sshd from logging to the console.

DVG-4694589_16_group_limit_fix.patch
	Fixes issue with users in more than 16 groups.

DVG-4748610+4897588_ssh-agent_via_launchd.patch
	Adds support for launching ssh-agent from Mac OS X's launchd.

DVG-4808140_getpwuid_botch.patch
	Fixes a bug where ssh makes calls to getpwuid and expects the  
returned value to remain unchanged after subsequent calls, which is  
not guaranteed by POSIX.

DVG-4853931_enable_GSSAPI.patch & pam.patch
	Changes some default settings on Mac OS X.

DVG-4853931_enable_GSSAPI_AfterInstall.patch & apple-bsm.patch
	Unused.

DVG-4907495_name_resolution_error_message.patch
	Improves a generic "System error" message when hostname resolution  
fails.

DVG-5142987_launchd_DISPLAY_for_X11.patch
	Fixes issue with X11 forwarding on Mac OS X.

DVG-5258734_pty_permission_fix.patch & sshpty.c.patch
	Fixes PTY handling on Mac OS X.

bsm.patch
	Part of BSM support.

lastlog.patch
	Fixes lastlog on Mac OS X.

openssh-4.4p1-gsskex-20061002.patch
	Kerberos GSS Key Exchange support.

sacl.patch
	Service ACL support.


- Disco Vince Giffin
   OS Security Engineer
   Apple Inc.


From djm at mindrot.org  Fri Dec 14 10:27:18 2007
From: djm at mindrot.org (Damien Miller)
Date: Fri, 14 Dec 2007 10:27:18 +1100 (EST)
Subject: OpenSSH patches for Mac OS X
In-Reply-To: <6E36187B-E5AC-48CE-8B5A-95143143077D@apple.com>
References: <6E36187B-E5AC-48CE-8B5A-95143143077D@apple.com>
Message-ID: <alpine.BSO.0.99999.0712141025411.27644@fuyu.mindrot.org>

On Thu, 13 Dec 2007, Disco Vince Giffin wrote:

> OpenSSH Unix Dev,
> 
> 	Mac OS X 10.5 recently shipped with OpenSSH 4.5p1.  This build  
> includes a number of patches, some general bug fixes and some platform- 
> specific fixes and enhancements.  These patches are available from our  
> open source site (http://www.opensource.apple.com/darwinsource/10.5/OpenSSH-87/ 
> ).
> 	Following is a brief description of each patch.  We'd be more than  
> happy to see any of these patches integrated into the official  
> portable OpenSSH distribution.

Thanks! Could you confirm that these patches are being offered under
the license of the OpenSSH distribution and not the APSL?

-d

From jmknoble at pobox.com  Fri Dec 14 10:32:48 2007
From: jmknoble at pobox.com (Jim Knoble)
Date: Thu, 13 Dec 2007 18:32:48 -0500
Subject: OpenSSH patches for Mac OS X
In-Reply-To: <6E36187B-E5AC-48CE-8B5A-95143143077D@apple.com>
References: <6E36187B-E5AC-48CE-8B5A-95143143077D@apple.com>
Message-ID: <20071213233248.GB25170@crawfish.ais.com>

If you want any of your patches to be integrated, you should probably
start by (1) file Bugzilla reports for each of them at
https://bugzilla.mindrot.org/ , and (2) consider updating the patches
for the most current release of OpenSSH (which is 4.7p1 as of this
writing).

Circa 2007-12-13 17:04 dixit Disco Vince Giffin:

: OpenSSH Unix Dev,
: 
: 	Mac OS X 10.5 recently shipped with OpenSSH 4.5p1.  This build  
: includes a number of patches, some general bug fixes and some platform- 
: specific fixes and enhancements.  These patches are available from our  
: open source site (http://www.opensource.apple.com/darwinsource/10.5/OpenSSH-87/ 
: ).
: 	Following is a brief description of each patch.  We'd be more than  
: happy to see any of these patches integrated into the official  
: portable OpenSSH distribution.

  [...]

: - Disco Vince Giffin
:    OS Security Engineer
:    Apple Inc.

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: 6F39C2CC  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From vgiffin at apple.com  Fri Dec 14 15:11:15 2007
From: vgiffin at apple.com (Disco Vince Giffin)
Date: Thu, 13 Dec 2007 20:11:15 -0800
Subject: OpenSSH patches for Mac OS X
In-Reply-To: <alpine.BSO.0.99999.0712141025411.27644@fuyu.mindrot.org>
References: <6E36187B-E5AC-48CE-8B5A-95143143077D@apple.com>
	<alpine.BSO.0.99999.0712141025411.27644@fuyu.mindrot.org>
Message-ID: <F65BA982-A519-4E34-8753-6DF7F2773F29@apple.com>

Damien,

	Yes, these patches are offered under the same license as OpenSSH.
	Our policy is to distribute patches under the original licensing  
terms of the open source project.


- Disco Vince Giffin



On Dec 13, 2007, at 3:27 PM, Damien Miller wrote:

> On Thu, 13 Dec 2007, Disco Vince Giffin wrote:
>
>> OpenSSH Unix Dev,
>>
>> 	Mac OS X 10.5 recently shipped with OpenSSH 4.5p1.  This build
>> includes a number of patches, some general bug fixes and some  
>> platform-
>> specific fixes and enhancements.  These patches are available from  
>> our
>> open source site (http://www.opensource.apple.com/darwinsource/10.5/OpenSSH-87/
>> ).
>> 	Following is a brief description of each patch.  We'd be more than
>> happy to see any of these patches integrated into the official
>> portable OpenSSH distribution.
>
> Thanks! Could you confirm that these patches are being offered under
> the license of the OpenSSH distribution and not the APSL?
>
> -d


From nyh at math.technion.ac.il  Sat Dec 15 04:04:21 2007
From: nyh at math.technion.ac.il (Nadav Har'El)
Date: Fri, 14 Dec 2007 19:04:21 +0200
Subject: Enabling ServerAliveInterval by default
Message-ID: <20071214170421.GA10077@fermat.math.technion.ac.il>

Hi,

In the last several years, I noticed an annoying problem with ssh:
Long-running ssh connections are automatically disconnected after just a
few minutes of inactivity. This problem effects both interactive sessions
(using ssh without screen(1) became almost impossible...) as well as ssh port
forwarding and the likes.

I never noticed this problem until about 6 years ago, but since then have
noticed it on more and more client/server combinations that I use, to the
point that today I see this disconnection problem almost in every situation.
Although this problem is extremely annoying, I always viewed it as a "force
of nature" that I couldn't do anything about it.

But recently I found that that actually we *can* fix this diconnection
problem, and do it very easily.

It turns out that what causes this problem are network "devices" - firewalls,
load balancers and so on - which surround the client, server, or both, or the
networks they reside in. On the modern Internet, you'd be hard-pressed to
find a network configuration which doesn't have any of these devices.
The problem is that these devices need to track active connections, so to
avoid denial-of-service attacks and other problems, their creators took the
liberty to "forget" about active TCP connections after some time of inactivity
on these connections - often just after a few minutes of inactivity.
Because inactive ssh sessions by default don't transmit any data, these
firewalls forget about this session and when you do try to send some data
over this connection, it gets disconnected.

It turns out that recent versions of OpenSSH clients already have an option
that solves this problem - ServerAliveInterval.

Is there a reason why OpenSSH shouldn't enable ServerAliveInterval in the
default client configuration, with some interval of, say, 120 seconds?

I believe that because these automatically-disconnecting firewalls are almost
ubiquitous on today's firewall, this setting is very important, and most
users will not be able to discover it on their own (like I haven't, until
recently).

If ServerAliveInterval is enabled by default, with a short (few minute)
interval, we may also want to increase ServerAliveCountMax (which is
by default only 3), although I'm not sure about this. I think we should also
consider enabling by default the corresponding option in the server -
ClientAliveInterval.

Thanks in advance,
Nadav Har'El.

-- 
Nadav Har'El                        |        Friday, Dec 14 2007, 6 Tevet 5768
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Life is what happens to you while you're
http://nadav.harel.org.il           |busy making other plans. - John Lennon

From mouring at eviladmin.org  Sat Dec 15 09:30:00 2007
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Fri, 14 Dec 2007 16:30:00 -0600 (CST)
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <20071214170421.GA10077@fermat.math.technion.ac.il>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
Message-ID: <Pine.BSO.4.64.0712141622240.4463@miyako.eviladmin.org>



On Fri, 14 Dec 2007, Nadav Har'El wrote:

[..]
> Is there a reason why OpenSSH shouldn't enable ServerAliveInterval in the
> default client configuration, with some interval of, say, 120 seconds?
>

Because that is a packet every 120 seconds that isn't required for me and 
for most people with sane NAT timeouts or accessing local servers.  It 
could also increase internet costs for those under "Per-Meg" payment 
plans.

Same is true with ClientAliveInterval.  They exist to resolve a problem 
that someone may have, but I'd hate to see the extra traffic by default on 
my work LAN/WAN where it isn't required.

- Ben

From nyh at math.technion.ac.il  Sun Dec 16 07:05:00 2007
From: nyh at math.technion.ac.il (Nadav Har'El)
Date: Sat, 15 Dec 2007 22:05:00 +0200
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <Pine.BSO.4.64.0712141622240.4463@miyako.eviladmin.org>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
	<Pine.BSO.4.64.0712141622240.4463@miyako.eviladmin.org>
Message-ID: <20071215200500.GA7805@fermat.math.technion.ac.il>

On Fri, Dec 14, 2007, Ben Lindstrom wrote about "Re: Enabling ServerAliveInterval by default":
> On Fri, 14 Dec 2007, Nadav Har'El wrote:
> > Is there a reason why OpenSSH shouldn't enable ServerAliveInterval in the
> > default client configuration, with some interval of, say, 120 seconds?
> 
> Because that is a packet every 120 seconds that isn't required for me and 

Every default setting for an option is a compromise. Some people prefer it 
being disabled, and other people prefer it enabled. The question is just the
number of people who prefer each setting, and how much a person is hurt
or annoyed by the "wrong" setting.

I believe that for the ServerAliveInterval, the balance clearly falls to the
"enabled" side, because many people are seriously annoyed by the disabled
(current) setting, while only a few people will be very mildly annoyed by
the enabled setting (which I propose to make the default).

> for most people with sane NAT timeouts or accessing local servers. 

May I ask what is a "sane" NAT timeout? 5 minutes? 30 minutes? 1 hour? 1 day?

I've been using rsh, and later ssh, for remote login to Unix and Linux
servers for the last 16 years. What I usually want to do is open an ssh
window (or a port-forwarding session, and so on) to a remote host, and keep
this window open for a whole day - and often a lot more - once in a while
typing commands, but often leaving the window inactive for a long time.

I am guessing that a significant percentage of the SSH users do (or at least
want to do) the same thing. But doing this is impossible if ServerAliveInterval
is disabled, because after 5 minutes, 30 minutes, or 1 hour (or whatever you
think your "sane" timeout is), your session is disconnected, and when you
next go to the ssh window, you find that it is gone.

I haven't done a rigorous survey of how "sane" firewall/nat/etc. devices
behave, but I do use several client and server networks and experience the
basically same problem in all of them, so I'll be very surprised if I'm the
only one noticing it.

And about local servers - well, yes, ServerAliveInterval is not very important
in this case. But what is the price that we pay for it? A couple of TCP
packets every two minutes? This amounts to around 0.0001% (one milionth)
of the typical LAN bandwidth per inactive ssh session - I don't see how this
could worry anyone.

> It could also increase internet costs for those under "Per-Meg" payment 
> plans.

I'm not sure the 120 second timeout I suggested is actually needed. A more
rigourous survey can be conducted to see what timeouts people are experiencing
and set the interval at something higher - perhaps 5 minutes or 10 minutes
are enough (but in my experience, something like 30 minutes is probably too
much).

I think only in very rare circumstances will the extra heartbeat packets on
inactive ssh sessions will make any payment difference. On machines that have
very steep per-kilobyte payments but still plan to keep inactive ssh sessions
for very long times (can you give me an example of such a situation? and
remember that this situation can't have a firewall/etc that disconnects this
connection!) ssh can be configured to disable this ServerAliveInterval.
I just think that this situation - and not ssh on "normal" Internet-connected
computers - is the exceptional one, and as I explained above the default
should be chosen according to the typical use, not the exceptional one.

Nadav.

-- 
Nadav Har'El                        |      Saturday, Dec 15 2007, 7 Tevet 5768
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Attention: There will be a rain dance
http://nadav.harel.org.il           |Friday night, weather permitting.

From gert at greenie.muc.de  Mon Dec 17 02:29:22 2007
From: gert at greenie.muc.de (Gert Doering)
Date: Sun, 16 Dec 2007 16:29:22 +0100
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <20071215200500.GA7805@fermat.math.technion.ac.il>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
	<Pine.BSO.4.64.0712141622240.4463@miyako.eviladmin.org>
	<20071215200500.GA7805@fermat.math.technion.ac.il>
Message-ID: <20071216152921.GE308@greenie.muc.de>

Hi,

On Sat, Dec 15, 2007 at 10:05:00PM +0200, Nadav Har'El wrote:
> May I ask what is a "sane" NAT timeout? 5 minutes? 30 minutes? 1 hour? 1 day?

This borders very much on a religious war :-)

For me, no kind of NAT can ever be considered "sane".

Nevertheless the same issue applies to stateful firewall filtering, of
course - and in that case, I'd consider a timeout of "reasonably above
the values of TCP keepalive packets" to be "sane".

<religious>
Working around broken NATs instead of fixing the problem is not The Way To
Do Things.
</religious>


Personally, I have situations where I like ServerAliveInterval, and other
situations where it isn't needed, and is actually interfering with the
way I use SSH.  So I need to adapt the defaults either way.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From nyh at math.technion.ac.il  Mon Dec 17 05:56:25 2007
From: nyh at math.technion.ac.il (Nadav Har'El)
Date: Sun, 16 Dec 2007 20:56:25 +0200
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <20071216152921.GE308@greenie.muc.de>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
	<Pine.BSO.4.64.0712141622240.4463@miyako.eviladmin.org>
	<20071215200500.GA7805@fermat.math.technion.ac.il>
	<20071216152921.GE308@greenie.muc.de>
Message-ID: <20071216185625.GA9527@fermat.math.technion.ac.il>

On Sun, Dec 16, 2007, Gert Doering wrote about "Re: Enabling ServerAliveInterval by default":
> On Sat, Dec 15, 2007 at 10:05:00PM +0200, Nadav Har'El wrote:
> > May I ask what is a "sane" NAT timeout? 5 minutes? 30 minutes? 1 hour? 1 day?
> 
> This borders very much on a religious war :-)
> 
> For me, no kind of NAT can ever be considered "sane".
> <religious>
> Working around broken NATs instead of fixing the problem is not The Way To
> Do Things.
> </religious>

Note that I wasn't at all talking specifically about NAT. As I said in my
original post, many types of "stateful" devices, including for example
firewalls and load-balancers cause these problems.

So I'm having a very hard time understand why you see this as a religous war.

I'm having a very hard time believing that I have been the only person who
in the course of the last few years found it harder and harder to keep
non-LAN ssh connections active without being disconnected after a few minutes
of inactivity. I've seen this problem on several combinations of client and
server networks.

> Personally, I have situations where I like ServerAliveInterval, and other
> situations where it isn't needed, and is actually interfering with the
> way I use SSH.  So I need to adapt the defaults either way.

I am curious - how does ServerAliveInterval (again, with a large
ServerAliveCountMax, not the default 3) interfer with the way you use SSH?

-- 
Nadav Har'El                        |        Sunday, Dec 16 2007, 8 Tevet 5768
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |How much wood would a woodchuck chuck if
http://nadav.harel.org.il           |a woodchuck would chuck wood?

From bob at proulx.com  Mon Dec 17 06:21:58 2007
From: bob at proulx.com (Bob Proulx)
Date: Sun, 16 Dec 2007 12:21:58 -0700
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <20071216185625.GA9527@fermat.math.technion.ac.il>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
	<Pine.BSO.4.64.0712141622240.4463@miyako.eviladmin.org>
	<20071215200500.GA7805@fermat.math.technion.ac.il>
	<20071216152921.GE308@greenie.muc.de>
	<20071216185625.GA9527@fermat.math.technion.ac.il>
Message-ID: <20071216192158.GA32151@dementia.proulx.com>

Nadav Har'El wrote:
> I'm having a very hard time believing that I have been the only person who
> in the course of the last few years found it harder and harder to keep
> non-LAN ssh connections active without being disconnected after a few minutes
> of inactivity. I've seen this problem on several combinations of client and
> server networks.

I personally am not seeing this problem with any of the connections
that I am keeping online for long periods of time.

> > Personally, I have situations where I like ServerAliveInterval, and other
> > situations where it isn't needed, and is actually interfering with the
> > way I use SSH.  So I need to adapt the defaults either way.
> 
> I am curious - how does ServerAliveInterval (again, with a large
> ServerAliveCountMax, not the default 3) interfer with the way you use SSH?

One of the issues with setting a "keepalive" diddle is that it is also
a "makedead" diddle.  If the connection is not online at that moment
then the diddle packet will cause the connection failure to be noticed
and will make it die.  This causes many people to not refer to this so
much as a keepalive but as a makedead.  It makes the connection dead.
Note that BatchMode sets keepalives automatically.

Many people who now have connections that stay alive okay without a
diddle packet would, if it were globally enabled, find that their
connections die because the network connection timed out at times that
they did not care about using it.  The diddle would make their
connections dead.  Without the diddle then the connection only dies if
it is offline when real data is needed to be transferred.  It will
survive brief periods of the network being offline when nothing is
happening.  It only has problems if there are real problems.  With a
forced keepalive diddle packet sent periodically it may die due to
synthesized data.  This may happen at times when nothing would have
been active without the keepalive setting and the connection would
have survived it okay.

There are two valid sides to this problem.  There is no clear solution
that solves both problems at the same time.  Neither is clearly right
with the other clearly wrong.  This is what makes it a religous war
between the two opposing viewpoints.  There is no single right answer.
It is a value judgement as to which one is more important or more
common than the other one.  In these situations the status quo is
often the path of least resistance because it thrashes the least
number of people.

Bob

From hamish at gmail.com  Mon Dec 17 10:21:24 2007
From: hamish at gmail.com (Hamish Allan)
Date: Sun, 16 Dec 2007 23:21:24 +0000
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <20071216192158.GA32151@dementia.proulx.com>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
	<Pine.BSO.4.64.0712141622240.4463@miyako.eviladmin.org>
	<20071215200500.GA7805@fermat.math.technion.ac.il>
	<20071216152921.GE308@greenie.muc.de>
	<20071216185625.GA9527@fermat.math.technion.ac.il>
	<20071216192158.GA32151@dementia.proulx.com>
Message-ID: <597e7edb0712161521i65cc574as55137c7786356140@mail.gmail.com>

On Dec 16, 2007 6:56 PM, Nadav Har'El <nyh at math.technion.ac.il> wrote:

> I'm having a very hard time believing that I have been the only person who
> in the course of the last few years found it harder and harder to keep
> non-LAN ssh connections active without being disconnected after a few minutes
> of inactivity. I've seen this problem on several combinations of client and
> server networks.

FWIW, your experience mirrors mine almost exactly and I am very
grateful to you for bringing ServerAliveInterval to my attention.

On Dec 16, 2007 7:21 PM, Bob Proulx <bob at proulx.com> wrote:

> Without the diddle then the connection only dies if
> it is offline when real data is needed to be transferred.  It will
> survive brief periods of the network being offline when nothing is
> happening.  It only has problems if there are real problems.

This cuts both ways -- it only notices problems when they have already
become problems, rather than noticing potential problems and
addressing them.

Hamish

From philip at yarra.no-ip.org  Mon Dec 17 10:30:23 2007
From: philip at yarra.no-ip.org (Philip)
Date: Mon, 17 Dec 2007 10:30:23 +1100
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <20071216185625.GA9527@fermat.math.technion.ac.il>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
	<20071216152921.GE308@greenie.muc.de>
	<20071216185625.GA9527@fermat.math.technion.ac.il>
Message-ID: <200712171030.23170.philip@yarra.no-ip.org>

On Monday 17 December 2007 05:56:25 Nadav Har'El wrote:
> I'm having a very hard time believing that I have been the only person who
> in the course of the last few years found it harder and harder to keep
> non-LAN ssh connections active without being disconnected after a few
> minutes of inactivity. I've seen this problem on several combinations of
> client and server networks.

+1 here - it also took me a long while to figure out what was going on when I 
had this problem. I wish it had been a default years ago.

It's easy enough to change the defaults on machines under your own control, 
but the biggest problem I had was convincing the administrators of remote 
systems I had to use to change their sshd_config. They are far more 
comfortable staying with the bundled defaults. For some systems, we set up a 
shell alias:

alias ka='while [ 1 ]; do echo -n "."; sleep 120; done'

Then of course you have to remember to run that each time you stop actively 
using a session. In short: PITA.

Regarding Bob Proulx's discussion of "make-dead" vs. "keep-alive" - it's a 
point worth considering. I've usually set an interval of a few minutes, and a 
very large ServerAliveCountMax so that it's used only for keeping the 
connection alive, not disconnecting temporarily-missing clients. Is this 
something worth considering as a default? 

Regards, Philip.

From william at 25thandClement.com  Mon Dec 17 11:15:06 2007
From: william at 25thandClement.com (William Ahern)
Date: Sun, 16 Dec 2007 16:15:06 -0800
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <200712171030.23170.philip@yarra.no-ip.org>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
	<20071216152921.GE308@greenie.muc.de>
	<20071216185625.GA9527@fermat.math.technion.ac.il>
	<200712171030.23170.philip@yarra.no-ip.org>
Message-ID: <20071217001506.GA14955@wilbur.25thandClement.com>

On Mon, Dec 17, 2007 at 10:30:23AM +1100, Philip wrote:
> On Monday 17 December 2007 05:56:25 Nadav Har'El wrote:
> > I'm having a very hard time believing that I have been the only person who
> > in the course of the last few years found it harder and harder to keep
> > non-LAN ssh connections active without being disconnected after a few
> > minutes of inactivity. I've seen this problem on several combinations of
> > client and server networks.
> 
> +1 here - it also took me a long while to figure out what was going on when I 
> had this problem. I wish it had been a default years ago.
> 
> It's easy enough to change the defaults on machines under your own control, 
> but the biggest problem I had was convincing the administrators of remote 
> systems I had to use to change their sshd_config. They are far more 

I would hope that you also made a pass at trying to convince them not to use
stateful firewalls (or firewalls, period) in situations where they're
entirely superfluous--which encompasses the vast majority of current usages.
(NAT is another issue; equally abhorrent, its not useful to complain without
available alternatives--IPv6.)

I too have watched this problem rise over the years, and it ebbs and flows
with the laziness and inexperience of administrators. I've seen servers
hacked into countless times, and if there's any correlation with firewalls I
would say that those who use firewalls are more likely to get hacked
(especially those who aren't programmers, or socket programmers, because
they mistrust or just don't plain understand the address and port system,
which of course leads to many other mistakes; in this case ignorance is
particularly dangerous, because a firewall just adds more lines of code
along the network path.)

Anyhow, that's my rant. I tried to stay out of it. Reasonable people can
disagree regarding the setting. But whenever you find a network path with
the problem, and you actually bother communicating with another admin, I
would hope we can all agree we have a duty (and/or just plain self-interest)
to try to inject some sanity into this horrible state of affairs. Likely
you'll be ignored, but there have been successes, and in any event its
worthwhile to raise awareness.

Its worthwhile to point that, thankfully, intermediate ISPs aren't causing
this problem. Its either you or your remote peer; so if your pleadings fall
on deaf ears on this forum that's your explanation.


From philip at yarra.no-ip.org  Mon Dec 17 12:24:43 2007
From: philip at yarra.no-ip.org (Philip)
Date: Mon, 17 Dec 2007 12:24:43 +1100
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <20071217001506.GA14955@wilbur.25thandClement.com>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
	<200712171030.23170.philip@yarra.no-ip.org>
	<20071217001506.GA14955@wilbur.25thandClement.com>
Message-ID: <200712171224.43202.philip@yarra.no-ip.org>

On Monday 17 December 2007 11:15:06 William Ahern wrote:
> I would hope that you also made a pass at trying to convince them [not to 
use evil stuff]

In the position where I mainly encountered such problems, we had to consider:
- language barriers - I only speak English, which makes it hard for me to 
communicate the issue
- political issues - inter-departmental, vendor/purchaser, international
- "face" issues - senior admins often don't take kindly to some foreigner 
telling them how to do their jobs
- competence issues - often, Windows admins have had Unix boxes foisted on 
them with little or no training
- type of network connection - the admins are usually on the same LAN as the 
SSH hosts, so they never see the problem themselves

I agree, we should try to get everyone to do The Right Thing, but sometimes it 
just isn't going to happen. Sensible defaults are useful in such cases 
(defining "sensible" is going to be the problem here, I suspect).

On the bright side: I don't do that job any more.

Regards, Philip.

From stuge-openssh-unix-dev at cdy.org  Mon Dec 17 13:11:49 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Mon, 17 Dec 2007 03:11:49 +0100
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <200712171224.43202.philip@yarra.no-ip.org>
	<200712171030.23170.philip@yarra.no-ip.org>
	<20071216185625.GA9527@fermat.math.technion.ac.il>
References: <200712171224.43202.philip@yarra.no-ip.org>
	<20071214170421.GA10077@fermat.math.technion.ac.il>
	<20071216152921.GE308@greenie.muc.de>
	<20071216185625.GA9527@fermat.math.technion.ac.il>
	<200712171030.23170.philip@yarra.no-ip.org>
	<20071214170421.GA10077@fermat.math.technion.ac.il>
	<Pine.BSO.4.64.0712141622240.4463@miyako.eviladmin.org>
	<20071215200500.GA7805@fermat.math.technion.ac.il>
	<20071216152921.GE308@greenie.muc.de>
	<20071216185625.GA9527@fermat.math.technion.ac.il>
Message-ID: <20071217021149.23960.qmail@cdy.org>

On Sun, Dec 16, 2007 at 08:56:25PM +0200, Nadav Har'El wrote:
> I'm having a very hard time believing that I have been the only
> person who in the course of the last few years found it harder and
> harder to keep non-LAN ssh connections active without being
> disconnected after a few minutes of inactivity.

I don't find it hard.

If you are running the ssh client, there is ServerAliveInterval and
ServerAliveCountMax.

If you are running the sshd, there is ClientAliveInterval and
ClientAliveCountMax.

Set them up so that OpenSSH works for you the way you want it to.


On Mon, Dec 17, 2007 at 10:30:23AM +1100, Philip wrote:
> +1 here - it also took me a long while to figure out what was going
> on when I had this problem.

This is of course unfortunate. But please keep in mind that what you
are experiencing is not originating from or caused by OpenSSH (or any
other application for that matter) and thus that is the wrong place
to _solve_ the problem.


> I wish it had been a default years ago.

I believe in obvious defaults. That is impossible in this case.


> It's easy enough to change the defaults on machines under your own
> control, but the biggest problem I had was convincing the
> administrators of remote systems I had to use to change their
> sshd_config.

Again, there are some options also in the client that will send extra
IDLE packets.


> For some systems, we set up a shell alias:
> 
> alias ka='while [ 1 ]; do echo -n "."; sleep 120; done'
> 
> Then of course you have to remember to run that each time you stop
> actively using a session. In short: PITA.

If you want to get creative like this there is a large number of
workarounds that could be concieved. The channel and subsystem
concepts in SSH could be used to do stuff. All automated.

It will be easier to change your local config though.


> Regarding Bob Proulx's discussion of "make-dead" vs. "keep-alive" -
> it's a point worth considering. I've usually set an interval of a
> few minutes, and a very large ServerAliveCountMax so that it's used
> only for keeping the connection alive, not disconnecting
> temporarily-missing clients. Is this something worth considering as
> a default?

I don't think so, because sending packets like this on a dead
connection will (naturally) also affect the OS TCP connection
state machine, and then you would suddenly need to be root everywhere
in order to fully control what and how connections should be kept
alive. (Because now it's a kernel setting.)


On Mon, Dec 17, 2007 at 12:24:43PM +1100, Philip wrote:
> In the position where I mainly encountered such problems, we had to
> consider:
> - language barriers - I only speak English, which makes it hard for
> me to communicate the issue

If root does not understand english I see how it can be difficult for
them to work with the configuration files and corresponding
documentation too. I would argue this falls under competence.


> - political issues - inter-departmental, vendor/purchaser,
> international

As much as I would like them to, it is quite impossible for OpenSSH
configuration defaults to abstract these issues.


> - "face" issues - senior admins often don't take kindly to some
> foreigner telling them how to do their jobs

One can ask in many ways. The admin is supposedly there to support
users, and thus it should be possible for users to formally, or even
informally, submit a change request so that they can do their job
better. If that's not the case, I would argue that this is a
political issue. See above.


> - competence issues - often, Windows admins have had Unix boxes
> foisted on them with little or no training

So you want an AI configuration file generator? I strongly believe
that no effort whatsoever should be spent on trying to solve this
problem since it will be futile. Better just educate people!


> - type of network connection - the admins are usually on the same
> LAN as the SSH hosts, so they never see the problem themselves

See face issues. root should care.


> I agree, we should try to get everyone to do The Right Thing, but
> sometimes it just isn't going to happen. Sensible defaults are
> useful in such cases (defining "sensible" is going to be the
> problem here, I suspect).

Certainly if a single set of defaults must be "sensible" for all
possible combinations of {language,political,competence} issues.


//Peter

From mouring at eviladmin.org  Mon Dec 17 16:22:58 2007
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Sun, 16 Dec 2007 23:22:58 -0600 (CST)
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <20071217021149.23960.qmail@cdy.org>
References: <200712171224.43202.philip@yarra.no-ip.org>
	<20071214170421.GA10077@fermat.math.technion.ac.il>
	<20071216152921.GE308@greenie.muc.de>
	<20071216185625.GA9527@fermat.math.technion.ac.il>
	<200712171030.23170.philip@yarra.no-ip.org>
	<20071214170421.GA10077@fermat.math.technion.ac.il>
	<Pine.BSO.4.64.0712141622240.4463@miyako.eviladmin.org>
	<20071215200500.GA7805@fermat.math.technion.ac.il>
	<20071216152921.GE308@greenie.muc.de>
	<20071216185625.GA9527@fermat.math.technion.ac.il>
	<20071217021149.23960.qmail@cdy.org>
Message-ID: <Pine.BSO.4.64.0712162257260.4463@miyako.eviladmin.org>


On Mon, 17 Dec 2007, Peter Stuge wrote:
> On Mon, Dec 17, 2007 at 12:24:43PM +1100, Philip wrote:

[..]
>> - "face" issues - senior admins often don't take kindly to some
>> foreigner telling them how to do their jobs
>
> One can ask in many ways. The admin is supposedly there to support
> users, and thus it should be possible for users to formally, or even
> informally, submit a change request so that they can do their job
> better. If that's not the case, I would argue that this is a
> political issue. See above.
>

As an admin I have to interject that a lot of people tell us "how to do 
our jobs" and quite often they forget that we are not just responsible to 
make their stuff work, but balance the needs of everyone.

And that is why we tend to get miffed at outsiders telling us how to do 
our jobs. =)

So forgive us if we tend to disregard "drive-by" admining from the general 
population in a lot of cases.

[..]

>> I agree, we should try to get everyone to do The Right Thing, but
>> sometimes it just isn't going to happen. Sensible defaults are
>> useful in such cases (defining "sensible" is going to be the
>> problem here, I suspect).
>
> Certainly if a single set of defaults must be "sensible" for all
> possible combinations of {language,political,competence} issues.
>
>

Thus is the reason why one hires folks to manage servers.  So that they 
can decide what makes sense for the majority of their users.

My last comment for people asking for it to be enabled by default is to 
start thinking of the traffic in terms of a medium to large company (300 - 
3000 employees) and the additional bandwith consumed on a daily basis 
by this feature when it isn't required.

Colour me silly, but such options really should be deployed as a scalpel, 
and not as a blunt hammer.

Granted, I speak for only myself and frankly I'm no one important in the 
grand scheme of things.

- Ben

From djm at mindrot.org  Mon Dec 17 17:08:27 2007
From: djm at mindrot.org (Damien Miller)
Date: Mon, 17 Dec 2007 17:08:27 +1100 (EST)
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <20071214170421.GA10077@fermat.math.technion.ac.il>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
Message-ID: <alpine.BSO.0.99999.0712171628080.3051@fuyu.mindrot.org>

On Fri, 14 Dec 2007, Nadav Har'El wrote:

> It turns out that recent versions of OpenSSH clients already have an option
> that solves this problem - ServerAliveInterval.
> 
> Is there a reason why OpenSSH shouldn't enable ServerAliveInterval in the
> default client configuration, with some interval of, say, 120 seconds?

Activating protocol-level keepalives is not without costs:
{Client,Server}AliveInterval is not just a keepalive - it is also a
"make dead" that will kill a connection that has experienced packet loss
for AliveInterval*AliveCountMax, but which TCP would otherwise have been
able to recover from.

-d

From nyh at math.technion.ac.il  Mon Dec 17 21:33:16 2007
From: nyh at math.technion.ac.il (Nadav Har'El)
Date: Mon, 17 Dec 2007 12:33:16 +0200
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <20071217001506.GA14955@wilbur.25thandClement.com>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
	<20071216152921.GE308@greenie.muc.de>
	<20071216185625.GA9527@fermat.math.technion.ac.il>
	<200712171030.23170.philip@yarra.no-ip.org>
	<20071217001506.GA14955@wilbur.25thandClement.com>
Message-ID: <20071217103316.GA641@fermat.math.technion.ac.il>

On Sun, Dec 16, 2007, William Ahern wrote about "Re: Enabling ServerAliveInterval by default":
> Its worthwhile to point that, thankfully, intermediate ISPs aren't causing
> this problem. Its either you or your remote peer

This is correct for some definition of "you" and "remote peer".

What do you do when "you" is a workstation in a large company, and
"remote peer" is a workstation in large university? You obvious can't
convince either of these sites to stop using their firewall/nat/whatever,
even if you have good arguments.

-- 
Nadav Har'El                        |        Monday, Dec 17 2007, 8 Tevet 5768
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |The road to good intentions is paved with
http://nadav.harel.org.il           |hell.

From markus.r.friedl at arcor.de  Mon Dec 17 21:27:06 2007
From: markus.r.friedl at arcor.de (Markus Friedl)
Date: Mon, 17 Dec 2007 11:27:06 +0100
Subject: Enabling ServerAliveInterval by default
In-Reply-To: <20071214170421.GA10077@fermat.math.technion.ac.il>
References: <20071214170421.GA10077@fermat.math.technion.ac.il>
Message-ID: <20071217102706.GA26617@folly>

On Fri, Dec 14, 2007 at 07:04:21PM +0200, Nadav Har'El wrote:
> Is there a reason why OpenSSH shouldn't enable ServerAliveInterval in the
> default client configuration, with some interval of, say, 120 seconds?

Yes, it will break TCP where NAT is not involved, TCP is robust.
What you need is some kind of 'NAT-detection', but that's scary.

-m

From postmaster at mx4.sidi.istruzione.it  Wed Dec 19 23:31:59 2007
From: postmaster at mx4.sidi.istruzione.it (Content-filter at mx4.sidi.istruzione.it)
Date: Wed, 19 Dec 2007 13:31:59 +0100 (CET)
Subject: VIRUS (Worm.Mydoom.M): IN UNA E-MAIL DA LEI INVIATA
In-Reply-To: <20071219123155.D19E150A3A@mx4.sidi.istruzione.it>
Message-ID: <VS04051-03-13@mx4.sidi.istruzione.it>

VIRUS ALERT

Il sistema di scansione ha rilevato un problema
in una email presumibilmente inviata da Lei
-> (<openssh-unix-dev at mindrot.org>),
per il seguente destinatario:
-> agtd09000r at istruzione.it

La consegna del messaggio non e' potuta avvenire

Di seguito i riferimenti della e-Mail inviata:
------------------------- BEGIN HEADERS -----------------------------
Return-Path: <openssh-unix-dev at mindrot.org>
Received: from mindrot.org (unknown [62.123.102.59])
	by mx4.sidi.istruzione.it (Mail Service) with ESMTP id D19E150A3A
	for <agtd09000r at istruzione.it>; Wed, 19 Dec 2007 13:31:54 +0100 (CET)
From: openssh-unix-dev at mindrot.org
To: agtd09000r at istruzione.it
Subject: Delivery reports about your e-mail
Date: Wed, 19 Dec 2007 13:47:12 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0005_EB10B04D.FE1169BA"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-Id: <20071219123155.D19E150A3A at mx4.sidi.istruzione.it>
-------------------------- END HEADERS ------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: header
Type: text/rfc822-headers
Size: 695 bytes
Desc: Message headers
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071219/82cb4538/attachment.bin 

From cecglis at sandia.gov  Wed Dec 19 08:04:25 2007
From: cecglis at sandia.gov (Glissman, Cecily A)
Date: Tue, 18 Dec 2007 14:04:25 -0700
Subject: Installation difficulties
Message-ID: <C846567E733D5D49B79A3CADF840F6FB04202108@ES23SNLNT.srn.sandia.gov>

Hello,

I am trying to install openssl-0.9.8 for my linux emulator, Cygwin.

There is a file named config in the directory.  When I execute,
./config, I get the following output:

Operating system: i686-whatever-cygwin
Configuring for Cygwin
Operating system: i686-whatever-cygwin
Configuring for Cygwin
Configuring for Cygwin
    no-camellia     [default]  OPENSSL_NO_CAMELLIA (skip dir)
    no-gmp          [default]  OPENSSL_NO_GMP (skip dir)
    no-krb5         [krb5-flavor not specified] OPENSSL_NO_KRB5
    no-mdc2         [default]  OPENSSL_NO_MDC2 (skip dir)
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-rfc3779      [default]  OPENSSL_NO_RFC3779 (skip dir)
    no-seed         [default]  OPENSSL_NO_SEED (skip dir)
    no-shared       [default] 
    no-tlsext       [default]  OPENSSL_NO_TLSEXT (skip dir)
    no-zlib         [default] 
    no-zlib-dynamic [default] 
IsMK1MF=0
CC            =gcc
CFLAG         =-DOPENSSL_THREADS  -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS
-DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM
-DRMD160_ASM -DAES_ASM
EX_LIBS       =
CPUID_OBJ     =x86cpuid-cof.o
BN_ASM        =bn86-cof.o co86-cof.o
DES_ENC       =dx86-cof.o yx86-cof.o
AES_ASM_OBJ   =ax86-cof.o
BF_ENC        =bx86-cof.o
CAST_ENC      =cx86-cof.o
RC4_ENC       =rx86-cof.o
RC5_ENC       =r586-cof.o
MD5_OBJ_ASM   =mx86-cof.o
SHA1_OBJ_ASM  =sx86-cof.o s512sse2-cof.o
RMD160_OBJ_ASM=rm86-cof.o
PROCESSOR     =
RANLIB        =true
ARFLAGS       =
PERL          =perl
THIRTY_TWO_BIT mode
DES_PTR used
DES_RISC1 used
DES_UNROLL used
BN_LLONG mode
RC4_INDEX mode
RC4_CHUNK is undefined



Then the complaint:

'make' is not recognized as an internal or external command, operable
program or batch file.



Do you have any suggestions?  (I don't care which version of ssh I
install - I just need to have ssh capability)

Thanks!

Cecily Glissman


From stuge-openssh-unix-dev at cdy.org  Thu Dec 20 02:36:06 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Wed, 19 Dec 2007 16:36:06 +0100
Subject: Installation difficulties
In-Reply-To: <C846567E733D5D49B79A3CADF840F6FB04202108@ES23SNLNT.srn.sandia.gov>
References: <C846567E733D5D49B79A3CADF840F6FB04202108@ES23SNLNT.srn.sandia.gov>
Message-ID: <20071219153607.25096.qmail@cdy.org>

Hi Cecily,

On Tue, Dec 18, 2007 at 02:04:25PM -0700, Glissman, Cecily A wrote:
> I am trying to install openssl-0.9.8 for my linux emulator, Cygwin.

First off, this is the OpenSSH mailing list, so there may be a better
forum (the Cygwin list or possibly the OpenSSL list) to ask.

Your OpenSSL config output looks fine.


> Then the complaint:
> 
> 'make' is not recognized as an internal or external command,
> operable program or batch file.

This is because GNU make has not been installed in your Cygwin
system.


> Do you have any suggestions?  (I don't care which version of ssh
> I install - I just need to have ssh capability)

Then I suggest that you simply install the OpenSSH that is included
in the Cygwin distribution.

I believe all you need to do is run the Cygwin installer and add the
openssh package. If you run into trouble I think the best place to
ask is the Cygwin mailing lists.


//Peter

From vinschen at redhat.com  Thu Dec 20 02:28:11 2007
From: vinschen at redhat.com (Corinna Vinschen)
Date: Wed, 19 Dec 2007 16:28:11 +0100
Subject: Installation difficulties
In-Reply-To: <C846567E733D5D49B79A3CADF840F6FB04202108@ES23SNLNT.srn.sandia.gov>
References: <C846567E733D5D49B79A3CADF840F6FB04202108@ES23SNLNT.srn.sandia.gov>
Message-ID: <20071219152811.GB18860@calimero.vinschen.de>

On Dec 18 14:04, Glissman, Cecily A wrote:
> Hello,
> 
> I am trying to install openssl-0.9.8 for my linux emulator, Cygwin.
> 
> There is a file named config in the directory.  When I execute,
> ./config, I get the following output:

First of all, you don't need to build from source.  The latest OpenSSL
version 0.9.8g is available as part of the Cygwin net distribution:

  http://cygwin.com/cgi-bin2/package-grep.cgi?grep=openssl

Second, the right way to create the OpenSSL package for Cygwin from
source is to run the util/cygwin.sh shell script from the openssl
toplevel source dir.

> Then the complaint:
> 
> 'make' is not recognized as an internal or external command, operable
> program or batch file.

This has nothing to do with OpenSSL.  You either don't have make
installed, or your PATH environment variable doesn't point to the Cygwin
/bin directory.  When using Cygwin anyway, I also wouldn't run this from
cmd.exe.  Start a POSIX shell like bash or tcsh.  Bash is what you get
automatically when running the cygwin.bat batch file.  Everything you
need is part of the Cygwin net distro, really.

Since all of this is rather Cygwin distro related than OpenSSL related,
you should send subsequent mails to the cygwin AT cygwin DOT com mailing
list instead of here.  I've set the Reply-To accordingly.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

From duncan_j_ferguson at yahoo.co.uk  Wed Dec 19 22:34:39 2007
From: duncan_j_ferguson at yahoo.co.uk (Duncan Ferguson)
Date: Wed, 19 Dec 2007 11:34:39 +0000
Subject: $HOME/.ssh/config and host/hostname resolution how-to?
Message-ID: <77D8FED0-7C30-4454-93AD-4C5EB100C86C@yahoo.co.uk>

Hiya,

What is the easiest way of looking up a hostname to see if it exists,  
taking into account the .ssh/config file?

If i have an entry in my file

host host1
   hostname server.domain.name

then usual OS calls won't recognise the 'alias' host1.  So, i need to  
make a call via ssh somehow to check if the name resolves without  
actually initiating a full blown 'expensive' connection to it, such  
as using 'ssh host1 true' or something (which also relies on 'true'  
being on the path, or always being installed in the same place if the  
path is provided - neither of which can be guaranteed).

I tried ssh-keyscan, but this ignores the config file (probably  
correctly), so what is the more appropriate way to perform the name  
validation?  I have tried 'ssh -n host1' which seems to work - would  
this be the best option?

I am using:

   OpenSSH_4.6p1 Debian-5build1, OpenSSL 0.9.8e 23 Feb 2007

on Etch in this instance, but the method will need to be portable.

Thanks

   Duncs

From dtucker at zip.com.au  Thu Dec 20 07:40:01 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 19 Dec 2007 21:40:01 +0100
Subject: $HOME/.ssh/config and host/hostname resolution how-to?
In-Reply-To: <77D8FED0-7C30-4454-93AD-4C5EB100C86C@yahoo.co.uk>
References: <77D8FED0-7C30-4454-93AD-4C5EB100C86C@yahoo.co.uk>
Message-ID: <476981A1.6050201@zip.com.au>

Duncan Ferguson wrote:
> Hiya,
> 
> What is the easiest way of looking up a hostname to see if it exists,  
> taking into account the .ssh/config file?
> 
> If i have an entry in my file
> 
> host host1
>    hostname server.domain.name
> 
> then usual OS calls won't recognise the 'alias' host1.  So, i need to  
> make a call via ssh somehow to check if the name resolves without  
> actually initiating a full blown 'expensive' connection to it, such  
> as using 'ssh host1 true' or something (which also relies on 'true'  
> being on the path, or always being installed in the same place if the  
> path is provided - neither of which can be guaranteed).
> 
> I tried ssh-keyscan, but this ignores the config file (probably  
> correctly), so what is the more appropriate way to perform the name  
> validation?  I have tried 'ssh -n host1' which seems to work - would  
> this be the best option?

I'm not quite sure what you're trying to achieve, could you give an example?

Depending on what you want, there's a couple of options.

If you just want to return quickly if the host is down, you can set the 
ConnectTimeout to a lowish value.

If you want to do something more complicated, (eg fail if your 
dial-on-demand link is down or similar) you could use a ProxyCommand and 
implement whatever logic you want in a shell script (that finishes by 
exec'ing netcat).

-- 
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 wknox at mitre.org  Thu Dec 20 02:23:02 2007
From: wknox at mitre.org (Knox, Bill)
Date: Wed, 19 Dec 2007 10:23:02 -0500
Subject: Installation difficulties
In-Reply-To: <C846567E733D5D49B79A3CADF840F6FB04202108@ES23SNLNT.srn.sandia.gov>
References: <C846567E733D5D49B79A3CADF840F6FB04202108@ES23SNLNT.srn.sandia.gov>
Message-ID: <3B660B4ACB06BE488E3938F95115E4DE02135C32@IMCSRV4.MITRE.ORG>

Your best bet is to just install the OpenSSH version that comes with
Cygwin instead of trying to build it yourself - the maintainers of that
package are very good about keeping it up to date with the latest
portable release. And in case you ever need to post to the Cygwin list,
Cygwin is "an emulation layer providing substantial POSIX system call
functionality" which provides "a Linux-like environment for Windows" -
it ain't Linux or a Linux emulator, and calling it that tends to get
you chewed out by some other people on the Cygwin list.

                  Bill Knox
                  Lead Infosec Engineer/Scientist
                  The MITRE Corporation

-----Original Message-----
From: openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org
[mailto:openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org] On Behalf
Of Glissman, Cecily A
Sent: Tuesday, December 18, 2007 4:04 PM
To: openssh-unix-dev at mindrot.org
Subject: Installation difficulties

Hello,

I am trying to install openssl-0.9.8 for my linux emulator, Cygwin.

There is a file named config in the directory.  When I execute,
./config, I get the following output:

Operating system: i686-whatever-cygwin
Configuring for Cygwin
Operating system: i686-whatever-cygwin
Configuring for Cygwin
Configuring for Cygwin
    no-camellia     [default]  OPENSSL_NO_CAMELLIA (skip dir)
    no-gmp          [default]  OPENSSL_NO_GMP (skip dir)
    no-krb5         [krb5-flavor not specified] OPENSSL_NO_KRB5
    no-mdc2         [default]  OPENSSL_NO_MDC2 (skip dir)
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-rfc3779      [default]  OPENSSL_NO_RFC3779 (skip dir)
    no-seed         [default]  OPENSSL_NO_SEED (skip dir)
    no-shared       [default] 
    no-tlsext       [default]  OPENSSL_NO_TLSEXT (skip dir)
    no-zlib         [default] 
    no-zlib-dynamic [default] 
IsMK1MF=0
CC            =gcc
CFLAG         =-DOPENSSL_THREADS  -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS
-DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM
-DRMD160_ASM -DAES_ASM
EX_LIBS       =
CPUID_OBJ     =x86cpuid-cof.o
BN_ASM        =bn86-cof.o co86-cof.o
DES_ENC       =dx86-cof.o yx86-cof.o
AES_ASM_OBJ   =ax86-cof.o
BF_ENC        =bx86-cof.o
CAST_ENC      =cx86-cof.o
RC4_ENC       =rx86-cof.o
RC5_ENC       =r586-cof.o
MD5_OBJ_ASM   =mx86-cof.o
SHA1_OBJ_ASM  =sx86-cof.o s512sse2-cof.o
RMD160_OBJ_ASM=rm86-cof.o
PROCESSOR     =
RANLIB        =true
ARFLAGS       =
PERL          =perl
THIRTY_TWO_BIT mode
DES_PTR used
DES_RISC1 used
DES_UNROLL used
BN_LLONG mode
RC4_INDEX mode
RC4_CHUNK is undefined



Then the complaint:

'make' is not recognized as an internal or external command, operable
program or batch file.



Do you have any suggestions?  (I don't care which version of ssh I
install - I just need to have ssh capability)

Thanks!

Cecily Glissman

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From hamish at gmail.com  Thu Dec 20 09:41:04 2007
From: hamish at gmail.com (Hamish Allan)
Date: Wed, 19 Dec 2007 22:41:04 +0000
Subject: $HOME/.ssh/config and host/hostname resolution how-to?
In-Reply-To: <77D8FED0-7C30-4454-93AD-4C5EB100C86C@yahoo.co.uk>
References: <77D8FED0-7C30-4454-93AD-4C5EB100C86C@yahoo.co.uk>
Message-ID: <597e7edb0712191441l6c42d948rdf2b97f71a9e6e37@mail.gmail.com>

On Dec 19, 2007 11:34 AM, Duncan Ferguson <duncan_j_ferguson at yahoo.co.uk> wrote:

> What is the easiest way of looking up a hostname to see if it exists,
> taking into account the .ssh/config file?

It sounds to me like you want to use ssh to parse ~/.ssh/config for
you. To avoid any overhead, you could simply parse it yourself.

Hamish

From wojak at inet.biz.pl  Fri Dec 21 06:54:55 2007
From: wojak at inet.biz.pl (Wojtek Kupiec)
Date: Thu, 20 Dec 2007 20:54:55 +0100
Subject: ForceCommand - Subsystem
Message-ID: <476AC88F.80600@inet.biz.pl>

Hi All

First of all apologize for my bad English ? it is not my native language.

I'm using ssh for my everyday work. And I have noticed strange behaviour 
in sshd daemon.

In sshd_config file there is option ForceCommand, and if I'm making sftp 
connection it look like command is also executed, I receive error 
message and connection is lost. In my opinion ForceCommand should not be 
considered when subsystem is activated.


I have made a patch (please see attached file) it will probably solve 
the problem.


Best Regareds

Wojak


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_file
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071220/d2c0865d/attachment.ksh 

From slawmaster at gmail.com  Fri Dec 21 06:00:41 2007
From: slawmaster at gmail.com (John Floren)
Date: Thu, 20 Dec 2007 11:00:41 -0800
Subject: a newbie sshd debugging question
Message-ID: <7d3530220712201100u46dcde45s17f2728076cf273a@mail.gmail.com>

Hi everyone
I'm in the process of porting ssh2 to Plan 9, but there's a problem. I
can currently log in and run a few commands, but after a very small
number of commands (or simply striking return a few times), the server
tells the client that we sent a bad packet size and we exit.
To debug this, I've got the client showing the plaintext packets it's
sending, but I don't know what the server is reading. I *just*
downloaded the source and built sshd on Unix to test this, but I don't
know where the received packets are being decrypted and gdb is not
playing nicely at this time... can someone tell me where the
decryption happens so I can drop in a print statement?
Thanks


John
-- 
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

From dtucker at zip.com.au  Fri Dec 21 07:15:19 2007
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 20 Dec 2007 21:15:19 +0100
Subject: a newbie sshd debugging question
In-Reply-To: <7d3530220712201100u46dcde45s17f2728076cf273a@mail.gmail.com>
References: <7d3530220712201100u46dcde45s17f2728076cf273a@mail.gmail.com>
Message-ID: <476ACD57.3010504@zip.com.au>

John Floren wrote:
> Hi everyone
> I'm in the process of porting ssh2 to Plan 9, but there's a problem. I
> can currently log in and run a few commands, but after a very small
> number of commands (or simply striking return a few times), the server
> tells the client that we sent a bad packet size and we exit.
> To debug this, I've got the client showing the plaintext packets it's
> sending, but I don't know what the server is reading. I *just*
> downloaded the source and built sshd on Unix to test this, but I don't
> know where the received packets are being decrypted and gdb is not
> playing nicely at this time... can someone tell me where the
> decryption happens so I can drop in a print statement?

For OpenSSH, look for PACKET_DEBUG in packet.c.  You might want to try 
building sshd ./configure --with-cflags=-DPACKET_DEBUG first and see if 
that does what you want.

-- 
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 slawmaster at gmail.com  Fri Dec 21 09:04:05 2007
From: slawmaster at gmail.com (John Floren)
Date: Thu, 20 Dec 2007 14:04:05 -0800
Subject: a newbie sshd debugging question
In-Reply-To: <476ACD57.3010504@zip.com.au>
References: <7d3530220712201100u46dcde45s17f2728076cf273a@mail.gmail.com>
	<476ACD57.3010504@zip.com.au>
Message-ID: <7d3530220712201404k2c7854c0p8bcb0f270591f44f@mail.gmail.com>

On Dec 20, 2007 12:15 PM, Darren Tucker <dtucker at zip.com.au> wrote:
>
> John Floren wrote:
> > Hi everyone
> > I'm in the process of porting ssh2 to Plan 9, but there's a problem. I
> > can currently log in and run a few commands, but after a very small
> > number of commands (or simply striking return a few times), the server
> > tells the client that we sent a bad packet size and we exit.
> > To debug this, I've got the client showing the plaintext packets it's
> > sending, but I don't know what the server is reading. I *just*
> > downloaded the source and built sshd on Unix to test this, but I don't
> > know where the received packets are being decrypted and gdb is not
> > playing nicely at this time... can someone tell me where the
> > decryption happens so I can drop in a print statement?
>
> For OpenSSH, look for PACKET_DEBUG in packet.c.  You might want to try
> building sshd ./configure --with-cflags=-DPACKET_DEBUG first and see if
> that does what you want.
>
> --
> 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.
>

Great, thanks! Now, as debugging progresses... can someone tell me
what packet type 5d is? (or show me some docs that contain the
definition)


John
-- 
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

From mouring at eviladmin.org  Fri Dec 21 10:06:21 2007
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Thu, 20 Dec 2007 17:06:21 -0600 (CST)
Subject: ForceCommand - Subsystem
In-Reply-To: <476AC88F.80600@inet.biz.pl>
References: <476AC88F.80600@inet.biz.pl>
Message-ID: <Pine.BSO.4.64.0712201656330.4463@miyako.eviladmin.org>


This also effects the "command=" limitor for key authentication.  Which 
could become a security risk for folks expecting the current behavior.

Even at that I would expect "ForceCommand" to always come in play (could 
be because it was documented states it would).  It would be better to 
have "ForceNonSubsystemCommandForNonKeyAuthentication" directive (not that 
I would give up an evening coding that for submission =).

- Ben

On Thu, 20 Dec 2007, Wojtek Kupiec wrote:

> Hi All
>
> First of all apologize for my bad English ??? it is not my native language.
>
> I'm using ssh for my everyday work. And I have noticed strange behaviour in 
> sshd daemon.
>
> In sshd_config file there is option ForceCommand, and if I'm making sftp 
> connection it look like command is also executed, I receive error message and 
> connection is lost. In my opinion ForceCommand should not be considered when 
> subsystem is activated.
>
>
> I have made a patch (please see attached file) it will probably solve the 
> problem.
>
>
> Best Regareds
>
> Wojak
>
>
>

From stuge-openssh-unix-dev at cdy.org  Fri Dec 21 11:52:53 2007
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Fri, 21 Dec 2007 01:52:53 +0100
Subject: a newbie sshd debugging question
In-Reply-To: <7d3530220712201404k2c7854c0p8bcb0f270591f44f@mail.gmail.com>
References: <7d3530220712201100u46dcde45s17f2728076cf273a@mail.gmail.com>
	<476ACD57.3010504@zip.com.au>
	<7d3530220712201404k2c7854c0p8bcb0f270591f44f@mail.gmail.com>
Message-ID: <20071221005253.32131.qmail@cdy.org>

On Thu, Dec 20, 2007 at 02:04:05PM -0800, John Floren wrote:
> can someone tell me what packet type 5d is?

$ grep 93 ssh2.h
#define SSH2_MSG_CHANNEL_WINDOW_ADJUST                  93


> (or show me some docs that contain the definition)

RFC 4250 and RFC 4254.


//Peter

From shahid.shaikh at in.ibm.com  Fri Dec 21 13:32:38 2007
From: shahid.shaikh at in.ibm.com (Shahid M Shaikh)
Date: Fri, 21 Dec 2007 08:02:38 +0530
Subject: Shahid M Shaikh is out of the office.
Message-ID: <OF81EE9AFD.936B2CE3-ON652573B8.000DF9A6-652573B8.000DF9A6@in.ibm.com>


I will be out of the office starting  12/21/2007 and will not return until
12/30/2007.

I will respond to your message when I return. If its necessary, please
contact my Manager Arun Anbalagan(arunprasath at in.ibm.com)


From vgiffin at apple.com  Fri Dec 21 16:00:57 2007
From: vgiffin at apple.com (Disco Vince Giffin)
Date: Thu, 20 Dec 2007 21:00:57 -0800
Subject: OpenSSH patches for Mac OS X
In-Reply-To: <20071213233248.GB25170@crawfish.ais.com>
References: <6E36187B-E5AC-48CE-8B5A-95143143077D@apple.com>
	<20071213233248.GB25170@crawfish.ais.com>
Message-ID: <301D87CB-B9AD-472E-BB67-A7FAABFF4468@apple.com>

Jim,

	Thanks for the suggestions.  I have take both of them (in reverse  
order).


- Disco Vince Giffin



On Dec 13, 2007, at 3:32 PM, Jim Knoble wrote:

> If you want any of your patches to be integrated, you should probably
> start by (1) file Bugzilla reports for each of them at
> https://bugzilla.mindrot.org/ , and (2) consider updating the patches
> for the most current release of OpenSSH (which is 4.7p1 as of this
> writing).
>
> Circa 2007-12-13 17:04 dixit Disco Vince Giffin:
>
> : OpenSSH Unix Dev,
> :
> : 	Mac OS X 10.5 recently shipped with OpenSSH 4.5p1.  This build
> : includes a number of patches, some general bug fixes and some  
> platform-
> : specific fixes and enhancements.  These patches are available from  
> our
> : open source site (http://www.opensource.apple.com/darwinsource/10.5/OpenSSH-87/
> : ).
> : 	Following is a brief description of each patch.  We'd be more than
> : happy to see any of these patches integrated into the official
> : portable OpenSSH distribution.
>
>  [...]
>
> : - Disco Vince Giffin
> :    OS Security Engineer
> :    Apple Inc.
>
> -- 
> jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
> (GnuPG key ID: 6F39C2CC  >>>>>>  http://www.pobox.com/~jmknoble/ 
> keys/ )
> (GnuPG fingerprint:  
> 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC)
> + 
> ----------------------------------------------------------------------+
> |[L]iberty, as we all know, cannot flourish in a country that is  
> perma-|
> | nently on a war footing, or even a near-war footing.  --Aldous  
> Huxley|
> + 
> ----------------------------------------------------------------------+


From djm at mindrot.org  Fri Dec 21 16:04:22 2007
From: djm at mindrot.org (Damien Miller)
Date: Fri, 21 Dec 2007 16:04:22 +1100 (EST)
Subject: OpenSSH patches for Mac OS X
In-Reply-To: <301D87CB-B9AD-472E-BB67-A7FAABFF4468@apple.com>
References: <6E36187B-E5AC-48CE-8B5A-95143143077D@apple.com>
	<20071213233248.GB25170@crawfish.ais.com>
	<301D87CB-B9AD-472E-BB67-A7FAABFF4468@apple.com>
Message-ID: <alpine.BSO.0.99999.0712211603420.9154@fuyu.mindrot.org>

On Thu, 20 Dec 2007, Disco Vince Giffin wrote:

> Jim,
> 
> 	Thanks for the suggestions.  I have take both of them (in reverse  
> order).

Thanks - I plan on having a concerted bash at the open bugs over
the xmas/new year holiday, so you are just in time :)

-d

From vinschen at redhat.com  Sat Dec 22 03:17:59 2007
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 21 Dec 2007 17:17:59 +0100
Subject: OpenSSH patches for Mac OS X
In-Reply-To: <6E36187B-E5AC-48CE-8B5A-95143143077D@apple.com>
References: <6E36187B-E5AC-48CE-8B5A-95143143077D@apple.com>
Message-ID: <20071221161759.GL18860@calimero.vinschen.de>

Hi,

On Dec 13 14:04, Disco Vince Giffin wrote:
> DVG-4122722+5277818_new_EA.patch & DVG-4648874_preserve_EA_mtime.patch
> 	Adds a scp -E option, which preserves HFS+ extended attributes.

wasn't a decision made not to add any more functionality to scp,
especially not adding new command line options?


Just curious,
Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From imorgan at nas.nasa.gov  Sat Dec 22 04:26:50 2007
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 21 Dec 2007 09:26:50 -0800
Subject: ReceiveBufferSize option (bz#1332)
In-Reply-To: <alpine.BSO.0.99999.0712211603420.9154@fuyu.mindrot.org>
References: <6E36187B-E5AC-48CE-8B5A-95143143077D@apple.com>
	<20071213233248.GB25170@crawfish.ais.com>
	<301D87CB-B9AD-472E-BB67-A7FAABFF4468@apple.com>
	<alpine.BSO.0.99999.0712211603420.9154@fuyu.mindrot.org>
Message-ID: <20071221172650.GA14354@linux55.nas.nasa.gov>

On Fri, Dec 21, 2007 at 16:04:22 +1100, Damien Miller wrote:
> 
> Thanks - I plan on having a concerted bash at the open bugs over
> the xmas/new year holiday, so you are just in time :)
> 

Hi Damien,

Awhile back I submitted bz#1332 which adds a ReceiveBufferSize option to
ssh(1). I've been meaning to follow-up on this for a while now, but have
been distracted with other work.

Is there any chance of getting this patch included with the 4.8 release?
If there are issues with the implementation, I would be happy to address
them.

Thanks

-- 
Iain Morgan

From jmmv at NetBSD.org  Thu Dec 27 07:15:19 2007
From: jmmv at NetBSD.org (Julio M. Merino Vidal)
Date: Wed, 26 Dec 2007 20:15:19 +0000
Subject: sshd's -e doesn't work as expected
Message-ID: <20071226201519.GA22699@NetBSD.org>

Hello,

I'm running a sshd server using the -e flag so that I can capture its
whole output and later send it to the user.  I'm also setting LogLevel
to DEBUG1 in the configuration file and I don't want to disturb syslogd.
But the problem is that it doesn't work as expected (or as I expect,
which I think should be the correct behavior).  The log file ends up
being empty because the call to daemon(0, 0) done by the server
effectively closes the stderr stream and all prints to it do not work.

I've fixed this issue with the attached patch.  Hope that it is OK and
can be committed.  If not, please tell me why.

Thank you,

Index: sshd.c
===================================================================
RCS file: /cvsroot/src/crypto/dist/ssh/sshd.c,v
retrieving revision 1.42
diff -u -p -r1.42 sshd.c
--- sshd.c	18 Dec 2007 02:35:33 -0000	1.42
+++ sshd.c	26 Dec 2007 20:12:22 -0000
@@ -1485,8 +1485,16 @@ main(int ac, char **av)
 	if (!(debug_flag || inetd_flag || no_daemon_flag)) {
 		int fd;
 
-		if (daemon(0, 0) < 0)
+		if (daemon(0, 1) < 0)
 			fatal("daemon() failed: %.200s", strerror(errno));
+		close(STDIN_FILENO);
+		open(_PATH_DEVNULL, O_RDONLY);
+		close(STDOUT_FILENO);
+		open(_PATH_DEVNULL, O_WRONLY);
+		if (!log_stderr) {
+			close(STDERR_FILENO);
+			open(_PATH_DEVNULL, O_WRONLY);
+		}
 
 		/* Disconnect from the controlling tty. */
 		fd = open(_PATH_TTY, O_RDWR | O_NOCTTY);

-- 
Julio M. Merino Vidal <jmmv at NetBSD.org>

From jmknoble at pobox.com  Thu Dec 27 10:41:45 2007
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 26 Dec 2007 18:41:45 -0500
Subject: sshd's -e doesn't work as expected
In-Reply-To: <20071226201519.GA22699@NetBSD.org>
References: <20071226201519.GA22699@NetBSD.org>
Message-ID: <20071226234145.GB15113@crawfish.ais.com>

I think the intent was for '-e' to be used with '-D':

__________[from sshd(8)]__________

-D      When this option is specified, sshd will not detach and
        does not become a daemon.  This allows easy monitoring of sshd.

__________[end sshd(8)]__________

Perhaps sshd should complain if '-e' appears without '-D'?

--jim

Circa 2007-12-26 15:15 dixit Julio M. Merino Vidal:

: Hello,
: 
: I'm running a sshd server using the -e flag so that I can capture its
: whole output and later send it to the user.  I'm also setting LogLevel
: to DEBUG1 in the configuration file and I don't want to disturb syslogd.
: But the problem is that it doesn't work as expected (or as I expect,
: which I think should be the correct behavior).  The log file ends up
: being empty because the call to daemon(0, 0) done by the server
: effectively closes the stderr stream and all prints to it do not work.
: 
: I've fixed this issue with the attached patch.  Hope that it is OK and
: can be committed.  If not, please tell me why.
: 
: Thank you,
: 
: Index: sshd.c
: ===================================================================
: RCS file: /cvsroot/src/crypto/dist/ssh/sshd.c,v
: retrieving revision 1.42
: diff -u -p -r1.42 sshd.c
: --- sshd.c	18 Dec 2007 02:35:33 -0000	1.42
: +++ sshd.c	26 Dec 2007 20:12:22 -0000
: @@ -1485,8 +1485,16 @@ main(int ac, char **av)
:  	if (!(debug_flag || inetd_flag || no_daemon_flag)) {
:  		int fd;
:  
: -		if (daemon(0, 0) < 0)
: +		if (daemon(0, 1) < 0)
:  			fatal("daemon() failed: %.200s", strerror(errno));
: +		close(STDIN_FILENO);
: +		open(_PATH_DEVNULL, O_RDONLY);
: +		close(STDOUT_FILENO);
: +		open(_PATH_DEVNULL, O_WRONLY);
: +		if (!log_stderr) {
: +			close(STDERR_FILENO);
: +			open(_PATH_DEVNULL, O_WRONLY);
: +		}
:  
:  		/* Disconnect from the controlling tty. */
:  		fd = open(_PATH_TTY, O_RDWR | O_NOCTTY);
: 
: -- 
: Julio M. Merino Vidal <jmmv at NetBSD.org>
: _______________________________________________
: openssh-unix-dev mailing list
: openssh-unix-dev at mindrot.org
: https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
: 

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: 6F39C2CC  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From jmmv84 at gmail.com  Thu Dec 27 19:30:40 2007
From: jmmv84 at gmail.com (Julio M. Merino Vidal)
Date: Thu, 27 Dec 2007 09:30:40 +0100
Subject: sshd's -e doesn't work as expected
In-Reply-To: <20071226234145.GB15113@crawfish.ais.com>
References: <20071226201519.GA22699@NetBSD.org>
	<20071226234145.GB15113@crawfish.ais.com>
Message-ID: <5D5EE84B-69F1-46CF-B54C-56656D2FFD52@gmail.com>

On 27/12/2007, at 0:41, Jim Knoble wrote:

> I think the intent was for '-e' to be used with '-D':
>
> __________[from sshd(8)]__________
>
> -D      When this option is specified, sshd will not detach and
>         does not become a daemon.  This allows easy monitoring of  
> sshd.
>
> __________[end sshd(8)]__________
>
> Perhaps sshd should complain if '-e' appears without '-D'?

Maybe, but I want it to run it in the background, so I would need to  
launch it with & instead.

Thinking about it, this may be good enough though.  At first, I  
thought that the pidfile was written before the call to daemon(3) so  
I thought it'd be safe to access that file immediately after the call  
to sshd (without -D nor -d) returned.  But after checking the code I  
see this is not the case (how could it be? you don't know the pid  
until you fork...), so it makes no difference for me to use -D or &  
because I can hit the race condition in any of the two ways.

So, OK.  If -e is always supposed to be used alongside with -D, then  
the daemon should complain about that situation.

Thanks,

-- 
Julio M. Merino Vidal <jmmv84 at gmail.com>



From jmknoble at pobox.com  Fri Dec 28 10:31:20 2007
From: jmknoble at pobox.com (Jim Knoble)
Date: Thu, 27 Dec 2007 18:31:20 -0500
Subject: sshd's -e doesn't work as expected
In-Reply-To: <5D5EE84B-69F1-46CF-B54C-56656D2FFD52@gmail.com>
References: <20071226201519.GA22699@NetBSD.org>
	<20071226234145.GB15113@crawfish.ais.com>
	<5D5EE84B-69F1-46CF-B54C-56656D2FFD52@gmail.com>
Message-ID: <20071227233120.GF15113@crawfish.ais.com>

Circa 2007-12-27 03:30 dixit Julio M. Merino Vidal:

: On 27/12/2007, at 0:41, Jim Knoble wrote:
: 
: > I think the intent was for '-e' to be used with '-D':
    [...]
: > Perhaps sshd should complain if '-e' appears without '-D'?
: 
: Maybe, but I want it to run it in the background, so I would need to  
: launch it with & instead.
: 
: Thinking about it, this may be good enough though.  At first, I  
: thought that the pidfile was written before the call to daemon(3) so  
: I thought it'd be safe to access that file immediately after the call  
: to sshd (without -D nor -d) returned.  But after checking the code I  
: see this is not the case (how could it be? you don't know the pid  
: until you fork...), so it makes no difference for me to use -D or &  
: because I can hit the race condition in any of the two ways.

If you need the PID of the sshd process, you can get it without a race
using (for example):

	#!/bin/sh
	/usr/local/sbin/sshd -D &
	SSHD_PID="$!"

The shell knows the process ID of the child it spawns to run sshd.

: So, OK.  If -e is always supposed to be used alongside with -D, then  
: the daemon should complain about that situation.

Perhaps you could generate a patch and attach it to your bug report.

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: 6F39C2CC  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From mouring at eviladmin.org  Fri Dec 28 11:47:52 2007
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Thu, 27 Dec 2007 18:47:52 -0600 (CST)
Subject: sshd's -e doesn't work as expected
In-Reply-To: <20071227233120.GF15113@crawfish.ais.com>
References: <20071226201519.GA22699@NetBSD.org>
	<20071226234145.GB15113@crawfish.ais.com>
	<5D5EE84B-69F1-46CF-B54C-56656D2FFD52@gmail.com>
	<20071227233120.GF15113@crawfish.ais.com>
Message-ID: <alpine.BSO.1.00.0712271846480.31834@miyako.eviladmin.org>


Does one also want to consider -i along with -D or -d?

- Ben

On Thu, 27 Dec 2007, Jim Knoble wrote:

> Circa 2007-12-27 03:30 dixit Julio M. Merino Vidal:
>
> : On 27/12/2007, at 0:41, Jim Knoble wrote:
> :
> : > I think the intent was for '-e' to be used with '-D':
>    [...]
> : > Perhaps sshd should complain if '-e' appears without '-D'?
> :
> : Maybe, but I want it to run it in the background, so I would need to
> : launch it with & instead.
> :
> : Thinking about it, this may be good enough though.  At first, I
> : thought that the pidfile was written before the call to daemon(3) so
> : I thought it'd be safe to access that file immediately after the call
> : to sshd (without -D nor -d) returned.  But after checking the code I
> : see this is not the case (how could it be? you don't know the pid
> : until you fork...), so it makes no difference for me to use -D or &
> : because I can hit the race condition in any of the two ways.
>
> If you need the PID of the sshd process, you can get it without a race
> using (for example):
>
> 	#!/bin/sh
> 	/usr/local/sbin/sshd -D &
> 	SSHD_PID="$!"
>
> The shell knows the process ID of the child it spawns to run sshd.
>
> : So, OK.  If -e is always supposed to be used alongside with -D, then
> : the daemon should complain about that situation.
>
> Perhaps you could generate a patch and attach it to your bug report.
>
> --
> jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
> (GnuPG key ID: 6F39C2CC  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
> (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC)
> +----------------------------------------------------------------------+
> |[L]iberty, as we all know, cannot flourish in a country that is perma-|
> | nently on a war footing, or even a near-war footing.  --Aldous Huxley|
> +----------------------------------------------------------------------+
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From jmmv84 at gmail.com  Fri Dec 28 20:05:32 2007
From: jmmv84 at gmail.com (Julio M. Merino Vidal)
Date: Fri, 28 Dec 2007 10:05:32 +0100
Subject: sshd's -e doesn't work as expected
In-Reply-To: <20071227233120.GF15113@crawfish.ais.com>
References: <20071226201519.GA22699@NetBSD.org>
	<20071226234145.GB15113@crawfish.ais.com>
	<5D5EE84B-69F1-46CF-B54C-56656D2FFD52@gmail.com>
	<20071227233120.GF15113@crawfish.ais.com>
Message-ID: <A72512B3-94DC-4C23-904E-F43B47851AEB@gmail.com>

On 28/12/2007, at 0:31, Jim Knoble wrote:

> If you need the PID of the sshd process, you can get it without a race
> using (for example):
>
> 	#!/bin/sh
> 	/usr/local/sbin/sshd -D &
> 	SSHD_PID="$!"
>
> The shell knows the process ID of the child it spawns to run sshd.

Ah, cool.  I didn't know of that variable.  Thank you.

> : So, OK.  If -e is always supposed to be used alongside with -D, then
> : the daemon should complain about that situation.
>
> Perhaps you could generate a patch and attach it to your bug report.

Here it goes:

Index: sshd.8
===================================================================
RCS file: /cvsroot/src/crypto/dist/ssh/sshd.8,v
retrieving revision 1.38
diff -u -p -r1.38 sshd.8
--- sshd.8	18 Dec 2007 02:35:32 -0000	1.38
+++ sshd.8	28 Dec 2007 09:03:53 -0000
@@ -36,7 +36,7 @@
  .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  .\"
  .\" $OpenBSD: sshd.8,v 1.237 2007/06/07 19:37:34 pvalchev Exp $
-.Dd $Mdocdate: June 7 2007 $
+.Dd $Mdocdate: December 28 2007 $
  .Dt SSHD 8
  .Os
  .Sh NAME
@@ -121,6 +121,8 @@ Maximum is 3.
  When this option is specified,
  .Nm
  will send the output to the standard error instead of the system log.
+This option requires
+.Fl D .
  .It Fl f Ar config_file
  Specifies the name of the configuration file.
  The default is
Index: sshd.c
===================================================================
RCS file: /cvsroot/src/crypto/dist/ssh/sshd.c,v
retrieving revision 1.42
diff -u -p -r1.42 sshd.c
--- sshd.c	18 Dec 2007 02:35:33 -0000	1.42
+++ sshd.c	28 Dec 2007 09:03:53 -0000
@@ -1330,6 +1330,8 @@ main(int ac, char **av)
  		closefrom(REEXEC_MIN_FREE_FD);
  	else
  		closefrom(REEXEC_DEVCRYPTO_RESERVED_FD);
+	if (log_stderr && !no_daemon_flag)
+		fatal("The -e option also requires -D");

  	SSLeay_add_all_algorithms();

-- 
Julio M. Merino Vidal <jmmv84 at gmail.com>



From david.daniel.smith at gmail.com  Fri Dec 28 22:44:13 2007
From: david.daniel.smith at gmail.com (David Smith)
Date: Fri, 28 Dec 2007 20:44:13 +0900
Subject: OpenSSH PKCS#11merge
Message-ID: <200712282044.18280.david.daniel.smith@gmail.com>

ping.

I've been using Alon's patch and following his arguments on this list for a 
while. I want to add my voice to say that the current opensc support should 
be completely replaced with pkcs#11 support, since it is the right way to 
handle smart cards. The use case that my organization wants is to use the TPM 
chips available in most machines as our primary smartcard mechanism, 
supporting any other card on machines that don't have TPM chips. The TPM chip 
is supported by an alternative pkcs#11 library, opencryptoki, and thus is 
unusable from applications that use opensc directly, because it's not a 
pkcs#15 card.

This is just one use-case of why having simple pkcs#11 support is much more 
valuable then opensc-only, as is written in the opensc introduction and the 
RSA pkcs#15 specification.

Alon's patch already functions parallel to the opensc support and RedHat is 
bundling it (or a similar patch, I'm not sure of the details). I would like 
this supported included mainline with all appropriate speed and importance.

Thanks,
David Smith
-- 
man perl | tail -6 | head -2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071228/90017558/attachment.bin 

From alon.barlev at gmail.com  Sat Dec 29 05:50:42 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 28 Dec 2007 20:50:42 +0200
Subject: OpenSSH PKCS#11merge
In-Reply-To: <9e0cf0bf0711101143u943b32m88c8035f70942dea@mail.gmail.com>
References: <200709250733.47491.alon.barlev@gmail.com>
	<9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com>
	<Pine.BSO.4.64.0709291946090.28817@fuyu.mindrot.org>
	<9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com>
	<20070929142628.13104.qmail@cdy.org>
	<200709292009.39873.alon.barlev@gmail.com>
	<9e0cf0bf0710130913q7ef26c55gf3d9e391beef3b33@mail.gmail.com>
	<20071014035528.10383.qmail@cdy.org>
	<9e0cf0bf0710132242k2a84ea74x644fdee327b780a2@mail.gmail.com>
	<9e0cf0bf0711101143u943b32m88c8035f70942dea@mail.gmail.com>
Message-ID: <9e0cf0bf0712281050g75ee27b5n54eef7f9f6f51e56@mail.gmail.com>

Hello,

On 12/28/07, David Smith <david.daniel.smith at gmail.com> wrote:
> ping.

I also considered to ping... :)
Thanks for the reminder.

> is supported by an alternative pkcs#11 library, opencryptoki, and thus is
> unusable from applications that use opensc directly, because it's not a
> pkcs#15 card.

Also the patch introduces dynamic support for cryptographic hardware,
handling session timeouts, token removal etc..

> Alon's patch already functions parallel to the opensc support and RedHat is
> bundling it (or a similar patch, I'm not sure of the details). I would like
> this supported included mainline with all appropriate speed and importance.

Redhat developed nss based patch for OpenSSH, nss is much more
complicated and does not support all PKCS#11 tokens. The pkcs11-helper
based patch is much lighter and more compatible. Anyway, redhat will
face the same issues with OpenSSH regarding the dynamic hardware
usage.

If OpenSSH developers prefers to use Redhat's nss patch and this is
the way people be able to use more secured environment, it is fine.

I believe that my work is lighter and provide better service to users.

The main issue I am waiting for Peter to response is why he thinks
that the ssh-agent protocol should not be changed to support dynamic
environment. This is the main issue left, all the other are minor.
Currently, I execute a user prompt program directly from the agent,
while the other components of OpenSSH execute this from the main
executable. But I need a way to signal the caller that I need some
more information from the user.

Best Regards,
Alon Bar-Lev.

From mouring at eviladmin.org  Sun Dec 30 12:02:35 2007
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Sat, 29 Dec 2007 19:02:35 -0600 (CST)
Subject: OpenSSH PKCS#11merge
In-Reply-To: <9e0cf0bf0712281050g75ee27b5n54eef7f9f6f51e56@mail.gmail.com>
References: <200709250733.47491.alon.barlev@gmail.com>
	<9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com>
	<Pine.BSO.4.64.0709291946090.28817@fuyu.mindrot.org>
	<9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com>
	<20070929142628.13104.qmail@cdy.org>
	<200709292009.39873.alon.barlev@gmail.com>
	<9e0cf0bf0710130913q7ef26c55gf3d9e391beef3b33@mail.gmail.com>
	<20071014035528.10383.qmail@cdy.org>
	<9e0cf0bf0710132242k2a84ea74x644fdee327b780a2@mail.gmail.com>
	<9e0cf0bf0711101143u943b32m88c8035f70942dea@mail.gmail.com>
	<9e0cf0bf0712281050g75ee27b5n54eef7f9f6f51e56@mail.gmail.com>
Message-ID: <alpine.BSO.1.00.0712291805550.31834@miyako.eviladmin.org>


I'm sorry if this has been discussed in other places.  Looking back at 
this thread I don't see any real discussion of it here.

However, can someone give a run down as to why the current smartcard 
implement fails, why it cannot be fixed and thus must be replaced? 
It bothers me when people's solution is to throw out code because it 
doesn't do what they want without giving a solid reason why a new 
infrastructure is needed, or how this new setup will completely replace 
the existing setup.

Just as bad is having two implementations living side-by-side and by the 
looks of the patch can both be compiled in.  Does having both enabled 
have any ill effects?  Should they both be allowed to be compiled in?

As for X.509.. If one has followed this list for any period in time they 
will have seen the concerns about OpenSSL's X.509 parser complexity and 
the issues it has caused them in the past.  That is part of the reason why 
djm@ and the other have no intention.

I remember discussions about writing a simplified X.509 parser that only 
looking at fields that OpenSSH cared about, but I've been away for over 
two years so I suspect that was abandoned. =)

- Ben


On Fri, 28 Dec 2007, Alon Bar-Lev wrote:

> Hello,
>
> On 12/28/07, David Smith <david.daniel.smith at gmail.com> wrote:
>> ping.
>
> I also considered to ping... :)
> Thanks for the reminder.
>
>> is supported by an alternative pkcs#11 library, opencryptoki, and thus is
>> unusable from applications that use opensc directly, because it's not a
>> pkcs#15 card.
>
> Also the patch introduces dynamic support for cryptographic hardware,
> handling session timeouts, token removal etc..
>
>> Alon's patch already functions parallel to the opensc support and RedHat is
>> bundling it (or a similar patch, I'm not sure of the details). I would like
>> this supported included mainline with all appropriate speed and importance.
>
> Redhat developed nss based patch for OpenSSH, nss is much more
> complicated and does not support all PKCS#11 tokens. The pkcs11-helper
> based patch is much lighter and more compatible. Anyway, redhat will
> face the same issues with OpenSSH regarding the dynamic hardware
> usage.
>
> If OpenSSH developers prefers to use Redhat's nss patch and this is
> the way people be able to use more secured environment, it is fine.
>
> I believe that my work is lighter and provide better service to users.
>
> The main issue I am waiting for Peter to response is why he thinks
> that the ssh-agent protocol should not be changed to support dynamic
> environment. This is the main issue left, all the other are minor.
> Currently, I execute a user prompt program directly from the agent,
> while the other components of OpenSSH execute this from the main
> executable. But I need a way to signal the caller that I need some
> more information from the user.
>
> Best Regards,
> Alon Bar-Lev.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From david.daniel.smith at gmail.com  Sun Dec 30 13:30:45 2007
From: david.daniel.smith at gmail.com (David Smith)
Date: Sun, 30 Dec 2007 11:30:45 +0900
Subject: OpenSSH PKCS#11merge
In-Reply-To: <alpine.BSO.1.00.0712291805550.31834@miyako.eviladmin.org>
References: <200709250733.47491.alon.barlev@gmail.com>
	<9e0cf0bf0712281050g75ee27b5n54eef7f9f6f51e56@mail.gmail.com>
	<alpine.BSO.1.00.0712291805550.31834@miyako.eviladmin.org>
Message-ID: <200712301130.45791.david.daniel.smith@gmail.com>

Hi Ben,

Sunday 30 December 2007 10:02:35 ? Ben Lindstrom ????????:
> I'm sorry if this has been discussed in other places.  Looking back at
> this thread I don't see any real discussion of it here.

It has been discussed in many threads on the list over the last few years. 
Search for PKCS or the posts from Alon Bar-Lev and you should find them all.

>
> However, can someone give a run down as to why the current smartcard
> implement fails, why it cannot be fixed and thus must be replaced?
> It bothers me when people's solution is to throw out code because it
> doesn't do what they want without giving a solid reason why a new
> infrastructure is needed, or how this new setup will completely replace
> the existing setup.

Sure. To sum it up, currently OpenSSH uses OpenSC, which only provides support 
for a limited number of smartcards. OpenSC is meant to be just another 
PKCS#11 API implementation and if OpenSSH where to use PKCS#11 API instead of 
OpenSC's specific API, it would be available to the wider world of 
smartcards. Personally, I want to use it with opencryptoki, another free 
PKCS#11 implementation, that supports the TPM chip in many workstations and 
laptops.

On top of this, Alon's patch adds new features: dynamic insertion and remove 
of smartcards, session timeouts, and token removals.

>
> Just as bad is having two implementations living side-by-side and by the
> looks of the patch can both be compiled in.  Does having both enabled
> have any ill effects?  Should they both be allowed to be compiled in?
>

There aren't really any ill effects of having both in, but it is redundant. 
OpenSC speaks PKCS#11 so using Alon's code one would still have support for 
the same cards they're using now, and with his feature improvements it would 
work better. I'm suggesting to have both of them compiled in and available to 
ease the transition, but it's been stated on this thread that the PKCS#11 
support should eventually completely replace the OpenSC support.

> As for X.509.. If one has followed this list for any period in time they
> will have seen the concerns about OpenSSL's X.509 parser complexity and
> the issues it has caused them in the past.  That is part of the reason why
> djm@ and the other have no intention.

Let's leave the x509 issue for another day. The PKCS#11 patch doesn't 
*require* x509 support, and I'm much more interested right now in having a 
secure storage option for my SSH key then I am in having that key be 
validated via my organization's PKI, as probably a few other people are.

>
> I remember discussions about writing a simplified X.509 parser that only
> looking at fields that OpenSSH cared about, but I've been away for over
> two years so I suspect that was abandoned. =)
>

Well, apparently the x509 support patch from Roumen Petrov is extremely full 
so whenever that issue comes back around, it might be a good starting point.

Thanks for your feedback,
dds

> On Fri, 28 Dec 2007, Alon Bar-Lev wrote:
> > Hello,
> >
> > On 12/28/07, David Smith <david.daniel.smith at gmail.com> wrote:
> >> ping.
> >
> > I also considered to ping... :)
> > Thanks for the reminder.
> >
> >> is supported by an alternative pkcs#11 library, opencryptoki, and thus
> >> is unusable from applications that use opensc directly, because it's not
> >> a pkcs#15 card.
> >
> > Also the patch introduces dynamic support for cryptographic hardware,
> > handling session timeouts, token removal etc..
> >
> >> Alon's patch already functions parallel to the opensc support and RedHat
> >> is bundling it (or a similar patch, I'm not sure of the details). I
> >> would like this supported included mainline with all appropriate speed
> >> and importance.
> >
> > Redhat developed nss based patch for OpenSSH, nss is much more
> > complicated and does not support all PKCS#11 tokens. The pkcs11-helper
> > based patch is much lighter and more compatible. Anyway, redhat will
> > face the same issues with OpenSSH regarding the dynamic hardware
> > usage.
> >
> > If OpenSSH developers prefers to use Redhat's nss patch and this is
> > the way people be able to use more secured environment, it is fine.
> >
> > I believe that my work is lighter and provide better service to users.
> >
> > The main issue I am waiting for Peter to response is why he thinks
> > that the ssh-agent protocol should not be changed to support dynamic
> > environment. This is the main issue left, all the other are minor.
> > Currently, I execute a user prompt program directly from the agent,
> > while the other components of OpenSSH execute this from the main
> > executable. But I need a way to signal the caller that I need some
> > more information from the user.
> >
> > Best Regards,
> > Alon Bar-Lev.
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



-- 
man perl | tail -6 | head -2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071230/dfb39a37/attachment-0001.bin 

From alon.barlev at gmail.com  Sun Dec 30 18:24:11 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 30 Dec 2007 09:24:11 +0200
Subject: OpenSSH PKCS#11merge
In-Reply-To: <200712301130.45791.david.daniel.smith@gmail.com>
References: <200709250733.47491.alon.barlev@gmail.com>
	<9e0cf0bf0712281050g75ee27b5n54eef7f9f6f51e56@mail.gmail.com>
	<alpine.BSO.1.00.0712291805550.31834@miyako.eviladmin.org>
	<200712301130.45791.david.daniel.smith@gmail.com>
Message-ID: <9e0cf0bf0712292324y3d20b47cy46b3d96526f1a5a8@mail.gmail.com>

On 12/30/07, David Smith <david.daniel.smith at gmail.com> wrote:
> > However, can someone give a run down as to why the current smartcard
> > implement fails, why it cannot be fixed and thus must be replaced?
> > It bothers me when people's solution is to throw out code because it
> > doesn't do what they want without giving a solid reason why a new
> > infrastructure is needed, or how this new setup will completely replace
> > the existing setup.
>
> Sure. To sum it up, currently OpenSSH uses OpenSC, which only provides support
> for a limited number of smartcards. OpenSC is meant to be just another
> PKCS#11 API implementation and if OpenSSH where to use PKCS#11 API instead of
> OpenSC's specific API, it would be available to the wider world of
> smartcards. Personally, I want to use it with opencryptoki, another free
> PKCS#11 implementation, that supports the TPM chip in many workstations and
> laptops.

I will try to rephrase this...

PKCS#11 is a standard specification, most hardware cryptography
support this standard in order to enable hardware and platform
independent applications to use the hardware.

OpenSC interface is a proprietary specification.

In order to support hardware cryptography, you have some options:
1. Support PKCS#11, thus supporting any device that comes with this
interface (most).
2. Support a specific implementation, just like OpenSSH does.
3. Reimplement from scratch, gnupg is an example for that.

Any option other than (1) implies supporting a minimum set of hardware
devices, making a large group of users unhappy (unable to use secured
solutions).

Best Regards,
Alon Bar-Lev.

From alon.barlev at gmail.com  Mon Dec 31 09:41:13 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 31 Dec 2007 00:41:13 +0200
Subject: OpenSSH PKCS#11merge
In-Reply-To: <9e0cf0bf0712292324y3d20b47cy46b3d96526f1a5a8@mail.gmail.com>
References: <200709250733.47491.alon.barlev@gmail.com>
	<9e0cf0bf0712281050g75ee27b5n54eef7f9f6f51e56@mail.gmail.com>
	<alpine.BSO.1.00.0712291805550.31834@miyako.eviladmin.org>
	<200712301130.45791.david.daniel.smith@gmail.com>
	<9e0cf0bf0712292324y3d20b47cy46b3d96526f1a5a8@mail.gmail.com>
Message-ID: <9e0cf0bf0712301441w5b51dd3ydd23c5565304a9e7@mail.gmail.com>

Hello,

Thanks for Ben help I released a new version of PKCS#11 patch, available from:
http://alon.barlev.googlepages.com/openssh-pkcs11

Most of the work is *BSD coding styles, I also allocated short options
for the parameters, as I understand now that long options are not
valid and configuration file for the agent will not be available.

There is an agentless configuration now, mainly to be OpenSC
compatible. This is none recommended as it loads all available keys of
a provided into ssh, and will prompt for passphrase every time ssh is
executed.

I hope we will be able to resolve the last issue... How the agent
protocol can support dynamic nature of hardware cryptography... Or if
there any other suggestions of how the expected behavior might be.

Best Regards,
Alon Bar-Lev.

---

ChangeLog:

20071229
 - (alonbl) Indent file to meet BSD styles.
 - (alonbl) Modify parameters (again) to meet BSD styles.
   I truly regret that I keep modifying the parameters, I believe
   this is not the last time, as I don't have full cooperation of
   upstream.
   Get provider keys:
        Old:
                ssh-add --pkcs11-show-ids ...
        New:
                ssh-keygen -K provider_info
   Add key:
        Old:
                ssh-add --pkcs11-add-id ...
        New:
                ssh-add -I id [session_cache [cert_file]]

   Agentless operation (not recommended, OpenSC compatibility):
        New:
                ssh -# provider_info ...

   Because I don't wish to add more switches, I added a format
   for provider information:
        lib[:prot_auth[:private_mode[:cert_is_private]]]
   For most implementations specify only the library name.
 - Rebase with openssh-4.7p1.
 - (alonbl) Release 0.20