Patch for openssh server

[Christian Iversen]

On Tuesday 15 August 2006 16:08, Darren Tucker wrote:
> Christian Iversen wrote:
> > On Tuesday 15 August 2006 07:53, Darren Tucker wrote:
> >> I see no such option (I'm not sure another sshd_config option would help
> >> your cause, though).  Did you attach the version of the patch that you
> >> intended to?
> >
> > We didn't actually write that functionality, in case the patch would be
> > rejected. I'll add it right away if you think there's some chance it
> > could be accepted?
>
> No, I don't think an option would make a positive difference and it
> could be easily added if needed.  I was just pointing out that the patch
> was not as described and wondered if this was accidental.

Ok - well I meant to write a note that this functionality was indeed missing, 
but it seems I forgot.

> [...]
>
> >> Users of proftpd, apache and postfix don't usually have the option to
> >> run other programs to generate their network traffic.
> >
> > I'm sorry, but I don't really understand what you are trying to point
> > out? I mean, I can see that the statement is true, but I don't see the
> > relevance. If the user uses, say, mutt to read his email, would you
> > actually rather have mutt do the traffic accounting? :)
>
> No, if I cared about per-user traffic volumes I'd prefer that the system
> account for everything rather than instrumenting a bunch of
> applications.  Users with shell access have lots of other ways to
> generate network traffic.

That's true, but ssh is still the right option for us. For instance, how would 
you log the username with iptables or <insert-other-program-here>?

> >> (it'll count it as it arrives in the encrypted pipe, but not once it
> >> goes back out over the network).
> >
> > You mean in the case of remote port forwards?
>
> Remote or local (ie ssh -L/-R).

That was a bad explanation on my part. I meant forwarding to another machine. 

> > In case the user forwards a port on 127.0.0.1, we don't want to count
> > traffic. Or at least, we want to  count it seperately.
>
> What about the server's local net?  This is a good example of why you
> might want your packet filter to do your user accounting.

Well, I'm hoping we can find a compromise we can all live with. For instance, 
we could ignore the problem completely in the first version :-)

We have written a specialized shell that only accepts rsync connections, in 
order to use as a backup service. I'd rather have a very simple patch that 
doesn't count retransmitted traffic, than a complex one that does.

> >> These types don't exactly match (u_long is preferred).
> >
> > I'm sorry, what do you mean? Are you referring to the signedness issue
> > below?
>
> "ulong" != "u_long"

Got it :)

> >>> +	logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out);
> >>
> >> bytes_in and bytes_out are unsigned but the format string is signed.
> >
> > Oops, my bad. Indeed, that would be a problem if the user transferred
> > more bytes than there are atoms in the universe ;-)
>
> Yeah, it's not something that people are likely hit in an enormous hurry
> :-)

Not really, no ;-)

-- 
Regards,
Christian Iversen