| raw e-mail | index | archive | help
It appears that tip is mistakenly echoing characters when it picks up a stale connection. I've noticed this problem for a long time now, but this is the clearest example so far of what seems like undesirable behavior. Normally I keep a tip session running on a usb-serial adapter to monitor the GPIO serial console of (several) Raspberry Pi computers. The scheme is to ssh into one Pi, su to root and run tip on the usb-serial adapter, thus getting a console session that displays a login prompt and console messages on the connected Pi. >From time to time a login session is left running, and then the ssh session drops for reasons unclear but likely immaterial to the puzzle. On restarting the tip session at least some of the accumulated console output spews forth. On the face of it that seems good, since it lets me see output that would otherwise be lost. But, after re-connecting to the console, it looks as if some of the stale console output is being echoed back to the originating console and interpreted by that shell (which remains running) as a command. Here is an example. root@www:/home/bob # tip ucom [ucom:dv=/dev/cuaU0:br#115200:pa=none:] Stale lock on cuaU0 PID=1449... overriding. connected sW��cRSwh] Apr 16 18:40:41 www sshd[42733]: error: maximum authentication attempts exceeded for root from 14.225.192.42 port 55170 ssh2 [preauth] Apr 16 18:40:47 www sshd[42737]: error: maximum authentication attempts exceeded for invalid user admin from 14.225.192.42 port 50516 ssh2 [preauth] [lots of old console login failure reports] .... [roughly 100 lines of login failure messages] .... bob@www:~ % Apr 16 13:32:18 www sshd[42185]: fatal: Timeout before authentication for 110.7.52.1xJ^s Apr: No match. bob@www:~ % bob@www:~ % load: 2.98 not a controlling terminal load:: Too many arguments. bob@www:~ % bob@www:~ % ^R Modifier failed. bob@www:~ % bob@www:~ % Apr 16 13:32:18 www sshd[42185]: fatal: Timeout before authentication for Þ×gs^R Apr: No match. bob@www:~ % bob@www:~ % ×^s×^PgcÒÖs×ëgsÒÖs×ëãcJÖ^@Apr 17 08:38:42 www sshd[45444]: error: Fssh_kex_exchange_identification: read: Connection reset by peer Apr 17 08:45:19 www sshd[45466]: error: Fssh_kex_exchange_identification: read: Connection reset by peer It looks like the final lines include error messages issued by the shell running on the serial console. I didn't type them and wonder how input might be delivered to the shell. Is it possible that the usb-serial adapter is echoing received characters when tip has exited due to failure of the ssh session? If so, that seems highly undesirable, since console messages containing valid commands could be acted acted upon with the priviledge associated with the shell, which can be and is sometimes root. Apologies in advance if this is a dumb idea, but I'm seeing lots of very naive ssh attacks and starting to wonder if there's an ulterior motive for them. Thanks for reading, bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>