Re: USB-serial adapter suggestions needed

On Wed, Jan 10, 2024 at 11:30:28AM -0800, Mark Millard wrote:
> On Jan 10, 2024, at 11:21, Mark Millard <marklmi@yahoo.com> wrote:
> 
> > On Jan 10, 2024, at 10:16, bob prohaska <fbsd@www.zefox.net> wrote:
> > 
> >> On Tue, Jan 09, 2024 at 05:03:42PM -0800, Mark Millard wrote:
> >>> On Jan 9, 2024, at 14:47, bob prohaska <fbsd@www.zefox.net> wrote:
> >>> 
> >> [transcript of ssh-tip disconnect omitted]
> >>> 
> >>> Interesting.
> >>> 
> >>> www.zefox.org is the aarch64 that is not configured in config.txt
> >>> in the normal aarch64 manor. As I've requested before, please test
> >>> using a config.txt that instead has:
> >>> 
> >>> QUOTE
> >>> [all]
> >>> arm_64bit=1
> >>> dtparam=audio=on,i2c_arm=on,spi=on
> >>> dtoverlay=mmc
> >>> dtoverlay=disable-bt
> >>> device_tree_address=0x4000
> >>> kernel=u-boot.bin
> >>> 
> >>> [pi4]
> >>> hdmi_safe=1
> >>> armstub=armstub8-gic.bin
> >>> 
> >>> # Local addition:
> >>> [all]
> >>> force_mac_address=b8:27:eb:71:46:4f
> >>> END QUOTE
> >>> 
> >>> Please do not use a configuration based in part on armv7 FreeBSD
> >>> config.txt material any more for the testing activity: Just use
> >>> the FreeBSD normal aarch64 configuration with the force_mac_address
> >>> related material added at the end.
> >>> 
> >>> I want to know if this also fails when powerd is not in
> >>> use anywhere.
> >>> 
> >> 
> >> I'd like to let the the present OS build/install cycle complete.
> >> Then I'll replace config.txt on www.zefox.org and reboot.
> >> That should be done in another day or two. The remote console
> >> disconnect reported above hasn't happened again, all consoles
> >> have stayed connected and responsive.
> >> 
> >> 
> >>> [I assume that the "The Pi4 workstation" is the "pi4 RasPiOS
> >>> workstation". True? Presuming yes: Is the RasPiOS the 64 bit
> >>> variation? (Just my curiosity.)]
> >>> 
> >> Yes. Uname -a reports 
> >> Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 
> >> BST 2023 aarch64 GNU/Linux
> >> 
> >>> Do you run the buildworld on www.zefox.org and such via the
> >>> tip session on pelorus.zefox.org ? Via an ssh session from the
> >>> "pi4 RasPiOS workstation" to www.zefox.org ? More generally:
> >>> 
> >>> A) What runs (if anything) via the tip session started from
> >>>   pelorus.zefox.org ?
> >>> 
> >>> B) What runs (if anything) via the ssh session connected to
> >>>   www.zefox.org ?
> >>> 
> >> 
> >> In general the tip session is used only for observation or
> >> troubleshooting. Ssh connections are used for other activity, 
> >> including OS build/install cycles, poudriere, etc. They are
> >> usually placed in the background, writing to log files so that
> >> accidental disconnects from the workstation don't stop them.
> > 
> > Are you using:
> > 
> > NAME
> >     nohup ??? invoke a utility immune to hangups
> >

The OS build commands end with &, which I gather does nohup 
among other things (not sure what).  

> > That only ssh sessions that in turn run tip fail suggests that the
> > tip session gets the initial problem and then things propagate. I
> > want more than a suggestion. For example: direct tip runs that
> > are not in any ssh session: still get some form of failures?
> 

As it happens, the tip connection between nemesis.zefox.com (terminal
server) and ns2.zefox.net (console host) dropped. The display reported:

login: Jan 10 09:42:46 ns2 sshd[48003]: error: Fssh_kex_exchange_identification: Connection closed by remote host
Jan 10 10:51:54 ns2 sshd[48135]: error: PAM: Authentication error for illegal user shell from 185.11.61.234
Jan 10 10:53:03 ns2 sshd[48138]: error: Fssh_kex_exchange_identification: Connection closed by remote host
Jan 10 10:55:47 ns2 sshd[48152]: error: Fssh_kex_exchange_identification: Connection closed by remote host
Jan 10 11:22:26 ns2 sshd[48203]: error: PAM: Authentication error for illegal user test from 85.209.11.226
Jan 10 12:24:21 ns2 sshd[48300]: error: Fssh_kex_exchange_identification: Connection closed by remote host
Jan 10 13:12:06 ns2 sshd[48380]: error: Fssh_kex_exchange_identification: Connection closed by remote host
Jan 10 13:14:06 ns2 sshd[48381]: fatal: Timeout before authentication for 59.56.110.106 port 50300
Jan 10 13:34:34 ns2 sshd[926]: error: beginning MaxStartups throttling
Jan 10 14:12:41 ns2 sshd[48506]: error: PAM: Authentication error for illegal user shutdown from 185.11.61.234


FreeBSD/arm (ns2.zefox.net) (ttyu0)

login: client_loop: send disconnect: Broken pipe
bob@raspberrypi:~ $ 

Interestingly, there's a MaxStartups warning. I discovered the failure
somewhat before 15:17 hours. The link had been up for a couple of
days IIRC.
 
I logged in on nemsis.zefox.com's hdmi console and usb keyboard (the only Pi
in my collection set up for video console logins), opened x11, started an
xterm, su'd to root and ran tip to connect to ns2.zefox.net.

The connection was normal, no problem with needing to power-cycle the 
usb-serial adapter using usbconfig; tip connected and displayed a brief
string of mixed printable and non-printing characters, ending with a
login prompt on the same line. Next came two reports from ns2 of 
"... kex protocol error...."  





> >             Specifies the maximum number of concurrent unauthenticated
> >             connections to the SSH daemon.  Additional connections will be
> >             dropped until authentication succeeds or the LoginGraceTime
> >             expires for a connection.  The default is 10:30:100.
> > 
> >             Alternatively, random early drop can be enabled by specifying the
> >             three colon separated values start:rate:full (e.g. "10:30:60").
> >             sshd(8) will refuse connection attempts with a probability of
> >             rate/100 (30%) if there are currently start (10) unauthenticated
> >             connections.  The probability increases linearly and all
> >             connection attempts are refused if the number of unauthenticated
> >             connections reaches full (60).

If sshd mixed up new with existing sessions it might kill one running tip,
but it'd likely kill others from time to time. So far that hasn't happend,
at least not often. 
 
> > 
> > It does suggest that testing isolated from the source(s) of
> > unauthenticated sessions could be worth while in case handling
> > the load from such sessions when already heavily loaded with
> > buildworld/builkernel or the like leads to other problems (and
> > denial of service consequences?).
> > 
> > I do not expect that this issue is all that likely but
> > expectations are not evidence of their own accuracy/inaccuracy.

It's my (very) subjective impression the ssh/tip problems are more
frequent when ssh attacks are more abundant. Nemesis.zefox.com is
public and sees a certain amount of doorknocking but for some 
reason considerably less than www.zefox.org.  

As an aside, during some stages of testing with pelorus.zefox.org
the host was on the LAN and so not subject to attack. It certainly
didn't prevent failure of tip sessions. Now pelorus.zefox.org is
on a public IP and seeing at least sporadic doorknocking. 

Thanks for reading!

bob prohaska