From ed at membled.com  Mon Aug  1 03:34:08 2005
From: ed at membled.com (Ed Avis)
Date: Sun, 31 Jul 2005 18:34:08 +0100 (BST)
Subject: Mirror site ftp.plig.org out of date
Message-ID: <Pine.LNX.4.63.0507311832090.1208@youngs.future-i.net>

The mirror site ftp.plig.org is out of date, for example 
<ftp://ftp.plig.org/pub/OpenBSD/OpenSSH/portable/snapshot/> stops in 
2005-03-07 while the same directory on the master site has recent 
files.

I don't know whether this outdatedness applies only to the Portable 
OpenSSH snapshots or to the whole OpenBSD tree.

-- 
Ed Avis <ed at membled.com>



From frederik at a5.repetae.net  Tue Aug  2 22:09:21 2005
From: frederik at a5.repetae.net (Frederik Eaton)
Date: Tue, 2 Aug 2005 05:09:21 -0700
Subject: port forwarding trouble
Message-ID: <20050802120921.GA24095@a5.repetae.net>

Hi all,

When I set up multiple tunnels from remote hosts to ports on
localhost, I get the following error when I try to use them:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

(even though the keys haven't changed on the remote hosts). I assume
this is because the known_hosts file doesn't include port numbers.
However, this means that at least as I have things set up tunneling is
quite unusable. Is there a configuration option that I'm forgetting to
set which will cause ssh to differentiate between various ports on the
same host?

Thanks in advance,

Frederik



From stuge-openssh-unix-dev at cdy.org  Tue Aug  2 22:46:10 2005
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Tue, 2 Aug 2005 14:46:10 +0200
Subject: port forwarding trouble
In-Reply-To: <20050802120921.GA24095@a5.repetae.net>
References: <20050802120921.GA24095@a5.repetae.net>
Message-ID: <20050802124610.20204.qmail@cdy.org>

On Tue, Aug 02, 2005 at 05:09:21AM -0700, Frederik Eaton wrote:
> Is there a configuration option that I'm forgetting to set which
> will cause ssh to differentiate between various ports on the same
> host?

No, but see HostKeyAlias in ssh_config(5)


//Peter



From dtucker at zip.com.au  Wed Aug  3 01:48:31 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 03 Aug 2005 01:48:31 +1000
Subject: port forwarding trouble
In-Reply-To: <20050802120921.GA24095@a5.repetae.net>
References: <20050802120921.GA24095@a5.repetae.net>
Message-ID: <42EF95CF.5090001@zip.com.au>

Frederik Eaton wrote:
> When I set up multiple tunnels from remote hosts to ports on
> localhost, I get the following error when I try to use them:
> 
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> 
> (even though the keys haven't changed on the remote hosts). I assume
> this is because the known_hosts file doesn't include port numbers.

There's an open bug and patch for this:
http://bugzilla.mindrot.org/show_bug.cgi?id=910

> However, this means that at least as I have things set up tunneling is
> quite unusable. Is there a configuration option that I'm forgetting to
> set which will cause ssh to differentiate between various ports on the
> same host?

As Peter Stuge noted earlier, you can use HostKeyAlias to specify the 
real name of the host you're connecting to over the forward.

-- 
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 frederik at a5.repetae.net  Wed Aug  3 02:39:59 2005
From: frederik at a5.repetae.net (Frederik Eaton)
Date: Tue, 2 Aug 2005 17:39:59 +0100
Subject: port forwarding trouble
In-Reply-To: <42EF95CF.5090001@zip.com.au>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
Message-ID: <20050802163959.GH23428@a5.repetae.net>

Thanks for your reply.

> >When I set up multiple tunnels from remote hosts to ports on
> >localhost, I get the following error when I try to use them:
> >
> >@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> >@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
> >@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> >IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> >
> >(even though the keys haven't changed on the remote hosts). I assume
> >this is because the known_hosts file doesn't include port numbers.
> 
> There's an open bug and patch for this:
> http://bugzilla.mindrot.org/show_bug.cgi?id=910

Hmm, it seems like this is getting hung up over
HostbasedAuthentication, which isn't really documented in the man
page. What is it, what is "rhosts based authentication"? How many
people use it?

When will the patch be incorporated?

> >However, this means that at least as I have things set up tunneling is
> >quite unusable. Is there a configuration option that I'm forgetting to
> >set which will cause ssh to differentiate between various ports on the
> >same host?
> 
> As Peter Stuge noted earlier, you can use HostKeyAlias to specify the 
> real name of the host you're connecting to over the forward.

So, I could just write a wrapper that always passes "-o
HostKeyAlias=host:port" to ssh to get around the bug?

Also, I don't think that the "host at port" syntax suggested in the bug
comments is a good idea. There should be some standard for ipv6, and
we should use it. E.g., what do URLs use to specify the port when the
host is specified as an IPv6 address?

A brief search indicated "host.:port" might be used somewhere. But
"host:port" is so common that it would be better to use a different
notation only when 'host' is IPv6. "@" is especially bad, because it
makes it look like the host is a user.

Frederik



From stuge-openssh-unix-dev at cdy.org  Wed Aug  3 09:13:30 2005
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Wed, 3 Aug 2005 01:13:30 +0200
Subject: port forwarding trouble
In-Reply-To: <20050802163959.GH23428@a5.repetae.net>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
Message-ID: <20050802231330.27584.qmail@cdy.org>

On Tue, Aug 02, 2005 at 05:39:59PM +0100, Frederik Eaton wrote:
> > As Peter Stuge noted earlier, you can use HostKeyAlias to specify
> > the real name of the host you're connecting to over the forward.
> 
> So, I could just write a wrapper that always passes "-o
> HostKeyAlias=host:port" to ssh to get around the bug?

That, or add the following to ~/.ssh/config or /etc/ssh/ssh_config

Host tunnelhost
  HostKeyAlias real.host.name
  HostName localhost
  Port 2222

And then connect to it using:

ssh tunnelhost

Repeat for as many tunnelhosts as you want, just change Host,
HostKeyAlias and Port for each.


//Peter



From tusker at tusker.org  Wed Aug  3 12:34:26 2005
From: tusker at tusker.org (Damien Mascord)
Date: Wed, 03 Aug 2005 10:34:26 +0800
Subject: Hung ssh client connection
Message-ID: <42F02D32.6070401@tusker.org>

Hi guys,

I am running with: "OpenSSH_3.9p1 Debian-1ubuntu2, OpenSSL 0.9.7e 25 Oct
2004", as an ssh client, and am having some strange behaviour with a
firewall of ours.

We have a netscreen 5gt-plus, running ScreenOS 5.0.2, which has an ssh
daemon running.

I ssh to the firewall using `ssh username@<ip address>`, which works
correctly (ie, connects, and I can use the console of the firewall).

If I restart the firewall using the command 'reset', I get a message
that the firewall is resetting, which is good.

Now, the SSH client is hung, CTRL-C, CTRL-Z, CTRL-] don't do anything at
all.

Attaching strace:

root@<hostname>:~ # strace -p 28530
Process 28530 attached - interrupt to quit
select(7, [3 4], [], NULL, NULL <


It seems to be sitting there waiting for keyboard input, so as a last
resort, I try CTRL-~ which then disconnects (with a time out)!

Read from remote host <ip address>: Connection timed out
Connection to <ip address> closed.

What could be the cause of this connection 'hanging' ? Is it on the SSH
client, the SSH server not closing the connection correctly upon reset ?
 Or could it be something in the TCP OS layer ?

If it is expected behaviour, I apologize, though would like to
understand why this is happening on a technical level.

I am running:
# uname -a
Linux packrat 2.6.10-5-686-smp #1 SMP Tue Jun 7 09:34:54 UTC 2005 i686
GNU/Linux

which comes with glibc-2.3.2

Thanks in advance,

Damien



From dtucker at zip.com.au  Wed Aug  3 12:55:20 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 03 Aug 2005 12:55:20 +1000
Subject: Hung ssh client connection
In-Reply-To: <42F02D32.6070401@tusker.org>
References: <42F02D32.6070401@tusker.org>
Message-ID: <42F03218.7070208@zip.com.au>

Damien Mascord wrote:
> We have a netscreen 5gt-plus, running ScreenOS 5.0.2, which has an ssh
> daemon running.
[...]
> If I restart the firewall using the command 'reset', I get a message
> that the firewall is resetting, which is good.
[...]
> What could be the cause of this connection 'hanging' ? Is it on the SSH
> client, the SSH server not closing the connection correctly upon reset ?
>  Or could it be something in the TCP OS layer ?

When you "reset" your firewall, it flushes its state table, right?  If 
so then would probably include the SSH TCP connection too.

One place this might show up is in "netstat" on the client: if there's a 
constant value in the "Send-Q" column for the ssh connection to your 
firewall then that's almost certainly what's happening.

> If it is expected behaviour, I apologize, though would like to
> understand why this is happening on a technical level.

If connections *to* the firewall (as opposed to *through* it) are 
subject the the firewall rules and unless it has the capability to 
re-learn established connections then it's the behaviour I would expect.

-- 
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 tusker at tusker.org  Wed Aug  3 13:22:52 2005
From: tusker at tusker.org (Damien Mascord)
Date: Wed, 03 Aug 2005 11:22:52 +0800
Subject: Hung ssh client connection
In-Reply-To: <42F03218.7070208@zip.com.au>
References: <42F02D32.6070401@tusker.org> <42F03218.7070208@zip.com.au>
Message-ID: <42F0388C.4060505@tusker.org>

Darren Tucker wrote:
> Damien Mascord wrote:
> 
>> We have a netscreen 5gt-plus, running ScreenOS 5.0.2, which has an ssh
>> daemon running.
> 
> [...]
> 
>> If I restart the firewall using the command 'reset', I get a message
>> that the firewall is resetting, which is good.
> 
> [...]
> 
>> What could be the cause of this connection 'hanging' ? Is it on the SSH
>> client, the SSH server not closing the connection correctly upon reset ?
>>  Or could it be something in the TCP OS layer ?
> 
> 
> When you "reset" your firewall, it flushes its state table, right?  If
> so then would probably include the SSH TCP connection too.

*nods* ok, makes sense, so because the firewall isn't responding at all
to the SSH connection (that it no longer knows about), the client is
just waiting until it either times out or gets a connect reset ?

> One place this might show up is in "netstat" on the client: if there's a
> constant value in the "Send-Q" column for the ssh connection to your
> firewall then that's almost certainly what's happening.

The Send-Q starts at 0, and starts increasing as I 'send' characters
through the ssh client, until it grows until 5632:


tcp        0   5632 <ip of client>:38428      <ip of firewall>:22
   ESTABLISHED 30202/ssh

(Where does the value 5632 come from?)

tcpdump shows an ack sent every 2 minutes:

11:05:45.612452 IP <ip of client>.38428 > <ip of firewall>.ssh: P
2749294956:2749295044(88) ack 270286710 win 7680
11:07:45.594004 IP <ip of client>.38428 > <ip of firewall>.ssh: P
0:88(88) ack 1 win 7680
11:09:45.575585 IP <ip of client>.38428 > <ip of firewall>.ssh: P
0:88(88) ack 1 win 7680

>> If it is expected behaviour, I apologize, though would like to
>> understand why this is happening on a technical level.
> 
> If connections *to* the firewall (as opposed to *through* it) are
> subject the the firewall rules and unless it has the capability to
> re-learn established connections then it's the behaviour I would expect.

So, because the firewall silently ignores the ACKs sent to it, the
client has nothing to do except wait for some indication?

Would the following sysctl value have an effect on the timeout ?

net.ipv4.tcp_retries2 = 15 # Defines how many times a TCP packet is
retransmitted in established state before giving up.

Cheers,

Damien







From dtucker at zip.com.au  Wed Aug  3 13:44:29 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 03 Aug 2005 13:44:29 +1000
Subject: Hung ssh client connection
In-Reply-To: <42F0388C.4060505@tusker.org>
References: <42F02D32.6070401@tusker.org> <42F03218.7070208@zip.com.au>
	<42F0388C.4060505@tusker.org>
Message-ID: <42F03D9D.80401@zip.com.au>

Damien Mascord wrote:
> Darren Tucker wrote:
>>When you "reset" your firewall, it flushes its state table, right?  If
>>so then would probably include the SSH TCP connection too.
> 
> *nods* ok, makes sense, so because the firewall isn't responding at all
> to the SSH connection (that it no longer knows about), the client is
> just waiting until it either times out or gets a connect reset ?

Yes.  There's nothing else it can do.

>>One place this might show up is in "netstat" on the client: if there's a
>>constant value in the "Send-Q" column for the ssh connection to your
>>firewall then that's almost certainly what's happening.
> 
> The Send-Q starts at 0, and starts increasing as I 'send' characters
> through the ssh client, until it grows until 5632:
[...]
> (Where does the value 5632 come from?)

It's just the number of bytes that have been sent by the client and not 
yet acknowledged by the server.  If it stops growing at 5632 then that's 
probably the limit of the send queue in the kernel (in which case strace 
would probably show writes to the network descriptor either blocking or 
returning EAGAIN).

[...]
> So, because the firewall silently ignores the ACKs sent to it, the
> client has nothing to do except wait for some indication?

Yes.

> Would the following sysctl value have an effect on the timeout ?
> 
> net.ipv4.tcp_retries2 = 15 # Defines how many times a TCP packet is
> retransmitted in established state before giving up.

Probably.  I've never tried it.

You could also set the ServerAliveInterval and ServerAliveCountMax in 
~/.ssh/config or ssh_config to make it detect the failure faster.

-- 
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 philipp.bunge at id.unibe.ch  Thu Aug  4 18:37:17 2005
From: philipp.bunge at id.unibe.ch (Philipp Bunge)
Date: Thu, 04 Aug 2005 10:37:17 +0200
Subject: Patch to selectively override a user's shell
Message-ID: <D5E72B1F-5B07-4060-A49F-4EEBC9132951@id.unibe.ch>

Hello,

I don't know if this is of anybody's interest here, but I have  
written a patch to selectively override a user's shell dependent of  
the username.

The reason behind this is, that at the high performance cluster I  
work at, we would like that normal users are only permitted to use  
scp and sftp (and thus a shell like rssh) on our master nodes, but  
should retain their normal shell on all other nodes. With this patch,  
we can define what users may retain their normal shell on the master  
nodes and which ones will have their shell changed to a default one.


The patch can be found here: https://ubelix.unibe.ch/local/tmp/ 
openssh-4.1_p1-shell-override.patch



USAGE: The patch adds three config parameters to sshd_config. These are;
     * OverrideShell - Shell to be used if the user's shell will be  
overridden (e.g. OverrideShell /usr/bin/rssh).
     * AllowShell - Space separated list of users that should be  
allowed to use their shell as specified in /etc/passwd or in LDAP or  
wherever your authenticating from. If this is set, any user that is  
not listed here will receive the shell specified in OverrideShell.
     * DenyShell - Space separated list of users who will be denied  
their shell specified in /etc/passwd or wherever and will receive the  
OverrideShell instead. If only this is set, all other users will get  
their normal shell.



EXAMPLES: To deny the normal shell to all users except for root and  
admin and provide them with rssh as a shell instead /etc/ssh/ 
sshd_config should contain following lines:

     # Use a shell that allows us to use scp and sftp but won't allow  
us to log in:
     OverrideShell /usr/bin/rssh
     # Only root and admin are allowed to log in directly:
     AllowShell root admin

To allow all users to log in except user1 and user2 who should only  
be able to use scp and sftp:

     # Use a shell that allows us to use scp and sftp but won't allow  
us to log in:
     OverrideShell /usr/bin/rssh
     # Everyone may log in except for user1 and user2
     DenyShell user1 user2


I would be happy to hear any feedback!

Regards,
Philipp

PS.: I'm not subscribed to this mailinglist, please cc any replies to  
me.



From frederik at a5.repetae.net  Thu Aug  4 23:09:51 2005
From: frederik at a5.repetae.net (Frederik Eaton)
Date: Thu, 4 Aug 2005 06:09:51 -0700
Subject: scp -S, sftp -S (was: Re: port forwarding trouble)
In-Reply-To: <20050802231330.27584.qmail@cdy.org>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050802231330.27584.qmail@cdy.org>
Message-ID: <20050804130951.GA8385@a5.repetae.net>

On Wed, Aug 03, 2005 at 01:13:30AM +0200, Peter Stuge wrote:
> On Tue, Aug 02, 2005 at 05:39:59PM +0100, Frederik Eaton wrote:
> > > As Peter Stuge noted earlier, you can use HostKeyAlias to specify
> > > the real name of the host you're connecting to over the forward.
> > 
> > So, I could just write a wrapper that always passes "-o
> > HostKeyAlias=host:port" to ssh to get around the bug?
> 
> That, or add the following to ~/.ssh/config or /etc/ssh/ssh_config
> 
> Host tunnelhost
>   HostKeyAlias real.host.name
>   HostName localhost
>   Port 2222
> 
> And then connect to it using:
> 
> ssh tunnelhost
> 
> Repeat for as many tunnelhosts as you want, just change Host,
> HostKeyAlias and Port for each.

OK. The reason I'm doing this is that I'm finally getting around to
writing an ssh wrapper which fixes all of the gripes I have with ssh.
(Well, to be precise I wrote one earlier in zsh and now I'm writing a
better, cleaner version in Haskell.) So always specifying a -o
HostKeyAlias=X option on the command line is something I can do
automatically.

Now, as I'm investigating interactions with various programs, I've run
into a problem: the -S option to sftp and scp lets you give the name
of an executable to use instead of ssh, but doesn't let you specify
arguments to pass to that executable (as does rsync's -e option).

Furthermore, if scp executes another scp instance remotely, then it
does not propagate its own -S value to the remote instance - it seems
to me that it should at least be possible to configure scp to do this,
even if it isn't the default.

I am willing to fix both of these problems in openssh, and update the
documentation, if people think it would be a good idea.

Frederik

P.S. The features of my ssh wrapper:

(a) Separation of command arguments is preserved. 

$ ssh localhost sh -c "echo hi"

$ fssh localhost sh -c "echo hi"
hi

(b) Ports can be specified in the host name (with "=" or ":"), and a
string of hosts can be specified by joining them with "+". This is
quite useful for logging onto hosts which live behind a firewall.
(Below, the ofb.net admins didn't want to make the forwarded port
externally accessible)

$ fssh ofb.net+localhost:42224 hostname
taisa
$ fssh ofb.net+localhost:42224 sh -c "echo hi"
hi

(c) Host aliases can be defined with a script ~/.host_alias:

$ ~/.host_alias taisa
ofb.net+localhost:42224
$ fssh taisa sh -c "echo hi" 
hi

My version of the .host_alias script produces different results
depending on current network location, so that as I move my laptop
around I can use the same names to refer to the same hosts, without
sacrificing efficiency in the cases when I am on the same subnet as
those hosts by using the appropriate shortcuts when possible.

(d) The mapping from hosts to host keys takes port number into
account. For instance, the previous command invokes 'ssh' as:

ssh -o 'HostKeyAlias=ofb.net' ofb.net -- "ssh -o 'HostKeyAlias=localhost:42224' -p 42224 localhost -- \"sh -c 'echo hi'\""

...

All of this makes it possible for me to use things like cvs and rsync
rather transparently across tunnels and firewalls just by configuring
the appropriate environment variables (CVS_RSH, RSYNC_RSH). However,
as noted above, there are still some wrinkles that I would like to
smooth out.



From dtucker at zip.com.au  Thu Aug  4 23:15:20 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 04 Aug 2005 23:15:20 +1000
Subject: New Set of High Performance Networking Patches Available
In-Reply-To: <42B32989.2080106@psc.edu>
References: <42B32989.2080106@psc.edu>
Message-ID: <42F214E8.5000201@zip.com.au>

Chris Rapier wrote:
> http://www.psc.edu/networking/projects/hpn-ssh/

Looking at these has been on my to-do list for a while and I finally 
took a look.

> 1) HPN performance even without both sides of the connection being HPN 
> enabled. As long as the bulk data flow is in the direction of the HPN 
> side you should see improved performance. I've measure 200Mb/s to an HPN 
> server from a non HPN client and vice versa.

I've been testing with tunbridge[1] on OpenBSD to add latency.  I've 
seen an improvement of around 50% throughput on scp with 100ms of 
latency (each way, ie 200ms rtt) simulated link with Linux endpoints.

Using -w doesn't seem to make any difference (or sometimes it's a net 
loss) although it's quite possible something in my test environment is 
responsible for that.  (Yes, I did the stack tuning, both netstat and 
getsockopt show the buffers are 1MB or more.)

> 2) HPN client can now set the local tcp receive buffer on a per 
> connection basis. Using the -w option allows the client to override the 
> local tcp receive window settings up to the maximum tcp buffer size. 
> This is just a setsockopt() call really.

I think this should be a ssh_config(5) option (maybe "TCPReceiveBuffer" 
?) rather than a command-line switch (ssh already has enough switches...)

This would allow it to be set either per-connection or globally, and may 
be passed through from the scp command line with the "-o" option.

The latter would also mean that scp would need less modification (and 
scp's code is mostly shared with rcp, so that's also a plus).

Attached is a diff relative to openssh-4.1p1-hpn11.diff with a couple of 
proposed changes:
* move the sshconnect.c setsockopt code into its own function
* make that function style(9) compliant
* fix a bug where strerror was used on the non-error path
* make BUFFER_MAX_HPN_LEN an unsigned to placate gcc -Wsign-compare
* replace magic numbers in channels.h with symbolic names

I don't think I changed any functionality (but I could have missed 
something...)

[1] http://www.iijlab.net/~kjc/software/dist/tunbridge-0.1.tar.gz

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

From dtucker at zip.com.au  Thu Aug  4 23:26:00 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 04 Aug 2005 23:26:00 +1000
Subject: New Set of High Performance Networking Patches Available
In-Reply-To: <42F214E8.5000201@zip.com.au>
References: <42B32989.2080106@psc.edu> <42F214E8.5000201@zip.com.au>
Message-ID: <42F21768.1080602@zip.com.au>

Darren Tucker wrote:
> +#define CHAN_SES_WINDOW_DEFAULT	(BUFFER_MAX_LEN/2)

Thinking about it, those ought to be (BUFFER_MAX_LEN - BUFFER_MAX_CHUNK) 
since in 4.0 and up, the buffers will be compacted once the buffer 
offset is beyond BUFFER_MAX_CHUNK, rather than half of the allocated 
size in previous versions.

-- 
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 Sergio.Gelato at astro.su.se  Thu Aug  4 23:35:49 2005
From: Sergio.Gelato at astro.su.se (Sergio Gelato)
Date: Thu, 4 Aug 2005 15:35:49 +0200
Subject: port forwarding trouble
In-Reply-To: <20050802163959.GH23428@a5.repetae.net>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
Message-ID: <20050804133549.GB2317@hanuman.astro.su.se>

* Frederik Eaton [2005-08-02 17:39:59 +0100]:
> Also, I don't think that the "host at port" syntax suggested in the bug
> comments is a good idea. 

At the very least it should be port at host. There is precedent for that,
e.g. in FlexLM LM_LICENSE_FILE environment variables.

>                          There should be some standard for ipv6, and
> we should use it. E.g., what do URLs use to specify the port when the
> host is specified as an IPv6 address?

I'm not sure about URLs, but various tools simply require square
brackets around the IPv6 address, as in
	[0:1:2:3:4:5:6:7]:port
For example, this (minus the port number) is what you are supposed to
do in /etc/hosts.allow. Implementations differ as to whether one needs
[fe80::]/10 or [fe80::/10] for network prefixes, but I think the former
is winning.

> A brief search indicated "host.:port" might be used somewhere. 
> But "host:port" is so common that it would be better to use a different
> notation only when 'host' is IPv6. "@" is especially bad, because it
> makes it look like the host is a user.

The [address]:port notation should be OK to use with both IPv4 (optional) 
and IPv6.



From dtucker at zip.com.au  Fri Aug  5 00:41:37 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 05 Aug 2005 00:41:37 +1000
Subject: port forwarding trouble
In-Reply-To: <20050804133549.GB2317@hanuman.astro.su.se>
References: <20050802120921.GA24095@a5.repetae.net>	<42EF95CF.5090001@zip.com.au>	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
Message-ID: <42F22921.7090204@zip.com.au>

Sergio Gelato wrote:
> * Frederik Eaton [2005-08-02 17:39:59 +0100]:
>>Also, I don't think that the "host at port" syntax suggested in the bug
>>comments is a good idea. 
> 
> At the very least it should be port at host. There is precedent for that,
> e.g. in FlexLM LM_LICENSE_FILE environment variables.

Why is that better the host at port?  I would bet there's precedent for 
that somewhere too.

[...]
> I'm not sure about URLs, but various tools simply require square
> brackets around the IPv6 address, as in
> 	[0:1:2:3:4:5:6:7]:port

That would be OK for new entries but it's not backward compatible with 
existing known_hosts files.

Once you add an optional ":port" I don't see how it's possible to 
reliably distinguish between IPv6 addresses created by old versions and 
host:port indentifiers created by new versions.

> For example, this (minus the port number) is what you are supposed to
> do in /etc/hosts.allow. Implementations differ as to whether one needs
> [fe80::]/10 or [fe80::/10] for network prefixes, but I think the former
> is winning.

OpenSSH already understands that notation, eg for ListenAddress (minus 
the network prefix, I think).

>>A brief search indicated "host.:port" might be used somewhere. 
>>But "host:port" is so common that it would be better to use a different
>>notation only when 'host' is IPv6. "@" is especially bad, because it
>>makes it look like the host is a user.

They're host keys, I don't see how the identifiers could be confused 
with a user. There's no reference to users at all in known_hosts.

