rpi 5, imager v2.0.7, latest asl release from april. headless, no monitor.
options in imager as per install instructions, ssh enabled/password, acct pi created with password. done this many times before but not in the last 6 months...
now i cannot even have bitwise connect to ssh/terminal session. seems to get past authentication but then gets refused - cannot connect with my favorite tool bitwise nor via command line ssh session on winblows.
what the heck am i missing ??? gotta be something stupid i forgot or is missing. rebuilt SD many times. same result. almost like the pi acct didnt get created.
i do see the "ssh" file on the disk prior to trying it, so seems ssh is enabled ???
yes... followed the instructions you posted, just like i have in the past. been installing asl3 since buster, bullseye, bookworm, and now trixie (this is my first experience with trixie).
powered on rpi... waited as you must always after a new sd is installed as there are a bunch of initial scripts that must be run as you know.... pinged the rpi, both via wifi and ethernet (on a diff address) and it replies as expected. Yes, i can connect to the web page, but i cannot get past the login screen as it does not seem to accept the login/pwd.
this has gotta be a bonehead me problem, missing something obvious. ssh replies sorta indicate that i got trough the authentication only to have the shell close? the following is the output from my ssh connect attempt with bitwise client (similar happens with ssh commandline).
17:23:31.935 Current date: 2026-06-07
17:23:31.935 Started a new SSH connection.
17:23:31.966 Connecting to SSH server 10.0.0.135:22.
17:23:31.974 Connection established.
17:23:31.987 Server version: SSH-2.0-OpenSSH_10.0p2 Debian-7+deb13u4
17:23:31.987 First key exchange started. Cryptographic provider: Windows CNG (x86) with additions
17:23:32.002 Host key algorithm list after reordering: RSA/sha2-512,RSA/sha2-256,Ed25519,ECDSA/nistp256,RSA/sha1,ECDSA/secp256k1,ECDSA/nistp521,ECDSA/nistp384.
17:23:32.026 Received host key from the server. Algorithm: RSA/sha2-512, size: 3072 bits, SHA-256 fingerprint: ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
17:23:32.035 First key exchange completed using Curve25519 (strict). Connection encryption and integrity: aes256-gcm, compression: none.
17:23:32.046 Attempting password authentication.
17:23:32.146 Authentication completed.
17:23:32.146 Extension "no-flow-control" disabled.
17:23:32.376 Terminal channel opened.
17:23:32.376 Opened session channel 0.
17:23:32.376 Synchronizing with server's host keys.
17:23:32.398 Host key synchronization completed without saving or erasing any keys. Number of keys received: 3.
17:23:32.406 Terminal channel: PTY request accepted.
17:23:32.406 Terminal channel: Terminal shell opened.
17:23:32.446 Terminal channel: Terminal process launched.
17:23:32.455 Terminal channel: EOF received.
17:23:32.455 Terminal channel: Received exit code 1.
17:23:32.455 Terminal channel closed by server.
17:23:32.455 Closed channel 0.
notice at the bottom... Last login: Sun Jun 7 18:32:23 2026 from 10.0.0.37
This account is currently not available.
Connection to 10.0.0.135 closed.
i@10.0.0.135's password:
hostfile_replace_entries: hostkeys_foreach: No such file or directory
update_known_hosts: hostfile_replace_entries failed for /.ssh/known_hosts2: No such file or directory
Linux xxx-asl 6.18.33+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.33-1+rpt1 (2026-06-01) aarch64
Welcome to AllStarLink v3
A CLI menu is accessible by typing 'sudo asl-menu'
The Asterisk CLI is accessible by typing 'sudo asterisk -rv'
Last login: Sun Jun 7 18:23:32 2026 from 10.0.0.37
This account is currently not available.
Connection to 10.0.0.135 closed.
Loading wasm program... done.
Connecting to pi@10.0.0.135... pi@10.0.0.135's password:
Linux xxx-asl 6.18.33+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.33-1+rpt1 (2026-06-01) aarch64
Welcome to AllStarLink v3
A CLI menu is accessible by typing 'sudo asl-menu'
The Asterisk CLI is accessible by typing 'sudo asterisk -rv'
There "ASL" scripts have no dependencies on the login/username.
I haven't heard of anyone having "login" issues for a while. There were some issues with the initial 2.0.x versions of the Raspberry Pi Imager but things have been behaving for the past few months. One thing that you could "try" would be to install/use the 1.9.6 version of the app.
well... the account ID apparently now matters (which it shouldnt)...
using the login of "asl" works, and ssh came right up as expecdted, no other changes.
this presents a security risk obviously (if only asl works)... this coupling hasnt been there since before bookworm....
seems like this is something that must be corrected, as the init scripts must be able to work with any chosen login id, not only "asl"... i so infrequently fiddle with this stuff but once/year, and forget all the nuances every time i have to dip into the crypt.
i also instantly got into the cockpit web page, no problem, looks like it always has.
allan, is this something you think should be a candidate for a bugfix?
Good to hear that "asl" worked for you. Personally, I have never used "pi" or "asl" as my login. But, at the same time, I would not have expected issues with using any name other than those that are part of the base OS template (those found in /etc/passwd).
Is this a bug? Possibly? But, if so, it would be either a "Trixie" or Raspberry Pi Imager issue.
reason i ask, is i have no idea how to report a bug. should i report it ? how ? suggestions ? i am not a asl expert by any means. i have been asked to integrate it into our repeater to gain Echostink capabilities.
but yes... sensitivity to a login ID is NOT good, and the issue (unwanted dependency) could be related to any component as i dont know the boundaries/roles/responsibilites of them. i just consider all of it the "codebase". not likely to be Debian itself...
i do recall a few years ago this was also the case where some dependency on login ID crept into the codebase crypt somehow, which is why i was surprised it's back. i think it was the imager back then, u had to run a specific version of the rpi imager.
lot of scripting kicks off and runs once on a fresh SD build on first boot that is very ASL specific.
Honestly, there's very little ASL specific scripting that runs on the first boot. The scripts are at GitHub : asl3-pi-image with the long startup waits all relating to ensuring you are staring off with the latest up-to-date packages.
As for login(s), there was a push to move away from creating images with pre-defined logins and passwords (e.g. "pi" + "raspberry") and that's one reason why we are using the Raspberry Pi Imager with its customisation options allowing you to create your own login and password.
I can/will add a "create an ASL image with a pi login" item to my TODO list to see if I can repro your issue.
i can understand why any pre-made logins/accts are undesireable, its convienient for us hobbyists to have them, but doesnt pass security scrutiny.
all i did to reproduce the issue was to go through the imager (v2.0.7, which may matter) using "pi" as the login/acct with a 10 character password.
to "fix" it, all i did was create in the imager tool an account named "asl", and *poof* it all worked as i had been used to and expected, creating the home directory of "asl" on trixie.
i did NOT try imaging again with a tertiary account id that was NOT either "pi" or "asl" to know for sure if any non "asl" account would work, or if its sensitive to "pi" specifically. that is still ambiguous.
since i am just starting this project, i can readily try another acct name and let you know without really losing anything. i'll try that today... i'll create an "alf" ( in honor of Alfred E. Newman) account in the imager and give it a rip.
By default, a root user can’t connect to ssh. If the account you are using for ssh is a root or root- equivalent you either need to use a non-root account and rely on sudo to run commands, or you need to edit the ssh_config and look at the PermitRootLogin directive. Also look at require key based login and disallow password based.
Earlier in this thread I suggested using the Raspberry Pi Imager to flash a minimal Raspbian (non-ASL) Trixie image using the same customisation options ("pi", password, Wi-Fi, ...). That would help identify if the issue relates to ASL.
proved - if you create an acct named "pi" in the imager (2.0.7), you cannot establish an ssh session, nor login to the webpage.
reflashed, with an account named "alf", and all is well, login/ssh is fine, web page as well.
reflashed, with an acct named "pi", and once again, i cannot establish a ssh session. as before the authentication occurs fine, but the channel is closed (see notes above).
reflashed, with an acct named "asl", and all is well...
so i guess the moral of the story is, that if any acct name is used OTHER than "pi", all is likely well.
We can certainly update the ASL Manual. If would be great if you could create an issue @ GitHub: ASL3-Manual : Issues. Else, I'll add an issue ... but you need to give me a few days (kinda "busy" right now)
you can use any username you want, I did a fresh install this morning and set the username to anarchy with my normal password and had no trouble. I am more curious as to how you are writting the image to sdcard
jory, you must not have read carefully the context of the thread as the answer to the questions u have are in it.
of course you will have no problem with the username of anarchy... i would expect that given the tests i ran above... your results are consistent with mine.
if you read the flow of events, you would know it is an apparent issue ONLY with the acct/username of "pi" AND only if using the asl3 applicance download as discussed in the install instructions using the pi imager.
username of "pi" DOES work with generic Debian/Trixie install, but if using the https://rpi.allstarlink.org/latest.json custom repo as per the appliance instructions... NO GO...