Hallo Ihr Lieben,
ich weiß gerade nicht ob ich zu blöd bin oder an Alsheimer leide.
Problem: ich kann mich nicht mehr direkt an meinem Raspi anmelden.
Beschreibung: Bei einer Anmeldung per PuTTY bekomme ich sofort nach eingabe des Namen "pi" ein "Server unexpectedly closed connection" zurück.
Auch per Konsole kommt schon nach der Eingabe den Namen ein PAM Failure, aborting: Critical error zurück.
Ich bin nicht fit in Sachen Linux, arbeite aber schon einige Jahre mit FHEM auf den Raspi. Ich habe den Rasp bestimmt schon ein Jahr nicht mehr direkt angesprochen.
Kann mir jemand helfen?
LG
Der Hausierer
Er ist Pingbar und fhem läuft / ist er erreichbar?
Wobei ich befürchte, das die SDCard ein Problem hat ...
Danke für die schnelle Antwort.
ja, ist pinbar und Fhem läuft und funktioniert.
ich sehe aber das ein backup von FHEM nicht läuft. Es wird nur eine "0" Byte Datei angelegt
Was gibt denn dies (einzeln) in der FHEM Kommandozeile zurück?
{qx(cat /etc/passwd)}
{qx(df -h)}
Ich denke auch, da stimmt was mit der SD Card nicht.
Zitatich sehe aber das ein backup von FHEM nicht läuft. Es wird nur eine "0" Byte Datei angelegt
Wie siehst Du das?
Hallo Otto123 schon wieder Du, Du bist ja fleißiger als die Polizei erlaubt ;)
{qx(cat /etc/passwd)} ergibt:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:x:100:103:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:104:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:105:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:106:systemd Bus Proxy,,,:/run/systemd:/bin/false
_apt:x:104:65534::/nonexistent:/bin/false
pi:x:1000:1000:,,,:/home/pi:/bin/bash
messagebus:x:105:109::/var/run/dbus:/bin/false
statd:x:106:65534::/var/lib/nfs:/bin/false
sshd:x:107:65534::/run/sshd:/usr/sbin/nologin
avahi:x:108:112:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false
fhem:x:999:20::/opt/fhem:/bin/false
mosquitto:x:109:113::/var/lib/mosquitto:/usr/sbin/nologin
{qx(df -h)} ergibt:
/dev/root 7,1G 7,0G 0 100% /
devtmpfs 460M 0 460M 0% /dev
tmpfs 464M 0 464M 0% /dev/shm
tmpfs 464M 18M 446M 4% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/mmcblk0p1 43M 22M 21M 51% /boot
Heißt das die Karte ist voll???
@Wernieman: ich habe direkt auf der Karte nachgesehen
/dev/root 7,1G 7,0G 0 100% /Sie ist voll zu 100%
Zitat@Wernieman: ich habe direkt auf der Karte nachgesehen
Konntest Du nachschauen? Also noch ein Zugriff offen? Womit?
Auf jedem falle mußt Du unnützes wegwerfen .. wie groß ist die Karte?
ja zugriff -> karte rausnehmen -> in einen anderen Rechner stecken -> und nachsehen
kein Zugriff über den Raspi
16G groß
Dann guck Dir mal die Größe vom logdir an, also /var/log/
Mit was für ein System greifst Du zu?
riesige Dateien liegen dort daemon.log und syslog z.B. je 1,6, G groß. Kann ich die einfach löschen?
Ich greife mit einem Windows 10 Rechner zu.
Ich glaube ich hatte dafür vor langer Zeit mal einen Treiber installiert. Bin aber überhaupt nicht sicher. Das ging eben einfach als ich die Karte in den Card Reader gesteckt hatte.
Dann lösche mal "eine" und probiere danach aus, ob Du wieder Zugreifen kannst.
Tip: Mache vorher einen Dump der Karte!
Besser ist löschen auf einem System, was das Linux-Dateisystem nativ kann.
Wenn es läuft, müssen wir dann uns dann ums aufräumen und darum kümmern, das es nicht wieder passiert .... aber das ist der 2. Stepp
ich habe mutig beide gelöscht. Die Karte sieht jetzt viel besser aus.
Dateisystem Gr��e Benutzt Verf. Verw% Eingeh�ngt auf
/dev/root 7,1G 3,8G 3,0G 56% /
devtmpfs 460M 0 460M 0% /dev
tmpfs 464M 0 464M 0% /dev/shm
tmpfs 464M 12M 452M 3% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/mmcblk0p1 43M 22M 21M 51% /boot
amelden kann ich mich aber immer noch nicht :-[
FHEM kann aber selber wieder auf die Karte schreiben. z.B. Update und Backup
Dann müstest Du mal ind er syslog und der authlog nach den Gründen suchen ...
also /var/log/...
Ahh, langsam dämmert es mir:
Das hier steht in der auth.log:
Oct 16 09:26:24 raspberrypi sshd[10465]: PAM _pam_init_handlers: error reading /etc/pam.d/sshd
Oct 16 09:26:24 raspberrypi sshd[10465]: PAM _pam_init_handlers: [Critical error - immediate abort]
Oct 16 09:26:24 raspberrypi sshd[10465]: PAM error reading PAM configuration file
Oct 16 09:26:24 raspberrypi sshd[10465]: PAM pam_start: failed to initialize handlers
Oct 16 09:26:24 raspberrypi sshd[10465]: PAM pam_end: NULL pam handle passed
Oct 16 09:26:24 raspberrypi sshd[10465]: fatal: PAM: initialisation failed
sehe ich das richtig, das System kann die sshd Datei nicht lesen.
und jetzt?
Versuch in der FHEM Kommandozeile:
{qx(cat /etc/pam.d/sshd)}
Wenn das nicht sinnvolles zurück gibt - da steht nichts spezielles drin. Könnte man ersetzen?
Das ist die Antwort auf {qx(cat /etc/pam.d/sshd)}
# PAM configuration for the Secure Shell service
# Standard Un*x authentication.
@include common-auth
# Disallow non-root logins when /etc/nologin exists.
account required pam_nologin.so
# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account required pam_access.so
# Standard Un*x authorization.
@include common-account
# SELinux needs to be the first session rule. This ensures that any
# lingering context has been cleared. Without this it is possible that a
# module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
# Set the loginuid process attribute.
session required pam_loginuid.so
# Create a new session keyring.
session optional pam_keyinit.so force revoke
# Standard Un*x session setup and teardown.
@include common-session
# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session optional pam_motd.so motd=/run/motd.dynamic
session optional pam_motd.so noupdate
# Print the status of the user's mailbox upon successful login.
session optional pam_mail.so standard noenv # [1]
# Set up user limits from /etc/security/limits.conf.
session required pam_limits.so
# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
session required pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
session required pam_env.so user_readenv=1 envfile=/etc/default/locale
# SELinux needs to intervene at login time to ensure that the process starts
# in the proper default security context. Only sessions which are intended
# to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
# Standard Un*x password updating.
@include common-password
und was sagt mir das nun?
Ich würde mal behaupten: An der Datei selbst liegt es nicht. Die Datei ist vorhanden und lesbar und sieht aus wie bei mir :-\
Eine Datei in Folge? Kenne mich damit aber zu wenig aus. Mal sehen ob Werner noch ne Idee hat.
Kann denn fhem die ssh-config lesen?
Kann es bei mir nicht ausprobieren, da ich auf dem Server das Logging geändert habe ...
Du meinst so?
{qx(cat /etc/ssh/ssh_config)}
funktioniert bei mir unter FHEM ;)
Also kann der User fhem es ;o)
Vielleicht einfach mal Tastatur und Monitor am raspi anschließen, und booten und mal schauen, was im boot-prozess passiert? Dann könnte man ssh ausschließen. Dann bist du auf der Konsole und wenn Du dich da auch nicht anmelden kannst, liegt es nicht an ssh.
Um zu testen, ob die SD-Karte was hat: Mal eine Datei mit einem beliebigen Inhalt anlegen und dann booten bzw. den pi auch mal vom Netzteil trennen / Karte rausnehmen und dann schauen, ob die Datei noch da ist, bzw. den gewünschten Inhalt hat.
Viele Grüße, Holger
Hallo Zusammen,
auch mit Tastatur und Monitor bin ich nicht wirklich weiter gekommen. Ich bin aber auch nicht wirklich gut an der Konsole. Auf jeden Fall bin ich zur Entscheidung gekommen, das dies wohl ein SK Karten Problem sein muss. Irgendwie wurde der Raspi auch immer langsamer. Ich habe jetzt alles neu aufgesetzt und fertig....
Danke nochmal für die Tipps und Hilfen