Reset der "passwd" Datei / "root" Einstellungen?

[wrybit]

Hy,

ich habe leider einen fatalen Fehler gemacht ... und brauche nun Hilfe.

Nach der installation von "bash" wollte ich diese CLI für den "root" aktivieren.
Also habe ich in der "/etc/passwd" die Einstellungen angepasst.
Leider dabei unachtsam "/bin/bash" anstatt "/opt/bin/bash" eingetragen.
Logische konsequenz: Ich kann mich nicht mehr als "root" via ssh einloggen.

1. "root" darf auch nicht via FTP drauf (Synology default) ... änderbar?
2. SU darf nur "root" ausführen (danke ...)
3. SUDO darf ich nur als "root" installieren (habe ich leider noch nicht)
4. ipkg kann nur als "root" effektiv ausgeführt werden
5. Telnet hat das selbe Problem wie SSH

Client:~ user$ telnet 192.168.178.39
Trying 192.168.178.39...
CubeStation login: root
Password:
login: cannot run /bin/bash: No such file or directory
Connection closed by foreign host.​

6. Die "passwd" Datei kann nur als "root" abgespeichert werden (als "admin" kann ich meine Fehler sehen)

Als "admin" komme ich noch via SSH auf die Kiste aber das hilft mir leider
wenig wenn ich mich nicht Irre. Ich habe eine CS407.fw634 mit 4TB also ..
schnell mal Daten wo anders Hin .. ist auch nur schwer möglich.

Kann ich durch Firmware update oder ähnliches das ganze Reseten?
Oder gibt es eine "fw patch" mit dem ich da einen default einstellen kann?
Kann man SSH von aussen zwingen eine andere CLI zu nutzen?

Hat irgendeiner eine Idee. .... so ein shit.

 

[itari]

hi wrybit,

ich denke, nur ein Reset des Systems (4 Sek. vorn / 4 Sek. hinten) bringt es wieder hin (Reset Kennwort und IP). Musst, glaube ich, die Firmware neu installieren, Daten bleiben unangetastet. Und dann gehts wieder.

Tipp: Mach solche Änderungen nicht in der /etc/passwd, sondern im Shell-Startup-Skript des Benutzers root: /root/.profile (/opt/bin/bash am Ende der Datei). Wenns falsch wird, bekommst höchstens ne Fehlermeldung, kannst aber mit der normalen Shell weiterspielen. Und legt dir einen zweiten Benutzer mit der ID=0 in der /etc/passwd an (mit Standard-Shell). Dann kannst dich auch immer mit dem einloggen und hast root-Rechte. Noch besser ist, wenn du dir sudo installierst ...

 

[wrybit]

Problem erfolgreich gelöst

Danke itari!

System Reset, hat das Problem gelöst. Jedoch muss man bei der CS407 den
Reset Button zwei mal zu je 4 sec. innerhalb von insgesamt 10sec. drücken.

Jedoch bringt es ne Menge Arbeit mit sich alles neu einzurichten. User ... etc.
Da wäre eine Möglichkeit alle Einstellungen die ja über verschiedene Config-
Dateien verstreut sind, mit einem Script zu Backupen und später wieder
zurück zu schreiben. ... Vielleicht schreibe ich das mal als Feature-Request
an Synology.

Egal ... mein Problem ist erstmal gelöst. Ging leicht und ohne Problem in 10 min.

Greez WrYBiT

 

[itari]

klasse, das es nu wieder geht.

Die User usw. kann man mit der "Konfigurations-Sicherung" sichern und auch wiederherstellen. Schau mal in den Disk-Station-Manager ...

 

[raoul.d]

wiederherstellung der shell für root - restore / recover root shell in passwd

ich habe leider einen fatalen Fehler gemacht ... [...]

Nach der installation von "bash" wollte ich diese CLI für den "root" aktivieren.
Also habe ich in der "/etc/passwd" die Einstellungen angepasst.
Leider dabei unachtsam "/bin/bash" anstatt "/opt/bin/bash" eingetragen.
Logische konsequenz: Ich kann mich nicht mehr als "root" via ssh einloggen.

folgende Lösung ist mindestens zutreffend für DS207+
Voraussetzung ist irgendeine Möglichlichkeit, in /etc/ Dateien editieren zu können, sei es shell (telnet, ssh), web-backend... und die Möglichkeit zum Neustart - web-backend, Stecker raus(?)

Sicherheitslücke und Rettungsring war bei mir /etc/crontab mit -rw-rw-rw-

