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