-- 
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 jos at catnook.com  Fri Aug  5 01:48:33 2005
From: jos at catnook.com (Jos Backus)
Date: Thu, 4 Aug 2005 08:48:33 -0700
Subject: port forwarding trouble
In-Reply-To: <42F22921.7090204@zip.com.au>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
	<42F22921.7090204@zip.com.au>
Message-ID: <20050804154855.GA89699@lizzy.catnook.local>

On Fri, Aug 05, 2005 at 12:41:37AM +1000, Darren Tucker wrote:
> Sergio Gelato wrote:
> > * Frederik Eaton [2005-08-02 17:39:59 +0100]:
> >>Also, I don't think that the "host at port" syntax suggested in the bug
> >>comments is a good idea. 
> > 
> > At the very least it should be port at host. There is precedent for that,
> > e.g. in FlexLM LM_LICENSE_FILE environment variables.
> 
> Why is that better the host at port?  I would bet there's precedent for 
> that somewhere too.

port at host preserves symmetry with user at host?

-- 
Jos Backus
jos at catnook.com



From dtucker at zip.com.au  Fri Aug  5 01:59:45 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 05 Aug 2005 01:59:45 +1000
Subject: scp -S, sftp -S
In-Reply-To: <20050804130951.GA8385@a5.repetae.net>
References: <20050802120921.GA24095@a5.repetae.net>	<42EF95CF.5090001@zip.com.au>	<20050802163959.GH23428@a5.repetae.net>	<20050802231330.27584.qmail@cdy.org>
	<20050804130951.GA8385@a5.repetae.net>
Message-ID: <42F23B71.10202@zip.com.au>

Frederik Eaton wrote:
[...]
> (b) Ports can be specified in the host name (with "=" or ":"), and a
> string of hosts can be specified by joining them with "+". This is
> quite useful for logging onto hosts which live behind a firewall.
> (Below, the ofb.net admins didn't want to make the forwarded port
> externally accessible)

If you have "connect" or "nc" on the intermediate host(s), this can also 
be accompished via ssh_config.

For example, imagine you have host "internalhost" behind host 
"firewall".  You can construct ~/.ssh/config like so:

Host internalhost
	ProxyCommand ssh firewall connect %h %p

These are "stackable".   If you were to have another host 
"reallyinternal" that was only reachable from "internalhost" then you 
could simply add:

Host reallyinternal
	ProxyCommand ssh internalhost connect %h %p

The proxycommand can also be a shell script that behaves differently 
under different conditions.  (I have one that knows which proxies to use 
for the various networks I inhabit.)

If you have pubkey auth then it's pretty much transparent.

You pay a price in multiple encryption (although you can mitigate this 
by specifying a fast cipher like arcfour for the intermediate hops.)

One day I'd like ssh to learn how to establish a single port forward and 
pass the traffic to and from stdin/stdout, which would remove the need 
to have connect/nc on the intermediate hosts (and the modified ssh would 
only be required on the client end).

[...]
> All of this makes it possible for me to use things like cvs and rsync
> rather transparently across tunnels and firewalls just by configuring
> the appropriate environment variables (CVS_RSH, RSYNC_RSH). However,
> as noted above, there are still some wrinkles that I would like to
> smooth out.

Yeah, at a previous employer we used to run rsync and cvs over the above 
   on networks where there was no end-to-end route (and sometimes not 
even end-to-middle routes :-).

-- 
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 Sergio.Gelato at astro.su.se  Fri Aug  5 02:01:08 2005
From: Sergio.Gelato at astro.su.se (Sergio Gelato)
Date: Thu, 4 Aug 2005 18:01:08 +0200
Subject: port forwarding trouble
In-Reply-To: <42F22921.7090204@zip.com.au>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
	<42F22921.7090204@zip.com.au>
Message-ID: <20050804160108.GC2317@hanuman.astro.su.se>

* Darren Tucker [2005-08-05 00:41:37 +1000]:
> Sergio Gelato wrote:
> >* Frederik Eaton [2005-08-02 17:39:59 +0100]:
> >>Also, I don't think that the "host at port" syntax suggested in the bug
> >>comments is a good idea. 
> >
> >At the very least it should be port at host. There is precedent for that,
> >e.g. in FlexLM LM_LICENSE_FILE environment variables.
> 
> Why is that better the host at port?  I would bet there's precedent for 
> that somewhere too.

Because "@" traditionally stands for the preposition "at", and most
people find it more natural to use the host name as a scope identifier
than the port number (maybe also because e-mail addresses have
the host name on the right side of the @ sign).

And while we are comparing with e-mail addresses: how about host!port ?

> [...]
> >I'm not sure about URLs, but various tools simply require square
> >brackets around the IPv6 address, as in
> >	[0:1:2:3:4:5:6:7]:port
> 
> That would be OK for new entries but it's not backward compatible with 
> existing known_hosts files.

That means the code to parse existing known_hosts files needs to be a
little more complex. New entries should obviously use the less ambiguous
notation.

> Once you add an optional ":port" I don't see how it's possible to 
> reliably distinguish between IPv6 addresses created by old versions and 
> host:port indentifiers created by new versions.

Don't add an optional ":port" for IPv6 address literals, then; make the
[v6addr]:port notation mandatory in such cases. 

If you've already allowed v6addr:port, then the ambiguity is with us no 
matter what. For interpreting existing known_hosts files, one could
agree that (a) the now-deprecated notation causes a warning to be
emitted, and (b) an ambiguous string is interpreted as matching
either interpretation, e.g. ::1:22 is equivalent to [::1]:22,[::1:22] .

> >For example, this (minus the port number) is what you are supposed to
> >do in /etc/hosts.allow. Implementations differ as to whether one needs
> >[fe80::]/10 or [fe80::/10] for network prefixes, but I think the former
> >is winning.
> 
> OpenSSH already understands that notation, eg for ListenAddress (minus 
> the network prefix, I think).
> 
> >>A brief search indicated "host.:port" might be used somewhere. 
> >>But "host:port" is so common that it would be better to use a different
> >>notation only when 'host' is IPv6. "@" is especially bad, because it
> >>makes it look like the host is a user.
> 
> They're host keys, I don't see how the identifiers could be confused 
> with a user. There's no reference to users at all in known_hosts.

The software wouldn't be confused, but humans who edit the known_hosts 
file might.



From dtucker at zip.com.au  Fri Aug  5 02:07:20 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 05 Aug 2005 02:07:20 +1000
Subject: port forwarding trouble
In-Reply-To: <20050804154855.GA89699@lizzy.catnook.local>
References: <20050802120921.GA24095@a5.repetae.net>	<42EF95CF.5090001@zip.com.au>	<20050802163959.GH23428@a5.repetae.net>	<20050804133549.GB2317@hanuman.astro.su.se>	<42F22921.7090204@zip.com.au>
	<20050804154855.GA89699@lizzy.catnook.local>
Message-ID: <42F23D38.106@zip.com.au>

Jos Backus wrote:
> On Fri, Aug 05, 2005 at 12:41:37AM +1000, Darren Tucker wrote:
>>Why is that better the host at port?  I would bet there's precedent for 
>>that somewhere too.
> 
> port at host preserves symmetry with user at host?

port at host reduces consistency with the other places in OpenSSH where 
ports may be specified as an optional appendage?

-- 
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 rapier at psc.edu  Fri Aug  5 02:12:20 2005
From: rapier at psc.edu (Chris Rapier)
Date: Thu, 04 Aug 2005 12:12:20 -0400
Subject: New Set of High Performance Networking Patches Available
In-Reply-To: <42F214E8.5000201@zip.com.au>
References: <42B32989.2080106@psc.edu> <42F214E8.5000201@zip.com.au>
Message-ID: <42F23E64.9000203@psc.edu>



Darren Tucker wrote:
> Chris Rapier wrote:
> 
>> http://www.psc.edu/networking/projects/hpn-ssh/
> 
> 
> Looking at these has been on my to-do list for a while and I finally 
> took a look.

Excellent.

>> 1) HPN performance even without both sides of the connection being HPN 
>> enabled. As long as the bulk data flow is in the direction of the HPN 
>> side you should see improved performance. I've measure 200Mb/s to an 
>> HPN server from a non HPN client and vice versa.
> 
> 
> I've been testing with tunbridge[1] on OpenBSD to add latency.  I've 
> seen an improvement of around 50% throughput on scp with 100ms of 
> latency (each way, ie 200ms rtt) simulated link with Linux endpoints.

In the real word test environments we have set up we're commonly seeing 
improvements of 10 to 30x greater throughput. 25MBytes/s+ where before 
we were seeing less than 1Mbyte/s.

> Using -w doesn't seem to make any difference (or sometimes it's a net 
> loss) although it's quite possible something in my test environment is 
> responsible for that.  (Yes, I did the stack tuning, both netstat and 
> getsockopt show the buffers are 1MB or more.)

It will only make a difference when the client is acting as the data 
sink. Obviously the max buffer size has to be large enough to handle the 
  user defined setting. In our test environments it has been shown to 
make a difference - some of our users have reported good results with it 
as well. If its possible maybe we could get you on one of our test 
machines to try it out. Shoot me a note if you are interested and I'll 
see what our policies on this are.

>> 2) HPN client can now set the local tcp receive buffer on a per 
>> connection basis. Using the -w option allows the client to override 
>> the local tcp receive window settings up to the maximum tcp buffer 
>> size. This is just a setsockopt() call really.
> 
> 
> I think this should be a ssh_config(5) option (maybe "TCPReceiveBuffer" 
> ?) rather than a command-line switch (ssh already has enough switches...)

Well, the problem is that you only want to set a large buffer size when 
you really need it and even then, its often best to tune the buffer to 
the specific path. Providing this option on the command line, in our 
view, allows for the greatest flexibility. I have no objection to there 
being a default in the ssh_config but I think its important for the user 
to be able to override it.

> This would allow it to be set either per-connection or globally, and may 
> be passed through from the scp command line with the "-o" option.

Okay, so thats basically the same thing. I'd suggest using a shorter 
name though but thats not a mahjor point to get hung up on.

> The latter would also mean that scp would need less modification (and 
> scp's code is mostly shared with rcp, so that's also a plus).

I honestly think changing scp's code isn't a bad thing. :)

> Attached is a diff relative to openssh-4.1p1-hpn11.diff with a couple of 
> proposed changes:
> * move the sshconnect.c setsockopt code into its own function
> * make that function style(9) compliant
> * fix a bug where strerror was used on the non-error path
> * make BUFFER_MAX_HPN_LEN an unsigned to placate gcc -Wsign-compare
> * replace magic numbers in channels.h with symbolic names
> 
> I don't think I changed any functionality (but I could have missed 
> something...)
> 
> [1] http://www.iijlab.net/~kjc/software/dist/tunbridge-0.1.tar.gz

Mike Stevens and I will take a look at next week I think. We're working 
on some other stuff based on SSH (basically a more advanced port 
forwarding system) that we're trying to nail down. That should be done 
by the end of this week though.

Chris



From dtucker at zip.com.au  Fri Aug  5 02:27:36 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 05 Aug 2005 02:27:36 +1000
Subject: port forwarding trouble
In-Reply-To: <20050804160108.GC2317@hanuman.astro.su.se>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
	<42F22921.7090204@zip.com.au>
	<20050804160108.GC2317@hanuman.astro.su.se>
Message-ID: <42F241F8.5030702@zip.com.au>

Sergio Gelato wrote:
> * Darren Tucker [2005-08-05 00:41:37 +1000]:
> 
>>Sergio Gelato wrote:
>>
>>>* Frederik Eaton [2005-08-02 17:39:59 +0100]:
>>>
>>>>Also, I don't think that the "host at port" syntax suggested in the bug
>>>>comments is a good idea. 
>>>
>>>At the very least it should be port at host. There is precedent for that,
>>>e.g. in FlexLM LM_LICENSE_FILE environment variables.
>>
>>Why is that better the host at port?  I would bet there's precedent for 
>>that somewhere too.
> 
> 
> Because "@" traditionally stands for the preposition "at", and most
> people find it more natural to use the host name as a scope identifier
> than the port number (maybe also because e-mail addresses have
> the host name on the right side of the @ sign).

As a mnemonic is still works ("host foo.far.com at port 22").

> And while we are comparing with e-mail addresses: how about host!port ?

I don't mind it (as long as it's not a valid char in a host name.. what 
are the rules these days?), but see below.

[...]
>>>I'm not sure about URLs, but various tools simply require square
>>>brackets around the IPv6 address, as in
>>>	[0:1:2:3:4:5:6:7]:port
>>
>>That would be OK for new entries but it's not backward compatible with 
>>existing known_hosts files.
> 
> That means the code to parse existing known_hosts files needs to be a
> little more complex. New entries should obviously use the less ambiguous
> notation.

I had to come up with a heuristic for this for another reason (sshd's 
ListenAddress is slightly broken for bare IPv6 addresses) which might be 
enough:

if the string doesn't contain "[]" and contains 2 or more ":"
	it's a bare IPv6 address
else
	do existing tests in misc.c:hpdelim()

>>Once you add an optional ":port" I don't see how it's possible to 
>>reliably distinguish between IPv6 addresses created by old versions and 
>>host:port indentifiers created by new versions.
> 
> Don't add an optional ":port" for IPv6 address literals, then; make the
> [v6addr]:port notation mandatory in such cases. 

That's reasonable since the notation with the port spec isn't backward 
compatible anyway.

> If you've already allowed v6addr:port, then the ambiguity is with us no 
> matter what.

I don't think that notation is permitted anyplace.  It's not documented, 
anyway.

> For interpreting existing known_hosts files, one could
> agree that (a) the now-deprecated notation causes a warning to be
> emitted, and (b) an ambiguous string is interpreted as matching
> either interpretation, e.g. ::1:22 is equivalent to [::1]:22,[::1:22] .

[...]
>>They're host keys, I don't see how the identifiers could be confused 
>>with a user. There's no reference to users at all in known_hosts.
> 
> The software wouldn't be confused, but humans who edit the known_hosts 
> file might.

Since it's always numeric I can't see that being a big problem.

I'd like to use the same format everywhere if possible, but not if it 
means breaking a gazillion existing known_hosts files.

-- 
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 frederik at a5.repetae.net  Fri Aug  5 02:36:10 2005
From: frederik at a5.repetae.net (Frederik Eaton)
Date: Thu, 4 Aug 2005 17:36:10 +0100
Subject: scp -S, sftp -S
In-Reply-To: <42F23B71.10202@zip.com.au>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050802231330.27584.qmail@cdy.org>
	<20050804130951.GA8385@a5.repetae.net> <42F23B71.10202@zip.com.au>
Message-ID: <20050804163610.GC25444@a5.repetae.net>

> [...]
> If you have pubkey auth then it's pretty much transparent.
> 
> You pay a price in multiple encryption (although you can mitigate this 
> by specifying a fast cipher like arcfour for the intermediate hops.)
> 
> One day I'd like ssh to learn how to establish a single port forward and 
> pass the traffic to and from stdin/stdout, which would remove the need 
> to have connect/nc on the intermediate hosts (and the modified ssh would 
> only be required on the client end).

I see. That would be nice. But why was 'connect' needed at all? I
found that nesting ssh as I described works fine (except that you need
a wrapper script to manage the task of quoting your command properly).
Does your version have lower latency or something? I guess my version
puts some extra encryption burden on the firewall, and doesn't have
end-end encryption, so if you don't trust the firewall operator...

Anyway, I do this often enough that I think I'll find my shorter
syntax quite useful. If necessary, the wrapper script can always be
modified to chain things with ProxyCommand instead of through the ssh
remote command arguments.

Frederik



From dtucker at zip.com.au  Fri Aug  5 02:41:48 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 05 Aug 2005 02:41:48 +1000
Subject: New Set of High Performance Networking Patches Available
In-Reply-To: <42F23E64.9000203@psc.edu>
References: <42B32989.2080106@psc.edu> <42F214E8.5000201@zip.com.au>
	<42F23E64.9000203@psc.edu>
Message-ID: <42F2454C.1030604@zip.com.au>

Chris Rapier wrote:
> Darren Tucker wrote:
[hpn patch]
>> I've been testing with tunbridge[1] on OpenBSD to add latency.  I've 
>> seen an improvement of around 50% throughput on scp with 100ms of 
>> latency (each way, ie 200ms rtt) simulated link with Linux endpoints.
> 
> In the real word test environments we have set up we're commonly seeing 
> improvements of 10 to 30x greater throughput. 25MBytes/s+ where before 
> we were seeing less than 1Mbyte/s.
> 
>> Using -w doesn't seem to make any difference (or sometimes it's a net 
>> loss) although it's quite possible something in my test environment is 
>> responsible for that.  (Yes, I did the stack tuning, both netstat and 
>> getsockopt show the buffers are 1MB or more.)
> 
> It will only make a difference when the client is acting as the data 
> sink. Obviously the max buffer size has to be large enough to handle the 
> user defined setting.

I can see 1+ MB sitting in the server's TCP send queue.  I suspect it's 
some local problem limiting TCP throughput in the high-BDP configuration 
(they're not super beefy hosts but a direct connect gives me ~6MB/s so 
they're capable of more than the ~ 500-600 KB/s I'm seeing with the 
latency).

> In our test environments it has been shown to 
> make a difference - some of our users have reported good results with it 
> as well. If its possible maybe we could get you on one of our test 
> machines to try it out. Shoot me a note if you are interested and I'll 
> see what our policies on this are.
> 
>>> 2) HPN client can now set the local tcp receive buffer on a per 
>>> connection basis. Using the -w option allows the client to override 
>>> the local tcp receive window settings up to the maximum tcp buffer 
>>> size. This is just a setsockopt() call really.
>>
>> I think this should be a ssh_config(5) option (maybe 
>> "TCPReceiveBuffer" ?) rather than a command-line switch (ssh already 
>> has enough switches...)
> 
> Well, the problem is that you only want to set a large buffer size when 
> you really need it and even then, its often best to tune the buffer to 
> the specific path. Providing this option on the command line, in our 
> view, allows for the greatest flexibility. I have no objection to there 
> being a default in the ssh_config but I think its important for the user 
> to be able to override it.

You can specify it in the config file on a per-host basis and/or as a 
default so I think it's OK.  In fact, it's probably more convenient for 
end users (as opposed to people testing ssh mods :-) since they can just 
enable it for the appropriate hosts then forget about it.

>> This would allow it to be set either per-connection or globally, and 
>> may be passed through from the scp command line with the "-o" option.
> 
> Okay, so thats basically the same thing. I'd suggest using a shorter 
> name though but thats not a mahjor point to get hung up on.

There's an existing config TCP option (TCPKeepAlive), I picked it to be 
consistent with that.

>> The latter would also mean that scp would need less modification (and 
>> scp's code is mostly shared with rcp, so that's also a plus).
> 
> I honestly think changing scp's code isn't a bad thing. :)

Yeah but you don't have to maintain it :-)

[patch]
> Mike Stevens and I will take a look at next week I think. We're working 
> on some other stuff based on SSH (basically a more advanced port 
> forwarding system) that we're trying to nail down. That should be done 
> by the end of this week though.

Thanks.

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



From rapier at psc.edu  Fri Aug  5 02:55:28 2005
From: rapier at psc.edu (Chris Rapier)
Date: Thu, 04 Aug 2005 12:55:28 -0400
Subject: New Set of High Performance Networking Patches Available
In-Reply-To: <42F2454C.1030604@zip.com.au>
References: <42B32989.2080106@psc.edu> <42F214E8.5000201@zip.com.au>
	<42F23E64.9000203@psc.edu> <42F2454C.1030604@zip.com.au>
Message-ID: <42F24880.4070900@psc.edu>



Darren Tucker wrote:
> Chris Rapier wrote:

> I can see 1+ MB sitting in the server's TCP send queue.  I suspect it's 
> some local problem limiting TCP throughput in the high-BDP configuration 
> (they're not super beefy hosts but a direct connect gives me ~6MB/s so 
> they're capable of more than the ~ 500-600 KB/s I'm seeing with the 
> latency).

Yeah, thats definitely low. Can you try a loopback to your localhost and 
dump the data into /dev/null to see what sort of limit the CPU is 
imposing? Also, what cipher? 3des is justa nightmare. Most of our tests 
are using arcfour and blowfish.


> You can specify it in the config file on a per-host basis and/or as a 
> default so I think it's OK.  In fact, it's probably more convenient for 
> end users (as opposed to people testing ssh mods :-) since they can just 
> enable it for the appropriate hosts then forget about it.

That works. Honestly, this was mostly an afterthought - one of the users 
that connects to us needed something like this for various reasons. They 
did good stuff with it though (near term storm forecasting 
http://www.psc.edu/publicinfo/news/2005/2005-07-05-caps.html - all data 
xfered with hpn-ssh).


>>> This would allow it to be set either per-connection or globally, and 
>>> may be passed through from the scp command line with the "-o" option.
>>
>>
>> Okay, so thats basically the same thing. I'd suggest using a shorter 
>> name though but thats not a mahjor point to get hung up on.
> 
> 
> There's an existing config TCP option (TCPKeepAlive), I picked it to be 
> consistent with that.

I just hate having really long command lines but consistant nomenclature 
is important. I have no objections to a longer more descriptive name.

>>> The latter would also mean that scp would need less modification (and 
>>> scp's code is mostly shared with rcp, so that's also a plus).
>>
>>
>> I honestly think changing scp's code isn't a bad thing. :)
> 
> 
> Yeah but you don't have to maintain it :-)

Yeah, but if we change it enough we'll be forced to maintain it. So this 
would be an excellent opportunity to pass the torch :D



From dtucker at zip.com.au  Fri Aug  5 02:56:57 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 05 Aug 2005 02:56:57 +1000
Subject: scp -S, sftp -S
In-Reply-To: <20050804163610.GC25444@a5.repetae.net>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050802231330.27584.qmail@cdy.org>
	<20050804130951.GA8385@a5.repetae.net> <42F23B71.10202@zip.com.au>
	<20050804163610.GC25444@a5.repetae.net>
Message-ID: <42F248D9.8080706@zip.com.au>

Frederik Eaton wrote:
>>[...]
>>If you have pubkey auth then it's pretty much transparent.
>>
>>You pay a price in multiple encryption (although you can mitigate this 
>>by specifying a fast cipher like arcfour for the intermediate hops.)
>>
>>One day I'd like ssh to learn how to establish a single port forward and 
>>pass the traffic to and from stdin/stdout, which would remove the need 
>>to have connect/nc on the intermediate hosts (and the modified ssh would 
>>only be required on the client end).
> 
> I see. That would be nice. But why was 'connect' needed at all?

Because a proxycommand operates on stdio, you need to make a TCP 
connection somehow.  If ssh learns the above then it won't be necessary.

> I found that nesting ssh as I described works fine (except that you need
> a wrapper script to manage the task of quoting your command properly).

I don't follow: with the example I gave, a multi-hop ssh works exactly 
the same as a single-hop.

> Does your version have lower latency or something?

The main thing it gives you is a guaranteed end-to-end SSH connection 
and thus:
a) a verifyable host key on *your* client, thus no MITM.
b) 8-bit clean
c) no quoting problems
d) no managing local port numbers, no chance of collision.

> I guess my version
> puts some extra encryption burden on the firewall, and doesn't have
> end-end encryption, so if you don't trust the firewall operator...

I'm guessing you do the the equivalent of "ssh -t hosta ssh hostb"?  If 
so then you're vulnerable to snooping and/or MITM at each of the 
intermediate hops since the traffic is fully decrypted then passed to 
ssh for re-encryption.  (I have heard of compromises of this configuration.)

> Anyway, I do this often enough that I think I'll find my shorter
> syntax quite useful. If necessary, the wrapper script can always be
> modified to chain things with ProxyCommand instead of through the ssh
> remote command arguments.

Sure, do what works for you.  I was just offering some options.

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



From dtucker at zip.com.au  Fri Aug  5 03:03:33 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 05 Aug 2005 03:03:33 +1000
Subject: New Set of High Performance Networking Patches Available
In-Reply-To: <42F24880.4070900@psc.edu>
References: <42B32989.2080106@psc.edu> <42F214E8.5000201@zip.com.au>
	<42F23E64.9000203@psc.edu> <42F2454C.1030604@zip.com.au>
	<42F24880.4070900@psc.edu>
Message-ID: <42F24A65.1030703@zip.com.au>

Chris Rapier wrote:
[throughput]
> Yeah, thats definitely low. Can you try a loopback to your localhost and 
> dump the data into /dev/null to see what sort of limit the CPU is 
> imposing? Also, what cipher? 3des is justa nightmare. Most of our tests 
> are using arcfour and blowfish.

Tried all that.  All tests done with arcfour, same (low) throughput 
copying to /dev/null.  And as I mentioned, systems did 6MB/s throughput 
w/out the high-latency network (which was disk-to-disk).

I will probably try measuring with ttcp or netperf next.

-- 
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 jos at catnook.com  Fri Aug  5 03:13:28 2005
From: jos at catnook.com (Jos Backus)
Date: Thu, 4 Aug 2005 10:13:28 -0700
Subject: port forwarding trouble
In-Reply-To: <42F23D38.106@zip.com.au>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
	<42F22921.7090204@zip.com.au>
	<20050804154855.GA89699@lizzy.catnook.local>
	<42F23D38.106@zip.com.au>
Message-ID: <20050804171350.GA98187@lizzy.catnook.local>

On Fri, Aug 05, 2005 at 02:07:20AM +1000, Darren Tucker wrote:
> Jos Backus wrote:
> > On Fri, Aug 05, 2005 at 12:41:37AM +1000, Darren Tucker wrote:
> >>Why is that better the host at port?  I would bet there's precedent for 
> >>that somewhere too.
> > 
> > port at host preserves symmetry with user at host?
> 
> port at host reduces consistency with the other places in OpenSSH where 
> ports may be specified as an optional appendage?

