Moinsen!
Am 15.01. habe ich an einer meiner Arch-Kisten per ssh ein Update gefahren. Ich war an zwei Konsolen angemeldet; eine als User, eine als root. Während des Updates hat es den User 'rausgeschmissen, root blieb unbehelligt, aber seit diesem Moment kann sich kein User mehr anmelden...root aber schon - sowohl direkt an der Konsole, als auch per ssh.
Außerdem hat seit dem diese Arch-Installation irgendwo einen Knoten im System:
# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● avahi-daemon.service loaded failed failed Avahi mDNS/DNS-SD Stack
● icecream.service loaded failed failed Icecream Distributed Compiler
● plymouth-deactivate.service loaded failed failed Deactivate Plymouth Boot Screen
● systemd-timesyncd.service loaded failed failed Network Time Synchronization
user@618.service loaded failed failed User Manager for UID 618 (<- sddm)
# journalctl -b (die relevanten Teile)
Jan 18 11:16:22 vintage systemd[1]: systemd-timesyncd.service: Main process exited, code=exited, status=203/EXEC
Jan 18 11:16:22 vintage systemd[1]: systemd-timesyncd.service: Failed with result 'exit-code'.
Jan 18 11:16:22 vintage systemd[1]: Failed to start Network Time Synchronization.
Jan 18 11:16:22 vintage systemd[1]: systemd-timesyncd.service: Service has no hold-off time, scheduling restart.
Jan 18 11:16:22 vintage systemd[1]: systemd-timesyncd.service: Scheduled restart job, restart counter is at 1.
Jan 18 11:16:22 vintage systemd[1]: Stopped Network Time Synchronization.
Jan 18 11:16:22 vintage systemd[1]: Starting Network Time Synchronization...
Jan 18 11:16:22 vintage systemd[434]: systemd-timesyncd.service: Failed to connect stdout to the journal socket, ignoring: Permission denied
Jan 18 11:16:22 vintage systemd[1]: Started Show Plymouth Boot Screen.
[...]
Jan 18 11:16:23 vintage avahi-daemon[509]: open(/run/avahi-daemon//pid): Permission denied
Jan 18 11:16:23 vintage systemd[1]: Started Apply cpupower configuration.
Jan 18 11:16:23 vintage avahi-daemon[509]: Failed to create PID file: Permission denied
Jan 18 11:16:23 vintage systemd[1]: avahi-daemon.service: Main process exited, code=exited, status=255/n/a
Jan 18 11:16:23 vintage systemd[1]: avahi-daemon.service: Failed with result 'exit-code'.
Jan 18 11:16:23 vintage systemd[1]: Failed to start Avahi mDNS/DNS-SD Stack.
[...]
Jan 18 11:16:24 vintage systemd[1]: plymouth-deactivate.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Jan 18 11:16:24 vintage systemd[1]: plymouth-deactivate.service: Failed with result 'exit-code'.
Jan 18 11:16:24 vintage systemd[1]: Failed to start Deactivate Plymouth Boot Screen.
Jan 18 11:16:24 vintage systemd[1]: Started Simple Desktop Display Manager.
Jan 18 11:16:24 vintage systemd[1]: icecream.service: Main process exited, code=exited, status=100/n/a
Jan 18 11:16:24 vintage systemd[1]: icecream.service: Failed with result 'exit-code'.
[...]
Jan 18 11:16:25 vintage systemd[565]: user@618.service: Failed to connect stdout to the journal socket, ignoring: Permission denied
Jan 18 11:16:25 vintage systemd[1]: Started Session c1 of user sddm.
Jan 18 11:16:25 vintage systemd-logind[507]: New session c1 of user sddm.
Jan 18 11:16:25 vintage systemd[565]: pam_unix(systemd-user:session): session opened for user sddm by (uid=0)
Jan 18 11:16:25 vintage systemd[1]: user@618.service: Failed with result 'protocol'.
Jan 18 11:16:25 vintage systemd[1]: Failed to start User Manager for UID 618.
Jan 18 11:16:25 vintage sddm-helper[563]: pam_systemd(sddm-greeter:session): Failed to create session: Start job for unit user@618.service failed with 'failed'
Jan 18 11:16:25 vintage sddm[533]: Greeter session started successfully
Jan 18 11:16:25 vintage sddm-helper[563]: [PAM] Closing session
Jan 18 11:16:25 vintage sddm-helper[563]: pam_unix(sddm-greeter:session): session closed for user sddm
Jan 18 11:16:25 vintage sddm-helper[563]: [PAM] Ended.
Jan 18 11:16:25 vintage sddm[533]: Auth: sddm-helper exited with 3
Jan 18 11:16:25 vintage sddm[533]: Greeter stopped.
Jan 18 11:16:25 vintage systemd-logind[507]: Removed session c1.
Jan 18 11:16:25 vintage systemd[1]: Removed slice User Slice of sddm.
Es ist mir ein Rätsel und ich finde bislang keinen Übeltäter. Kernel, systemd* und intel-ucode habe ich testhalber auf die vorige Version gesetzt: Kein Unterschied. Permission auf /tmp und /run sind ok. Auch bei anderen, nahezu identischen Arch-Kisten bei mir sonst keinerlei Probleme.

Was übersehe ich denn da? Wald? Bäume? Seltsam. Hatte seit Jahren nie auch nur annähernd solch argen Probleme (zumindest keine, die man nicht recht flott selber/per Community beheben konnte).
Was ist die Fehlermeldung beim Anmelden des "rausgeschmissenen" Benutzers?
Was passiert bei einem Verbindungsversuch mittels:
ssh -vvv …
?
Was sagt das journal des sshd bezüglich der gescheiterten Anmeldungen?

Wie sehen denn folgende Dateien bei dir aus?
/etc/ssh/sshd_config
/etc/passwd
/etc/group
Hast du eine Firewall in Betrieb?
iptables -S
PS: was steht in folgender Datei:
/etc/environment
?
ich hatte mal ähnliches, da war eine volle Root-Partition schuld.
...an ssh wird's mit Sicherheit nicht liegen, da ich mich als User ja genausowenig lokal anmelden kann. Deshalb lasse ich das drumherum von ssh zunächst einmal weg.
Da die User-Home per ecrypt verschlüsselt sind, habe ich zum weiteren testen einen Test-User ohne Schnickschnack angelegt.
Wer auch immer von den Usern, also auch "test", sich einloggt, bekommt folgenden um die Ohren gehauen:
# ssh test@192.168.0.126
test@192.168.0.126's password:
Last login: Thu Jan 18 12:21:11 2018 from 192.168.0.122
Could not chdir to home directory /home/test: Permission denied
/bin/bash: Permission denied
Connection to 192.168.0.126 closed.
# ls -lh /home/
insgesamt 12K
[...]
drwx------ 2 test test 4,0K 18. Jan 08:28 test
# ls -lh /bin/bash
-rwxr-xr-x 1 root root 809K 14. Feb 2017 /bin/bash
ein journal -f am Ziel-Host zeigt in diesem Moment
Jan 18 12:24:58 vintage sshd[7963]: Accepted password for test from 192.168.0.122 port 49026 ssh2
Jan 18 12:24:58 vintage sshd[7963]: pam_unix(sshd:session): session opened for user test by (uid=0)
Jan 18 12:24:58 vintage systemd[1]: Created slice User Slice of test.
Jan 18 12:24:58 vintage systemd[1]: Starting User Manager for UID 1003...
Jan 18 12:24:58 vintage systemd[7966]: user@1003.service: Failed to connect stdout to the journal socket, ignoring: Permission denied
Jan 18 12:24:58 vintage systemd-logind[507]: New session c8 of user test.
Jan 18 12:24:58 vintage systemd[1]: Started Session c8 of user test.
Jan 18 12:24:58 vintage systemd[7966]: pam_unix(systemd-user:session): session opened for user test by (uid=0)
Jan 18 12:24:58 vintage systemd[7967]: pam_unix(systemd-user:session): session closed for user test
Jan 18 12:24:58 vintage systemd[1]: user@1003.service: Failed with result 'protocol'.
Jan 18 12:24:58 vintage systemd[1]: Failed to start User Manager for UID 1003.
Jan 18 12:24:58 vintage sshd[7963]: pam_systemd(sshd:session): Failed to create session: Start job for unit user@1003.service failed with 'failed'
Jan 18 12:24:58 vintage sshd[7969]: error: /dev/pts/2: Permission denied
Jan 18 12:24:58 vintage sshd[7968]: Received disconnect from 192.168.0.122 port 49026:11: disconnected by user
Jan 18 12:24:58 vintage sshd[7963]: pam_unix(sshd:session): session closed for user test
Jan 18 12:24:58 vintage systemd-logind[507]: Removed session c8.
Jan 18 12:24:58 vintage systemd[1]: Removed slice User Slice of test.
Stutzig macht mich ja hier schon Failed to connect stdout to the journal socket, ignoring: Permission denied

/etc/passwd und /etc/group lasse ich ebenfalls zunächst außen vor. Da hat sich nichts geändert (bis auf den User "test") - es sei denn, Du hast genau dafür eine Idee, dann hole ich es gerne nach.

Eine Firewall oder sonstige iptables-Einstellungen sind keine an den lokalen Systemen. Dafür gibts im LAN eine eigene Kiste für das INet.

/etc/environment ist leer, bzw.
#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#
jg72 schriebich hatte mal ähnliches, da war eine volle Root-Partition schuld.
🙂 Ja, das hatte ich auch schon einmal. DAS habe ich aber als erstes ausgeschlossen 😉
Höchstwahrscheinlich sind die Permissions deiner Root-Partition defekt.
ls -alFd /
Sollte so aussehen:
$ ls -alFd /
drwxr-xr-x 23 root root 4096 Jan 11 17:50 //
schard schriebHöchstwahrscheinlich sind die Permissions deiner Root-Partition defekt.
ls -alFd /
Sollte so aussehen:
$ ls -alFd /
drwxr-xr-x 23 root root 4096 Jan 11 17:50 //
Aha:
# ls -alFd /
drwxr-x--- 18 root root 4096 16. Jan 18:21 //
Aber wie kommt's? Und wie bekommt man es wieder hin?
Ganz einfach:
chmod 755 /
Jeder muss den Root-Ordner (/) lesen (r) und betreten (x) können!
Warum sich die Rechte verändert haben? K.A.
schard schriebGanz einfach:
chmod 755 /
Jeder muss den Root-Ordner (/) lesen (r) und betreten (x) können!
Selbstverständlich 😉
Und ja, chmod 755 / half. Das war ja mal wieder ZU einfach. Auch nach Reboot alles wieder im Lot. Sehr sehr seltsam...
Immerhin: Problem gelöst. Toll! Vielen vielen Dank! Werde dann mal ein Auge darauf halten, was den Fehler überhaupt produziert hat. Aber das ist eine andere Geschichte.