Alessandro Lannocca

Trying vanilla bookworm from trunk on nanopi-r5c, changing sshd port seems to work aless@CORBINO ~ % ssh root@192.168.1.101 -p 61022 root@192.168.1.101's password: X11 forwarding request failed on channel 0 _ _ ____ _ ____ ____ ____ | \ | | _ \(_) | _ \| ___| / ___| | \| | |_) | | | |_) |___ \| | | |\ | __/| | | _ < ___) | |___ |_| \_|_| |_| |_| \_\____/ \____| Welcome to Armbian-unofficial 24.8.0-trunk Bookworm with Linux 6.6.34-current-rockchip64 No end-user support: built from trunk System load: 15% Up time: 4 min Memory usage: 5% of 3.65G IP: 192.168.1.101 CPU temp: 41°C Usage of /: 4% of 58G RX today: n/a [ General system configuration (beta): armbian-config ] Last login: Sun Jun 16 17:03:59 2024 from 192.168.1.116 nappio:~:# systemctl status ssh ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled) Active: active (running) since Sun 2024-06-16 17:05:26 CEST; 30s ago Docs: man:sshd(8) man:sshd_config(5) Process: 3174 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS) Main PID: 3175 (sshd) Tasks: 1 (limit: 4297) Memory: 3.2M CPU: 567ms CGroup: /system.slice/ssh.service └─3175 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups" Jun 16 17:05:26 nappio systemd[1]: Starting ssh.service - OpenBSD Secure Shell server... Jun 16 17:05:26 nappio sshd[3175]: Server listening on 0.0.0.0 port 61022. Jun 16 17:05:26 nappio sshd[3175]: Server listening on :: port 61022. Jun 16 17:05:26 nappio systemd[1]: Started ssh.service - OpenBSD Secure Shell server. Jun 16 17:05:42 nappio sshd[3178]: Accepted password for root from 192.168.1.116 port 51699 ssh2 Jun 16 17:05:42 nappio sshd[3178]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Jun 16 17:05:43 nappio sshd[3178]: pam_env(sshd:session): deprecated reading of user environment enabled nappio:~:# /etc/ssh/sshd_config: # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/bin:/usr/games # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. Include /etc/ssh/sshd_config.d/*.conf Port 61022 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress ::

Works for me on Trixie, will check with Bookworm: # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/bin:/usr/games # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. Include /etc/ssh/sshd_config.d/*.conf Port 1122 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: [...] ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: disabled) Active: active (running) since Sun 2024-06-16 02:31:25 CEST; 13s ago Invocation: cd3972f4454d4e37a5ce90e6fade1946 Docs: man:sshd(8) man:sshd_config(5) Process: 1054 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS) Main PID: 1103 (sshd) Tasks: 9 (limit: 4296) Memory: 40.1M (peak: 56.2M) CPU: 9.397s CGroup: /system.slice/ssh.service ├─1103 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups" ├─1347 "sshd: kali [priv]" ├─1510 "sshd: kali@pts/0" ├─1511 -zsh ├─1525 tmux -u -2 -f /usr/share/byobu/profiles/tmuxrc new-session -n - /usr/bin/byobu-shell ├─1559 tmux -u -2 -f /usr/share/byobu/profiles/tmuxrc new-session -n - /usr/bin/byobu-shell ├─1567 /usr/bin/zsh ├─1789 systemctl status ssh └─1790 less giu 16 02:31:24 nappio systemd[1]: Starting ssh.service - OpenBSD Secure Shell server... giu 16 02:31:25 nappio sshd[1103]: Server listening on 0.0.0.0 port 1122. giu 16 02:31:25 nappio sshd[1103]: Server listening on :: port 1122. giu 16 02:31:25 nappio systemd[1]: Started ssh.service - OpenBSD Secure Shell server. gi We're not using ssh.socket by default anymore, so I expect ssh to honour "Port" directive from config file: @ynotssor can you please share your "/etc/ssh/sshd_config" and any file under "/etc/ssh/ssh_config.d" please ? Thank you!

Should be fixed by PR #6687 - my tests went well - additional testing and feedback welcome