Yeah, too bad we can't fix those. :-)

Like Sergio I don't like the use of `@' as a non-host scope qualifier as the
reverse seems to be the established use outside of OpenSSH. I `like host!port'
better since it avoids using `@' and carries with it the UUCP notion of moving
closer to the destination with each bang (first host, then port).

-- 
Jos Backus
jos at catnook.com



From frederik at a5.repetae.net  Fri Aug  5 03:14:45 2005
From: frederik at a5.repetae.net (Frederik Eaton)
Date: Thu, 4 Aug 2005 18:14:45 +0100
Subject: scp -S, sftp -S
In-Reply-To: <42F248D9.8080706@zip.com.au>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050802231330.27584.qmail@cdy.org>
	<20050804130951.GA8385@a5.repetae.net> <42F23B71.10202@zip.com.au>
	<20050804163610.GC25444@a5.repetae.net>
	<42F248D9.8080706@zip.com.au>
Message-ID: <20050804171445.GE25444@a5.repetae.net>

> ...
> >I found that nesting ssh as I described works fine (except that you need
> >a wrapper script to manage the task of quoting your command properly).
> 
> I don't follow: with the example I gave, a multi-hop ssh works exactly 
> the same as a single-hop.

By "nesting ssh" I'm referring to my method which you reproduce below,
i.e. passing an ssh command to ssh.

> >Does your version have lower latency or something?
> 
> The main thing it gives you is a guaranteed end-to-end SSH connection 
> and thus:
> a) a verifyable host key on *your* client, thus no MITM.
> b) 8-bit clean
> c) no quoting problems
> d) no managing local port numbers, no chance of collision.
> 
> >I guess my version
> >puts some extra encryption burden on the firewall, and doesn't have
> >end-end encryption, so if you don't trust the firewall operator...
> 
> I'm guessing you do the the equivalent of "ssh -t hosta ssh hostb"?  If 
> so then you're vulnerable to snooping and/or MITM at each of the 
> intermediate hops since the traffic is fully decrypted then passed to 
> ssh for re-encryption.  (I have heard of compromises of this configuration.)
> 
> >Anyway, I do this often enough that I think I'll find my shorter
> >syntax quite useful. If necessary, the wrapper script can always be
> >modified to chain things with ProxyCommand instead of through the ssh
> >remote command arguments.
> 
> Sure, do what works for you.  I was just offering some options.
> 
> -- 
> 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 rick.jones2 at hp.com  Fri Aug  5 03:21:18 2005
From: rick.jones2 at hp.com (Rick Jones)
Date: Thu, 04 Aug 2005 10:21:18 -0700
Subject: New Set of High Performance Networking Patches Available
In-Reply-To: <42F24880.4070900@psc.edu>
References: <42B32989.2080106@psc.edu>
	<42F214E8.5000201@zip.com.au>	<42F23E64.9000203@psc.edu>
	<42F2454C.1030604@zip.com.au> <42F24880.4070900@psc.edu>
Message-ID: <42F24E8E.8070300@hp.com>

Random observations, some more obvious than others :)

*) in the face of packet losses, the TCP congestion window may not get and/or 
stay as large as the classic TCP window.  so, check netstat statistics

*) if you cannot get the perf level with say a netperf TCP_STREAM test :) it 
ain't gonna happen with crypto.

rick jones



From rapier at psc.edu  Fri Aug  5 04:47:02 2005
From: rapier at psc.edu (Chris Rapier)
Date: Thu, 04 Aug 2005 14:47:02 -0400
Subject: New Set of High Performance Networking Patches Available
In-Reply-To: <42F24A65.1030703@zip.com.au>
References: <42B32989.2080106@psc.edu>
	<42F214E8.5000201@zip.com.au>	<42F23E64.9000203@psc.edu>
	<42F2454C.1030604@zip.com.au>	<42F24880.4070900@psc.edu>
	<42F24A65.1030703@zip.com.au>
Message-ID: <42F262A6.40709@psc.edu>



Darren Tucker wrote:
> Chris Rapier wrote:
> [throughput]
> 
>>Yeah, thats definitely low. Can you try a loopback to your localhost and 
>>dump the data into /dev/null to see what sort of limit the CPU is 
>>imposing? Also, what cipher? 3des is justa nightmare. Most of our tests 
>>are using arcfour and blowfish.
> 
> 
> Tried all that.  All tests done with arcfour, same (low) throughput 
> copying to /dev/null.  And as I mentioned, systems did 6MB/s throughput 
> w/out the high-latency network (which was disk-to-disk).
> 
> I will probably try measuring with ttcp or netperf next.

You might want to try iPerf too. Its a good tool. Better in some 
environments not as good in others.



From stuge-openssh-unix-dev at cdy.org  Fri Aug  5 07:20:59 2005
From: stuge-openssh-unix-dev at cdy.org (Peter Stuge)
Date: Thu, 4 Aug 2005 23:20:59 +0200
Subject: scp -S, sftp -S
In-Reply-To: <42F248D9.8080706@zip.com.au>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050802231330.27584.qmail@cdy.org>
	<20050804130951.GA8385@a5.repetae.net> <42F23B71.10202@zip.com.au>
	<20050804163610.GC25444@a5.repetae.net>
	<42F248D9.8080706@zip.com.au>
Message-ID: <20050804212059.24544.qmail@cdy.org>

On Fri, Aug 05, 2005 at 02:56:57AM +1000, Darren Tucker wrote:
> > I see. That would be nice. But why was 'connect' needed at all?
> 
> Because a proxycommand operates on stdio, you need to make a TCP
> connection somehow.  If ssh learns the above then it won't be
> necessary.

Doesn't it already, for remote port forwarding?


//Peter



From djm at mindrot.org  Fri Aug  5 09:57:20 2005
From: djm at mindrot.org (Damien Miller)
Date: Fri, 5 Aug 2005 09:57:20 +1000 (EST)
Subject: port forwarding trouble
In-Reply-To: <20050804160108.GC2317@hanuman.astro.su.se>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
	<42F22921.7090204@zip.com.au>
	<20050804160108.GC2317@hanuman.astro.su.se>
Message-ID: <Pine.BSO.4.63.0508050952120.3592@fuyu.mindrot.org>

On Thu, 4 Aug 2005, Sergio Gelato wrote:

> * Darren Tucker [2005-08-05 00:41:37 +1000]:
>> Sergio Gelato wrote:
>>> * Frederik Eaton [2005-08-02 17:39:59 +0100]:
>>>> Also, I don't think that the "host at port" syntax suggested in the bug
>>>> comments is a good idea.
>>>
>>> At the very least it should be port at host. There is precedent for that,
>>> e.g. in FlexLM LM_LICENSE_FILE environment variables.
>>
>> Why is that better the host at port?  I would bet there's precedent for
>> that somewhere too.
>
> Because "@" traditionally stands for the preposition "at", and most
> people find it more natural to use the host name as a scope identifier
> than the port number (maybe also because e-mail addresses have
> the host name on the right side of the @ sign).
>
> And while we are comparing with e-mail addresses: how about host!port ?

Yay! let's all have a completely meaningless discussion about what 
character is used to delimit the port, while completely ignoring the 
substantive parts of the patch.

The character doesn't matter one bit, and if proceed with turning on 
HashKnownHosts by default then you won't ever see it.

If you want to contribute to this discussions, then please start by 
reading and testing the patch.

-d



From dtucker at zip.com.au  Fri Aug  5 13:07:01 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 05 Aug 2005 13:07:01 +1000
Subject: scp -S, sftp -S
In-Reply-To: <20050804212059.24544.qmail@cdy.org>
References: <20050802120921.GA24095@a5.repetae.net>	<42EF95CF.5090001@zip.com.au>	<20050802163959.GH23428@a5.repetae.net>	<20050802231330.27584.qmail@cdy.org>	<20050804130951.GA8385@a5.repetae.net>
	<42F23B71.10202@zip.com.au>	<20050804163610.GC25444@a5.repetae.net>	<42F248D9.8080706@zip.com.au>
	<20050804212059.24544.qmail@cdy.org>
Message-ID: <42F2D7D5.7020505@zip.com.au>

Peter Stuge wrote:
> On Fri, Aug 05, 2005 at 02:56:57AM +1000, Darren Tucker wrote:
> 
>>>I see. That would be nice. But why was 'connect' needed at all?
>>
>>Because a proxycommand operates on stdio, you need to make a TCP
>>connection somehow.  If ssh learns the above then it won't be
>>necessary.
> 
> Doesn't it already, for remote port forwarding?

ssh knows how to do match up TCP connections with TCP connections, and 
stdio on the client with stdio on the server.

What I'm talking about is either adding a new option or extending -L to 
understand something like "ssh -N -L stdio:remotehost:22 
intermediatehost" and have that do the equivalent of "ssh 
intermediatehost connect remotehost 22" but without the extra "connect" 
process.

-- 
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 nobs at tigress.com  Sun Aug  7 23:08:38 2005
From: nobs at tigress.com (Emil 'nobs' Obermayr)
Date: Sun, 7 Aug 2005 15:08:38 +0200
Subject: feature-request: trap-door
Message-ID: <200508071511.03504.nobs@tigress.com>

Hi,

while discussing with friends how to 'hide' an ssh-entry to a system (using 
uncommon ports, "knocking" on a sequence of ports with telnet, etc) we saw 
the problem you need all that ports open on the client side as well. But 
maybe on the client side you are just a guest and those ports are locked for 
a good reason.

So we had another idea: using a sequence of login-names directly to the 
ssh-server. If someone gives the right sequence of accounts, the IP will be 
accepted for "real" logins for a while. If the sequence is wrong, the IP can 
be logged in syslog and locked out totally from the system by another tool 
with a firewall.

This could be a nice feature for people that need to have access to their 
system from varying clients all over the internet. Additionally when a hacker 
tries to hack the ssh he could be locked out from other services as well.

Is it possible to put such a feature in sshd? Could it be a patch or external 
addon?

What do you think?

Bye!

Emil 'nobs' Obermayr
Braunschweig, Germany
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050807/50952442/attachment.bin 

From dtucker at zip.com.au  Mon Aug  8 00:56:40 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 08 Aug 2005 00:56:40 +1000
Subject: feature-request: trap-door
In-Reply-To: <200508071511.03504.nobs@tigress.com>
References: <200508071511.03504.nobs@tigress.com>
Message-ID: <42F62128.3080809@zip.com.au>

Emil 'nobs' Obermayr wrote:
[...]
> So we had another idea: using a sequence of login-names directly to the 
> ssh-server. If someone gives the right sequence of accounts, the IP will be 
> accepted for "real" logins for a while. If the sequence is wrong, the IP can 
> be logged in syslog and locked out totally from the system by another tool 
> with a firewall.
> 
> This could be a nice feature for people that need to have access to their 
> system from varying clients all over the internet. Additionally when a hacker 
> tries to hack the ssh he could be locked out from other services as well.
> 
> Is it possible to put such a feature in sshd?  Could it be a patch or
> external addon?

I doubt it.  It's of very limited use and it's a DoS waiting to happen.

If you're using an external authentication system such as PAM or BSDAuth 
then you can implement whatever policy you want at that level.

> What do you think?

It would be trivial to implement this with some kind of external 
log-watching process: create a group such as "sshallowed", then put 
"AllowGroups sshallowed" into sshd_config.  The exeternal process could 
then add/remote the appropriate user(s) to and from that group based on 
the activity in the log.

Just because it's possible doesn't make it a good idea, though.

-- 
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 skeleten at shillest.net  Tue Aug  9 06:58:35 2005
From: skeleten at shillest.net (Norihiko Murase)
Date: Tue, 09 Aug 2005 05:58:35 +0900
Subject: (4.1p1) configure fails with --without-audit
Message-ID: <20050809055835.32778e%skeleten@shillest.net>

Hi,

I tried to build the version 4.1p1 on FreeBSD.

When the option "--without-audit" is added, the configure
script stops illegally with the following message:
    Unknown audit module no
Note that the option "--without-audit" is equivalent to
"--with-audit=no".

It may be better that you should edit configure.ac.


Thanks,
---
Norihiko Murase <skeleten at shillest.net>



From skeleten at shillest.net  Tue Aug  9 10:43:09 2005
From: skeleten at shillest.net (Norihiko Murase)
Date: Tue, 09 Aug 2005 09:43:09 +0900
Subject: (4.1p1) Building failure with libedit on FreeBSD 4.x-RELEASE
Message-ID: <20050809094309.100104e%skeleten@shillest.net>

Hi,

I've noticed that building 4.1p1 fails on FreeBSD 4.x if the
libedit support is enabled by the "--with-libedit" configure
option.

I tried to build OpenSSH-4.1p1 under the following environment:
  CPU: i386 family
  OS: FreeBSD 4.11-RELEASE
  Compiler: gcc-2.95.4 (/usr/bin/gcc)
  ----
  libedit: (located at /usr/lib/)

