ubuntuusers.de

OK, also der neue Eintrag der shd_config hat auch nichts gebracht. Wer weiß. Aber das mit der Sicherheit sehe ich jetzt nicht so extrem wichtig. 1. ist es nur ein Raspberry wo nix weiter drauf ist außer paar Test's und 2. könnte man auch per firewall die ip festlegen, welche drauf zugreifen kann/darf.

Hallo matze31,

da die Meldungen unmittelbar beim Einloggen auf dem Server - also angezeigt auf dem Client - aber die Meldung kommt ja vom Server, vermute ich mal, dass Du über die authorized_keys ein Kommando mitgibst bzw. das Format der authorized_keys nicht stimmt?! Wie hast Du die authorized_keys denn kopiert? Dateisystemkopie also z.B. über cp oder per Editor Copy&Paste?

Beginnen alle Schlüssel-Einträge in der authorized_keys direkt mit "ssh-..." oder gibt es Einträge bei denen vor dem "ssh" noch etwas anderes steht?

Sicherheit darf gerne jeder selbst entscheiden, ich wollte es nur nicht unerwähnt lassen, weil so ein Thread ja auch mal von einem Laien über Suchmaschine angesteuert werden kann. War nicht mit erhobenen Zeigefinger gemeint. Trotzdem stellt sich mir die Frage, ob man passwortlosen Root-Zugang braucht oder das nicht auch auf andere Weise lösen kann, aber auch das ist nicht von oben herab gemeint.

LG, Newubunti

EDIT:

Der Fehler könnte auch noch hervorgerufen werden durch:

/root/.bashrc

/root/.bash_profile

/root/.profile

auf dem PI.

Ich habe mal die vorgeschlagenen Dateien gelöscht. Die Warnung kommt trotzdem noch. Ich kann nicht mal mit dem Befehl

ssh-copy-id -i ~/.ssh/id_rsa.pub pi@ip

da kommt die Meldung:

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/matze/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
pi@192.168.178.22's password: 
bash: line 0: exec: sh: not found

Edit: Ja das stimmt, die Sicherheit ist das A und O. Wie gesagt bei mir kommt es jetzt in dem Fall nicht drauf an.

Ich hatte eigentlich nicht gemeint, dass Du die Dateien einfach löschen sollst.

Was läuft denn auf dem Pi für ein System?

Und wie sieht die nun aktuell auf dem Pi genutzte sshd_config aus und wie die ssh_config auf dem Client?

Welche Dateien finden sich im Home-Verzeichnis des Benutzers pi und welche im Verzeichnis /root auf dem Pi?

Und kannst Du mal soweit wie möglich schildern, was Du am ssh-Server auf dem PI alles so verschraubt hast?

LG, Newubunti

matze31 schrieb:

bash: line 0: exec: sh: not found

Wie sind die Ausgaben von:

file /bin/sh
file /bin/dash
which sh

?

Ich habe die sshd_config so übernommen wie von @Newubunti angegeben.

Die Ausgaben ergeben:

$ file /bin/sh
/bin/sh: symbolic link to dash

$ file /bin/dash
/bin/dash: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=ad60267f867c5fb0ec2397bcdbac27bb5d884b34, stripped

$ which sh
/usr/bin/sh

Letztendlich werde ich ja den Pi nochmal mit einen neuen Image versehen (dauert mit allen drum und dran 30 min). Mir ging es nur darum wo die Ursache lag und in Zukunft nicht den gleichen Fehler zu machen.

matze31 schrieb:

Die Ausgaben ergeben:

$ file /bin/sh
/bin/sh: symbolic link to dash

$ which sh
/usr/bin/sh

Die Frage ist hier, warum gibt es bei dir die sh in 2 verschiedenen Verzeichnissen? "/bin/sh" ist der symlink, aber was ist "/usr/bin/sh" (das von which gefunden wird) und wer/was hat das so angelegt? Wie sind die Ausgaben von:

file /usr/bin/sh
type sh

? Warum findet which das "/bin/sh" (d. h. den symlink auf die dash) nicht?

Wenn ich es richtig nachvollziehe - was hier anhand dürftiger Informationen nicht so ganz einfach ist - dann ist der Fehler

bash: line 0: exec: sh: not found

ja wohl erst aufgetreten nachdem ich auf .bashrc etc. hingewiesen habe, worauf matze31 diese Dateien ja einfach gelöscht hat. Da man darüber ja PATH setzen kann, könnte es jetzt schon sein, dass dem System jetzt PATH fehlt und deshalb sh nicht gefunden wird. Zwar gilt z.B. für Ubuntu,

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

aber wir wissen ja nicht, was auf dem PI für ein System läuft und was matze31 schon alles ausprobiert hat.

matze31 schrieb:

Mir ging es nur darum wo die Ursache lag und in Zukunft nicht den gleichen Fehler zu machen.

Ja, guter Vorsatz bzw. Ansatz. Aber dafür musst Du zukünftig Deine Änderungen genauer dokumentieren. Das fängt schon mal damit an, dass man Configs nicht einfach überschreibt, sondern zuvor eine Kopie anlegt. Und das machst Du dann so bei jeder Datei die Du anfasst. Das scheint erst mal unnötig viel Arbeit zu sein, aber ich kann Dir aus eigener Erfahrung sagen, dass das am Ende einen Haufen Zeit spart.

LG, Newubunti

matze31 schrieb:

/usr/bin/id: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=f8db9064d2203f35fa4c3c30f6ec4b0b7c614b5f, for GNU/Linux 3.2.0, stripped

__BTW__: Poste mal auch die Ausgabe von:
{{{
openssl speed -elapsed -evp aes-256-cbc

$ file /usr/bin/sh
/usr/bin/sh: symbolic link to dash

type sh
sh is /usr/bin/sh

Ich habe aktuelles Raspbian drauf. Wie gesagt ich hatte nur etwas an der sshd_config geändert und noch den public_key kopiert.

matze31 schrieb:

$ file /usr/bin/sh
/usr/bin/sh: symbolic link to dash

type sh
sh is /usr/bin/sh

Ich habe aktuelles Raspbian drauf.

Also ich habe auch das aktuelle raspbian (32bit; buster) auf einem meiner PI4s und da gibt es diesen Pfad für sh bzw. symlink für die dash, nicht:

:~ $ file /usr/bin/sh
/usr/bin/sh: cannot open `/usr/bin/sh' (No such file or directory)

Hast Du evtl. einen 64bit-Kernel geladen oder gar das noch nicht offizielle 64bit-raspbian auf deinem PI?

Wie sind auf deinem PI die Ausgaben von:

uname -a
ls -la /lib/modules

?