I'm checking it - It's my fault TBH, to get ssh to start reliably on first boot on Debian Trixie the only way was to move it to socket activation Perhaps there's an additional route to try - unfortunately at the moment Trixie cannot be built via debootstrap due to changes to wireguard package (wireguard-tools not available in repo) I'll closely monitor the situation and find a solution asap - worst case scenario we can revert my previous changes from here PR #6586 Apologies for the inconvenience, and thank you for reporting this issue!

Hi Thomas, thanks for your report - I was thinking about a cronjob too o something that monitors dmesg nevertheless, as a mitigation to avoid a reboot when wifi stops I can suggest: sudo rmmod sprdwl_ng && sudo modprobe sprdwl_ng Definitely not elegant, but gets wifi back from the dead until the next band hop Hope it helps Ale

Dear All, in order to learn about Armbian and experiment a little, I came up with some really basic config files / scripts / patches to adapt my SBC experience to my kali needs (wants) Please bear with me for my lame practices and "coding" style - here's my repo, should it be helpful to anyone Kali Customizing & Co I just own an orangepizero3 and orangepizero2w, with a 5plus in them mail, so conent in my repo will likely cover just those Thank you for managing this project and for supporting us users Grazie 🙏🏻 Ale

After blaming: - networkmanager - ifupdown - systemd - my router - my provider - myself I tested with a separate wifi AP (not managed by my provider) and sprdwl_ng crashes to the point of being incapable of "seeing" any network again (until rmmod and insmod) when the same ESSID is broadcast both under 2.4Ghz and 5.5Ghz My wild assumption is that this driver doens't like (buggy perhaps?) to be "band-steered" Whens ticking to a single band, no issue. Hope it helps someone in my same situation

Dear All, I get frequent and random disconnection from orangepizero3 onboard wifi with armibian community (self-built) both trunk and 24.02 current kernel, 6.6.26 and 6.6.28 message is always [21738.338021] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21848.116072] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21915.426734] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection sm_state (5), status: (2)! [21915.426817] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection Vodafone-CSC failed status code:1! [21919.477424] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [[21738.338021] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21848.116072] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21915.426734] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection sm_state (5), status: (2)! [21915.426817] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection Vodafone-CSC failed status code:1! [21919.477424] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it Full logs available at armbianmonitor -u Any help/hint/solution deeply appreciated