Building fails with the following messages:
----------
gcc -g -O2 -Wall ...... -DHAVE_CONFIG_H -c sftp.c
sftp.c: In function `interactive_loop':
sftp.c:1247: too many arguments to function `el_init'
sftp.c:1251: `H_SETSIZE' undeclared (first use in this function)
sftp.c:1251: (Each undeclared identifier is reported only once
sftp.c:1251: for each function it appears in.)
sftp.c:1251: warning: passing arg 2 of `history' makes integer from pointer without a cast
sftp.c:1326: warning: passing arg 2 of `history' makes integer from pointer without a cast
gmake: *** [sftp.o] Error 1
----------

This is because of the spec-differences between the
following types of the libedit:
  [1] the version attached to FreeBSD-4.x
  [2] the version distributed at
      http://www.thrysoee.dk/editline/

# The version attached to FreeBSD-5.x is the same as [2],
# I think.

I think that it is no problem that you require the libedit
distributed at http://www.thrysoee.dk/editline/ ; however, I
would like to suggest that you should improve the configure
script.

The configure script should check whether the libedit on the
system can be used or not --- concretely,
  * the number of the arguments of el_init()
  * whether the macro H_SETSIZE is defined or not


Best Regards,
---
Norihiko Murase <skeleten at shillest.net>



From tim at multitalents.net  Tue Aug  9 12:21:39 2005
From: tim at multitalents.net (Tim Rice)
Date: Mon, 8 Aug 2005 19:21:39 -0700 (PDT)
Subject: (4.1p1) configure fails with --without-audit
In-Reply-To: <20050809055835.32778e%skeleten@shillest.net>
References: <20050809055835.32778e%skeleten@shillest.net>
Message-ID: <Pine.UW2.4.63.0508081919530.13640@server01.int.multitalents.net>

On Tue, 9 Aug 2005, Norihiko Murase wrote:

> Hi,
> 
> I tried to build the version 4.1p1 on FreeBSD.
> 
> When the option "--without-audit" is added, the configure
> script stops illegally with the following message:
>     Unknown audit module no
> Note that the option "--without-audit" is equivalent to
> "--with-audit=no".

Does the attached patch work for you?

> 
> It may be better that you should edit configure.ac.
> 
> 
> Thanks,
> ---
> Norihiko Murase <skeleten at shillest.net>
> 

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net
-------------- next part --------------
--- configure.ac.old	2005-07-28 17:41:11.044914000 -0700
+++ configure.ac	2005-08-08 19:18:54.046480022 -0700
@@ -1040,6 +1040,8 @@
 		AC_MSG_RESULT(debug)
 		AC_DEFINE(SSH_AUDIT_EVENTS, [], Use audit debugging module)
 		;;
+	  no)
+		;;
 	  *)
 		AC_MSG_ERROR([Unknown audit module $withval])
 		;;

From dtucker at zip.com.au  Tue Aug  9 19:56:13 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 9 Aug 2005 19:56:13 +1000
Subject: (4.1p1) Building failure with libedit on FreeBSD 4.x-RELEASE
In-Reply-To: <20050809094309.100104e%skeleten@shillest.net>
References: <20050809094309.100104e%skeleten@shillest.net>
Message-ID: <20050809095613.GA11593@gate.dodgy.net.au>

On Tue, Aug 09, 2005 at 09:43:09AM +0900, Norihiko Murase wrote:
> I've noticed that building 4.1p1 fails on FreeBSD 4.x if the
> libedit support is enabled by the "--with-libedit" configure
> option.

Could you please test this patch?  You will need to run "autoreconf"
after applying the patch to rebuild configure.

Thanks.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: configure.ac
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v
retrieving revision 1.282
diff -u -p -r1.282 configure.ac
--- configure.ac	2 Aug 2005 14:20:15 -0000	1.282
+++ configure.ac	9 Aug 2005 09:42:52 -0000
@@ -1023,6 +1023,19 @@ AC_ARG_WITH(libedit,
 			[ AC_MSG_ERROR(libedit not found) ],
 			[ -lcurses ]
 		)
+		AC_MSG_CHECKING(if libedit version is compatible)
+		AC_TRY_COMPILE([#include <histedit.h>],
+		    [
+int main(void)
+{
+	el_init("", NULL, NULL, NULL);
+	exit(0);
+}
+		    ],
+		    [ AC_MSG_RESULT(yes) ],
+		    [ AC_MSG_RESULT(no)
+		      AC_MSG_ERROR(libedit version is not compatible) ]
+		)
 	fi ]
 )
 

From dtucker at zip.com.au  Tue Aug  9 23:19:10 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 9 Aug 2005 23:19:10 +1000
Subject: port forwarding trouble
In-Reply-To: <20050804133549.GB2317@hanuman.astro.su.se>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
Message-ID: <20050809131910.GA12966@gate.dodgy.net.au>

On Thu, Aug 04, 2005 at 03:35:49PM +0200, Sergio Gelato wrote:
> I'm not sure about URLs, but various tools simply require square
> brackets around the IPv6 address, as in
> 	[0:1:2:3:4:5:6:7]:port
> For example, this (minus the port number) is what you are supposed to
> do in /etc/hosts.allow. Implementations differ as to whether one needs
> [fe80::]/10 or [fe80::/10] for network prefixes, but I think the former
> is winning.

Alright, I've made an attempt to implement this and attached it to
the bug.  Please let us know how reviewing and testing the patch goes.
Better wording for the man page would also be appreciated.

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

Brief overview from patch description:
Implement port spec as per sshd(8) ListenAddress

The following are valid hostname entries:
localhost
127.0.0.1
::1
localhost:222
127.0.0.1:222
[::1]:222

The first 3 should remain backward compatible with older versions and
are still written if possible.  The syntax is compatible with the sshd(8)
ListenAddress option (uses the same parser).

-- 
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 guyverdh at mchsi.com  Wed Aug 10 00:30:05 2005
From: guyverdh at mchsi.com (guyverdh at mchsi.com)
Date: Tue, 09 Aug 2005 14:30:05 +0000
Subject: feature-request: trap-door
Message-ID: <080920051430.1862.42F8BDED000981C4000007462197913363080B9D0A90979A09@mchsi.com>

Why would you place this functionality at the application layer, why not use 
port knocking at the firewall layer?

It's a lot simpler to implement (even if you have to set it up manually via 
the services and inetd.conf files), than to change the code for sshd.

A couple of lines in an inetd.conf and services file can make an easy to use 
port knocking to open an SSHD daemon on a port the knocker specifies.  Then 
after 30 seconds, the listener closes. 

If there's interest, I can submit an example.



From tim at multitalents.net  Wed Aug 10 03:20:31 2005
From: tim at multitalents.net (Tim Rice)
Date: Tue, 9 Aug 2005 10:20:31 -0700 (PDT)
Subject: (4.1p1) configure fails with --without-audit
In-Reply-To: <20050809055835.32778e%skeleten@shillest.net>
References: <20050809055835.32778e%skeleten@shillest.net>
Message-ID: <Pine.UW2.4.63.0508091019530.29791@server01.int.multitalents.net>

On Tue, 9 Aug 2005, Norihiko Murase wrote:

> Hi,
> 
> I tried to build the version 4.1p1 on FreeBSD.
> 
> When the option "--without-audit" is added, the configure
> script stops illegally with the following message:
>     Unknown audit module no
> Note that the option "--without-audit" is equivalent to
> "--with-audit=no".
> 
> It may be better that you should edit configure.ac.

Now fixed in CVS.
Thanks for the report.

> 
> 
> Thanks,
> ---
> Norihiko Murase <skeleten at shillest.net>
> 

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




From djm at mindrot.org  Wed Aug 10 11:19:28 2005
From: djm at mindrot.org (Damien Miller)
Date: Wed, 10 Aug 2005 11:19:28 +1000 (EST)
Subject: port forwarding trouble
In-Reply-To: <20050809131910.GA12966@gate.dodgy.net.au>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
	<20050809131910.GA12966@gate.dodgy.net.au>
Message-ID: <Pine.BSO.4.63.0508101118290.29249@fuyu.mindrot.org>

(trimmed Cc)

On Tue, 9 Aug 2005, Darren Tucker wrote:

> http://bugzilla.mindrot.org/show_bug.cgi?id=910
>
> Brief overview from patch description:
> Implement port spec as per sshd(8) ListenAddress
>
> The following are valid hostname entries:
> localhost
> 127.0.0.1
> ::1
> localhost:222
> 127.0.0.1:222
> [::1]:222
>
> The first 3 should remain backward compatible with older versions and
> are still written if possible.  The syntax is compatible with the sshd(8)
> ListenAddress option (uses the same parser).

How does this work with HashKnownHosts?

-d



From djm at mindrot.org  Wed Aug 10 11:21:06 2005
From: djm at mindrot.org (Damien Miller)
Date: Wed, 10 Aug 2005 11:21:06 +1000 (EST)
Subject: (4.1p1) Building failure with libedit on FreeBSD 4.x-RELEASE
In-Reply-To: <20050809095613.GA11593@gate.dodgy.net.au>
References: <20050809094309.100104e%skeleten@shillest.net>
	<20050809095613.GA11593@gate.dodgy.net.au>
Message-ID: <Pine.BSO.4.63.0508101120460.29249@fuyu.mindrot.org>

On Tue, 9 Aug 2005, Darren Tucker wrote:

> On Tue, Aug 09, 2005 at 09:43:09AM +0900, Norihiko Murase wrote:
>> I've noticed that building 4.1p1 fails on FreeBSD 4.x if the
>> libedit support is enabled by the "--with-libedit" configure
>> option.
>
> Could you please test this patch?  You will need to run "autoreconf"
> after applying the patch to rebuild configure.

should it also test for the presence of H_SETSIZE?

-d



From frederik at a5.repetae.net  Wed Aug 10 18:01:20 2005
From: frederik at a5.repetae.net (Frederik Eaton)
Date: Wed, 10 Aug 2005 09:01:20 +0100
Subject: port forwarding trouble
In-Reply-To: <20050809131910.GA12966@gate.dodgy.net.au>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
	<20050809131910.GA12966@gate.dodgy.net.au>
Message-ID: <20050810080120.GP25444@a5.repetae.net>

Thanks for taking care of this.

Frederik

On Tue, Aug 09, 2005 at 11:19:10PM +1000, Darren Tucker wrote:
> On Thu, Aug 04, 2005 at 03:35:49PM +0200, Sergio Gelato wrote:
> > I'm not sure about URLs, but various tools simply require square
> > brackets around the IPv6 address, as in
> > 	[0:1:2:3:4:5:6:7]:port
> > For example, this (minus the port number) is what you are supposed to
> > do in /etc/hosts.allow. Implementations differ as to whether one needs
> > [fe80::]/10 or [fe80::/10] for network prefixes, but I think the former
> > is winning.
> 
> Alright, I've made an attempt to implement this and attached it to
> the bug.  Please let us know how reviewing and testing the patch goes.
> Better wording for the man page would also be appreciated.
> 
> http://bugzilla.mindrot.org/show_bug.cgi?id=910
> 
> Brief overview from patch description:
> Implement port spec as per sshd(8) ListenAddress
> 
> The following are valid hostname entries:
> localhost
> 127.0.0.1
> ::1
> localhost:222
> 127.0.0.1:222
> [::1]:222
> 
> The first 3 should remain backward compatible with older versions and
> are still written if possible.  The syntax is compatible with the sshd(8)
> ListenAddress option (uses the same parser).
> 
> -- 
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
> 



From dtucker at zip.com.au  Wed Aug 10 19:00:15 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 10 Aug 2005 19:00:15 +1000
Subject: (4.1p1) Building failure with libedit on FreeBSD 4.x-RELEASE
In-Reply-To: <Pine.BSO.4.63.0508101120460.29249@fuyu.mindrot.org>
References: <20050809094309.100104e%skeleten@shillest.net>
	<20050809095613.GA11593@gate.dodgy.net.au>
	<Pine.BSO.4.63.0508101120460.29249@fuyu.mindrot.org>
Message-ID: <20050810090015.GA14875@gate.dodgy.net.au>

On Wed, Aug 10, 2005 at 11:21:06AM +1000, Damien Miller wrote:
[...]
> >Could you please test this patch?  You will need to run "autoreconf"
> >after applying the patch to rebuild configure.
> 
> should it also test for the presence of H_SETSIZE?

It could but I don't think it matters much.  The current diff ought to be
enough to detect the aforementioned incompatible library (based on my read
of FreeBSD's cvsweb).

I will add it if you think it adds any value to the test.

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



From dtucker at zip.com.au  Wed Aug 10 19:06:37 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 10 Aug 2005 19:06:37 +1000
Subject: port forwarding trouble
In-Reply-To: <Pine.BSO.4.63.0508101118290.29249@fuyu.mindrot.org>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
	<20050809131910.GA12966@gate.dodgy.net.au>
	<Pine.BSO.4.63.0508101118290.29249@fuyu.mindrot.org>
Message-ID: <20050810090637.GB14875@gate.dodgy.net.au>

On Wed, Aug 10, 2005 at 11:19:28AM +1000, Damien Miller wrote:
> On Tue, 9 Aug 2005, Darren Tucker wrote:
> >http://bugzilla.mindrot.org/show_bug.cgi?id=910
> >
> >Brief overview from patch description:
> >Implement port spec as per sshd(8) ListenAddress
> >
> >The following are valid hostname entries:
> >localhost
> >127.0.0.1
> >::1
> >localhost:222
> >127.0.0.1:222
> >[::1]:222
> >
> >The first 3 should remain backward compatible with older versions and
> >are still written if possible.  The syntax is compatible with the sshd(8)
> >ListenAddress option (uses the same parser).
> 
> How does this work with HashKnownHosts?

Same as the previous diff, ie as far as I can tell it works the same way
as described above, with or without HashKnownHosts, and with or without
a matching hashed known_hosts entry for the server in question.

If there's a hashed known_hosts entry for "foo", and you connect to "foo"
port 123 without a hostkeyalias then you'll get an unknown host key
warning, but the same is true without an unhashed entry.

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



From dtucker at zip.com.au  Thu Aug 11 00:35:10 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 11 Aug 2005 00:35:10 +1000
Subject: port forwarding trouble
In-Reply-To: <20050809131910.GA12966@gate.dodgy.net.au>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
	<20050809131910.GA12966@gate.dodgy.net.au>
Message-ID: <42FA109E.2020606@zip.com.au>

Darren Tucker wrote:
> Alright, I've made an attempt to implement this and attached it to
> the bug.  Please let us know how reviewing and testing the patch goes.
> Better wording for the man page would also be appreciated.
> 
> http://bugzilla.mindrot.org/show_bug.cgi?id=910
> 
> Brief overview from patch description:
> Implement port spec as per sshd(8) ListenAddress
> 
> The following are valid hostname entries:
> localhost
> 127.0.0.1
> ::1
> localhost:222
> 127.0.0.1:222
> [::1]:222
> 
> The first 3 should remain backward compatible with older versions and
> are still written if possible.  The syntax is compatible with the sshd(8)
> ListenAddress option (uses the same parser).

It occurrs to me that since it doesn't actually need *parse* the
host:port identifiers then factoring out that code is a waste of time,
so this diff is much simpler :-)

(I can't connect to bugzilla right now but I will attach it to bug #910
when I can.)

Testing still appreciated.

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

From djm at mindrot.org  Thu Aug 11 20:33:17 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Aug 2005 20:33:17 +1000
Subject: port forwarding trouble
In-Reply-To: <42FA109E.2020606@zip.com.au>
References: <20050802120921.GA24095@a5.repetae.net>	<42EF95CF.5090001@zip.com.au>	<20050802163959.GH23428@a5.repetae.net>	<20050804133549.GB2317@hanuman.astro.su.se>	<20050809131910.GA12966@gate.dodgy.net.au>
	<42FA109E.2020606@zip.com.au>
Message-ID: <42FB296D.3000500@mindrot.org>

Darren Tucker wrote:

> (I can't connect to bugzilla right now but I will attach it to bug #910
> when I can.)

Sorry, bugzilla and the lists were down today after my cat3524 switch
gave up the magic smoke. They are back now.

-d



From Richard.Dickens at reuters.com  Thu Aug 11 23:54:46 2005
From: Richard.Dickens at reuters.com (Richard Dickens)
Date: Thu, 11 Aug 2005 14:54:46 +0100
Subject: Porting to Dynix 4.1.3...
Message-ID: <T72b23cf97a0a01f019c644@lonsmime01.rit.reuters.com>

Hello there,

I am trying to build OpenSSH on the above (very old) version of unix.

With a bit of hacking, I have managed to get everything to compile and
run. Scp works fine however when I log in via ssh I end up with a
session without a controlling terminal.

I have followed the code in pty_make_controlling_tty and it seems to go
as follows:

1. Starts with a controlling tty.

2. setsid works, no controlling tty.

3. open of tty works, however it doesn't become the controlling tty.

4. open of /dev/tty fails.

I don't have a huge experience of pseudo ttys or controlling ttys but it
looks to me like point 3 fails because there is already an open file
handle pointing to the same device. 

As an aside, Dynix has a function called fvhangup (virtually hangup the
specified controlling terminal) but if I insert a call to this then all
slave terminals are hung up which seems to cause the master to close.

Can anyone offer any hints on how I can persuade my session to pick up a
controlling terminal?

Regards,
Richard Dickens


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

To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo 

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



From dtucker at zip.com.au  Fri Aug 12 00:34:54 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 12 Aug 2005 00:34:54 +1000
Subject: Porting to Dynix 4.1.3...
In-Reply-To: <T72b23cf97a0a01f019c644@lonsmime01.rit.reuters.com>
References: <T72b23cf97a0a01f019c644@lonsmime01.rit.reuters.com>
Message-ID: <42FB620E.2040104@zip.com.au>

Richard Dickens wrote:
> Hello there,
> 
> I am trying to build OpenSSH on the above (very old) version of unix.
[...]
> Can anyone offer any hints on how I can persuade my session to pick up a
> controlling terminal?

Try "./configure --with-cflags=-DNEED_SETPRGP"

That seems to help with controlling ttys on oldish Unixes.  If it works
then please let us know a) that it does and b) what the output of
./config.guess is on your system so we can update configure...

-- 
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 Sergio.Gelato at astro.su.se  Thu Aug 11 01:53:36 2005
From: Sergio.Gelato at astro.su.se (Sergio Gelato)
Date: Wed, 10 Aug 2005 17:53:36 +0200
Subject: port forwarding trouble
In-Reply-To: <42FA109E.2020606@zip.com.au>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
	<20050809131910.GA12966@gate.dodgy.net.au>
	<42FA109E.2020606@zip.com.au>
Message-ID: <20050810155336.GE2271@hanuman.astro.su.se>

* Darren Tucker [2005-08-11 00:35:10 +1000]:
> It occurrs to me that since it doesn't actually need *parse* the
> host:port identifiers then factoring out that code is a waste of time,
> so this diff is much simpler :-)

Remind me: why do you need to check for the second ':' before deciding to
use square brackets? As far as avoiding ambiguity is concerned, I would 
argue that even a single ':' in the host string is enough to warrant 
bracketing.

It is true that an IPv6 address cannot be written with less than two ':'.
What I don't see right now is under what other circumstances host could
contain a single ':'. If, as I believe, it cannot, then you might as
well drop the second strchr() call. And even if it can, bracketing may
still be appropriate.

Isn't the reason for your two-':' heuristic that ListenAddress lines can
already be in host:port form? I don't think that's an issue here.

> +	if ((p = strchr(host, ':')) != NULL && strchr(p+1, ':') != NULL)
> +		ret = asprintf(&p, "[%s]:%hd", host, port); /* IPv6 */
> +	else
> +		ret = asprintf(&p, "%s:%hd", host, port);



From djm at mindrot.org  Fri Aug 12 09:28:33 2005
From: djm at mindrot.org (Damien Miller)
Date: Fri, 12 Aug 2005 09:28:33 +1000 (EST)
Subject: port forwarding trouble
In-Reply-To: <20050810155336.GE2271@hanuman.astro.su.se>
References: <20050802120921.GA24095@a5.repetae.net>
	<42EF95CF.5090001@zip.com.au>
	<20050802163959.GH23428@a5.repetae.net>
	<20050804133549.GB2317@hanuman.astro.su.se>
	<20050809131910.GA12966@gate.dodgy.net.au>
	<42FA109E.2020606@zip.com.au>
	<20050810155336.GE2271@hanuman.astro.su.se>
Message-ID: <Pine.BSO.4.63.0508120927440.20523@fuyu.mindrot.org>

On Wed, 10 Aug 2005, Sergio Gelato wrote:

> Remind me: why do you need to check for the second ':' before deciding to
> use square brackets? As far as avoiding ambiguity is concerned, I would
> argue that even a single ':' in the host string is enough to warrant
> bracketing.

to avoid breaking known_hosts files that have been working fine for the 
last five years.



From Richard.Dickens at reuters.com  Fri Aug 12 20:30:13 2005
From: Richard.Dickens at reuters.com (Richard Dickens)
Date: Fri, 12 Aug 2005 11:30:13 +0100
Subject: Porting to Dynix 4.1.3...
Message-ID: <974FF25EED65144AB4F511A094BE1D3A0BF69A@LONSMSXM06.emea.ime.reuters.com>

Darren,

NEED_SETPRGP didn't make any difference. Still says "open /dev/tty
failed - could not set controlling tty: No such device or address".

Anything else I can try?

Regards,
Richard Dickens 

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: 11 August 2005 15:35
To: Richard Dickens
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Porting to Dynix 4.1.3...

Richard Dickens wrote:
> Hello there,
> 
> I am trying to build OpenSSH on the above (very old) version of unix.
[...]
> Can anyone offer any hints on how I can persuade my session to pick up

> a controlling terminal?

Try "./configure --with-cflags=-DNEED_SETPRGP"

That seems to help with controlling ttys on oldish Unixes.  If it works
then please let us know a) that it does and b) what the output of
./config.guess is on your system so we can update configure...

--
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.


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

To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo 

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



From dtucker at zip.com.au  Fri Aug 12 22:16:42 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 12 Aug 2005 22:16:42 +1000
Subject: Porting to Dynix 4.1.3...
In-Reply-To: <974FF25EED65144AB4F511A094BE1D3A0BF69A@LONSMSXM06.emea.ime.reuters.com>
References: <974FF25EED65144AB4F511A094BE1D3A0BF69A@LONSMSXM06.emea.ime.reuters.com>
Message-ID: <42FC932A.8060806@zip.com.au>

Richard Dickens wrote:
> NEED_SETPRGP didn't make any difference. Still says "open /dev/tty
> failed - could not set controlling tty: No such device or address".
> 
> Anything else I can try?

Is Dynix a SysV derivative with STREAMS?  If so, try adding
"-DSSHD_ACQUIRES_CTTY" to CFLAGS.

Failing that, take a look in the system headers and see which of the the
following exist on your platform:
TCSETCTTY TIOCSCTTY TIOCNOTTY

It's possible that it has TCSETCTTY, however sshd will only use that on
UNICOS.  Try hacking sshpty.c and replace the "#ifdef _UNICOS" with
"#ifdef TCSETCTTY".

Failing that, see if you can find some example code that sets a
controlling terminal on Dynix and look at what it does...

-- 
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 rapier at psc.edu  Sat Aug 13 03:21:36 2005
From: rapier at psc.edu (Chris Rapier)
Date: Fri, 12 Aug 2005 13:21:36 -0400
Subject: failure during key exchange?
Message-ID: <42FCDAA0.1030409@psc.edu>

I have been contacted by some people who are having a problem with
transfer files using OpenSSH 4.1p1 with the HPN patch. I've taken a look
at their problem and I don't think its a problem with the HPN code so I
thought I would bounce it over here to see if anyone here has some insight.

In brief the connection is dying without spitting out an error message
during the key exchange. Of course its not consistant because that would
be too damn easy. I've narrowed it down to a section of code in keygexc.c.

Their hardware setup is (and I quote):
- Tests using the "new" scp were run between a V880 and a Sunfire 6800
domain.  3GB, 5GB, and 10GB files were transferred from a remote file
system striped across 6 disks and mounted on the 6800, to a similar but
separate file system mounted on the V880.

- Tests using the "traditional" scp were done from /tmp to /tmp (before
the remote file systems became available to us).

- In between was a Cisco 6509 Layer 3 switch, with a 1000Base-sx
connection to each server.

- Between the Cisco and the V880 was a PacketStorm WAN emulator, which
we used to inject latency into the network.

A typical debug looks like

debug2: channel 0: window 2607104 sent adjust 2621440
debug2: channel 0: window 2590720 sent adjust 2629632
test10g                                        39% 4088MB  14.1MB/s 
07:15 ETAdebug2: channel 0: window 2615296 sent adjust 2614272
debug1: SSH2_MSG_KEXINIT received
debug1: SSH2_MSG_KEXINIT sent
debug2: kex_parse_kexinit: 
diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: 
diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: 
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,none
debug2: kex_parse_kexinit: 
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,none
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client none hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server none hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
lost connection
c9d1#

Which makes me think it could be some problem with atomicio during the 
keyexchange. I just don't know. Anyone have any insight on something 
like this?



From dtucker at zip.com.au  Mon Aug 15 22:11:55 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 15 Aug 2005 22:11:55 +1000
Subject: OpenSSH LynxOS port
In-Reply-To: <1124104063.23890.0.camel@osah.patria.fi>
References: <1124104063.23890.0.camel@osah.patria.fi>
Message-ID: <4300868B.6000506@zip.com.au>

Olli Savia wrote:
> The attached patch is a port of the current CVS (2005-08-11) version
> of OpenSSH portable to LynxOS. Could you consider adding it to the
> future releases of OpenSSH? If the patch needs additional work, please
> let me know.

Looks mostly reasonable, some comments and questions below.

> +        AC_DEFINE(LYNXOS_BROKEN_SETVBUF, 1, [LynxOS has broken setvbuf() implementation])

I would prefer this to be generic (ie just BROKEN_SETVBUF, I'll edit it
locally).

> +#if defined(__Lynx__)
> +  /* LynxOS defines these in param.h which we do not want to include */

Why don't we want param.h?  Having to redefine a bunch of stuff is a bit
ugly.

> +#include <stdarg.h>

Due to the wacky state of system headers out in the world, this has a
reasonable chance of breaking something, somewhere.  Unless anyone else
objects, I'm ok with putting it in for now.  We might have to ifdef it
if something breaks in prerelease testing.

-- 
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 skeleten at shillest.net  Tue Aug 16 04:58:24 2005
From: skeleten at shillest.net (Norihiko Murase)
Date: Tue, 16 Aug 2005 03:58:24 +0900
Subject: (4.1p1) configure fails with --without-audit
In-Reply-To: (Your message of "Tue, 9 Aug 2005 10:20:31 -0700 (PDT)
	")  <Pine.UW2.4.63.0508091019530.29791@server01.int.multitalents.net>
References: <20050809055835.32778e%skeleten@shillest.net>
	<Pine.UW2.4.63.0508091019530.29791@server01.int.multitalents.net>
Message-ID: <20050816035824.14da9f%skeleten@shillest.net>

Hi,

I thank you very much for checking and fixing, and I'm very
sorry to be late for replying it.

I did test this change on the SNAP-20050811 version, which
was available at
  ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ .


Yes, thanks to this patch the configure does NOT stop
illegally any longer; it works well except one small problem.

This (small) problem is the curious message. The configure
script now prints the following message in checking the
audit modules:
------------------------------------------------------------
...(snip)...
checking for /proc/pid/fd directory... no
checking for supported audit module... checking for arc4random... yes
checking for b64_ntop... no
...(snip)...
------------------------------------------------------------

This is because the result string "no" is missing. It may be
better that you should add it also in the case of
"--without-audit". I attach the patch (configure_ac_audit.diff)
for this.


Best Regards,
---
Norihiko Murase <skeleten at shillest.net>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: configure_ac_audit.diff
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050816/f4741df7/attachment.ksh 

From skeleten at shillest.net  Tue Aug 16 05:07:41 2005
From: skeleten at shillest.net (Norihiko Murase)
Date: Tue, 16 Aug 2005 04:07:41 +0900
Subject: (4.1p1) Building failure with libedit on FreeBSD 4.x-RELEASE
In-Reply-To: (Your message of "Wed, 10 Aug 2005 19:00:15 +1000")
	<20050810090015.GA14875@gate.dodgy.net.au>
References: <20050809094309.100104e%skeleten@shillest.net>
	<20050809095613.GA11593@gate.dodgy.net.au>
	<Pine.BSO.4.63.0508101120460.29249@fuyu.mindrot.org>
	<20050810090015.GA14875@gate.dodgy.net.au>
Message-ID: <20050816040741.1d599c%skeleten@shillest.net>

Hi,

I did check also the following change
  > 20050810
  >  - (dtucker) [configure.ac] Test libedit library and headers for compatibility.
  >    Report from skeleten AT shillest.net, ok djm@
via the SNAP-20050811 version, which was available at
  ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ .


Now the configure script does detect the non-compatible
version of libedit with the following messages:
------------------------------------------------------------
...(snip)...
checking for el_init in -ledit... yes
checking if libedit version is compatible... no
configure: error: libedit version is not compatible
------------------------------------------------------------

However, it may be better that you should change the
configure.ac file by applying EITHER OF the 2 patches
attached:
    configure_ac_libedit1.diff
    configure_ac_libedit2.diff
The config.log file contains the following; you can see the
curious test program, where the main() contains the main().
------------------------------------------------------------
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by OpenSSH configure Portable, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $ ./configure --prefix=/usr/local/OpenSSH --with-rpath --without-osfsia --with-zlib=/usr/local/zlib --without-skey --without-tcp-wrappers --with-libedit --without-audit --without-pam --with-ssl-dir=/usr/local/OpenSSL --without-rand-helper --with-privsep-user=sshd --with-privsep-path=/var/empty --without-sectok --without-opensc --without-kerberos5 --with-xauth=/usr/X11R6/bin/xauth --without-ipaddr-display --with-default-path=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin --with-superuser-path=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin --without-4in6 --with-pid-dir=/var/run

## --------- ##
## Platform. ##
## --------- ##

hostname = ********
uname -m = i386
uname -r = 4.11-RELEASE
uname -s = FreeBSD
uname -v = FreeBSD 4.11-RELEASE #0: Tue May  3 02:00:46 JST 2005     root@********:/usr/src/sys/compile/***** 

/usr/bin/uname -p = i386
/bin/uname -X     = unknown

...(snip)...


## ----------- ##
## Core tests. ##
## ----------- ##

...(snip)...
configure:10191: checking if libedit version is compatible
configure:10216: gcc -c -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -I/usr/local/zlib/include  conftest.c >&5
conftest.c: In function `main':
conftest.c:65: warning: `main' is normally a non-static function
conftest.c: In function `main':
conftest.c:66: `H_SETSIZE' undeclared (first use in this function)
conftest.c:66: (Each undeclared identifier is reported only once
conftest.c:66: for each function it appears in.)
conftest.c:67: too many arguments to function `el_init'
conftest.c:66: warning: unused variable `i'
configure:10222: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME "OpenSSH"
...(snip)...
| #define GLOB_HAS_ALTDIRFUNC 1
| #define USE_LIBEDIT
| /* end confdefs.h.  */
| #include <histedit.h>
| int
| main ()
| {
| 
| int main(void)
| {
| 	int i = H_SETSIZE;
| 	el_init("", NULL, NULL, NULL);
| 	exit(0);
| }
| 
|   ;
|   return 0;
| }
configure:10243: result: no
configure:10245: error: libedit version is not compatible

...(snip)...

configure: exit 1
------------------------------------------------------------

I THINK that these patch fixes this curious test program,
but I can't be sure of that... UNABLE to test this because I
don't have the autoconf tools installed on the system of me.
   X-)

Also, I am trying to install on the FreeBSD-4.x system
the libedit distributed at
  http://www.thrysoee.dk/editline/ ,
but I haven't succeeded; I am going to contact the author of
it.


Thank you very much,
---
Norihiko Murase <skeleten at shillest.net>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: configure_ac_libedit2.diff
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050816/ae61b420/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: configure_ac_libedit1.diff
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050816/ae61b420/attachment-0001.ksh 

From tim at multitalents.net  Tue Aug 16 10:52:13 2005
From: tim at multitalents.net (Tim Rice)
Date: Mon, 15 Aug 2005 17:52:13 -0700 (PDT)
Subject: (4.1p1) configure fails with --without-audit
In-Reply-To: <20050816035824.14da9f%skeleten@shillest.net>
References: <20050809055835.32778e%skeleten@shillest.net>
	<Pine.UW2.4.63.0508091019530.29791@server01.int.multitalents.net>
	<20050816035824.14da9f%skeleten@shillest.net>
Message-ID: <Pine.UW2.4.63.0508151749210.1437@server01.int.multitalents.net>

On Tue, 16 Aug 2005, Norihiko Murase wrote:

[snip]
> This (small) problem is the curious message. The configure
> script now prints the following message in checking the
> audit modules:
> ------------------------------------------------------------
> ...(snip)...
> checking for /proc/pid/fd directory... no
> checking for supported audit module... checking for arc4random... yes
> checking for b64_ntop... no
> ...(snip)...
> ------------------------------------------------------------

That'll teach me to whip out a quick fix right before I head off to bed.
I've commited your patch. Thanks.
It'll be in the next snapshot.

> 
> This is because the result string "no" is missing. It may be
> better that you should add it also in the case of
> "--without-audit". I attach the patch (configure_ac_audit.diff)
> for this.
> 
> 
> Best Regards,
> ---
> Norihiko Murase <skeleten at shillest.net>
> 

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




From tim at multitalents.net  Tue Aug 16 10:56:27 2005
From: tim at multitalents.net (Tim Rice)
Date: Mon, 15 Aug 2005 17:56:27 -0700 (PDT)
Subject: (4.1p1) Building failure with libedit on FreeBSD 4.x-RELEASE
In-Reply-To: <20050816040741.1d599c%skeleten@shillest.net>
References: <20050809094309.100104e%skeleten@shillest.net>
	<20050809095613.GA11593@gate.dodgy.net.au>
	<Pine.BSO.4.63.0508101120460.29249@fuyu.mindrot.org>
	<20050810090015.GA14875@gate.dodgy.net.au>
	<20050816040741.1d599c%skeleten@shillest.net>
Message-ID: <Pine.UW2.4.63.0508151752350.1437@server01.int.multitalents.net>

On Tue, 16 Aug 2005, Norihiko Murase wrote:

[snip]
> ------------------------------------------------------------
> 
> I THINK that these patch fixes this curious test program,
> but I can't be sure of that... UNABLE to test this because I
> don't have the autoconf tools installed on the system of me.
>    X-)

The configure_ac_libedit2.diff looks good. I've commited it.
Please test the next snapshot.


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




From ron_chen_123 at yahoo.com  Wed Aug 17 11:35:16 2005
From: ron_chen_123 at yahoo.com (Ron Chen)
Date: Tue, 16 Aug 2005 18:35:16 -0700 (PDT)
Subject: Feature request: Integration with GridEngine
Message-ID: <20050817013517.94080.qmail@web32912.mail.mud.yahoo.com>

Hi,

I opened an enchancement request:
http://bugzilla.mindrot.org/show_bug.cgi?id=1070

I am hoping that the patch can get into the standard
OpenSSH source tree, so that users just need to
download the latest version of OpenSSH tarball and
build an integrated sshd themselves.

Please let me know any further changes are needed.

Thanks,
 -Ron



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



From skeleten at shillest.net  Thu Aug 18 08:14:46 2005
From: skeleten at shillest.net (Norihiko Murase)
Date: Thu, 18 Aug 2005 07:14:46 +0900
Subject: (4.1p1) Building failure with libedit on FreeBSD 4.x-RELEASE
In-Reply-To: (Your message of "Mon, 15 Aug 2005 17:56:27 -0700 (PDT)
	")  <Pine.UW2.4.63.0508151752350.1437@server01.int.multitalents.net>
References: <20050809094309.100104e%skeleten@shillest.net>
	<20050809095613.GA11593@gate.dodgy.net.au>
	<Pine.BSO.4.63.0508101120460.29249@fuyu.mindrot.org>
	<20050810090015.GA14875@gate.dodgy.net.au>
	<20050816040741.1d599c%skeleten@shillest.net>
	<Pine.UW2.4.63.0508151752350.1437@server01.int.multitalents.net>
Message-ID: <20050818071446.c75377%skeleten@shillest.net>

Hi,


|From: Tim Rice <tim at multitalents.net>
|Subject: Re: (4.1p1) Building failure with libedit on FreeBSD 4.x-RELEASE
|Message-ID: <Pine.UW2.4.63.0508151752350.1437 at server01.int.multitalents.net>
|Date: Mon, 15 Aug 2005 17:56:27 -0700 (PDT)
|
|>The configure_ac_libedit2.diff looks good. I've commited it.
|>Please test the next snapshot.

I tested the SNAP-20050817 version, in which the following
problem is FIXED.
  > The config.log file contains the following; you can see the
  > curious test program, where the main() contains the main().

Thank you very much!


Best Regards,
---
Norihiko Murase
  The University of Aizu
E-mail: skeleten at shillest.net
        s1080224 at u-aizu.ac.jp



From skeleten at shillest.net  Thu Aug 18 08:31:19 2005
From: skeleten at shillest.net (Norihiko Murase)
Date: Thu, 18 Aug 2005 07:31:19 +0900
Subject: (4.1p1) configure fails with --without-audit
In-Reply-To: (Your message of "Mon, 15 Aug 2005 17:52:13 -0700 (PDT)
	")  <Pine.UW2.4.63.0508151749210.1437@server01.int.multitalents.net>
References: <20050809055835.32778e%skeleten@shillest.net>
	<Pine.UW2.4.63.0508091019530.29791@server01.int.multitalents.net>
	<20050816035824.14da9f%skeleten@shillest.net>
	<Pine.UW2.4.63.0508151749210.1437@server01.int.multitalents.net>
Message-ID: <20050818073119.d67984%skeleten@shillest.net>

|>That'll teach me to whip out a quick fix right before I head off to bed.
|>I've commited your patch. Thanks.
|>It'll be in the next snapshot.

I've seen this problem fixed on the SNAP-20050817 version.

Thank you very much!


Best Regards,
---
Norihiko Murase
  The University of Aizu
E-mail: skeleten at shillest.net
        s1080224 at u-aizu.ac.jp



From crxssi at hotmail.com  Thu Aug 18 02:04:30 2005
From: crxssi at hotmail.com (CRX Driver)
Date: Wed, 17 Aug 2005 12:04:30 -0400
Subject: OpenSSH sget/sput suggestion
Message-ID: <BAY102-F41BE4312329BBC15347619CFB30@phx.gbl>

Not sure if this has ever been suggested before as a feature request, but I 
am getting off my lazy a** and sending this Email to your list.  Hopefully 
you will think it is a wonderful idea.

I am forever using the wonderful OpenSSH on many systems and have done so 
for many years.  But I often find myself wanting to transfer files while 
ssh'ed into another system.

If I could just have a way to transfer a file back to me with something like 
"sget" or "sput" WHILE I am ssh'ed into another machine, THAT would save a 
tremendous amount of time.  As it is now, you have to type long names and 
paths and a password again each time with a separate scp session.

Imagine this:

ssh user at machine.com
cd /home/user
ls
rm junk
sget logfile


(and "logfile" just immediately gets scp'ed to my local machine)

I imagine "scp" or "sget" would somehow open a tunnel back to the client 
side for file transfer.  Or, I suppose it could be triggered in the client 
with a special keystroke while ssh'ed into a remote site.
--
/-------------------------------------------------------------------\
|       Mark A. Davis   Norfolk, VA; EDT         (757)-461-5001x431 |
|   Director of Information Systems & Commun,    www.himss.org      |
|    Lake Taylor Transitional Care Hospital      www.laketaylor.org |
| Charter Member,  TideWater Unix User's Group   www.twuug.org      |
|  Pioneer Member, Electronic Frontier Found.    www.eff.org        |
\-------------------------------------------------------------------/




From Sankar.Srinivasan at FMR.COM  Fri Aug 19 00:45:50 2005
From: Sankar.Srinivasan at FMR.COM (Srinivasan, Sankar)
Date: Thu, 18 Aug 2005 10:45:50 -0400
Subject: Sftp with chroot
Message-ID: <2AAB283A8C3B004593FC1D64AD3BFEA65F3313@MSGMROCLP2WIN.DMN1.FMR.COM>

Hi

Does anyone know if chroot is part of the latest openssh . If not how do
I enable the chroot feature with the openssh.
Any help is appreciated. I am currently running  3.7.1p2. This version
allows the user to traverse to other dirs and they can ftp the files .
I want to lock down the users to their home dir .

thanks



From Paul.Hyder at noaa.gov  Fri Aug 19 01:05:38 2005
From: Paul.Hyder at noaa.gov (Paul Hyder)
Date: Thu, 18 Aug 2005 09:05:38 -0600
Subject: Sftp with chroot
In-Reply-To: <2AAB283A8C3B004593FC1D64AD3BFEA65F3313@MSGMROCLP2WIN.DMN1.FMR.COM>
References: <2AAB283A8C3B004593FC1D64AD3BFEA65F3313@MSGMROCLP2WIN.DMN1.FMR.COM>
Message-ID: <4304A3C2.8080204@noaa.gov>

You might want to look at http://sublimation.org/scponly/
     Paul Hyder
     NOAA Forecast Systems Laboratory
     Boulder, CO

Srinivasan, Sankar wrote:
> Hi
> 
> Does anyone know if chroot is part of the latest openssh . If not how do
> I enable the chroot feature with the openssh.
> Any help is appreciated. I am currently running  3.7.1p2. This version
> allows the user to traverse to other dirs and they can ftp the files .
> I want to lock down the users to their home dir .
> 
> thanks
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From imorgan at nas.nasa.gov  Fri Aug 19 02:22:47 2005
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Thu, 18 Aug 2005 09:22:47 -0700 (PDT)
Subject: OpenSSH sget/sput suggestion
In-Reply-To: <BAY102-F41BE4312329BBC15347619CFB30@phx.gbl> from "CRX Driver"
	at Aug 17, 2005 12:04:30 PM
Message-ID: <200508181622.j7IGMloq015431@sun601.nas.nasa.gov>

On Wed Aug 17 09:04:30 2005, CRX Driver wrote:
> 
> Not sure if this has ever been suggested before as a feature request, but I 
> am getting off my lazy a** and sending this Email to your list.  Hopefully 
> you will think it is a wonderful idea.
> 
> I am forever using the wonderful OpenSSH on many systems and have done so 
> for many years.  But I often find myself wanting to transfer files while 
> ssh'ed into another system.
> 
> If I could just have a way to transfer a file back to me with something like 
> "sget" or "sput" WHILE I am ssh'ed into another machine, THAT would save a 
> tremendous amount of time.  As it is now, you have to type long names and 
> paths and a password again each time with a separate scp session.

You could use session multiplexing to eliminate some of the tedium.

> 
> Imagine this:
> 
> ssh user at machine.com
> cd /home/user
> ls
> rm junk
> sget logfile
> 

You can already do this with sftp.

> 
> (and "logfile" just immediately gets scp'ed to my local machine)
> 
> I imagine "scp" or "sget" would somehow open a tunnel back to the client 
> side for file transfer.  Or, I suppose it could be triggered in the client 
> with a special keystroke while ssh'ed into a remote site.
> 


--
Iain Morgan



From crxssi at hotmail.com  Fri Aug 19 07:14:28 2005
From: crxssi at hotmail.com (CRX Driver)
Date: Thu, 18 Aug 2005 17:14:28 -0400
Subject: OpenSSH sget/sput suggestion
In-Reply-To: <200508181622.j7IGMloq015431@sun601.nas.nasa.gov>
Message-ID: <BAY102-F16733869B49E2CEEB2B8BACFB20@phx.gbl>

>>Imagine this:
>>
>>ssh user at machine.com
>>cd /home/user
>>ls
>>rm junk
>>sget logfile

>You can already do this with sftp.

You can file browse with sftp, but you cannot run programs, kill processes 
and then grab a file all while already on-line through an existing ssh.




From dtucker at zip.com.au  Fri Aug 19 17:56:19 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 19 Aug 2005 17:56:19 +1000
Subject: OpenSSH sget/sput suggestion
In-Reply-To: <BAY102-F16733869B49E2CEEB2B8BACFB20@phx.gbl>
References: <BAY102-F16733869B49E2CEEB2B8BACFB20@phx.gbl>
Message-ID: <430590A3.1090506@zip.com.au>

CRX Driver wrote:
>>>Imagine this:
>>>
>>>ssh user at machine.com
>>>cd /home/user
>>>ls
>>>rm junk
>>>sget logfile
> 
>>You can already do this with sftp.
> 
> You can file browse with sftp, but you cannot run programs, kill processes 
> and then grab a file all while already on-line through an existing ssh.

See also the related discussion earlier on this list:
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=112116732631189&w=2

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



From djm at mindrot.org  Mon Aug 22 20:41:01 2005
From: djm at mindrot.org (Damien Miller)
Date: Mon, 22 Aug 2005 20:41:01 +1000
Subject: Call for release testing
Message-ID: <4309ABBD.8030609@mindrot.org>

Hi,

We would like to make one of our periodic releases shortly, so once
again we are asking for readers of this list (or anyone else) to
download and test a CVS snapshot of OpenSSH on your favourite
platforms.

The OpenBSD version is available in CVS HEAD:
http://www.openbsd.org/anoncvs.html

Portable snapshots are available the mirrors listed at
http://www.openssh.com/portable.html#ftp in the snapshots/
subdirectory

Please test! Running the regression tests supplied with Portable does
not require installation and is a simply:

$ ./configure && make tests

Testing on suitable non-production systems is also appreciated. Please
send reports of success or failure to openssh-unix-dev at mindrot.org.

Also, OpenSSH Portable has a (completely voluntary) configuration
survey. It will collect information about the platform and the
options OpenSSH was configured with and mail it to an archive. We
tried to be careful not to collect anything that might be considered
sensitive, however if anyone has any issues with the data collected
then please let us know).

The raw data will be available only to the development team, however
we may publish summary data at some point in the future. This data
will help us to better support your platforms.

You can view the data that is collected by running "make survey" and
looking at the file "survey" in the build dir. The data is not sent
until you explicitly request it ("make send-survey"). If you have any
doubts at all then ask us (or just don't send it).

Some of the changes in the coming release include:

  - Add a new compression method that delays the start of zlib
    compression until the user has been authenticated successfully. The
    new method "Compression=delayed" is on by default in the server.
    This eliminates the risk of another zlib vulnerability leading to
    a compromise of the server by a user without authentication
    credentials.

    NB. Older OpenSSH (<3.5) version have a bug which will cause them
    to refuse to connect to any server that does not offer compression
    when the client has compression requested. Since the new "delayed"
    server mode isn't supported by these older clients, they will
    refuse to connect to a new server unless compression is disabled
    (on the client end) or the original compression method is enabled
    on the server ("Compression=yes" in sshd_config)

  - Another round of proactive changes for signed vs unsigned integer
    bugs has been completed, including changing the atomicio() API to
    encourage safer programming. As a result of these changes, OpenSSH
    is now "gcc -Wsign-compare" clean on most platforms.

  - Added support for the improved arcfour cipher modes from
    draft-harris-ssh-arcfour-fixes-02. The improves the cipher's
    resistance to a number of attacks by discarding early keystream
    output.

  - Increase the default size of new RSA/DSA keys generated by
    ssh-keygen from 1024 to 2048 bits.

  - Many bugfixes and improvements to connection multiplexing,
    including:

    - Added ControlMaster=auto/autoask options to support opportunistic
      multiplexing (see the ssh_config(5) manpage for details).

    - The client will now gracefully fallback to starting a new TCP
      connection if it cannot connect to a specified multiplexing
      control socket

    - Added %h (target hostname), %p (target port) and %r (remote
      username) expansion sequences to ControlPath. Also allow
      ControlPath=none to disable connection multiplexing.

    - Implemented support for X11 and agent forwarding over multiplexed
      connections. Because of protocol limitations, the slave
      connections inherit the master's DISPLAY and SSH_AUTH_SOCK rather
      than distinctly forwarding their own.

  - The following bugs from http://bugzilla.mindrot.org/ were closed:

     #1025 - Correctly handle disabled special character in ttymodes
     #1054 - Don't terminate connection on getpeername() failure
     #1046 - AIX 5.3 Garbage on Login
     #623  - Don't use $HOME in manpages
     #829  - Don't allocate a tty if -n option is set
     #471  - Misleading error message if /dev/tty perms wrong
     #1033 - Fix compile-time warnings

  - Lots of other improvements and fixes. Please refer to the ChangeLog
    for details

Thanks to everyone who has contributed patches, problem or test reports.

Regards,
Damien Miller



From mbraun at uni-hd.de  Mon Aug 22 23:18:43 2005
From: mbraun at uni-hd.de (Martin Braun)
Date: Mon, 22 Aug 2005 15:18:43 +0200
Subject: [openssh-unix-announce] Call for release testing
Message-ID: <4309D0B3.9080005@uni-hd.de>

hello,

all tests on openssh-SNAP-20050819.tar.gz were succesful on a typical
SuSE Linux 9.3 (i586) install with
2.6.11.4-21.8-smp #1 SMP Tue Jul 19 12:42:37 UTC 2005 i686 i686 i386
GNU/Linux

regards,

Martin Braun



From moixa at gmx.ch  Tue Aug 23 06:24:15 2005
From: moixa at gmx.ch (Tobias Sager)
Date: Mon, 22 Aug 2005 22:24:15 +0200
Subject: 20050819 snapshot tests without problems
Message-ID: <430A346F.7050004@gmx.ch>

Hi all,

I downloaded and tested SNAP-20050819 on the following systems:
- Gentoo (as up-to-date as possible, though not bleeding edge) desktop
- An old LFS (linuxfromscratch) server
- Fedora Core 4 (server with newest updates)

All tests worked fine on every platform, no problems at all.

Cheers,
Tobias

Please CC me for follow-ups as I am not subscribed.
-- 
GPG-Key 0xEF37FF28 - 1024/4096 DSA/ELG-E - 16.11.2001
Fingerprint: 3C4B 155F 2621 CEAF D3A6 0CCB 937C 9597 EF37 FF28

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050822/c9d2a039/attachment.bin 

From gert at greenie.muc.de  Tue Aug 23 07:33:12 2005
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 22 Aug 2005 23:33:12 +0200
Subject: Call for release testing
In-Reply-To: <4309ABBD.8030609@mindrot.org>
References: <4309ABBD.8030609@mindrot.org>
Message-ID: <20050822213312.GZ1060@greenie.muc.de>

Hi,

On Mon, Aug 22, 2005 at 08:41:01PM +1000, Damien Miller wrote:
> Please test! Running the regression tests supplied with Portable does
> not require installation and is a simply:
> 
> $ ./configure && make tests

NetBSD 2.0.1 on Sparc64,  OpenSSH CVS snapshot as of today.

"autoreconf" gives a couple of warnings.

"make" runs through just fine.

"make tests" runs fine.

"make (send-)survey" -> done :-)

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 WKNOX at mitre.org  Tue Aug 23 08:37:46 2005
From: WKNOX at mitre.org (Knox,William R.)
Date: Mon, 22 Aug 2005 18:37:46 -0400
Subject: Call for release testing
Message-ID: <3B660B4ACB06BE488E3938F95115E4DE3D26FE@IMCSRV4.MITRE.ORG>

Test on Solaris 8 failed with the below output:

run test multiplex.sh ...
test connection multiplexing: envpass
ssh: otherhost: host/servname not known
environment not found
test connection multiplexing: transfer
ssh: otherhost: host/servname not known
cmp: EOF on /home/m27310/openssh/regress/ls.copy
ssh -Sctl: corrupted copy of /bin/ls
ssh: otherhost: host/servname not known
cmp: EOF on /home/m27310/openssh/regress/ls.copy
ssh -S ctl: corrupted copy of /bin/ls
sftp: failed copy /bin/ls
cmp: /home/m27310/openssh/regress/ls.copy: No such file or directory
sftp: corrupted copy of /bin/ls
test connection multiplexing: status 0
test connection multiplexing: status 1
test connection multiplexing: status 4
test connection multiplexing: status 5
test connection multiplexing: status 44
Master running (pid=27238)
Exit request sent.
failed connection multiplexing
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/home/m27310/openssh/regress'
make: *** [tests] Error 2

Built like so:
./configure --without-zlib-version-check --with-tcp-wrappers --with-pam

Tests were run as an unprivileged user. Solaris 8 patch level is
117350-20.

Happy to help with any further information.

                 Bill Knox
                 Lead Operating Systems Programmer/Analyst
                 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 Damien Miller
Sent: Monday, August 22, 2005 6:41 AM
To: openssh-unix-dev at mindrot.org; openssh-unix-announce at mindrot.org
Subject: Call for release testing

Hi,

We would like to make one of our periodic releases shortly, so once
again we are asking for readers of this list (or anyone else) to
download and test a CVS snapshot of OpenSSH on your favourite
platforms.

The OpenBSD version is available in CVS HEAD:
http://www.openbsd.org/anoncvs.html

Portable snapshots are available the mirrors listed at
http://www.openssh.com/portable.html#ftp in the snapshots/
subdirectory

Please test! Running the regression tests supplied with Portable does
not require installation and is a simply:

$ ./configure && make tests

Testing on suitable non-production systems is also appreciated. Please
send reports of success or failure to openssh-unix-dev at mindrot.org.

Also, OpenSSH Portable has a (completely voluntary) configuration
survey. It will collect information about the platform and the
options OpenSSH was configured with and mail it to an archive. We
tried to be careful not to collect anything that might be considered
sensitive, however if anyone has any issues with the data collected
then please let us know).

The raw data will be available only to the development team, however
we may publish summary data at some point in the future. This data
will help us to better support your platforms.

You can view the data that is collected by running "make survey" and
looking at the file "survey" in the build dir. The data is not sent
until you explicitly request it ("make send-survey"). If you have any
doubts at all then ask us (or just don't send it).

Some of the changes in the coming release include:

  - Add a new compression method that delays the start of zlib
    compression until the user has been authenticated successfully. The
    new method "Compression=delayed" is on by default in the server.
    This eliminates the risk of another zlib vulnerability leading to
    a compromise of the server by a user without authentication
    credentials.

    NB. Older OpenSSH (<3.5) version have a bug which will cause them
    to refuse to connect to any server that does not offer compression
    when the client has compression requested. Since the new "delayed"
    server mode isn't supported by these older clients, they will
    refuse to connect to a new server unless compression is disabled
    (on the client end) or the original compression method is enabled
    on the server ("Compression=yes" in sshd_config)

  - Another round of proactive changes for signed vs unsigned integer
    bugs has been completed, including changing the atomicio() API to
    encourage safer programming. As a result of these changes, OpenSSH
    is now "gcc -Wsign-compare" clean on most platforms.

  - Added support for the improved arcfour cipher modes from
    draft-harris-ssh-arcfour-fixes-02. The improves the cipher's
    resistance to a number of attacks by discarding early keystream
    output.

  - Increase the default size of new RSA/DSA keys generated by
    ssh-keygen from 1024 to 2048 bits.

  - Many bugfixes and improvements to connection multiplexing,
    including:

    - Added ControlMaster=auto/autoask options to support opportunistic
      multiplexing (see the ssh_config(5) manpage for details).

    - The client will now gracefully fallback to starting a new TCP
      connection if it cannot connect to a specified multiplexing
      control socket

    - Added %h (target hostname), %p (target port) and %r (remote
      username) expansion sequences to ControlPath. Also allow
      ControlPath=none to disable connection multiplexing.

    - Implemented support for X11 and agent forwarding over multiplexed
      connections. Because of protocol limitations, the slave
      connections inherit the master's DISPLAY and SSH_AUTH_SOCK rather
      than distinctly forwarding their own.

  - The following bugs from http://bugzilla.mindrot.org/ were closed:

     #1025 - Correctly handle disabled special character in ttymodes
     #1054 - Don't terminate connection on getpeername() failure
     #1046 - AIX 5.3 Garbage on Login
     #623  - Don't use $HOME in manpages
     #829  - Don't allocate a tty if -n option is set
     #471  - Misleading error message if /dev/tty perms wrong
     #1033 - Fix compile-time warnings

  - Lots of other improvements and fixes. Please refer to the ChangeLog
    for details

Thanks to everyone who has contributed patches, problem or test reports.

Regards,
Damien Miller

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



From tusker at tusker.org  Tue Aug 23 15:10:32 2005
From: tusker at tusker.org (Damien Mascord)
Date: Tue, 23 Aug 2005 13:10:32 +0800
Subject: Call for release testing
In-Reply-To: <4309ABBD.8030609@mindrot.org>
References: <4309ABBD.8030609@mindrot.org>
Message-ID: <430AAFC8.30905@tusker.org>

Damien Miller wrote:
> Hi,
> 
> We would like to make one of our periodic releases shortly, so once
> again we are asking for readers of this list (or anyone else) to
> download and test a CVS snapshot of OpenSSH on your favourite
> platforms.
> 
> The OpenBSD version is available in CVS HEAD:
> http://www.openbsd.org/anoncvs.html
> 
> Portable snapshots are available the mirrors listed at
> http://www.openssh.com/portable.html#ftp in the snapshots/
> subdirectory
> 
> Please test! Running the regression tests supplied with Portable does
> not require installation and is a simply:
> 
> $ ./configure && make tests

Hi,

Tested on Debian sarge, with no problems.
Tested on Sourcemage stable, with no problems.

One small issue, is that the tests assume that there is an existing 
installation with privsep, and hence require a /var/empty directory to 
exist in the filesystem.

run test connect.sh ...
Missing privilege separation directory: /var/empty
FATAL: sshd_proxy broken

After creating the /var/empty directory, the tests pass correctly... is 
this desired behaviour for the test suite ?  Should the tests be run 
inside a fakeroot or chroot instead ?

Damien



From dtucker at zip.com.au  Tue Aug 23 16:10:00 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 23 Aug 2005 16:10:00 +1000
Subject: Call for release testing
In-Reply-To: <430AAFC8.30905@tusker.org>
References: <4309ABBD.8030609@mindrot.org> <430AAFC8.30905@tusker.org>
Message-ID: <430ABDB8.4030506@zip.com.au>

Damien Mascord wrote:
> One small issue, is that the tests assume that there is an existing 
> installation with privsep, and hence require a /var/empty directory to 
> exist in the filesystem.
> 
> run test connect.sh ...
> Missing privilege separation directory: /var/empty
> FATAL: sshd_proxy broken
> 
> After creating the /var/empty directory, the tests pass correctly... is 
> this desired behaviour for the test suite ?  Should the tests be run 
> inside a fakeroot or chroot instead ?

Probably not.

A real chroot requires root privs and must be created (which is fiddly
and very system dependant).

fakeroot and friends have to be installed/provided and require a
LD_PRELOAD which is not available on some platforms.

I probably ought to be documented as a limitation, though.  Or maybe we
could check for the existence of the user and directory and disable the
privsep tests if missing (eg by unsetting SUDO).

-- 
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 phil at usc.edu  Tue Aug 23 17:12:41 2005
From: phil at usc.edu (Phil Dibowitz)
Date: Tue, 23 Aug 2005 00:12:41 -0700
Subject: openssh-unix-dev Digest, Vol 28, Issue 10
In-Reply-To: <mailman.62.1124773845.3777.openssh-unix-dev@mindrot.org>
References: <mailman.62.1124773845.3777.openssh-unix-dev@mindrot.org>
Message-ID: <20050823071241.GA19176@usc.edu>

On Tue, Aug 23, 2005 at 03:10:45PM +1000, openssh-unix-dev-request at mindrot.org wrote:
> Date: Fri, 19 Aug 2005 17:56:19 +1000
> From: Darren Tucker <dtucker at zip.com.au>
> Subject: Re: OpenSSH sget/sput suggestion
> To: CRX Driver <crxssi at hotmail.com>
> Cc: openssh-unix-dev at mindrot.org
> Message-ID: <430590A3.1090506 at zip.com.au>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> CRX Driver wrote:
> >>>Imagine this:
> >>>
> >>>ssh user at machine.com
> >>>cd /home/user
> >>>ls
> >>>rm junk
> >>>sget logfile
> > 
> >>You can already do this with sftp.
> > 
> > You can file browse with sftp, but you cannot run programs, kill processes 
> > and then grab a file all while already on-line through an existing ssh.
> 
> See also the related discussion earlier on this list:
> http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=112116732631189&w=2

Regarding the above thread and the above linked thread...

Having the "ssh -MS ..." is nice, but is NOT the same feature. I've been
meaning to impliment the feature referenced in the above thread for over a
year now.

There's no reason I shouldn't be able to be in the middle of some work on a
shell and put or get a file - though instead of making a ~S, I would have
implimented it in the ~C cli interface.

For example, it would be great to be doing something on a remote box, realize
I need the 4-line script in my local ~/bin and do a ~C, sput ~/bin/script,
quit, ./script.

Or have some long shell-pipeline and then redirect it to a file and then do ~C
sget file, quit, and continue working.

-- 
Phil Dibowitz

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

From selvesteen at gmail.com  Tue Aug 23 18:54:35 2005
From: selvesteen at gmail.com (Michael Selvesteen)
Date: Tue, 23 Aug 2005 14:24:35 +0530
Subject: Call for release testing
References: <4309ABBD.8030609@mindrot.org>
	<20050822213312.GZ1060@greenie.muc.de>
Message-ID: <00c301c5a7c0$55a9fbd0$290110ac@midco>

Hello All,

> Hi,
> 
> On Mon, Aug 22, 2005 at 08:41:01PM +1000, Damien Miller wrote:
> > Please test! Running the regression tests supplied with Portable does
> > not require installation and is a simply:
> > 
> > $ ./configure && make tests


Platforms :  HP-UX  B.11.23  U  ia64  &  HP-UX  B.11.11 U 9000/800

Except the following tests, all others passed

>> run test agent-getpeereid.sh ...
skipped (not supported on this platform)
>>run test agent-ptrace.sh ...
skipped (SUDO not set)
>>run test dynamic-forward.sh ...
skipped (no suitable ProxyCommand found)

Thanks
Michael




From dtucker at zip.com.au  Tue Aug 23 19:14:20 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 23 Aug 2005 19:14:20 +1000
Subject: Call for release testing
In-Reply-To: <00c301c5a7c0$55a9fbd0$290110ac@midco>
References: <4309ABBD.8030609@mindrot.org>	<20050822213312.GZ1060@greenie.muc.de>
	<00c301c5a7c0$55a9fbd0$290110ac@midco>
Message-ID: <430AE8EC.7060101@zip.com.au>

Thanks to all who have tested so far!

Michael Selvesteen wrote:
> Platforms :  HP-UX  B.11.23  U  ia64  &  HP-UX  B.11.11 U 9000/800
> Except the following tests, all others passed

>>>run test agent-getpeereid.sh ...
> skipped (not supported on this platform)

HP-UX does not have the kernel features required to implement this; ie
no way to know the euid of the process on the other end of a Unix domain
socket.  (Either that, or it does and OpenSSH doesn't know how to use
it, in which case we would like to know about it :-)

>>>run test agent-ptrace.sh ..
> skipped (SUDO not set)

If you have gdb installed and set up sudo to allow commands without
password then this will work then you can enable this with:

$ SUDO=sudo make tests

This is mentioned briefly in README.regress but could probably use a
better explanation.

>>>run test dynamic-forward.sh ...
> skipped (no suitable ProxyCommand found)

If you wish to test thism you can install connect[1] or a netcat that
supports SOCKS (OpenBSD's is OK, not sure about other variants).

[1] http://www.taiyo.co.jp/~gotoh/ssh/connect.html

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



From vinschen at redhat.com  Tue Aug 23 21:28:14 2005
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 23 Aug 2005 13:28:14 +0200
Subject: Call for release testing
In-Reply-To: <4309ABBD.8030609@mindrot.org>
References: <4309ABBD.8030609@mindrot.org>
Message-ID: <20050823112814.GM17452@calimero.vinschen.de>

On Aug 22 20:41, Damien Miller wrote:
> Hi,
> 
> We would like to make one of our periodic releases shortly, so once
> again we are asking for readers of this list (or anyone else) to
> download and test a CVS snapshot of OpenSSH on your favourite
> platforms.
> 
> The OpenBSD version is available in CVS HEAD:
> http://www.openbsd.org/anoncvs.html
> 
> Portable snapshots are available the mirrors listed at
> http://www.openssh.com/portable.html#ftp in the snapshots/
> subdirectory
> 
> Please test! Running the regression tests supplied with Portable does
> not require installation and is a simply:
> 
> $ ./configure && make tests

I've tested the CVS version from yesterday on Cygwin 1.5.18 and 1.5.19
(upcoming version).

`autoreconf', `make', `make install' run fine.  Installed version works
as expected.

`make tests' *could* run through with no errors, but there's a bug
in regress/test-exec.sh, which results in the testsuite not running:

  # Path to sshd must be absolute for rexec
  if [ ! -x /$SSHD ]; then
	  SSHD=`which sshd`
  fi

