From nobody Wed Apr 17 16:11:17 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VKQrS1Sdxz5H9Rk for ; Wed, 17 Apr 2024 16:11:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "generic", Issuer "generic" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VKQrQ6HG6z55xH for ; Wed, 17 Apr 2024 16:11:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.17.1) with ESMTPS id 43HGBHQm041233 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 17 Apr 2024 09:11:18 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.17.1/Submit) id 43HGBHh4041232; Wed, 17 Apr 2024 09:11:17 -0700 (PDT) (envelope-from fbsd) Date: Wed, 17 Apr 2024 09:11:17 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Tip echoing when it should not? Message-ID: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spamd-Bar: + X-Spamd-Result: default: False [1.40 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; NEURAL_SPAM_SHORT(0.50)[0.499]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[zefox.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4VKQrQ6HG6z55xH 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