Thank you everyone, I appreciate getting feedback from so many experts! Let me answer by point, hopefully some of my experience might be useful @Igor I get your point, Kali is mostly userspace and the convenience to have everything packaged (and rolling) in the same place - the only thing Armbian lacked was wifi injection capabilities which I solved by placing kali kernel patches in userpatches/kernel/archive/sunxi64-6.6 -rw-r--r-- 1 alex alex 17K apr 13 19:55 dwav-usb-mt-driver.patch -rw-r--r-- 1 alex alex 4,8K apr 13 19:55 kali-wifi-injection.patch -rw-r--r-- 1 alex alex 2,3K apr 13 19:55 wireless-carl9170-Enable-sniffer-mode-promisc-flag-t.patch Got them fresh from Kali's GitLab repo (an they're compatible up to kernel 6.6) Now, here's my build config file: userpatches/config-opi03.conf BOARD=orangepizero3 BRANCH=current RELEASE=trixie DEST_LANG="it_IT.UTF-8" COMPRESS_OUTPUTIMAGE=sha,xz KERNEL_CONFIGURE=no BSPFREEZE=yes CLEAN_LEVEL=debs,images,cache BUILD_DESKTOP=no BUILD_MINIMAL=yes BUILD_EXTERNAL=yes EXTERNAL_NEW=compile INSTALL_HEADERS=yes NO_APT_CACHER=yes ARTIFACT_IGNORE_CACHE=yes #KERNEL_GIT=shallow ENABLE_EXTENSIONS=kali HOST=opi03 #LOCALVERSION=-kali and here's my output from sudo apt update && sudo apt list --updateable pt-utils/kali-rolling 2.7.12+kali1 arm64 [aggiornabile da: 2.7.12] apt/kali-rolling 2.7.12+kali1 arm64 [aggiornabile da: 2.7.12] base-files/kali-rolling 1:2024.1.0 arm64 [aggiornabile da: 24.2.1-13-trixie] bluetooth/kali-rolling 5.71-1+kali1 all [aggiornabile da: 5.71-1] bluez/kali-rolling 5.71-1+kali1 arm64 [aggiornabile da: 5.71-1] command-not-found/kali-rolling 23.04.0-1+kali3 all [aggiornabile da: 23.04.0-1] dpkg/kali-rolling 1.22.4+kali2 arm64 [aggiornabile da: 1.22.4] init-system-helpers/kali-rolling 1.66+kali1 all [aggiornabile da: 1.66] init/kali-rolling 1.66+kali1 arm64 [aggiornabile da: 1.66] libapt-pkg6.0/kali-rolling 2.7.12+kali1 arm64 [aggiornabile da: 2.7.12] libbluetooth3/kali-rolling 5.71-1+kali1 arm64 [aggiornabile da: 5.71-1] libdpkg-perl/kali-rolling 1.22.4+kali2 all [aggiornabile da: 1.22.4] libpolkit-agent-1-0/kali-rolling 124-1+kali1 arm64 [aggiornabile da: 124-1] libpolkit-gobject-1-0/kali-rolling 124-1+kali1 arm64 [aggiornabile da: 124-1] linux-headers-current-sunxi64/trixie 24.2.1 arm64 [aggiornabile da: 24.2.1] linux-image-current-sunxi64/trixie 24.2.1 arm64 [aggiornabile da: 24.2.1] polkitd/kali-rolling 124-1+kali1 arm64 [aggiornabile da: 124-1] As you can see there are Armbian packages being overriden by Kali's counterpart: how may I know there's no "Frankestein" effect under the hood? I'd feel much safer knowing that Kali packages have been bootstrapped during image build itself - If I select "Bookworm" with "kali-extension.sh", the list gets much longer So I tried: Bootstrapping a kali snapshot rootfs (no kernel, no headers, no firmware, no u-boot, no dtbs, and no u-boot-menu, then proceeded installing: -rw-rw-r-- 1 alex alex 21K apr 14 11:55 armbian-bsp-cli-orangepizero3_24.2.1_arm64__1-PC13d1-Ve726-He72f-Ba537-R6632.deb -rw-rw-r-- 1 alex alex 1,7M apr 14 11:55 armbian-bsp-cli-orangepizero3-current_24.2.1_arm64__1-PC13d1-Ve726-He72f-Ba537-R6632.deb -rw-rw-r-- 1 alex alex 133K apr 14 11:53 armbian-config_24.2.1_all__1-SAfb17-B0293-R448a.deb -rw-rw-r-- 1 alex alex 225M apr 14 11:55 armbian-firmware_24.2.1_all__1-SA6b6f-B90f5-R448a.deb -rw-rw-r-- 1 alex alex 414M apr 14 11:54 armbian-firmware-full_24.2.1_all__1-SA6b6f-SMfbef-B90f5-R448a.deb -rw-rw-r-- 1 alex alex 2,4M apr 14 11:52 linux-dtb-current-sunxi64_24.2.1_arm64__6.6.16-Seb3e-D6b4a-P5d69-Cc165Hfe66-HK01ba-Vc222-B067e-R448a.deb -rw-rw-r-- 1 alex alex 94M apr 14 11:52 linux-headers-current-sunxi64_24.2.1_arm64__6.6.16-Seb3e-D6b4a-P5d69-Cc165Hfe66-HK01ba-Vc222-B067e-R448a.deb -rw-rw-r-- 1 alex alex 149M apr 14 11:52 linux-image-current-sunxi64_24.2.1_arm64__6.6.16-Seb3e-D6b4a-P5d69-Cc165Hfe66-HK01ba-Vc222-B067e-R448a.deb -rw-rw-r-- 1 alex alex 911K apr 14 11:52 linux-u-boot-orangepizero3-current_24.2.1_arm64__2024.01-S866c-P6305-H7b37-Vb97c-B11a8-R448a.deb It works a charm and no potential messing between package repos/distributions are present (hopefully), as the above packages are in a locally hosted repo which I manually added to Kali rootfs But this is a tedious work, manual and I can't say if it's good or not, to be honest it works great I'd feel it would be done the "right" way by integrating kali distrib into build scripts @going I'll definitely test KEEP_ORIGINAL_OS_RELEASE=yes and report back @c0rnelius Kali network services, especially avahi being able to broadcast services, thus giving away a penetration tester "presence", are disabled by default - in the past HCIUART was disabled by default too due to some reason I can't remember; nevertheless everything can be (re-)enabled, unmasked, etc by standard means - Kali does even include some fancy cryptroot-luks kernel patches that automatically "destroy" data on boot when full-disk-encryption is active in case of specific passwords being passed (like a dead man's switch I suppose) Thank you for your support guys!

Not strange at all, and by the way, thanks for your interest/support! I need special changes in the kernel, but I managed to get them built via armbian using userpatches I would prefer to keep armbian kernel + headers + firmware + dtb + uboot as they work perfectly I'd find the best solution to have armbian-config manage system configuration (on kali there's kalipi-config but it's raspberrypi oriented) For everything else, I'd prefer a clean rootfs, with kali repositories packages, installed directly at build time via chroot in armbian build framework If I change sources.list afterwards, I get some armbian packages mixed with kali's and vice-versa So ideally, I'd just select "Kali" instead of "trixie" or "bookworm" as distribution, while keeping the final rootfs structure armbian-pristine It isn't any different than enjoying armbian with ubuntu jammy instead of debian bookwork; do I give the idea? Specifically Kali has a lot of metapackages provididing wireless tools, metasploit and windows powershell toolkits and so on; it's specialized in offensive/defensive security; an assortment difficult to find elsewhere without major efforts

Hi @going, thanks for following up! Kali is the de-facto (in my opinion) penetration-testing and learning platform (I'm passionate about wireless) - orangepi boards are very decent hardware-wise but software support is lacking I enjoyed learning and playing around with armbian for the past 3 days, and I think it's the best framework for building self-contained small distros I'm looking towards a clean, lean, cli distro for my SBCs, kali is a great platform and Armbian with its framework works better than the patched-up google-drive solutions from vendor (kernel 6.1 vs kernel 6.6) Being a debian derivative (kali), I see the potential of converging armbian cleanliness with kali - especially since with older framework GoVanguard did it for some boards, and orangepi itself is based on a previous generation of armbian As of now, for running kali, I'm bound to RaspberryPI boards, as are the only ones with broad "mainline" kali coverage - in full honesty though I think armbian is a much superior framework than kali-arm for building I like a lot mainline support and armbian brought mainline support for both u-boot and kernel on orangepizero3 - I want to try and come up with a board config for orangepizero2w on armbian as soon as I find a kali solution! And my orangepi5plus is on its way, I want to play with it too! These topics bring out my beloved nerdiness

Dear All, I found armbian by chance and it's the best supporting linux solution for my orangepizero3 - will later start tinkering with orangepizero2w and orangepi5plus I'd love, along with Debian and Ubuntu, to have Kali selectable as distribution option - linux kernel, dtb, headers, u-boot, overlays and armbian-config would be the perfect base for it (and every other distribution imho) Being inspired by GoVanguard/karmbian, which is based on armbian's previous framework, I tried grossly "injecting" kali support into armbian branch v24.02 - but I'm lost; definitely no developer, just playing around specifically I'm stuck with "lib/functions/general/apt-utils.sh" function "apt_find_upstream_package_version_and_download_url()" - I don't know how to get kali deb packages url - kali tracker doesn't behave like Debian/Ubuntu - my clumsy approach is available at https://github.com/alexl83/build.git branch v24.02 I think orange pi boards are nice and hold potential, but manufacturer is stuck at an old forked armbian framework, old kernel and hacky dtbs - Armbian is great and I hope to get kali tools on it without "Frankensteining" Debian with overlapping repos, conflicts and pinnings Would love to get some proper support - sunxi64-current (6.6) works a charm, injection patches are ok, but even when deployed on trixie and using a kali extension script, the are overlapping packages - It would be great to have Kali distro just integrated in this framework Thanks for those who read all this Fingers crossed Alex