The above test `-x /$SSHD' fails on Cygwin.  The reason is that $SSHD
already contains an absolute path.  Therefore the evaluated path which
is tested in the above case starts with two leading slashes, like this:

  if [ ! -x //usr/src/openssh/build/sshd ]

The problem here is that paths beginning with two slashes are SMB network
paths on Cygwin/Windows.  So in the above case, the statement hangs and
eventually fails, because Cygwin searches for a file src/openssh/build/sshd
on the SMB server named "usr".

Please note that this is NOT a bug in Cygwin.  Paths beginning with two
slashes being different from paths beginning with one slash are blessed
by SUSv3, see

 http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html
 
Chapter 4.11 "Pathname Resolution", last paragraph:

  A pathname consisting of a single slash shall resolve to the root directory
  of the process. [...] A pathname that begins with two successive slashes
  may be interpreted in an implementation-defined manner, although more than
  two leading slashes shall be treated as a single slash.

So the above test should either make sure that the evaluated path
beginns with only one slash, or with more than 2 slashes.  The latter
idea looks most easy to implement:

  # Path to sshd must be absolute for rexec
  if [ ! -x ///$SSHD ]; then
	  SSHD=`which sshd`
  fi


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.



From vinschen at redhat.com  Tue Aug 23 21:29:37 2005
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 23 Aug 2005 13:29:37 +0200
Subject: Call for release testing
In-Reply-To: <430ABDB8.4030506@zip.com.au>
References: <4309ABBD.8030609@mindrot.org> <430AAFC8.30905@tusker.org>
	<430ABDB8.4030506@zip.com.au>
Message-ID: <20050823112937.GN17452@calimero.vinschen.de>

On Aug 23 16:10, Darren Tucker wrote:
> Damien Mascord wrote:
> > One small issue, is that the tests assume that there is an existing 
> > installation with privsep, and hence require a /var/empty directory to 
> > exist in the filesystem.
> > 
> > run test connect.sh ...
> > Missing privilege separation directory: /var/empty
> > FATAL: sshd_proxy broken
> > 
> > After creating the /var/empty directory, the tests pass correctly... is 
> > this desired behaviour for the test suite ?  Should the tests be run 
> > inside a fakeroot or chroot instead ?
> 
> Probably not.
> 
> A real chroot requires root privs and must be created (which is fiddly
> and very system dependant).
> 
> fakeroot and friends have to be installed/provided and require a
> LD_PRELOAD which is not available on some platforms.
> 
> I probably ought to be documented as a limitation, though.  Or maybe we
> could check for the existence of the user and directory and disable the
> privsep tests if missing (eg by unsetting SUDO).

Is there a problem to make the privsep path configurable?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.



From dtucker at zip.com.au  Tue Aug 23 21:59:48 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 23 Aug 2005 21:59:48 +1000
Subject: Call for release testing
In-Reply-To: <20050823112814.GM17452@calimero.vinschen.de>
References: <4309ABBD.8030609@mindrot.org>
	<20050823112814.GM17452@calimero.vinschen.de>
Message-ID: <430B0FB4.3010807@zip.com.au>

Corinna Vinschen wrote:
> `make tests' *could* run through with no errors, but there's a bug
> in regress/test-exec.sh, which results in the testsuite not running:
[...]
> So the above test should either make sure that the evaluated path
> beginns with only one slash, or with more than 2 slashes.  The latter
> idea looks most easy to implement:

