This is a discussion on Re: Patch for openssh server - openssh ; 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 > ...
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
> >> (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"
> >>> + 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 ;-)
openssh-unix-dev mailing list