Da ich mich nicht an irgendein chmod an dieser Datei erinnere, hoffe ich, das sind die Standardberechtigungen.

Erst war der Plan, darüber mit sed die /etc/passwd zu editieren, dann fiel mir der einfachere weg mit chmod und Handarbeit ein. Also:

22     18      12      9       *       root    chmod 666 /etc/passwd

in meiner crontab steht eine Kommentarzeile mit den Spaltenbedeutungen.
Die Ausführungszeit ausreichend bemessen, da die Syno ja nicht rast beim booten und die crontab vor dem Ausführungstermin ja geladen sein muss. (obiges war original der 12.9. 18:22)

Ich habe gar nicht erst versucht, den crond zu restarten (root privileges?), da ich über das web-backend neustarten konnte und dabei mit Sicherheit auch den crond erwischte.

Nach dem Neustart sollte man die /etc/passwd auf dem gleichen Weg wie vorher die crontab bearbeiten können:
/bin/bash wieder in /bin/ash (oder /opt/bin/bash) ändern --- you got it!

der root-SSH-Login funktioniert sofort wieder.

Jetzt aber vor weiteren Experimenten mit bash:

ln -s /opt/bin/bash /bin/bash

Danach je nach persönlichem Geschmack oder Sicherheitsbedürfnis /etc/passwd wieder auf 644 (go-w) zurücksetzen.

Und am besten - soweit ich gelesen habe - vor Upgrades oder so die root shell (in passwd) auf /bin/ash zurücksetzen!

(Man könnte ja auch den symlink /bin/ash statt auf busybox auf /opt/bin/bash zeigen lassen, wenn Upgrades das rückgängig machen, funktioniert trotzdem noch alles.)

---

Die andere Lösung über ein .pat-File ist meinerseits daran gescheitert, dass meine Geduld nicht ausreichte herauszufinden, wie man die Checksum-Datei mit Werten füllt, damit die Box (m)ein Script frisst.

Wenn jemand dafür die Lösung findet, immer her damit, das ermöglicht den mMn elegantesten Weg. Ich war schon drauf und dran, den Syno-Support zu fragen, ob sie mir ein Recovery-Script 'signieren'...

---

Schlussbemerkung:

das ganze habe ich hier falllengelassen, weil ich die Tage erst wieder festgestellt habe, dass es deutlich mehr Fragen als Antworten gibt (zumindest qualifizierte - "das Problem habbich auch, hat jemand ne Lösung? *schrei*").
Und ich möchte jeden ermutigen, seine Antworten zu veröffentlichen anstatt sich alleine zu freuen.

Grz.,
E.

 

[dawolf]

Ich habe das admin Passwort mit dieser Anleitung zurueckgesetzt: http://www.synology.com/wiki/index.php/How_to_Reset_the_Synology_System

Der Reset Knopf setzt aber nur das "admin" und "guest" passwort zurueck (auf leer), als root habe ich mich daher immer noch nicht anmelden koennen, dafuer bin ich wieder ins web interface gekommen (als admin, ohne passwort). Dort einfach das admin Passwort setzen und mit diesem geht dann der root login auf der shell auch wieder.

 

[lstrojny]

Weitere Variante zum Restore des root-Zugangs

Bei meiner Version ging der crontab-Hack leider nicht mehr. Also herumgeschaut, welche Files sonst noch so world-writable sind. Das geht so

find / -type f -perm 666 2>/dev/null

Leider kann die busybox kein find mit "-or", also nochmal, diesmal für executables:

find / -type f -perm 777 2>/dev/null

Aha, da ist doch was Spannendes mit dabei:

/usr/syno/synoman/webapi/encryption.cgi
/usr/syno/synoman/webapi/query.cgi

Diese beiden Files sind also über web erreichbar. Und jetzt prüfen, unter welchem Benutzer die laufen

ps | grep cgi

Bingo. root.

Das CGI ist ein kompiliertes Programm, aber das muss ja nicht so bleiben. CGI funktioniert so, dass erwartet wird, dass erst ein gültiger HTTP header kommt und dann der Content. CGI kann aber auch irgendwas anderes Auführbares sein, Hauptsache die erste Zeile zeigt auf einen gültigen Interpreter. Z.B. ash.

Wir überschreiben also einfach das File (davor haben wir davon ein Backup gemacht, klar):

vi /usr/syno/synoman/webapi/query.cgi

Wir löschen den ganzen Binary Garbage und schreiben das hier rein.

heap> cat query.cgi 
#!/bin/ash

