Well, as the title mentions, I've had this happen on three boxes now.

Mac - Primary Computer


  • Big Sur (the worst? terrible)
  • Pi 3/4/Zero
  • iTerm2 & Terminal

I have three Raspberry Pi boxes: 3, 4, & Zero


  • The zero has been a pain in the *** since day one, between EthGadget support on my computer and only every getting it to work via dual SSH tunnels (Mac -> Pi4 -> PiZero) or today only after soldering the pins so I could add a USB/Eth hat actually, worked great? until)
  • The Pi3 I updated yesterday and noticed a problem with SSH almost immediately
  • This morning I flashed the Zero in preparation for some soldering and adding an RJ45+USB hat. Worked great until about an hour ago when I ran a new function (see code below)
  • My other Pi4 was working fine on Wednesday, but I had an issue with some Python packages so after updating that I ran the usual upgrade. It too stopped working over SSH.
  • I set static IP addresses for every box, visually verified their connection to the network, and used ping to confirm they are visible to/on the network
  • Made sure all of them had an easily identified IP assignment. (192.168.1.AA, 192.168.1.BB, 192.168.CC, respectively)
  • Turned off VPNs, Firewall (on a second network) to ensure there was no interference from iptables, routing, tunneling, passthrough, or access restrictions


Code:
# added this today to ~/.bashrc ? Ran it once, and broke SSH somehow
function apt-updater {
apt-get update &&    
apt-get dist-upgrade -Vy &&    
apt-get autoremove -y &&    
apt-get autoclean &&    
apt-get clean &&    
reboot    
}
So, between the three boxes, all of them are refusing ssh connections after running combinations of
Code:
apt-get update && apt-get upgrade
OR the function displayed above.

I was able to SSH into ALL of them prior to this. Has anyone else had this problem? I've found a ton of posts elsewhere but all of them for older versions or assuming I can just log into a headless kali over USB (on BigSur ain't happening, I tried more times than I can count, hence the RJ45 hat on the Zero). I initially thought that it was something I did, but the third box in 2 days has me scratching my head, one of them being flashed just this afternoon? Naa, something isn't right.

Here is the output after today's update?


Code:
###########################################
# this is a sample of the output from the apt-get update that was working
# in the previous ssh session. Literally made it this far with the function above
###########################################
nmbd.service is a disabled or a static unit not running, not starting it.
samba-ad-dc.service is a disabled or a static unit not running, not starting it.
smbd.service is a disabled or a static unit not running, not starting it.
Setting up kali-desktop-xfce (2021.1.10) ...
Setting up sslyze (4.0.4-0kali1) ...
Setting up python3-pyproj (3.0.0-2) ...
Setting up python3-twisted (20.3.0-4) ...
Setting up faraday (3.14.2-0kali1) ...
faraday.service is a disabled or a static unit not running, not starting it.
Setting up python3-numexpr (2.7.2-2) ...
Setting up tasksel-data (3.64+kali3) ...
Setting up tasksel (3.64+kali3) ...
Setting up kali-linux-core (2021.1.10) ...
Setting up libdevmapper1.02.1:armel (2:1.02.175-2.1) ...
Setting up dmsetup (2:1.02.175-2.1) ...
update-initramfs: deferring update (trigger activated)
Setting up kali-linux-arm (2021.1.10) ...
Setting up nfs-common (1:1.3.4-5) ...
nfs-utils.service is a disabled or a static unit not running, not starting it.
Setting up kali-linux-headless (2021.1.10) ...
Setting up kali-linux-default (2021.1.10) ...
Processing triggers for libc-bin (2.31-9) ...
Processing triggers for shared-mime-info (2.0-1) ...
Processing triggers for udev (247.3-1) ...
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for initramfs-tools (0.139) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for dictionaries-common (1.28.4) ...
Processing triggers for php7.4-cli (7.4.15-5+deb11u1) ...
Processing triggers for libapache2-mod-php7.4 (7.4.15-5+deb11u1) ...
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
┌──(root💀kali)-[/home/kali]
└─# Connection to 192.168.1.88 closed by remote host.
Connection to 192.168.1.88 closed.
$ ssh [email protected]
^C
$ ssh [email protected]
The authenticity of host '192.168.1.99 (192.168.1.99)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxSHA256herexxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.99' (ECDSA) to the list of known hosts.
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:


$ ssh [email protected]
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:


$ ping 192.168.1.99
PING 192.168.1.99 (192.168.1.99): 56 data bytes
64 bytes from 192.168.1.99: icmp_seq=0 ttl=64 time=3.670 ms
64 bytes from 192.168.1.99: icmp_seq=1 ttl=64 time=2.586 ms
64 bytes from 192.168.1.99: icmp_seq=2 ttl=64 time=8.888 ms
64 bytes from 192.168.1.99: icmp_seq=3 ttl=64 time=13.170 ms
^C
--- 192.168.1.99 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.586/7.079/13.170/4.248 ms
$ ssh [email protected]
[email protected]'s password:


$ ssh [email protected]
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:


$ ssh [email protected]
ssh: connect to host 192.168.1.99 port 22: Operation timed out
$ ping 192.168.1.99
PING 192.168.1.99 (192.168.1.99): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
^C
--- 192.168.1.99 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
$ ping 192.168.1.99
PING 192.168.1.99 (192.168.1.99): 56 data bytes
64 bytes from 192.168.1.99: icmp_seq=0 ttl=64 time=5.943 ms
64 bytes from 192.168.1.99: icmp_seq=1 ttl=64 time=2.548 ms
^C
--- 192.168.1.99 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.548/4.245/5.943/1.697 ms
$ ssh [email protected]
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:


$ ssh [email protected]
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:
ssh_dispatch_run_fatal: Connection to 192.168.1.99 port 22: Broken pipe
$ ssh [email protected]
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:
[email protected]: Permission denied (publickey,password).
$ ssh [email protected]
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:
[email protected]: Permission denied (publickey,password).
Attempts to Resolve:


  • Popped BOOT into a card slot and tried
    Code:
    ?/BOOT/$ touch ssh
    on the ZERO (enables SSH per 2019/2020 defaults) - No dice
    Code:
  • $ ssh-keygen