Something like this ought to work too (untested):

case "$SSHD" in
/*) ;;
*) SSHD=`which sshd` ;;
esac

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



From dtucker at zip.com.au  Tue Aug 23 22:02:05 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 23 Aug 2005 22:02:05 +1000
Subject: Call for release testing
In-Reply-To: <4309ABBD.8030609@mindrot.org>
References: <4309ABBD.8030609@mindrot.org>
Message-ID: <430B103D.7080903@zip.com.au>

Damien Miller wrote:
> Also, OpenSSH Portable has a (completely voluntary) configuration
> survey [...]
> The raw data will be available only to the development team, however
> we may publish summary data at some point in the future. This data
> will help us to better support your platforms.

In case anyone is morbidly curious about the high-level results of the
survey so far, the results are below (41 responses in total, all numbers
as percentages)

breakdown by operating system (as reported by uname)
39.0    Linux
9.8     AIX
7.3     NetBSD
7.3     SunOS
4.9     HP-UX
4.9     OpenBSD
4.9     FreeBSD
4.9     SCO_SV
4.9     UnixWare
4.9     Darwin
2.4     sco42
2.4     CYGWIN_NT-5.1
2.4     UNIX_SV

breakdown by architecture
68.3    i386
14.6    powerpc
7.3     sparc
2.4     hppa2.0w
2.4     x86_64
2.4     hppa2.0n
2.4     sparc64

breakdown by compiler
34.1    gcc 3.3.x
14.6    gcc 3.4.x
14.6    gcc 2.95.x
7.3     gcc 2.96.x
7.3     gcc 3.2.x
4.9     gcc 4.0.x
4.9     cc
4.9     gcc 2.7.x
2.4     ccache gcc
2.4     egcs 2.91.66
2.4     icc

breakdown by configure options
26.8    --prefix
24.4    --with-tcp-wrappers
24.4    --sysconfdir
24.4    --with-privsep-path
17.1    --with-pam
14.6    --with-superuser-path
14.6    --with-default-path
12.2    --mandir
12.2    --with-privsep-user
12.2    --infodir
9.8     --disable-etc-default-login
9.8     --datadir
9.8     --localstatedir
7.3     --with-xauth
7.3     --with-md5-passwords
7.3     --with-mantype
7.3     --libexecdir
7.3     --with-kerberos5
7.3     --with-cflags
7.3     --with-ssl-dir
4.9     --with-audit
4.9     --disable-suid-ssh
4.9     --with-libedit
4.9     --without-zlib-version-check
4.9     --with-zlib
4.9     --without-kerberos5
4.9     --with-ldflags
4.9     --with-pid-dir
2.4     --without-libedit
2.4     --sharedstatedir
2.4     --without-rpath
2.4     --with-prngd-socket
2.4     --with-cppflags
2.4     --build
2.4     --disable-strip
2.4     --with-lastlog
2.4     --without-opensc
2.4     --without-skey
2.4     --with-random
2.4     --host
2.4     --with-prngd-port

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



From dtucker at zip.com.au  Tue Aug 23 22:17:58 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 23 Aug 2005 22:17:58 +1000
Subject: Call for release testing
In-Reply-To: <20050823112937.GN17452@calimero.vinschen.de>
References: <4309ABBD.8030609@mindrot.org>
	<430AAFC8.30905@tusker.org>	<430ABDB8.4030506@zip.com.au>
	<20050823112937.GN17452@calimero.vinschen.de>
Message-ID: <430B13F6.3080708@zip.com.au>

Corinna Vinschen wrote:
> On Aug 23 16:10, Darren Tucker wrote:
>>I probably ought to be documented as a limitation, though.  Or maybe we
>>could check for the existence of the user and directory and disable the
>>privsep tests if missing (eg by unsetting SUDO).
> 
> Is there a problem to make the privsep path configurable?

I don't think it needs to be a run-time knob, if that's what you mean.
It wouldn't be much use under normal circumstances.

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



From vinschen at redhat.com  Tue Aug 23 22:24:43 2005
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 23 Aug 2005 14:24:43 +0200
Subject: Call for release testing
In-Reply-To: <430B0FB4.3010807@zip.com.au>
References: <4309ABBD.8030609@mindrot.org>
	<20050823112814.GM17452@calimero.vinschen.de>
	<430B0FB4.3010807@zip.com.au>
Message-ID: <20050823122443.GQ17452@calimero.vinschen.de>

On Aug 23 21:59, Darren Tucker wrote:
> Corinna Vinschen wrote:
> > `make tests' *could* run through with no errors, but there's a bug
> > in regress/test-exec.sh, which results in the testsuite not running:
> [...]
> > So the above test should either make sure that the evaluated path
> > beginns with only one slash, or with more than 2 slashes.  The latter
> > idea looks most easy to implement:
> 
> Something like this ought to work too (untested):
> 
> case "$SSHD" in
> /*) ;;
> *) SSHD=`which sshd` ;;
> esac

Looks good to me.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.



From doctor at doctor.nl2k.ab.ca  Tue Aug 23 22:44:26 2005
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Tue, 23 Aug 2005 06:44:26 -0600
Subject: Call for release testing
In-Reply-To: <4309ABBD.8030609@mindrot.org>
References: <4309ABBD.8030609@mindrot.org>
Message-ID: <20050823124426.GB21524@doctor.nl2k.ab.ca>

On Mon, Aug 22, 2005 at 08:41:01PM +1000, Damien Miller wrote:
> Hi,
> 
> We would like to make one of our periodic releases shortly, so once
> again we are asking for readers of this list (or anyone else) to
> download and test a CVS snapshot of OpenSSH on your favourite
> platforms.
> 
> The OpenBSD version is available in CVS HEAD:
> http://www.openbsd.org/anoncvs.html
> 
> Portable snapshots are available the mirrors listed at
> http://www.openssh.com/portable.html#ftp in the snapshots/
> subdirectory
> 
> Please test! Running the regression tests supplied with Portable does
> not require installation and is a simply:
> 
> $ ./configure && make tests
> 
> Testing on suitable non-production systems is also appreciated. Please
> send reports of success or failure to openssh-unix-dev at mindrot.org.
> 
> Also, OpenSSH Portable has a (completely voluntary) configuration
> survey. It will collect information about the platform and the
> options OpenSSH was configured with and mail it to an archive. We
> tried to be careful not to collect anything that might be considered
> sensitive, however if anyone has any issues with the data collected
> then please let us know).
> 
> The raw data will be available only to the development team, however
> we may publish summary data at some point in the future. This data
> will help us to better support your platforms.
> 
> You can view the data that is collected by running "make survey" and
> looking at the file "survey" in the build dir. The data is not sent
> until you explicitly request it ("make send-survey"). If you have any
> doubts at all then ask us (or just don't send it).
> 
> Some of the changes in the coming release include:
> 
>   - Add a new compression method that delays the start of zlib
>     compression until the user has been authenticated successfully. The
>     new method "Compression=delayed" is on by default in the server.
>     This eliminates the risk of another zlib vulnerability leading to
>     a compromise of the server by a user without authentication
>     credentials.
> 
>     NB. Older OpenSSH (<3.5) version have a bug which will cause them
>     to refuse to connect to any server that does not offer compression
>     when the client has compression requested. Since the new "delayed"
>     server mode isn't supported by these older clients, they will
>     refuse to connect to a new server unless compression is disabled
>     (on the client end) or the original compression method is enabled
>     on the server ("Compression=yes" in sshd_config)
> 
>   - Another round of proactive changes for signed vs unsigned integer
>     bugs has been completed, including changing the atomicio() API to
>     encourage safer programming. As a result of these changes, OpenSSH
>     is now "gcc -Wsign-compare" clean on most platforms.
> 
>   - Added support for the improved arcfour cipher modes from
>     draft-harris-ssh-arcfour-fixes-02. The improves the cipher's
>     resistance to a number of attacks by discarding early keystream
>     output.
> 
>   - Increase the default size of new RSA/DSA keys generated by
>     ssh-keygen from 1024 to 2048 bits.
> 
>   - Many bugfixes and improvements to connection multiplexing,
>     including:
> 
>     - Added ControlMaster=auto/autoask options to support opportunistic
>       multiplexing (see the ssh_config(5) manpage for details).
> 
>     - The client will now gracefully fallback to starting a new TCP
>       connection if it cannot connect to a specified multiplexing
>       control socket
> 
>     - Added %h (target hostname), %p (target port) and %r (remote
>       username) expansion sequences to ControlPath. Also allow
>       ControlPath=none to disable connection multiplexing.
> 
>     - Implemented support for X11 and agent forwarding over multiplexed
>       connections. Because of protocol limitations, the slave
>       connections inherit the master's DISPLAY and SSH_AUTH_SOCK rather
>       than distinctly forwarding their own.
> 
>   - The following bugs from http://bugzilla.mindrot.org/ were closed:
> 
>      #1025 - Correctly handle disabled special character in ttymodes
>      #1054 - Don't terminate connection on getpeername() failure
>      #1046 - AIX 5.3 Garbage on Login
>      #623  - Don't use $HOME in manpages
>      #829  - Don't allocate a tty if -n option is set
>      #471  - Misleading error message if /dev/tty perms wrong
>      #1033 - Fix compile-time warnings
> 
>   - Lots of other improvements and fixes. Please refer to the ChangeLog
>     for details
> 
> Thanks to everyone who has contributed patches, problem or test reports.
> 
> Regards,
> Damien Miller


Damien,  BSD/OS 4.3.1 and FreeBSD 4.X running current Zlib and
Opensll 0.9.8a are all doing fine thank you.

-- 
Member - Liberal International	
This is doctor at nl2k.ab.ca	Ici doctor at nl2k.ab.ca
God Queen and country! Beware Anti-Christ rising!
Better to serve in Heaven that to Rule in Hell.



From dtucker at zip.com.au  Tue Aug 23 23:04:11 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 23 Aug 2005 23:04:11 +1000
Subject: Call for release testing
In-Reply-To: <3B660B4ACB06BE488E3938F95115E4DE3D26FE@IMCSRV4.MITRE.ORG>
References: <3B660B4ACB06BE488E3938F95115E4DE3D26FE@IMCSRV4.MITRE.ORG>
Message-ID: <430B1ECB.1030608@zip.com.au>

Knox,William R. wrote:
> Test on Solaris 8 failed with the below output:
[...]
> Built like so:
> ./configure --without-zlib-version-check --with-tcp-wrappers --with-pam

Could you please run the test with "set -x"?  The easiest way is to add
"set -x" at the start of test-exec.sh then rerun the test:

$ make tests LTESTS=multiplex TEST_SSH_TRACE=yes

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



From dtucker at zip.com.au  Tue Aug 23 23:33:54 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 23 Aug 2005 23:33:54 +1000
Subject: Call for release testing
In-Reply-To: <20050823122443.GQ17452@calimero.vinschen.de>
References: <4309ABBD.8030609@mindrot.org>	<20050823112814.GM17452@calimero.vinschen.de>	<430B0FB4.3010807@zip.com.au>
	<20050823122443.GQ17452@calimero.vinschen.de>
Message-ID: <430B25C2.3040604@zip.com.au>

Corinna Vinschen wrote:
> On Aug 23 21:59, Darren Tucker wrote:
>>Something like this ought to work too (untested):
>>
>>case "$SSHD" in
>>/*) ;;
>>*) SSHD=`which sshd` ;;
>>esac
> 
> Looks good to me.

OK, applied thanks.

(I even tested it first :-)

-- 
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  Wed Aug 24 00:18:28 2005
From: WKNOX at mitre.org (Knox,William R.)
Date: Tue, 23 Aug 2005 10:18:28 -0400
Subject: Call for release testing
Message-ID: <3B660B4ACB06BE488E3938F95115E4DE3D27C8@IMCSRV4.MITRE.ORG>

OK, it appears as though it ran fine that time. Added set -x as the
first line of the test-exec.sh file and ran the command as detailed
below. Output is attached. A subsequent run of the entire test after
removing the set -x entry also turned up no errors. I don't know whether
to be pleased or disappointed (I hate unreproducible errors). I've also
run the make send-survey - let me know if you want any information from
that.

For now, I guess Solaris 8 is a pass. Let me know if you want any more
information.

                 Bill Knox
                 Lead Operating Systems Programmer/Analyst
                 The MITRE Corporation 
-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: Tuesday, August 23, 2005 9:04 AM
To: Knox,William R.
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Call for release testing

Knox,William R. wrote:
> Test on Solaris 8 failed with the below output:
[...]
> Built like so:
> ./configure --without-zlib-version-check --with-tcp-wrappers
--with-pam

Could you please run the test with "set -x"?  The easiest way is to add
"set -x" at the start of test-exec.sh then rerun the test:

$ make tests LTESTS=multiplex TEST_SSH_TRACE=yes

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

From dtucker at zip.com.au  Wed Aug 24 00:32:22 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 24 Aug 2005 00:32:22 +1000
Subject: Call for release testing
In-Reply-To: <3B660B4ACB06BE488E3938F95115E4DE3D27C8@IMCSRV4.MITRE.ORG>
References: <3B660B4ACB06BE488E3938F95115E4DE3D27C8@IMCSRV4.MITRE.ORG>
Message-ID: <20050823143222.GA8232@gate.dodgy.net.au>

On Tue, Aug 23, 2005 at 10:18:28AM -0400, Knox,William R. wrote:
> OK, it appears as though it ran fine that time. Added set -x as the
> first line of the test-exec.sh file and ran the command as detailed
> below. Output is attached. A subsequent run of the entire test after
> removing the set -x entry also turned up no errors. I don't know whether
> to be pleased or disappointed (I hate unreproducible errors).

Me too.  Unfortunately, it's not entirely avoidable for our regress tests
since some rely on being able to establish listeners on various ports.  If
you have something else on the box that's busying out ephemeral ports
(especially the 3000-4250 range) then there's a chance the two will collide.

Sometimes these are obvious, but the source of yours isn't in the first
lot of output you were able to capture.

(Yeah, they could check the ports first, but that's a) system dependant
and b) racy anyway.)

For what it's worth, I was unable to reproduce any errors on Solaris 8
either, although with slightly different configure options.

> I've also
> run the make send-survey - let me know if you want any information from
> that.
> 
> For now, I guess Solaris 8 is a pass. Let me know if you want any more
> information.

Thanks for those.

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



From cmadams at hiwaay.net  Wed Aug 24 02:07:47 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 23 Aug 2005 11:07:47 -0500
Subject: Call for release testing
In-Reply-To: <4309ABBD.8030609@mindrot.org>
Message-ID: <20050823160747.GF694222@hiwaay.net>

Once upon a time, Damien Miller <djm at mindrot.org> said:
> Please test! Running the regression tests supplied with Portable does
> not require installation and is a simply:
> 
> $ ./configure && make tests

Tru64 passes all tests except for skipped tests:

   run test agent-getpeereid.sh ...
   skipped (not supported on this platform)

Tru64 doesn't have getpeereid.

   run test agent-ptrace.sh ...
   skipped (not supported on this platform)

I don't think there's a way to disable ptrace on Tru64.

   run test dynamic-forward.sh ...
   skipped (no suitable ProxyCommand found)

I'll look at installing the mentioned program for this test.

   run test multiplex.sh ...
   skipped (not supported on this platform)

It looks like the multiplex.sh test checks for DISABLE_FD_PASSING and
skips the test if it is defined, but I don't see why (it doesn't look
like the mux code checks DISABLE_FD_PASSING).

The only reason DISABLE_FD_PASSING is set on my system is because it is
Tru64 with SIA (which can't handle privsep).  FD passing works fine;
maybe disabling privsep should depend on a different option?

Anyway, commenting out the DISABLE_FD_PASSING check in multiplex.sh
allows it to run that test, and it then passes.

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



From grunk at pestilenz.org  Wed Aug 24 01:10:26 2005
From: grunk at pestilenz.org (Alexander von Gernler)
Date: Tue, 23 Aug 2005 17:10:26 +0200
Subject: Mirror site ftp.plig.org out of date
In-Reply-To: <Pine.LNX.4.63.0507311832090.1208@youngs.future-i.net>
References: <Pine.LNX.4.63.0507311832090.1208@youngs.future-i.net>
Message-ID: <20050823151026.GJ26204@pestilenz.org>

Hey Ed,

thanks for notifying us about that mirror. As I see that you CC:ed
their webmaster, did you get response from them?

* Ed Avis <ed at membled.com> [2005-07-31 19:34]:
> The mirror site ftp.plig.org is out of date, for example 
> <ftp://ftp.plig.org/pub/OpenBSD/OpenSSH/portable/snapshot/> stops in 
> 2005-03-07 while the same directory on the master site has recent 
> files.

The mirror seems to have at least two issues:
- the one mentioned by you
- they have a ``pegasos'' directory in snapshots, which we don't ship
  anymore. Mirroring with the rsync ``--delete'' option would save them
  from that.

Apart from that, I see a distfiles/ directory, perhaps mirrored from the
main site? If so, this is strongly discouraged. If built by
mirroring-ports(7), it is completely OK.

Their mirror is not that bad otherwise, so I will wait for reactions to
this for a while before doing changes relating to that.

Greets,
-- 
Alexander "grunk" von Gernler       PGP key 0xEBC27515
http://www.de.openbsd.org/ -- Free, functional, secure



From kmack at sgi.sk.ca  Wed Aug 24 07:17:39 2005
From: kmack at sgi.sk.ca (Kevin Mack)
Date: Tue, 23 Aug 2005 15:17:39 -0600
Subject: [openssh-unix-announce] Call for release testing
Message-ID: <s30b3e38.062@gwmail.sgi.sk.ca>

Successful build on Sparc Solaris 8, gcc 3.4.4
 
 
>>>Damien Miller <djm at mindrot.org> 08/22 10:41 am >>> 
Hi, 
 
We would like to make one of our periodic releases shortly, so once 
again we are asking for readers of this list (or anyone else) to 
download and test a CVS snapshot of OpenSSH on your favourite 
platforms. 
 
The OpenBSD version is available in CVS HEAD: 
http://www.openbsd.org/anoncvs.html 
 
Portable snapshots are available the mirrors listed at 
http://www.openssh.com/portable.html#ftp in the snapshots/ 
subdirectory 
 
Please test! Running the regression tests supplied with Portable does 
not require installation and is a simply: 
 
$ ./configure && make tests 
 
Testing on suitable non-production systems is also appreciated. Please 
send reports of success or failure to openssh-unix-dev at mindrot.org. 
 
Also, OpenSSH Portable has a (completely voluntary) configuration 
survey. It will collect information about the platform and the 
options OpenSSH was configured with and mail it to an archive. We 
tried to be careful not to collect anything that might be considered 
sensitive, however if anyone has any issues with the data collected 
then please let us know). 
 
The raw data will be available only to the development team, however 
we may publish summary data at some point in the future. This data 
will help us to better support your platforms. 
 
You can view the data that is collected by running "make survey" and 
looking at the file "survey" in the build dir. The data is not sent 
until you explicitly request it ("make send-survey"). If you have any 
doubts at all then ask us (or just don't send it). 
 
Some of the changes in the coming release include: 
 
 - Add a new compression method that delays the start of zlib 
   compression until the user has been authenticated successfully. The 
   new method "Compression=delayed" is on by default in the server. 
   This eliminates the risk of another zlib vulnerability leading to 
   a compromise of the server by a user without authentication 
   credentials. 
 
   NB. Older OpenSSH (<3.5) version have a bug which will cause them 
   to refuse to connect to any server that does not offer compression 
   when the client has compression requested. Since the new "delayed" 
   server mode isn't supported by these older clients, they will 
   refuse to connect to a new server unless compression is disabled 
   (on the client end) or the original compression method is enabled 
   on the server ("Compression=yes" in sshd_config) 
 
 - Another round of proactive changes for signed vs unsigned integer 
   bugs has been completed, including changing the atomicio() API to 
   encourage safer programming. As a result of these changes, OpenSSH 
   is now "gcc -Wsign-compare" clean on most platforms. 
 
 - Added support for the improved arcfour cipher modes from 
   draft-harris-ssh-arcfour-fixes-02. The improves the cipher's 
   resistance to a number of attacks by discarding early keystream 
   output. 
 
 - Increase the default size of new RSA/DSA keys generated by 
   ssh-keygen from 1024 to 2048 bits. 
 
 - Many bugfixes and improvements to connection multiplexing, 
   including: 
 
   - Added ControlMaster=auto/autoask options to support opportunistic 
     multiplexing (see the ssh_config(5) manpage for details). 
 
   - The client will now gracefully fallback to starting a new TCP 
     connection if it cannot connect to a specified multiplexing 
     control socket 
 
   - Added %h (target hostname), %p (target port) and %r (remote 
     username) expansion sequences to ControlPath. Also allow 
     ControlPath=none to disable connection multiplexing. 
 
   - Implemented support for X11 and agent forwarding over multiplexed 
     connections. Because of protocol limitations, the slave 
     connections inherit the master's DISPLAY and SSH_AUTH_SOCK rather 
     than distinctly forwarding their own. 
 
 - The following bugs from http://bugzilla.mindrot.org/ were closed: 
 
    #1025 - Correctly handle disabled special character in ttymodes 
    #1054 - Don't terminate connection on getpeername() failure 
    #1046 - AIX 5.3 Garbage on Login 
    #623  - Don't use $HOME in manpages 
    #829  - Don't allocate a tty if -n option is set 
    #471  - Misleading error message if /dev/tty perms wrong 
    #1033 - Fix compile-time warnings 
 
 - Lots of other improvements and fixes. Please refer to the ChangeLog 
   for details 
 
Thanks to everyone who has contributed patches, problem or test reports.

 
Regards, 
Damien Miller 
 
 
openssh-unix-announce mailing list 
openssh-unix-announce at mindrot.org 
http://www.mindrot.org/mailman/listinfo/openssh-unix-announce 
************DISCLAIMER*************
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you are not the named addressee, please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that using, disclosing, copying or distributing the contents of this information is strictly prohibited.
************DISCLAIMER*************



From al at starfishzone.com  Wed Aug 24 08:39:37 2005
From: al at starfishzone.com (Andrew)
Date: Tue, 23 Aug 2005 23:39:37 +0100
Subject: Success with openssh-SNAP-20050822
Message-ID: <6.0.3.0.2.20050823233722.03106eb0@mail.starfishzone.com>

Success on FreeBSD 5.2.1
	+ zlib-1.2.3
	+ openssl-0.98

Survey sent.



From xuesongchen363 at msn.com  Wed Aug 24 17:51:28 2005
From: xuesongchen363 at msn.com (xuesong chen)
Date: Wed, 24 Aug 2005 15:51:28 +0800
Subject: porting to threadx
Message-ID: <BAY5-F5237EC3F40471062CCF288EA80@phx.gbl>

hello guys,

I want to port the openssh to ThreadX-an embedded os.
Is there anyone who have experiences with ThreadX porting or any document 
that can help me know
what kind of things I can do?

Thanks in advance.

Arhtur




From ed at membled.com  Wed Aug 24 23:18:59 2005
From: ed at membled.com (Ed Avis)
Date: Wed, 24 Aug 2005 14:18:59 +0100 (BST)
Subject: Mirror site ftp.plig.org out of date
In-Reply-To: <20050823151026.GJ26204@pestilenz.org>
References: <Pine.LNX.4.63.0507311832090.1208@youngs.future-i.net>
	<20050823151026.GJ26204@pestilenz.org>
Message-ID: <Pine.LNX.4.63.0508241418270.14291@youngs.future-i.net>

On Tue, 23 Aug 2005, Alexander von Gernler wrote:

>thanks for notifying us about that mirror. As I see that you CC:ed 
>their webmaster, did you get response from them?

No I don't think so.

-- 
Ed Avis <ed at membled.com>



From rapier at psc.edu  Thu Aug 25 01:32:23 2005
From: rapier at psc.edu (Chris Rapier)
Date: Wed, 24 Aug 2005 11:32:23 -0400
Subject: Test Failure on Mac OS X 10.4.2
Message-ID: <430C9307.8040900@psc.edu>

I was able to get it to compile but the tests are failing. When I run 
the test as root I get:
run test connect.sh ...
Connection closed by 127.0.0.1
ssh connect with protocol 1 failed
failed simple connect
make[1]: *** [t-exec] Error 1
make: *** [tests] Error 2

However, when I run as a normal user I got:
test remote exit status: proto 1 status 0
/Users/rapier/Desktop/sshtest/openssh/regress/test-exec.sh: line 24: 
14772 Bus error               ${SSH} -$p -F $OBJ/ssh_proxy -n otherhost 
exec sh -c \'"sleep 2; exec > /dev/null 2>&1; sleep 3; exit $s"\'
exit code (with sleep) mismatch for protocol 1: 138 != 0
test remote exit status: proto 1 status 1
test remote exit status: proto 1 status 4
Connection closed by UNKNOWN
exit code mismatch for protocol 1: 255 != 4
Connection closed by UNKNOWN
exit code (with sleep) mismatch for protocol 1: 255 != 4
test remote exit status: proto 1 status 5
test remote exit status: proto 1 status 44
Connection closed by UNKNOWN
exit code mismatch for protocol 1: 255 != 44
Connection closed by UNKNOWN
exit code (with sleep) mismatch for protocol 1: 255 != 44
test remote exit status: proto 2 status 0
test remote exit status: proto 2 status 1
test remote exit status: proto 2 status 4
test remote exit status: proto 2 status 5
test remote exit status: proto 2 status 44
failed remote exit status
make[1]: *** [t-exec] Error 1
make: *** [tests] Error 2

I just ran it again as a normal user and this time I got:
run test exit-status.sh ...
test remote exit status: proto 1 status 0
test remote exit status: proto 1 status 1
test remote exit status: proto 1 status 4
test remote exit status: proto 1 status 5
test remote exit status: proto 1 status 44
Connection closed by UNKNOWN
exit code (with sleep) mismatch for protocol 1: 255 != 44
test remote exit status: proto 2 status 0
test remote exit status: proto 2 status 1
test remote exit status: proto 2 status 4
test remote exit status: proto 2 status 5
test remote exit status: proto 2 status 44
failed remote exit status
make[1]: *** [t-exec] Error 1
make: *** [tests] Error 2

The difference being that the first time I had the native sshd enabled. 
I have no idea if that made a difference though.

I'm going to try rebuilding this in a 'cleaner' environment than the one 
I have installed on this laptop. I'll let people know how that works (as 
I would not be surprised if it really is just me).

Chris



From djm at mindrot.org  Thu Aug 25 09:40:48 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 25 Aug 2005 09:40:48 +1000 (EST)
Subject: Test Failure on Mac OS X 10.4.2
In-Reply-To: <430C9307.8040900@psc.edu>
References: <430C9307.8040900@psc.edu>
Message-ID: <Pine.BSO.4.63.0508250938330.11293@fuyu.mindrot.org>

On Wed, 24 Aug 2005, Chris Rapier wrote:

> I was able to get it to compile but the tests are failing. When I run
> the test as root I get:
> run test connect.sh ...
> Connection closed by 127.0.0.1
> ssh connect with protocol 1 failed
> failed simple connect
> make[1]: *** [t-exec] Error 1
> make: *** [tests] Error 2
>
> However, when I run as a normal user I got:
> test remote exit status: proto 1 status 0
> /Users/rapier/Desktop/sshtest/openssh/regress/test-exec.sh: line 24:
> 14772 Bus error               ${SSH} -$p -F $OBJ/ssh_proxy -n otherhost

That looks like something is severly hosed. Can you try adding 
"set -x" to the start of test-exec.sh to see where it is failing.

Then, try running the failing command under a debugger to see where it is 
crashing.

-d



From al at starfishzone.com  Thu Aug 25 17:49:45 2005
From: al at starfishzone.com (Andrew)
Date: Thu, 25 Aug 2005 08:49:45 +0100
Subject: No subject
Message-ID: <6.0.3.0.2.20050825084845.03bc6c70@mail.starfishzone.com>

Success on FreeBSD 4.7
	+ zlib-1.2.3
	+ openssl-0.98

Survey sent. 



From rapier at psc.edu  Fri Aug 26 00:41:25 2005
From: rapier at psc.edu (Chris Rapier)
Date: Thu, 25 Aug 2005 10:41:25 -0400
Subject: Any comments on ietf secsh draft?
Message-ID: <430DD895.3080202@psc.edu>

http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-05.txt

So what do people think of this?



From jau at mawit.com  Fri Aug 26 07:22:26 2005
From: jau at mawit.com (Jukka A. Ukkonen)
Date: Fri, 26 Aug 2005 00:22:26 +0300
Subject: A new extension/subsystem for openssh???
Message-ID: <430E3692.30605@mawit.com>


	Howdy,

	A while ago it occurred to me that adding a little "glue"
	subsystem one could make life much easier for all those
	people who often need to combine ssh & rsync to update or
	mirror something efficiently and securely over the net.

	So, I came up with three little programs
	- ssync-server	- an sshd subsystem running rsync in server mode
	- ssync-client	- an ssh wrapper that gets ssh options right
	- ssync		- an rsync wrapper which launches rsync -e ssync-client

	The latter two could probably be combined in one ssync binary,
	but it seemed to be easier to manage the argument lists properly
	when done separately like this.
	If the openssh team is willing to distribute these as part of
	the openssh package, I could donate them.
	With just a few lines of extra code one gets full the combined
	power of two excellent packages which are both already so big
	that combining them for real would be approaching brain damage
	(or should I say mind rot in this case).

	Compared to running "rsync -e ssh yadda yadda" manually from
	the command line ssync subsystem gets rid of an unnecessary
	shell process on the server side and avoids some fumbling
	with the command line options on the clients side.

	This may be underlining the obvious, but still... One uses ssync
	exactly the same as plain rsync but without the complication
	of getting the remote shell program right. In fact ssync simply
	ignores any "-e rshprog" options.

	I hope you like the idea.

	// jau



From djm at mindrot.org  Fri Aug 26 08:21:50 2005
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Aug 2005 08:21:50 +1000
Subject: Any comments on ietf secsh draft?
In-Reply-To: <430DD895.3080202@psc.edu>
References: <430DD895.3080202@psc.edu>
Message-ID: <430E447E.7020508@mindrot.org>

Chris Rapier wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-05.txt
> 
> So what do people think of this?

We have supported these since May 2003.

-d



From rapier at psc.edu  Fri Aug 26 11:03:19 2005
From: rapier at psc.edu (Chris Rapier)
Date: Thu, 25 Aug 2005 21:03:19 -0400
Subject: Any comments on ietf secsh draft?
In-Reply-To: <430E447E.7020508@mindrot.org>
References: <430DD895.3080202@psc.edu> <430E447E.7020508@mindrot.org>
Message-ID: <430E6A57.6060507@psc.edu>

That was my impression but it nice to have confirmation. A collegue 
pointed these out to me and I wasn't sure if the *-ctr and the midstream 
rekeys you had followed this or not.

Thanks for the clue.

Damien Miller wrote:
> Chris Rapier wrote:
> 
>>http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-05.txt
>>
>>So what do people think of this?
> 
> 
> We have supported these since May 2003.
> 
> -d
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From plattner at inf.ethz.ch  Sat Aug 27 00:18:37 2005
From: plattner at inf.ethz.ch (Christian Plattner)
Date: Fri, 26 Aug 2005 16:18:37 +0200
Subject: Problematic issue with the x11_create_display_inet method in channel.c
Message-ID: <430F24BD.1070302@inf.ethz.ch>

Hi,

I am currently implementing X11 forwarding for our Java SSH2 library
(http://www.ganymed.ethz.ch/ssh2), and encountered a problem with the 
automatic display number selection
in the x11_create_display_inet() method in channel.c.

With my testcode I am able to get the OpenSSH daemon in a state where a 
following client connection, e.g., an OpenSSH client, is sometimes not 
able to properly use X11 forwarding.

I have no idea if you consider this to be relevant at all, but I would 
be very happy if one of the developers could take a look at it.

Thanks,
- Christian

============ DETAILED DESCRIPTION =====================================

Seen on: OpenSSH 4.1 on Fedora Core 4 (2.6.11-1.35_FC3smp).

Summary:

When doing X11 forwarding, OpenSSH sometimes attaches itself to a port 
(e.g., 6010) when there is still a connection to 127.0.0.1:6010 (in 
state TIME_WAIT). As a consequence, even though OpenSSH's bind operation 
to ::1:6010 goes well, X11 applications are not able to connect to 
127.0.0.1:6010.

Details:

Here is a part of netstat output if everything is fine (OpenSSH is ready 
to forward X11 connections)

Proto Recv-Q Send-Q Local Address               Foreign Address 
      State
tcp        0      0 127.0.0.1:6010              0.0.0.0:* 
     LISTEN
tcp        0      0 ::1:6010                    :::* 
     LISTEN

Here is a part of netstat output when things went wrong (OpenSSH thinks 
it is ready to forward X11 connections =)

Proto Recv-Q Send-Q Local Address               Foreign Address 
      State
tcp        0      0 127.0.0.1:6010              127.0.0.1:54806 
     TIME_WAIT
tcp        0      0 ::1:6010                    :::* 
     LISTEN

How did that happen? Well, the TIME_WAIT entry came from a previous (now 
closed) ssh connection that was using X11 forwarding, i.e., before the 
current ssh connection was opened, the netstat output looked as follows:

Proto Recv-Q Send-Q Local Address               Foreign Address 
      State
tcp        0      0 127.0.0.1:6010              127.0.0.1:54806 
     TIME_WAIT

I managed to produce such an entry by simply closing the ssh connection 
while X11 forwarding was in use (and one X11 application was active).






From djm at mindrot.org  Sat Aug 27 01:03:32 2005
From: djm at mindrot.org (Damien Miller)
Date: Sat, 27 Aug 2005 01:03:32 +1000
Subject: Problematic issue with the x11_create_display_inet method in
	channel.c
In-Reply-To: <430F24BD.1070302@inf.ethz.ch>
References: <430F24BD.1070302@inf.ethz.ch>
Message-ID: <430F2F44.2050007@mindrot.org>

Christian Plattner wrote:
> Hi,
> 
> I am currently implementing X11 forwarding for our Java SSH2 library
> (http://www.ganymed.ethz.ch/ssh2), and encountered a problem with the 
> automatic display number selection
> in the x11_create_display_inet() method in channel.c.

Could you try one of the snapshot releases[1]? I fixed quite a few bugs
in and around that function since 4.1.

If you can recreate the bug with a snapshot, then please file a bug
report at http://bugzilla.mindrot.org so it doesn't get lost.

-d

[1] Snapshots can be found in the snapshots/ subdirectory on most of the
mirrors: http://www.openssh.com/portable.html#mirrors



From arms at sco.com  Sat Aug 27 01:17:12 2005
From: arms at sco.com (Ahsan Rashid)
Date: Fri, 26 Aug 2005 11:17:12 -0400 (EDT)
Subject: Patch for UnixWare 7
Message-ID: <Pine.UW2.4.63.0508261111080.17599@gold.nj.sco.com>

Hi Openssh developers,

Attached please find patch to support long passwords (> 8-char) on 
UnixWare 7.

Thanks,
Ahsan

--
Ahsan Rashid
Escalations Research Group		arms at sco.com
The SCO Group Inc., Murray Hill, NJ	908 790 2279
-------------- next part --------------
--- openssh/CREDITS.old	2004-05-26 16:59:31.000000000 -0700
+++ openssh/CREDITS	2005-08-25 13:53:08.602447006 -0700
@@ -3,6 +3,7 @@
 Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos,
 Theo de Raadt, and Dug Song - Creators of OpenSSH
 
+Ahsan Rashid <arms at sco.com> - UnixWare long passwords
 Alain St-Denis <Alain.St-Denis at ec.gc.ca> - Irix fix
 Alexandre Oliva <oliva at lsd.ic.unicamp.br> - AIX fixes
 Andre Lucas <andre at ae-35.com> - new login code, many fixes
@@ -32,6 +33,7 @@
 David Hesprich <darkgrue at gue-tech.org> - Configure fixes
 David Rankin <drankin at bohemians.lexington.ky.us> - libwrap, AIX, NetBSD fixes
 Dag-Erling Sm?rgrav <des at freebsd.org> - Challenge-Response PAM code.
+Dhiraj Gulati <dgulati at sco.com> - UnixWare long passwords
 Ed Eden <ede370 at stl.rural.usda.gov> - configure fixes
 Garrick James <garrick at james.net> - configure fixes
 Gary E. Miller <gem at rellim.com> - SCO support
--- openssh/LICENCE.old	2005-08-15 12:49:38.213360001 -0700
+++ openssh/LICENCE	2005-08-25 13:55:28.242447017 -0700
@@ -204,6 +204,7 @@
 	William Jones
 	Darren Tucker
 	Sun Microsystems
+	The SCO Group
 
      * Redistribution and use in source and binary forms, with or without
      * modification, are permitted provided that the following conditions
--- openssh/auth.c.old	2005-06-17 08:29:12.595619001 -0700
+++ openssh/auth.c	2005-08-25 21:15:06.270527016 -0700
@@ -97,7 +97,11 @@
 	/* grab passwd field for locked account check */
 #ifdef USE_SHADOW
 	if (spw != NULL)