echo "Content-type: text/plain"
echo

chmod 666 /etc/passwd

echo "hi"

Dann gehen wir in einen Browser und rufen http://<url>:5000/webapi/query.cgi auf. Im Browser sollte jetzt "hi" stehen. Und außerdem sollte unsere /etc/passwd editierbar sein.

 

[crazyduck]

Hab das selbe Problem gehabt wie der TS,
sofern man noch einen admin Account hat, welcher Zugriff auf der Webinterface hat, kann man auch den Config File Editor installieren http://www.mertymade.com/syno/#cfe
man muss dann in dem CFE die /etc/passwd hinzufügen. Nach einem CFE neustart hat man dann wieder die Kontrolle über seine passwd.
Gruß Maxi

 

[Arkana]

Hallo allerseits,

mein Problem reiht sich glaube ich hier prima ein
Ich habe versucht meine DS214se so zu modifizieren, dass ich auch als normaler user (also nicht als root) via ssh/telnet verbinden kann.
Dabei habe ich in der /etc/passwd die Zeile des betreffenden Users folgendermaßen geändert:

alt
mein_user:x:1027:100::/var/services/homes/mein_user:/sbin/nologin

neu
mein_user:x:1027:100::/var/services/homes/mein_user:/bin/sh

Das Ende vom Lied ist, dass ich mich nun (nach einem Neustart der DS) als root nicht mehr via ssh/telnet verbinden kann (der User, den ich in der passwd angepasst habe, kann sich übrigens trotzdem nicht via ssh/telnet mitd der DS verbinden).
Will ich mich nun als root via ssh einloggen kommt nun folgende Fehlermeldung: /bin/ash : No such file or directory

Die Zeile für den root sieht übrigens folgendermaßen aus:
root:x:0:0:root:/root:/bin/ash

Ich bin ratlos, ich habe ja nichts am root geändert habe. Wenn ich nach /bin/ash suche dann sehe ich dass es korrekterweise mit der busybox verlinkt ist. Also wo liegt der Fehler? Und die interessantere Frage, wie kann ich das wieder beheben?

Ich kann mich im Moment nur per admin via ssh einloggen, leider hat der keine root-Rechte. Somit kann ich also auch die passwd nicht mehr bearbeiten.
Gibt es irgendeine elegante Lösung, die ohne factory-reset auskommt. Ich habe 4 TB Daten auf der DS und weiß nicht, wohin ich die auslagern könnte.

Auf das Webinterface habe ich nach wie vor Zugriff.

Vielen Dank im voraus!!!
Arkana

 

[goetz]

Hallo,

Dabei habe ich in der /etc/passwd die Zeile des betreffenden Users folgendermaßen geändert:

womit?

Gruß Götz

 

[Arkana]

Hallo Götz,

ich habe die passwd per vi geändert, solange ich mich noch als root via ssh einloggen konnte.

Gruß
Arkana

 

[crazyduck]

Moin,
Hast du mal versucht diesen Config File editor zu installieren? Also aus dem Post von mir?
Wobei ich nicht sicher bin ob der mit der neusten DSM funktioniert. Jedoch könntest du damit dann sämtliche Systemconfigs modifizieren.
Gruß

 

[Arkana]

Hallo crazyduck,

Danke für den Tipp! Ja, den Config File Editor habe ich mittlerweile installiert.

Ich habe nun eine gute und eine schlechte Nachricht.

Die gute Nachricht:
Ich konnte die passwd wieder auf den Originalzustand zurücksetzen.

Die schlechte Nachricht:
Es hat (wie schon vermutet) nichts bewirkt. Ich kann mich immer noch nicht als root via ssh verbinden.
Es kommt immer wieder die Fehlermeldung: /bin/ash : No such file or directory
Wenn ich per ls /bin auslese, dann kann ich aber sehen, das die /bin/ash auf die busybox verlinkt ist. Ich verstehe daher nicht die Fehlermeldung.

Ich habe nun auch mal ssh per Debug laufen lassen. Die Ausgabe sieht wie folgt aus:

