[mosh-users] Logging from mosh-server

[Keith Winstein]

Hello Jim,

To be honest, up to this point we have mostly thought of mosh-server as an
unprivileged process run by users. The debugging output from a user's
mosh-server is not something we imagined system administrators would care
that much about, any more than the debugging output from a user's screen or
tmux or pine.

So we haven't really designed for this use-case. If you are really
interested in logging packets that fail to verify the integrity check,
syslog may be appropriate, or maybe some sort of systemd facility -- I'm
not sure what's in vogue these days.

Can you tell us more about your needs -- do you plan to analyze to see
where the bogus packets are coming from (in which case we will need to
print out the source IP and port, which we don't do currently), or...?

Best regards,
Keith


On Wed, Dec 18, 2013 at 4:09 PM, Jim Cheetham <jim.cheetham at otago.ac.nz>wrote:

> Thanks Keith, that's a good start.
>
> I see a use-case difference between the network tick messages, the cases
> where users disconnect/change source IP, and when exceptions are
> detected; at the moment all of these are going to stderr. Are there any
> other classes of message I've missed?
>
> What approach would you like to use to differentiate? The syslog way is
> to give each of these cases a different facility.level; and then a
> combination of command-line flags to enable logging for that facility,
> and syslog configuration to decide where to send them. Of course syslog
> is a new dependency, but hopefully a positive one.
>
> The quick hack way would be to just collect stderr, then filter it
> through some regexps to discard the items we're not interested in, and
> pass the remainder to a log file, or to syslog (perhaps via logger).
> Trying to use complicated shell redirections via the mosh command isn't
> very successful, the quoting is ... tricky :-)
>
> The simple case here does work, though.
> $ ./mosh "--server=mosh-server new -v 2>/tmp/mosh-server.2.log" user at host
> although at the far end it is a little redundant in expansion
> $ mosh-server new -v new -s -c 8 -l LANG=en_NZ.UTF-8 -l LANGUAGE=en_NZ:en
>
> -jim
>
> Excerpts from Keith Winstein's message of 2013-12-19 06:28:33 +1300:
> > In addition, you can add a "-v" flag to the mosh-server command line to
> get
> > extra debugging information. It will log a "Crypto exception" if it gets
> an
> > invalid datagram.
> >
> > On Wed, Dec 18, 2013 at 12:02 PM, Quentin Smith <quentin at mit.edu> wrote:
> >
> > > On platforms that support updating utmp, yes, the user's IP address is
> > > updated whenever the server detects a client IP change. (It's also
> updated
> > > when the server thinks the client is offline.)
> > >
> > > --Quentin
> > >
> > >
> > > On Wed, 18 Dec 2013, Jim Cheetham wrote:
> > >
> > >  What sort of logs are available from mosh-server? I'm particularly
> > >> interested in being able to detect invalid attempts to talk to the
> > >> server (more likely to be DoS than realistic attempts to guess the
> key),
> > >> and also to track when a 'connected' user changed IP address
> > >> successfully. Related to this, do we update utmp when a user's IP
> > >> address changes, or only when it is initially connected?
> > >>
> > >> -jim
> > >> --
> > >> Jim Cheetham, Information Security, University of Otago, Dunedin, N.Z.
> > >> ✉ jim.cheetham at otago.ac.nz       ☏ +64 3 470 4670 ☏ m +64 21 227 0015
> > >> ⚷ OpenPGP: B50F BE3B D49B 3A8A 9CC3 8966 9374 82CD C982 0605
> > >>
> > >
> > > _______________________________________________
> > > mosh-users mailing list
> > > mosh-users at mit.edu
> > > http://mailman.mit.edu/mailman/listinfo/mosh-users
> > >
> > >
> --
> Jim Cheetham, Information Security, University of Otago, Dunedin, N.Z.
> ✉ jim.cheetham at otago.ac.nz       ☏ +64 3 470 4670 ☏ m +64 21 227 0015
> ⚷ OpenPGP: B50F BE3B D49B 3A8A 9CC3 8966 9374 82CD C982 0605
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-users/attachments/20131218/6af33c0d/attachment-0001.htm