I made a fresh boot of the latest v8.21 on my i5 laptop with the PC BIOS/CSM distribution in server mode.
The install was actually done on a 2nd USB stick from an i5 mini PC, from the first Rufus USB installing stick, of course also on this mini PC.
(Then the 2nd USB stick with the installed DietPi was used to boot the i5 laptop.)
Things went fine- wifi worked, software installs ( Jellyfin, midnight commander, Dashboard , etc) and deletes ( vnc, x11, LXDE) were fine, and after a couple reboots, and custom password setup, ā¦
I tried SSH from another Windows machine via PuTTY ( and Windows command line, and winscp) with the default Dropbear SSH server. Got denied root or DietPi user access.
Changed over to openssh server and then back to dropbear with no luck, and several reboots.
Pic above shows #journalctl -u ssh.service
and #ip a.
Funny enough my actual DietPi IP is 192.168.0.18, not .12 that journalctl output shows ! I also had both WiFi and Ethernet enabled, but used WiFi ( eth not available.)
Also I had made updates to the DietPi.txt file, to have the correct -2 for openssh when it showed -1; and then back to -1 for Dropbear when it still showed -2 after reboot, once I had switched back.
The # cat ~dietpi.conf did correctly show as in the link above.
Noticed that the time zone was still at the default utc ( London) after reboot even though I had changed the time zone to an Asia city !
So somethings are just wrong with DietPi configuration!
This output shows which IP tried to connect via SSH to your device, it is not the device IP itself.
Can you try to login locally and chagne the SSH password?
Is it also possible that you run the first boot setuo locally and on SSH you use a different keyboard layout (and bc of this you type a flase password)?
What does it mean to say SSH IP is different? Sorry bit of a Linux noob here
Isnāt the SSH password the same as the root or DietPi password ( all same in my case, including the global password: changed as usual from the menu when prompted during setup.)
Yes my setup as I said was on a different PC with a different keyboard. But I did check both PC keyboards ( one K400+ and the other a Bluetooth mini keyboard): same keys, same password as I typed in notepad++ to confirm.
So looks like the issues might have arisen from install on one PC, and then subsequent boot and setup on anotherā¦but this is quite common, and this should not occur !
The system donāt matter where DietPi was installed on. User and password are part of the entire config and not linked to a hardware. And yes, SSH password is same as on local consol.
If possible, login locally and change the password again. Make sure you have correct country / local setting on the local console. By default, we use UK keyboard layout.
so 192.168.0.18 is your DietPi device and 192.168.0.12 is the machine from where you tried to connect to your DietPi via SSH, probably a desktop PC/ laptop?
Everything is fine with the IPs, SSH IP is the IP of your device, you only have this one, donāt worry about this
Itās not about the keyboard, but which keyboard layout you set in your OS. I have a german keyboard but when I use UK layout and I press Z, the operating system shows an Y. So what you see on your keyboard is not always what your operating system receives. It depends on your localization settings and as Joulianr already set, the default layout is UK, which can diver from the layout of the machine you use for SSHing into your DietPi.
The problem was auto locale setting in the DietPi.txt file, which by default was set to c.utf-8.
This did not allow the special ā@ā in my original password !
So I changed the password to small letters only and had SSH access.
Then, upon a hunch, I changed auto locale to en_us.utf-8, changed back my password to the original with ā@ā , and rebooted.
SSH access worked.
( Before above I had also changed keyboard from āgbā to āusā and used the DietPi device keyboard for the ssh device, but that didnāt work with the ā@ā password.)
Before changing password, and after the failed SSH with ā@ā password, I noticed this error message on the console:
I would like to shrink my backup OS so it doesnāt keep 2x in size everytime.
So I thought it would be nice to ask Bing Skype gpt a quick way such that I donāt have to copy and paste from GitHub all the time to run this script ā¦the script is invoked correctly from the terminal ( I havenāt gone through it since I spent a lot of time accessing Jellyfin at port 8096 only to read later DietPi Jellyfin is at 8097 !)
But there seems to be a text encoding problem?
Anyway I can run the script manually on another USB stick with a 2nd DietPi instance on same PC to backup and shrink the first USB DietPi image when my configs are done
What do you mean it is not your script? As far as I understand, you tried to create a new alias in /root/.bashrc, right? And there is a syntax error in the lines you added. Or what is the exact problem?
The text encoding error comes from a mismatch between c.utf-8 and en_us.utf-8, due to how @MichaIng coded his dietpi-imager script, as far as I can tell.
But I donāt see anyone explaining the difference.
Going back to c.utf-8 would likely mean that I cannot use a password with special characters which is how this thread startedā¦so I will take the lesser evil
The dietpi-imager does not touch the content of the image/filesystems, so is unrelated.
The C.UTF-8 vs en_US.UTF-8 is only responsible for the output language of some programs (those which support different locales), but has no effect in keyboard/password inputs. Also C.UTF-8 is mostly identical to en_US.UTF-8, as US English is commonly the default.
The only thing which affects password input is the keyboard layout. We do since some versions ago already prompt for changing/selecting the keyboard layout on first boot (skipped if it has been changed in dietpi.txt, AFAIK), when being connected via local console, so assure no such issues happen. Of course one must select the correct layout which matches the attached keyboard.
Best to assure the password is entered correctly, e.g. if the exact keyboard layout is not known for sure, is probably to do first run setup via SSH.