ssh -vvv root@192.168.2.108
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.2.108 [192.168.2.108] port 22.
debug1: Connection established.
debug1: identity file /home/lucil/.ssh/id_rsa type -1
debug1: identity file /home/lucil/.ssh/id_rsa-cert type -1
debug1: identity file /home/lucil/.ssh/id_dsa type -1
debug1: identity file /home/lucil/.ssh/id_dsa-cert type -1
debug1: identity file /home/lucil/.ssh/id_ecdsa type -1
debug1: identity file /home/lucil/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/lucil/.ssh/id_ed25519 type -1
debug1: identity file /home/lucil/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1-hpn13v11
debug1: match: OpenSSH_5.8p1-hpn13v11 pat OpenSSH_5* compat 0x0c000000
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.2.108" from file "/home/lucil/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/lucil/.ssh/known_hosts:6
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: setup hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 2b:09:c8:ea:dd:6c:64:ca:46:09:ab:be:78:6e:b1:bc
debug3: load_hostkeys: loading entries for host "192.168.2.108" from file "/home/lucil/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/lucil/.ssh/known_hosts:6
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.2.108' is known and matches the ECDSA host key.
debug1: Found key in /home/lucil/.ssh/known_hosts:6
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/lucil/.ssh/id_rsa ((nil)),
debug2: key: /home/lucil/.ssh/id_dsa ((nil)),
debug2: key: /home/lucil/.ssh/id_ecdsa ((nil)),
debug2: key: /home/lucil/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/lucil/.ssh/id_rsa
debug3: no such identity: /home/lucil/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/lucil/.ssh/id_dsa
debug3: no such identity: /home/lucil/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/lucil/.ssh/id_ecdsa
debug3: no such identity: /home/lucil/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/lucil/.ssh/id_ed25519
debug3: no such identity: /home/lucil/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

 

[Arkana]

Jetzt kommt die Passwort-Abfrage:

root@192.168.2.108's password:
debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to 192.168.2.108 ([192.168.2.108]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env XDG_VTNR
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env CLUTTER_IM_MODULE
debug3: Ignored env SELINUX_INIT
debug3: Ignored env XDG_GREETER_DATA_DIR
debug3: Ignored env GPG_AGENT_INFO
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env VTE_VERSION
debug3: Ignored env SSH_AGENT_LAUNCHER
debug3: Ignored env WINDOWID
debug3: Ignored env UPSTART_SESSION
debug3: Ignored env GNOME_KEYRING_CONTROL
debug3: Ignored env GTK_MODULES
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env XDG_SESSION_PATH
debug3: Ignored env XDG_SEAT_PATH
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env DEFAULTS_PATH
debug3: Ignored env XDG_CONFIG_DIRS
debug3: Ignored env PATH
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env QT_IM_MODULE
debug3: Ignored env QT_QPA_PLATFORMTHEME
debug3: Ignored env JOB
debug3: Ignored env PWD
debug3: Ignored env XMODIFIERS
debug3: Ignored env GNOME_KEYRING_PID
debug1: Sending env LANG = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env GDM_LANG
debug3: Ignored env MANDATORY_PATH

debug3: Ignored env LOGNAME
debug3: Ignored env QT4_IM_MODULE
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env LESSOPEN
debug3: Ignored env INSTANCE
debug3: Ignored env UPSTART_JOB
debug3: Ignored env TEXTDOMAIN
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env DISPLAY
debug3: Ignored env XDG_CURRENT_DESKTOP
debug3: Ignored env GTK_IM_MODULE
debug3: Ignored env LESSCLOSE
debug3: Ignored env TEXTDOMAINDIR
debug3: Ignored env COLORTERM
debug3: Ignored env XAUTHORITY
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 87380
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
/bin/ash : No such file or directory
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

Connection to 192.168.2.108 closed.
Transferred: sent 2832, received 1600 bytes, in 0.1 seconds
Bytes per second: sent 26959.1, received 15231.1
debug1: Exit status 1


Ich hoffe, dass hier im Forum irgendwer etwas damit anzufangen weiß.

Gruß
Arkana

 

[Arkana]

ok Leute, also das ist mir jetzt super peinlich!!!

Ich habe das Problem gelöst. Es lag letztlich nur daran, dass ich ein paar Leerzeichen hinter dem Pfad stehen hatte "root:x:0:0:root:/root:/bin/ash "
Bei den normalen Benutern war die Situation die gleiche. Nur bei Admin gab es kein Leerzeichen dahinter, daher war er auch der einzige, der tatsächlich eine Shell bekommen hatte.

Ist mir echt peinlich, aber naja - wieder etwas gelernt

Vielen Dank an alle, die sich die Zeit für mich genommen haben!

MfG
Arkana

 

[dil88]

Wichtig ist, dass es wieder läuft. Danke für die Aufklärung.

 

[crazyduck]

Gut das du deine Lösung, vll für andere noch gepostet hast.