+#ifdef HAVE_LIBIAF
+		passwd = get_iaf_password(pw);
+#else
 		passwd = spw->sp_pwdp;
+#endif /* HAVE_LIBIAF */
 #else
 	passwd = pw->pw_passwd;
 #endif
--- openssh/configure.ac.old	2005-08-23 17:11:26.000000000 -0700
+++ openssh/configure.ac	2005-08-24 16:51:30.297680013 -0700
@@ -446,6 +446,8 @@
 	;;
 # UnixWare 7.x, OpenUNIX 8
 *-*-sysv5*)
+	check_for_libcrypt_later=1
+	AC_DEFINE(UNIXWARE_LONG_PASSWORDS, 1, [Support passwords > 8 chars])
 	AC_DEFINE(USE_PIPES)
 	AC_DEFINE(SETEUID_BREAKS_SETUID)
 	AC_DEFINE(BROKEN_SETREUID)
@@ -643,6 +645,7 @@
 	getopt.h \
 	glob.h \
 	ia.h \
+	iaf.h \
 	lastlog.h \
 	limits.h \
 	login.h \
@@ -1721,6 +1724,7 @@
 	AC_CHECK_LIB(crypt, crypt, LIBS="$LIBS -lcrypt")
 fi
 
+AC_CHECK_LIB(iaf, ia_openinfo)
 
 ### Configure cryptographic random number support
 
--- openssh/defines.h.old	2005-08-23 17:18:21.000000000 -0700
+++ openssh/defines.h	2005-08-24 16:51:30.367680004 -0700
@@ -688,6 +688,10 @@
 # define CUSTOM_SYS_AUTH_PASSWD 1
 #endif
 
+#ifdef UNIXWARE_LONG_PASSWORDS
+# define CUSTOM_SYS_AUTH_PASSWD 1
+#endif
+
 /* HP-UX 11.11 */
 #ifdef BTMP_FILE
 # define _PATH_BTMP BTMP_FILE
--- openssh/includes.h.old	2005-08-23 11:02:30.213506000 -0700
+++ openssh/includes.h	2005-08-24 16:51:30.387680002 -0700
@@ -169,6 +169,10 @@
 # include <ia.h>
 #endif
 
+#ifdef HAVE_IAF_H
+# include <iaf.h>
+#endif
+
 #ifdef HAVE_TMPDIR_H
 # include <tmpdir.h>
 #endif
--- openssh/openbsd-compat/Makefile.in.old	2005-06-13 15:36:16.322790000 -0700
+++ openssh/openbsd-compat/Makefile.in	2005-08-24 16:51:30.417680000 -0700
@@ -20,7 +20,7 @@
 
 COMPAT=bsd-arc4random.o bsd-closefrom.o bsd-cray.o bsd-cygwin_util.o bsd-getpeereid.o bsd-misc.o bsd-nextstep.o bsd-openpty.o bsd-snprintf.o bsd-waitpid.o fake-rfc2553.o openssl-compat.o xmmap.o xcrypt.o
 
-PORTS=port-irix.o port-aix.o
+PORTS=port-irix.o port-aix.o port-uw.o
 
 .c.o:
 	$(CC) $(CFLAGS) $(CPPFLAGS) -c $<
--- openssh/openbsd-compat/openbsd-compat.h.old	2005-06-17 08:29:17.605619000 -0700
+++ openssh/openbsd-compat/openbsd-compat.h	2005-08-25 20:51:19.325407005 -0700
@@ -173,5 +173,6 @@
 #include "bsd-cygwin_util.h"
 #include "port-irix.h"
 #include "port-aix.h"
+#include "port-uw.h"
 
 #endif /* _OPENBSD_COMPAT_H */
--- /dev/null	2005-08-25 21:20:32.000000000 -0700
+++ openssh/openbsd-compat/port-uw.c	2005-08-25 21:06:16.925487004 -0700
@@ -0,0 +1,116 @@
+/*
+ * Copyright (c) 2005 The SCO Group. All rights reserved.
+ * Copyright (c) 2005 Tim Rice. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "includes.h"
+
+#ifdef UNIXWARE_LONG_PASSWORDS
+#ifdef HAVE_CRYPT_H
+#include <crypt.h>
+#endif
+#include "packet.h"
+#include "buffer.h"
+#include "log.h"
+#include "servconf.h"
+#include "auth.h"
+#include "auth-options.h"
+
+int nischeck(char *);
+
+int
+sys_auth_passwd(Authctxt *authctxt, const char *password)
+{
+	struct passwd *pw = authctxt->pw;
+	char *encrypted_password;
+	char *salt;
+
+	/* Just use the supplied fake password if authctxt is invalid */
+	char *pw_password = authctxt->valid ? shadow_pw(pw) : pw->pw_passwd;
+
+	/* Check for users with no password. */
+	if (strcmp(pw_password, "") == 0 && strcmp(password, "") == 0)
+		return (1);
+
+	salt = (pw_password[0] && pw_password[1]) ? pw_password : "xx";
+	if (nischeck(pw->pw_name))
+		return(strcmp(crypt(password, salt), pw_password) == 0);
+	else
+		return(strcmp(bigcrypt(password, salt), pw_password) == 0);
+}
+
+int
+nischeck(char *namep)
+{
+	char password_file[] = "/etc/passwd";
+	FILE *fd;
+	struct passwd *ent = NULL;
+
+	if ((fd = fopen (password_file, "r")) == NULL) {
+		/*
+		 * If the passwd file has dissapeared we are in a bad state.
+		 * However, returning 0 will send us back throught the
+		 * authentication scheme that has checked the ia database for
+		 * passwords earlier.
+		 */
+		return(0);
+	}
+
+	/*
+	 * fgetpwent() only reads from password file, so we know for certain
+	 * that the user is local.
+	 */
+	while (ent = fgetpwent(fd)) {
+		if (strcmp (ent->pw_name, namep) == 0) {
+			/* Local user */
+			fclose (fd);
+			return(0);
+		}
+	}
+
+	fclose (fd);
+	return (1);
+}
+
+#endif /* UNIXWARE_LONG_PASSWORDS */
+
+#ifdef HAVE_LIBIAF
+char *
+get_iaf_password(struct passwd *pw)
+{
+	char *pw_password = NULL;
+
+	uinfo_t uinfo;
+	if(!ia_openinfo(pw->pw_name,&uinfo))
+	{
+		ia_get_logpwd(uinfo, &pw_password);
+		if(pw_password == NULL)
+			fatal("Unable to get the shadow passwd");
+		ia_closeinfo(uinfo);
+	 	return pw_password;
+	}
+	else
+		fatal("Unable to open the shadow passwd file");
+}
+#endif /* HAVE_LIBIAF */
+
--- /dev/null	2005-08-25 21:20:32.000000000 -0700
+++ openssh/openbsd-compat/port-uw.h	2005-08-25 21:14:30.080527002 -0700
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2005 Tim Rice.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "includes.h"
+
+#ifdef HAVE_LIBIAF
+char * get_iaf_password(struct passwd *pw);
+#endif /* HAVE_LIBIAF */
+
--- openssh/openbsd-compat/xcrypt.c.old	2005-04-23 17:58:46.364982000 -0700
+++ openssh/openbsd-compat/xcrypt.c	2005-08-25 21:14:50.830527003 -0700
@@ -91,7 +91,11 @@
 	struct spwd *spw = getspnam(pw->pw_name);
 
 	if (spw != NULL)
+#ifdef HAVE_LIBIAF
+		pw_password = get_iaf_password(pw);
+#else
 		pw_password = spw->sp_pwdp;
+#endif /* HAVE_LIBIAF */
 # endif
 # if defined(HAVE_GETPWANAM) && !defined(DISABLE_SHADOW)
 	struct passwd_adjunct *spw;
--- openssh/session.c.old	2005-07-28 17:41:12.124914028 -0700
+++ openssh/session.c	2005-08-24 16:51:30.507680006 -0700
@@ -1334,6 +1334,11 @@
 # ifdef _AIX
 		aix_usrinfo(pw);
 # endif /* _AIX */
+# ifdef HAVE_LIBIAF
+		if (set_id(pw->pw_name) != 0) {
+			exit(1);
+		}
+# endif
 		/* Permanently switch to the desired uid. */
 		permanently_set_uid(pw);
 #endif

From letsgonhlcanes at yahoo.com  Tue Aug 30 02:47:07 2005
From: letsgonhlcanes at yahoo.com (Lets Go Canes)
Date: Mon, 29 Aug 2005 09:47:07 -0700 (PDT)
Subject: Conflict between LDAP and Privilege Separation?
Message-ID: <20050829164707.74674.qmail@web50703.mail.yahoo.com>

Hi all.

OpenSSH_4.1p1, OpenSSL 0.9.7g 11 Apr 2005 on Solaris 8 using host-based
authentication.

With "PrivilegeSeparation yes" and "UsePAM no" everything works as
desired.  If I enable PAM, I am able to connect, but just before it
gives me a shell, it disconnects.  If I leave PAM enabled and disable
PrivilegeSeparation, it works.

Is this a current limitation, or is there something I can try?


--------------
Lets Go Canes!


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 



From tim at multitalents.net  Tue Aug 30 04:28:39 2005
From: tim at multitalents.net (Tim Rice)
Date: Mon, 29 Aug 2005 11:28:39 -0700 (PDT)
Subject: Conflict between LDAP and Privilege Separation?
In-Reply-To: <20050829164707.74674.qmail@web50703.mail.yahoo.com>
References: <20050829164707.74674.qmail@web50703.mail.yahoo.com>
Message-ID: <Pine.UW2.4.63.0508291122290.6596@server01.int.multitalents.net>

On Mon, 29 Aug 2005, Lets Go Canes wrote:

> Hi all.
> 
> OpenSSH_4.1p1, OpenSSL 0.9.7g 11 Apr 2005 on Solaris 8 using host-based
> authentication.
> 
> With "PrivilegeSeparation yes" and "UsePAM no" everything works as
> desired.  If I enable PAM, I am able to connect, but just before it
> gives me a shell, it disconnects.  If I leave PAM enabled and disable
> PrivilegeSeparation, it works.
> 
> Is this a current limitation, or is there something I can try?

Must be a local problem.
I'm not seeing any problem here with host-based auth.
I tried both local account and LDAP account.
....
tim at sun1 1% id
uid=31(tim) gid=85(trr)
tim at sun1 2% grep ":31:" /etc/passwd
tim at sun1 3% grep UsePAM /etc/ssh/sshd_config
UsePAM yes
tim at sun1 4% uname -r
5.8
tim at sun1 5% ssh -V
OpenSSH_4.1p1, OpenSSL 0.9.7g 11 Apr 2005
tim at sun1 6% ps -fu tim
     UID   PID  PPID  C    STIME TTY      TIME CMD
     tim   504   502  0 11:20:02 ?        0:00 /opt/mt/openssh/sbin/sshd -R
     tim   506   504  0 11:20:02 pts/3    0:00 -csh
tim at sun1 7% grep PrivilegeSeparation /etc/ssh/sshd_config
#UsePrivilegeSeparation yes
....

Try running sshd -ddd and see if the debug output sheds any light.
 
> 
> --------------
> Lets Go Canes!
> 

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




From letsgonhlcanes at yahoo.com  Tue Aug 30 06:57:22 2005
From: letsgonhlcanes at yahoo.com (Lets Go Canes)
Date: Mon, 29 Aug 2005 13:57:22 -0700 (PDT)
Subject: Conflict between LDAP and Privilege Separation?
Message-ID: <20050829205722.67330.qmail@web50712.mail.yahoo.com>

Hi all.

> Try running sshd -ddd and see if the debug output sheds any light.

Thank you for the suggestion.

The sshd side appears to just see the child go away:

debug3: mm_answer_pty: tty /dev/pts/5 ptyfd 9
debug2: monitor_read: 25 used once, disabling now
debug3: mm_request_receive entering
debug1: PAM: setting PAM_TTY to "/dev/pts/5"
debug2: fd 4 setting TCP_NODELAY
debug1: Entering interactive session.
debug1: Received SIGCHLD.
debug2: fd 10 setting O_NONBLOCK
debug3: fd 12 is O_NONBLOCK
debug2: fd 14 setting O_NONBLOCK
debug2: fd 15 setting O_NONBLOCK
debug1: server_init_dispatch_13
debug1: server_init_dispatch_15
debug1: End of interactive session; stdin 0, stdout (read 102, sent
102), stderr
 0 bytes.
debug1: Command exited with status 254.
debug1: Received exit confirmation.
[...]

The client side appears to be creating the session, but before it can
give a shell prompt, it dies:

[...]
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: fd 4 setting TCP_NODELAY
debug1: Requesting shell.
debug1: Entering interactive session.
Last login: Mon Aug 29 16:27:54 2005 from xyzzy.plugh.c
debug3: PAM session not opened, exiting
Connection to ssh-host closed.
debug1: Transferred: stdin 0, stdout 102, stderr 31 bytes in 0.0
seconds
debug1: Bytes per second: stdin 0.0, stdout 5185.8, stderr 1576.1
debug1: Exit status 254
[...]

Note the message:  debug3: PAM session not opened, exiting

I am also seeing in /var/adm/messages:

Aug 29 16:47:55 ssh-host sshd[26773]: [ID 776383 auth.error]
open_module: stat(/lib/security/pam_limits.so) failed: No such file or
directory
Aug 29 16:47:55 ssh-host sshd[26773]: [ID 487707 auth.error]
load_modules: can not open module /lib/security/pam_limits.so
Aug 29 16:47:55 ssh-host sshd[26773]: [ID 800047 auth.error] error:
PAM: pam_open_session(): Dlopen failure
Aug 29 16:47:55 ssh-host sshd[26773]: [ID 776383 auth.error]
open_module: stat(/lib/security/pam_nologin.so) failed: No such file or
directory
Aug 29 16:47:55 ssh-host sshd[26773]: [ID 487707 auth.error]
load_modules: can not open module /lib/security/pam_nologin.so

Note the "pam_open_session(): Dlopen failure"

I get the same behavior from multiple accounts (using different shells
and skeleton files).

I can work-around the problem by disabling either PAM and/or PrivSep
in sshd_config, but in my production environment PAM support will be
required, and PrivilegeSeparation is viewed as highly desirable.


--------------
Lets Go Canes!


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 



From tim at multitalents.net  Tue Aug 30 08:08:07 2005
From: tim at multitalents.net (Tim Rice)
Date: Mon, 29 Aug 2005 15:08:07 -0700 (PDT)
Subject: Conflict between LDAP and Privilege Separation?
In-Reply-To: <20050829205722.67330.qmail@web50712.mail.yahoo.com>
References: <20050829205722.67330.qmail@web50712.mail.yahoo.com>
Message-ID: <Pine.UW2.4.63.0508291504000.6596@server01.int.multitalents.net>

On Mon, 29 Aug 2005, Lets Go Canes wrote:

> Hi all.
> 
> > Try running sshd -ddd and see if the debug output sheds any light.
> 
> Thank you for the suggestion.
> 
> The sshd side appears to just see the child go away:
> 
[snip]
> Last login: Mon Aug 29 16:27:54 2005 from xyzzy.plugh.c
> debug3: PAM session not opened, exiting
> Connection to ssh-host closed.
> debug1: Transferred: stdin 0, stdout 102, stderr 31 bytes in 0.0
> seconds
> debug1: Bytes per second: stdin 0.0, stdout 5185.8, stderr 1576.1
> debug1: Exit status 254
> [...]
> 
> Note the message:  debug3: PAM session not opened, exiting
> 
> I am also seeing in /var/adm/messages:
> 
> Aug 29 16:47:55 ssh-host sshd[26773]: [ID 776383 auth.error]
> open_module: stat(/lib/security/pam_limits.so) failed: No such file or
> directory

Looks like a PAM configuration problem.

What does your /etc/pam.conf look like?

> Aug 29 16:47:55 ssh-host sshd[26773]: [ID 487707 auth.error]
> load_modules: can not open module /lib/security/pam_limits.so
> Aug 29 16:47:55 ssh-host sshd[26773]: [ID 800047 auth.error] error:
> PAM: pam_open_session(): Dlopen failure
> Aug 29 16:47:55 ssh-host sshd[26773]: [ID 776383 auth.error]
> open_module: stat(/lib/security/pam_nologin.so) failed: No such file or
> directory
> Aug 29 16:47:55 ssh-host sshd[26773]: [ID 487707 auth.error]
> load_modules: can not open module /lib/security/pam_nologin.so
> 
> Note the "pam_open_session(): Dlopen failure"
> 
> I get the same behavior from multiple accounts (using different shells
> and skeleton files).
> 
> I can work-around the problem by disabling either PAM and/or PrivSep
> in sshd_config, but in my production environment PAM support will be
> required, and PrivilegeSeparation is viewed as highly desirable.
> 
> 
> --------------
> Lets Go Canes!
> 

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




From rac at tenzing.org  Tue Aug 30 09:01:57 2005
From: rac at tenzing.org (Roger Cornelius)
Date: Mon, 29 Aug 2005 19:01:57 -0400
Subject: greater than 8 character passwords on SCO OSR6
Message-ID: <20050829230157.GA19840@tenzing.org>

I read the exchange regarding > 8 char passwords on Unixware from the
end of June.

Is anything being done to add support for >8 character passwords on SCO
OSR6 (in udk mode)?  I have it working by calling osr5bigcrypt(), instead
of bigcrypt(), in openbsd-compat/xcrypt.c and linking with -lcrypt.
libcrypt has bigcrypt(), but for whatever reason, openssh built with it
fails to authenticate passwords >8 chars in length.

bigcrypt() is not documented as being available in udk mode, and
osr5bigcrypt() is not documented at all, so not sure if this is the
"correct" fix.
-- 
Roger Cornelius        rac at tenzing.org



From tim at multitalents.net  Tue Aug 30 10:07:39 2005
From: tim at multitalents.net (Tim Rice)
Date: Mon, 29 Aug 2005 17:07:39 -0700 (PDT)
Subject: greater than 8 character passwords on SCO OSR6
In-Reply-To: <20050829230157.GA19840@tenzing.org>
References: <20050829230157.GA19840@tenzing.org>
Message-ID: <Pine.UW2.4.63.0508291655150.6596@server01.int.multitalents.net>

On Mon, 29 Aug 2005, Roger Cornelius wrote:

> I read the exchange regarding > 8 char passwords on Unixware from the
> end of June.
> 
> Is anything being done to add support for >8 character passwords on SCO
> OSR6 (in udk mode)?  I have it working by calling osr5bigcrypt(), instead
> of bigcrypt(), in openbsd-compat/xcrypt.c and linking with -lcrypt.
> libcrypt has bigcrypt(), but for whatever reason, openssh built with it
> fails to authenticate passwords >8 chars in length.

It's working fine on UnixWare using the latest snapshot.
Your post prompted me to test on OSR6. Although regression tests
have been pasing on OSR6, it looks like ia_openinfo() is failing.

It looks like I'm going ot have to disable long passwords for OSR6.

> 
> bigcrypt() is not documented as being available in udk mode, and
> osr5bigcrypt() is not documented at all, so not sure if this is the
> "correct" fix.
> 

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




From Larry.Welch at vignette.com  Tue Aug 30 21:49:54 2005
From: Larry.Welch at vignette.com (Welch, Larry)
Date: Tue, 30 Aug 2005 06:49:54 -0500
Subject: Replacing WinInet functions with OpenSSH API Calls
Message-ID: <4503BC263B51DD429E63785C4B5836D5594A1E@hqexchange1.vignette.com>

All,

I'm working with a solution which makes use of the WinINet API  (FTP
functions) to FTP files from a Windows 2K client to a AIX server.  While
this works fine, my current client wants me to use Secure FTP.  They are
running OpenSSH 3.71p, and the requirements are to not change the server
side daemon, and only change my client calls. 

While I'm fine with this, my current implementation takes advantage of
WinINets ability to completely manage the file transfer session.  I'm
simply making calls to InternetOpen(), FtpPutFile() and
InternetCloseHandle().  Is there a possibility that I can make API level
calls with OpenSSH and replace my WinINet calls?  If so, I have not been
able to locate API's to do so, and would appreciate some pointers to
documentation. 

If there is an API available, or an API based solution, I'm interested
in FREE or purchasing a commercial version.  I just want to meet the
requirements of my customer.

Thank you,

Larry Welch



From djm at mindrot.org  Tue Aug 30 21:59:48 2005
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Aug 2005 21:59:48 +1000
Subject: Replacing WinInet functions with OpenSSH API Calls
In-Reply-To: <4503BC263B51DD429E63785C4B5836D5594A1E@hqexchange1.vignette.com>
References: <4503BC263B51DD429E63785C4B5836D5594A1E@hqexchange1.vignette.com>
Message-ID: <43144A34.2010409@mindrot.org>

Welch, Larry wrote:
> All,
> 
> I'm working with a solution which makes use of the WinINet API  (FTP
> functions) to FTP files from a Windows 2K client to a AIX server.  While
> this works fine, my current client wants me to use Secure FTP.  They are
> running OpenSSH 3.71p, and the requirements are to not change the server
> side daemon, and only change my client calls. 

OpenSSH doesn't presently offer a library-style API. We would like to do
one, but is is not likely to happen soon (if ever) because it is a lot
of work.

On the other hand, you can run ssh at the end of a pipe and use it as a
transport by making reads and writes to/from the pipe. This is what scp,
sftp, cvs, rsync and a heap of other programs do.

Alternately, the sftp program supports batchfiles to automate transfers.
If you set up public key authentication, then you can use these to do
your work - your program could just write a batch file, run sftp and
check that it was successful.

-d



From Larry.Welch at vignette.com  Tue Aug 30 22:08:32 2005
From: Larry.Welch at vignette.com (Welch, Larry)
Date: Tue, 30 Aug 2005 07:08:32 -0500
Subject: Replacing WinInet functions with OpenSSH API Calls
Message-ID: <4503BC263B51DD429E63785C4B5836D5594A20@hqexchange1.vignette.com>

Thank you Damien.

Do you know of any commercial products which could provide me the APIs
which talk to the OpenSSH back end? My last resort would be to manage
the file transfer through my program, and I'm a bit concerned about
calling out because there will be hundreds of calls in a single
iteration of my program.

Cheers,

Larry

-----Original Message-----
From: Damien Miller [mailto:djm at mindrot.org] 
Sent: Tuesday, August 30, 2005 8:00 AM
To: Welch, Larry
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Replacing WinInet functions with OpenSSH API Calls

Welch, Larry wrote:
> All,
> 
> I'm working with a solution which makes use of the WinINet API  (FTP
> functions) to FTP files from a Windows 2K client to a AIX server.
While
> this works fine, my current client wants me to use Secure FTP.  They
are
> running OpenSSH 3.71p, and the requirements are to not change the
server
> side daemon, and only change my client calls. 

OpenSSH doesn't presently offer a library-style API. We would like to do
one, but is is not likely to happen soon (if ever) because it is a lot
of work.

On the other hand, you can run ssh at the end of a pipe and use it as a
transport by making reads and writes to/from the pipe. This is what scp,
sftp, cvs, rsync and a heap of other programs do.

Alternately, the sftp program supports batchfiles to automate transfers.
If you set up public key authentication, then you can use these to do
your work - your program could just write a batch file, run sftp and
check that it was successful.

-d



From djm at mindrot.org  Tue Aug 30 22:15:25 2005
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Aug 2005 22:15:25 +1000
Subject: Replacing WinInet functions with OpenSSH API Calls
In-Reply-To: <4503BC263B51DD429E63785C4B5836D5594A20@hqexchange1.vignette.com>
References: <4503BC263B51DD429E63785C4B5836D5594A20@hqexchange1.vignette.com>
Message-ID: <43144DDD.8030209@mindrot.org>

Welch, Larry wrote:
> Thank you Damien.
> 
> Do you know of any commercial products which could provide me the APIs
> which talk to the OpenSSH back end? 

I'm not really familiar with the commerical SSH products (the free ones
do everthing I need). There are free Perl and Python SSH implementations
that might help you and there is libssh2[1] which appears to be a C API.
(I haven't tried any of these.)

> My last resort would be to manage
> the file transfer through my program, and I'm a bit concerned about
> calling out because there will be hundreds of calls in a single
> iteration of my program.

If you are making lots of calls, then you could maintain a persistant
ssh connection and fire off transfers using the connection sharing
facilities. That way each transfer does not incur the cost of a key
exchange. See the ControlPath and ControlMaster options in "man
ssh_config" for more info.

-d

[1] http://www.libssh2.org/



From maf at appgate.com  Tue Aug 30 22:23:31 2005
From: maf at appgate.com (Martin Forssen)
Date: Tue, 30 Aug 2005 14:23:31 +0200 (CEST)
Subject: Replacing WinInet functions with OpenSSH API Calls
In-Reply-To: <4503BC263B51DD429E63785C4B5836D5594A20@hqexchange1.vignette.com>
References: <4503BC263B51DD429E63785C4B5836D5594A20@hqexchange1.vignette.com>
Message-ID: <tkrat.5348367b25d4ab38@appgate.com>

On 30 aug, Welch, Larry wrote:
> Do you know of any commercial products which could provide me the APIs
> which talk to the OpenSSH back end? My last resort would be to manage
> the file transfer through my program, and I'm a bit concerned about
> calling out because there will be hundreds of calls in a single
> iteration of my program.

MindTerm might fit the bill. It is a commercial Java implementation of
the SSH protocol and there are multiple ways of transferring files with
it. I see two ways of solving your problem with MindTerm.

1. Either integrate it and call the provided APIs directly, how hard
   this is depends entirely on your application.

2. Or you can launch MindTerm as a separate application which implements
   an ftp-proxy. In this case you run ftp as normal but connect to
   localhost where MindTerm listens. MindTerm can then forward the files
   either using ftp or sftp on the server.

For more information see http://www.appgate.com/mindterm or ask me.

	/MaF
-- 
Martin Forssen <maf at appgate.com>              Development Manager
Phone: +46 31 7744361                         AppGate Network Security AB



From djm at mindrot.org  Tue Aug 30 22:51:58 2005
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Aug 2005 22:51:58 +1000
Subject: Replacing WinInet functions with OpenSSH API Calls
In-Reply-To: <tkrat.5348367b25d4ab38@appgate.com>
References: <4503BC263B51DD429E63785C4B5836D5594A20@hqexchange1.vignette.com>
	<tkrat.5348367b25d4ab38@appgate.com>
Message-ID: <4314566E.7020700@mindrot.org>

I know in this case the conversation drifted that way of its own accord,
but for future reference I would like to make it clear that discussion
of commercial products is *off topic* for this mailing list, except
when it arises in the context of OpenSSH development (e.g. discussing
interoperability).

A statement to this effect will shortly be added to the Mailman listinfo
page and the welcome message.

Thanks,
Damien Miller



From letsgonhlcanes at yahoo.com  Wed Aug 31 00:09:50 2005
From: letsgonhlcanes at yahoo.com (Lets Go Canes)
Date: Tue, 30 Aug 2005 07:09:50 -0700 (PDT)
Subject: Conflict between LDAP and Privilege Separation?
In-Reply-To: <Pine.UW2.4.63.0508291504000.6596@server01.int.multitalents.net>
Message-ID: <20050830140950.27125.qmail@web50706.mail.yahoo.com>

Hi all.

--- Tim Rice <tim at multitalents.net> wrote:

> Looks like a PAM configuration problem.
> 
> What does your /etc/pam.conf look like?

As far as I am aware, it is the Solaris default:

#
#ident  "@(#)pam.conf   1.16    01/01/24 SMI"
#
# Copyright (c) 1996-2000 by Sun Microsystems, Inc.
# All rights reserved.
#
# PAM configuration
#
# Authentication management
#
login   auth required   /usr/lib/security/$ISA/pam_unix.so.1
login   auth required   /usr/lib/security/$ISA/pam_dial_auth.so.1
#
rlogin  auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1
rlogin  auth required   /usr/lib/security/$ISA/pam_unix.so.1
#
dtlogin auth required   /usr/lib/security/$ISA/pam_unix.so.1
#
rsh     auth required   /usr/lib/security/$ISA/pam_rhosts_auth.so.1
other   auth required   /usr/lib/security/$ISA/pam_unix.so.1
#
# Account management
#
login   account requisite       /usr/lib/security/$ISA/pam_roles.so.1
login   account required       
/usr/lib/security/$ISA/pam_projects.so.1
login   account required        /usr/lib/security/$ISA/pam_unix.so.1
#
dtlogin account requisite       /usr/lib/security/$ISA/pam_roles.so.1
dtlogin account required       
/usr/lib/security/$ISA/pam_projects.so.1
dtlogin account required        /usr/lib/security/$ISA/pam_unix.so.1
#
other   account requisite       /usr/lib/security/$ISA/pam_roles.so.1
other   account required       
/usr/lib/security/$ISA/pam_projects.so.1
other   account required        /usr/lib/security/$ISA/pam_unix.so.1
#
# Session management
#
other   session required        /usr/lib/security/$ISA/pam_unix.so.1
#
# Password management
#
other   password required       /usr/lib/security/$ISA/pam_unix.so.1
dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1
#
# Support for Kerberos V5 authentication (uncomment to use Kerberos)
#
#rlogin auth optional   /usr/lib/security/$ISA/pam_krb5.so.1
try_first_pass
#login  auth optional   /usr/lib/security/$ISA/pam_krb5.so.1
try_first_pass
#dtlogin        auth optional   /usr/lib/security/$ISA/pam_krb5.so.1
try_first_p
ass
#other  auth optional   /usr/lib/security/$ISA/pam_krb5.so.1
try_first_pass
#dtlogin        account optional /usr/lib/security/$ISA/pam_krb5.so.1
#other  account optional /usr/lib/security/$ISA/pam_krb5.so.1
#other  session optional /usr/lib/security/$ISA/pam_krb5.so.1
#other  password optional /usr/lib/security/$ISA/pam_krb5.so.1
try_first_pass
#
# Support for Solaris PPP (sppp)
ppp     auth    required        /usr/lib/security/$ISA/pam_unix.so.1
ppp     auth    required       
/usr/lib/security/$ISA/pam_dial_auth.so.1
ppp     account requisite       /usr/lib/security/$ISA/pam_roles.so.1
ppp     account required       
/usr/lib/security/$ISA/pam_projects.so.1
ppp     account required        /usr/lib/security/$ISA/pam_unix.so.1
ppp     session required        /usr/lib/security/$ISA/pam_unix.so.1


--------------
Lets Go Canes!

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



From Rochelle.Rosenberg at siemens.com  Wed Aug 31 07:02:18 2005
From: Rochelle.Rosenberg at siemens.com (Rosenberg, Rochelle)
Date: Tue, 30 Aug 2005 14:02:18 -0700
Subject: ssh develpers list
Message-ID: <5F98E47AD7B1C349895ED4E2EDF3918B0187395A@stca209a>

Hi,
I am software developer working on adding ssh server support to an  existing
embedded
device which is based on the VxWorks operating system.(very different than
windows/lynix/unix).
I am adding support for remote login to our products command line interface
and external file transfers(sftp).
Prior to this project I had no experience with SSH.
 
I have been using the O'Reilly SSH The Secure Shell book, the web and a 
bit of support from the vendor from which we bought our ssh code from
(OpenSSH)
(Support pertains to issues with building and integrating their ssh code
into our product)
Most references I've found pertain to Unix/Lynx and or Windows.
 
I am in search of other developers who may be doing similar work or at the
least
just be able to toss ideas around and get others opinions.
 
Given the above, Is this a viable list for me to subscribe to?
 
thanks
 



From djm at mindrot.org  Wed Aug 31 09:51:41 2005
From: djm at mindrot.org (Damien Miller)
Date: Wed, 31 Aug 2005 09:51:41 +1000 (EST)
Subject: ssh develpers list
In-Reply-To: <5F98E47AD7B1C349895ED4E2EDF3918B0187395A@stca209a>
References: <5F98E47AD7B1C349895ED4E2EDF3918B0187395A@stca209a>
Message-ID: <Pine.BSO.4.63.0508310949250.28389@fuyu.mindrot.org>

On Tue, 30 Aug 2005, Rosenberg, Rochelle wrote:

> Hi,
> I am software developer working on adding ssh server support to an  existing
> embedded
> device which is based on the VxWorks operating system.(very different than
> windows/lynix/unix).

Quite a few people have asked on this list about porting OpenSSH to 
VxWorks over the years and I am sure that some have succeeded. However, I 
don't think any of them submitted their changes back to us for 
integration.

-d



From bill at bfccomputing.com  Wed Aug 31 09:30:32 2005
From: bill at bfccomputing.com (Bill McGonigle)
Date: Tue, 30 Aug 2005 19:30:32 -0400
Subject: make tests failure: openssh-SNAP-20050827 on Redhat 9
Message-ID: <1ebf407aad2372740d51b9f038b5d579@bfccomputing.com>

This is a Redhat 9 box doing nightly updates from FedoraLegacy.org.

I have a script of the whole session if needed.

-Bill

----
ok transfer data
run test banner.sh ...
test banner: missing banner file
cmp: EOF on /home/flowerpt/src/openssh/openssh/regress/empty.in
missing banner file
test banner: size 0
cmp: EOF on /home/flowerpt/src/openssh/openssh/regress/banner.in
banner size 0 mismatch
test banner: size 10
cmp: EOF on /home/flowerpt/src/openssh/openssh/regress/banner.in
banner size 10 mismatch
test banner: size 100
cmp: EOF on /home/flowerpt/src/openssh/openssh/regress/banner.in
banner size 100 mismatch
test banner: size 1000
cmp: EOF on /home/flowerpt/src/openssh/openssh/regress/banner.in
banner size 1000 mismatch
test banner: size 10000
cmp: EOF on /home/flowerpt/src/openssh/openssh/regress/banner.in
banner size 10000 mismatch
test banner: size 100000
cmp: EOF on /home/flowerpt/src/openssh/openssh/regress/banner.in
banner size 100000 mismatch
test banner: suppress banner (-q)
cmp: EOF on /home/flowerpt/src/openssh/openssh/regress/empty.in
suppress banner (-q)
failed banner
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/home/flowerpt/src/openssh/openssh/regress'
make: *** [tests] Error 2
sh-2.05b$ exit
sh-2.05b$ exit


-----
Bill McGonigle, Owner           Work: 603.448.4440
BFC Computing, LLC              Home: 603.448.1668
bill at bfccomputing.com           Mobile: 603.252.2606
http://www.bfccomputing.com/    Pager: 603.442.1833
Jabber: flowerpt at gmail.com      Text: bill+text at bfccomputing.com
RSS: http://blog.bfccomputing.com/rss



From djm at mindrot.org  Wed Aug 31 14:21:30 2005
From: djm at mindrot.org (Damien Miller)
Date: Wed, 31 Aug 2005 14:21:30 +1000 (EST)
Subject: make tests failure: openssh-SNAP-20050827 on Redhat 9
In-Reply-To: <1ebf407aad2372740d51b9f038b5d579@bfccomputing.com>
References: <1ebf407aad2372740d51b9f038b5d579@bfccomputing.com>
Message-ID: <Pine.BSO.4.63.0508311420090.24797@fuyu.mindrot.org>

On Tue, 30 Aug 2005, Bill McGonigle wrote:

> This is a Redhat 9 box doing nightly updates from FedoraLegacy.org.
>
> I have a script of the whole session if needed.

Do you have any login banner configured for the system, e.g. using 
pam_motd or similar? This could interfere with that test.

-d