OS: Kali 2021.2
System: Rpi4/Rpi0w

Quick Rundown:
Environment: Kali linux 2021.2 ARM image with lightDM graphical environment set to autologin by modifying /etc/lightdm/lightdm.conf on lines 126 and 127. (Default user set to "kali"; user timeout set to "0").

Problem: When systemctl default is changed from "graphical" (boots to desktop) to "multi-user" (boots to terminal/no desktop), the auto login stops working. This makes sense because auto login is controlled by the lightDM.conf file and if lightDM is not launched, the lightdm.conf file is irrelevant. So I need a way to set autologin for multi-user.target

What I've tried:
modify lightdm.conf to allow auto login. Result: Works for desktop environment, does not work for booting straight into terminal.

modify a pam.d file that I read about on another forum by commenting out one line. Result: no effect on terminal login issue, causes graphical auto login to stop working. Reverted the pam.d file to its original state and graphical auto login works again, CLI auto login (expectedly) still does not.



Hello all,

I have gotten Kali to auto login for me in the lightdm graphical environment which is used by the Kali ARM image for Raspberry Pi by editing the lightdm.conf file to set the default user. Now when I boot Kali, I do not need to enter a username or password; it goes straight to the desktop and I can do this as either the default user "kali" or as root. But I ultimately will not require a graphical environment at all. Raspberry Pi, especially the 0w, is rather "challenged" in the hardware department which comes as no surprise, so an obvious benefit would be disabling the desktop environment all together to conserve system resources. I can do this with the following:

and then rebooting
Upon rebooting the system, it boots directly to a terminal the way the old Backtrack OS used to which is exactly what I wanted, but unfortunately the auto login will not work. Looking at the above command, one can easily note the argument "multi-user", which implies that there are...well, multiple users. And how is the computer to know which user to log in until user input is provided? Therein (I believe) lies the problem.

Therefore, I tried:
and
both of which were not valid as "kali.target" and "root.target" do not exist, so the terminal says. But it was worth a shot I suppose.

I am looking for a solution to auto-login while multi-user.target is the default boot parameter (or a different parameter can be used if necessary to accomplish this). I have scoured the internet with no successful configuration yet discovered. Several walkthroughs also mention needing to modify a pam.d file in /etc/, however I have found that by commenting out the appropriate line of the pam.d file, not only does auto login not work when set to multi-user, it also stops working with graphical boots. So modifying the pam.d file is obviously not the answer I was looking for.

The purpose behind this task is to run a headless Raspberry Pi (no mouse/no keyboard/no monitor) that I can simply turn on and know that in 60 seconds I'll be booted up and logged in. Once the login is complete, the SSH service can start automatically and I can use an SSH client on a remote device to log in to the Pi and control it remotely. While I am technically able to make this work in its current state by just booting to the desktop, it would be nice to not have to load a full blown graphical environment bogging the system down, especially for the lightweight Pi0w.

Thanks for any help anyone can give me for enabling autologin while multi-user.target is the default.

The easiest solution is to change the default back to graphical.target. Any specific reason you can't do that?
If not, try something like this.

1 members found this post helpful.

ondoho,

Thanks for the link. There's no reason I can't just switch back to graphical, it's just a personal preference given the Raspberry Pi 0w has very limited system resources. I would rather not tie up half of those very few resources maintaining a graphical environment that I'm not even looking at. But I suppose the x11vnc server could handy in addition to SSH. So it's not all bad. I admit I haven't tried to run a VNC server on a Pi0w yet, but I'm not optimistic that it will run smoothly. I'd rather just load the barebones into a terminal and control it over SSH.

Kali is an advanced and highly tweaked distro for penetration testing which is not what you seem to be doing with it by enabling auto login to root.

1 members found this post helpful.

uteck -

I am well aware of what Kali Linux is; I've been using it since it was Backtrack 5r3. There are numerous tools in Kali Linux which require root privileges to run properly, as well as many others which do not. At any rate, your response offers nothing towards helping me figure out how to enable auto login in multi-user.target.

As you only have 5 posts on this site, 3 when when I responded, then you probably have missed all the posts by total noobs that have no idea how to use Linux, let alone Kali, so anyone asking for Kali help here is suspect.
As such a long time user of Kali, then you should be familiar with the forum at their site, for their distro with special tools that need auto-login root access.

Scroll down to the top answer:
https://askubuntu.com/questions/1687...-tty-upon-boot

1 members found this post helpful.

I have not played with kali much but the latest version is supposed to be like a "regular" distribution. Normally ssh if enabled as a service should automatically start sometime after networking and having a user logged in before you can access the Pi from a remote client is not a requirement unless your system is configured differently. Under normal circumstances your reasons for auto login do not make sense.

However, virtual consoles are controlled by getty and since kali uses systemd you need to create an override configuration to automatically login.

https://wiki.archlinux.org/title/getty

1 members found this post helpful.

This is confusing, given that you were originally trying to modify lightDM, which is a display manager for graphical sessions.
So I assumed you still want a GUI (which can also be started from a command line).

Also, the graphical.target doesn't need to actually start a graphical environment. My system still uses graphical.target as default, yet it boots into a tty where I start X manually.

I wonder how you solved this meanwhile?