Allgemeine Verständnisfrage (openssh selbst kompiliert)

kesandal

New Member
Guten Tag,

ich arbeite mich so langsam in die Linux-Welt ein und habe eine allgemeine Verständnisfrage ob ich etwas korrekt gemacht habe.

Auf meinem Testserver lief der ssh-Dienst in einer älteren Version unter Debian 6 x64.

Ich habe mir die aktuellste Version besorgt und selbst kompiliert.

Nun meine Fragen:
im entpackten Verzeichnis, wo ich mein ./configure, make , make install ausgeführt habe war nun eine Datei namens sshd.

Reicht es nun diese nach /usr/local/sbin/ zu kopieren um meine aktuelle ssh Version zu ersetzen? - oder muss ich sonst noch etwas unternehmen

Kann ich das original Startskript in /etc/init.d/ weiter verwenden?
Die frühere Version wurde mit apt-get install installiert.

Vielen Dank.
 
Last edited by a moderator:
Hi,

ob du nur die eine Datei kopieren musst hängt davon ab ob das Programm statisch oder dynamisch kompiliert (bei manchen lässt sich dies via configure-parameter angeben).

Mach einfach mal ein ldd auf die Datei. Bei mir sieht das bspw. so aus (ersetze '$(which sshd) durch den Pfad zu deiner sshd):

strowi@Sleipnir:~> ldd $(which sshd)
linux-vdso.so.1 => (0x00007fffc351d000)
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007ff617153000)
libpam.so.0 => /lib64/libpam.so.0 (0x00007ff616f45000)
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007ff616b67000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007ff616964000)
libz.so.1 => /lib64/libz.so.1 (0x00007ff61674e000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007ff616517000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff6162fa000)
libc.so.6 => /lib64/libc.so.6 (0x00007ff615f6e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007ff615d6a000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff61735d000)

Das obige listet die Dateien auf von denen sshd abhängig ist. Sprich diese werden auch an der entsprechenden Stelle benötigt.
Aber Achtung u.U. sind diese schon durch andere Programme installiert. Evtl. sogar in einer anderen Version... das kann Probleme machen!

Um Probleme zu verhindern, wäre es das einfachste, das ganze unter /usr/local/ zu installieren (s. --prefix Option zu configure etc.). Mit "make install" wird das ganze dann an entsprechende Stelle kopiert.

Normalerweise ändert sich an den Start-Parametern nicht viel bei sshd, d.h. mit minimalen (Pfad-)Anpassungen sollte das auch funktionieren.

Gruß,
strowi
 
Nimm es mir nicht übel, aber das ist gleich in mehrere Richtungen der komplett falsche Ansatz!

1. Wenn du selbst compiliertes Zeug hast, dann gehört das nach /usr/local. Legst du es woanders hin, kommst du mit ziemlicher Sicherheit dem Paketmanagement in den Weg und das wiederum ist ein Garant für ein zerschossenes System.

2. Der Zielordner wird nicht durch wildes hin- und herkopieren festgelegt, gerade weil du so die Libraries nicht mitnimmst und dein frisch compiliertes Binary zerhaust. Du hast ein ./configure Flag, um den Zielordner festzulegen.

3. Auf deinem Server läuft schon ein SSH aus dem Paketmanagement. Wenn du jetzt ein zweites dazu packst, bekommst du mit Sicherheit irgendwas, aber kein stabiles System. SSH kannst du aber schlecht deinstallieren, wenn du nicht über das Rescue-System arbeitest.

und am wichtigsten

4. Debian 5? Das wird schon lange nicht mehr supportet. Keine Updates, daher auch kein aktuelles SSH. Einfach vernünftig auf Debian 6 updaten und alles wird gut.
 
Vielen Dank für Eure Antworten.

mit einem ldd <pfad zur sshd> erhalte ich folgendes:
Code:
linux-vdso.so.1 =>  (0x00007fff3a7b6000)
        libwrap.so.0 => /lib/libwrap.so.0 (0x00007f92f8572000)
        libpam.so.0 => /lib/libpam.so.0 (0x00007f92f8366000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f92f8161000)
        libutil.so.1 => /lib/libutil.so.1 (0x00007f92f7f5e000)
        libz.so.1 => /usr/local/lib/libz.so.1 (0x00007f92f7d48000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00007f92f7b2f000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f92f78f8000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00007f92f76e2000)
        libc.so.6 => /lib/libc.so.6 (0x00007f92f737f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f92f8781000)


@PapaBaer:
Ich nehm Dir nichts übel; lieber jetzt aus Fehlern lernen anstatt später wenn etwas im live-Betrieb läuft :)

zu 1: alles klar, mit meinem usr/local/sbin war ich dann wohl falsch :)
zu 2: ok.

zu3: Welche Möglichkeiten habe ich denn ohne Rescue-System?
Könnte ich mir theoretisch nicht ein Skript schreiben, welches mir das aktuelle SSH deinstalliert und das neue installiert? (bitte nicht erschlagen wenn die Idee schlecht ist :D )

zu 4: Ich habe es gerade im ausgangs-Posting korrigiert. Ich habe die aktuellste Version (6) von Debian.


Allgemeines noch:
Zusammengefasst heißt das, beim Kompilieren als Pfad /usr/local/ angeben.
Anschließend im start-Skript in /etc/init.d/ den Pfad anpassen!?

Besten Dank
 
Warum zum Teufel willst Du OpenSSH (oder irgendetwas Aderes) selbst kompilieren?
Was bietet Dir Dein Selbstkompilat was Dir die Version Deiner Distro nicht bietet?
 
Finde ich total spitze! Viel besser als dein System zu zerschießen ist dann aber, sich mit VirtualBox ne VM aufzusetzen und dann Gentoo oder Linux From Scratch zu bauen. Dazu bekommst du saubere Doku und wenn du fertig bist, ist deine Übung mit Debian nur noch das Vorspiel.
 
Es bietet mir die Möglichkeit etwas zu lernen / besser zu verstehen, darum wollte ich es gerne ausprobieren.

Mit dem Denkansatz wollte ich auch mein Debian 'verbessern' (in meinem Fall wollte ich ne aktuellere Version des Webservers selber compilieren), was aber im Endeffekt dazu geführt hat, daß einige Funktionen der Software nicht mehr verfügbar waren, weil eben die Zusammenarbeit mit anderen Softwarekomponenten des Systems nicht mehr funktionierte...
Ich hab mir auch die Empfehlung von unseren SSF-Experten zu Herzen genommen, nicht besser sein zu wollen als die Paketverwaltung und fange gerade an, mich in Gentoo reinzuarbeiten.:)
 
Last edited by a moderator:
Danke für Eure Antworten.
Ich denke ich weiß nun welchen Weg ich gehen sollte. :)

Nur um noch vermutlich ein Missverständnis meinerseits aus dem Weg zu räumen:

Bin ich bei Sachen die ich über apt-get installiere genau so gut unterwegs was die Sicherheit betrifft? Der Stand der Software hängt ja dort immer hinterher.

Danke
 
Bin ich bei Sachen die ich über apt-get installiere genau so gut unterwegs was die Sicherheit betrifft?

Willkommen im Aufgabenbereich eines Systemadministrators ;-)

Ja, du hängst einen Moment hinterher, auch wenn Debian im Allgemeinen sehr schnell ist, Upstream-Fixes einfließen zu lassen. Es liegt an dir, diese Lücke zu managen. Weißt du von einer Lücke? Betrifft dich eine konkrete Lücke? Musst du reagieren, bevor das Debian-Fix da ist? Dienst runterfahren, patchen und selbst kompilieren oder Workaround? Das sind genau die Dinge, die sich eben nicht über Plesk klicken lassen und viele vergessen das gern.

Aber was bleibt dir? Wenn du eine Distribution verwendest, musst du warten bis die Fixes da sind oder selbst reagieren und fixen. Die Alternative wäre tatsächlich LFS, aber das ist in der Praxis nicht umsetzbar. Dann hilft dir nämlich gar keiner mehr bei irgend einer Lücke und du müsstest alles selbst fixen und updaten. Bei einem so komplexen System wie Linux unmöglich.
 
Hallo kesandal, @lle anderen helfenden Hände :)

Von mir dann auch nochmal der Tip, den wir an nexus, der sich ebenfalls auf eine andere Distri umzusteigen entschlossen hat, gaben: (Obwohl SSF-Spezialist bin ICH sicherlich noch lange nicht ;)

Vom Selberkompilieren per "./Configure" rate ich grundsätzlich ab. Ich habe das auch mal früher in Debian gemacht. "XChat" (um mal eins zu nennen) und noch paar andere kleinere Sachen. Die Kompilierung klappt meist problemlos, doch man muss sehr aufpassen, wohin das Ganze dann installiert wird, da es ansonsten dazu kommt, was PapaBaer angesprochen hatte. Zum Zweiten, wie DEinstalliert man das programm danach? "apt-get --purge", wenn ich es bei Debian richtig in Erinnerung behielt, bringt nichts, da APT nichts von der Eigenkompilierung weiß. Wenn man das dann bei weiteren 10 Anwendungen auch so macht, kann ein Draht nicht verbogener sein, als das, aus den Eingenkompilaten entstandene System!

Wenn Du auf neuere Software, als Dir Debian bietet, das leider ältere Versionen anbietet, diese aber mit neuesten Sicherheitspatches dauerhaft patcht (was ich auch nicht unbedingt geil finde), stehst, was sicher hochanerkennenswert ist, weil es aufschluß darüber gibt, wieviel Dir Sicherheit wert ist, dann setze auf das ebenfalls von PapaBaer angesprochene gentoo. Du kannst ja auch mal in nexus´ Thema schauen. Die Frage die er stellte in Bezug auf Distributionen, ist Deiner sehr ähnlich, kesandal!

Wenn Du "DEINE" Distri wirklich "DEINE" nennen möchtest, ist gentoo für Dich ebenfalls das Richtige. Nur wird dort wirklich fast ALLES selbstkompiliert (aber per Paketmanager 'Portage'), was auch die Installationsdauer sehr stark beeinflusst! Das muss klar sein, dann :)
 
Last edited by a moderator:
Auf jeden Fall bedeutet es auch viel, viel Lernarbeit. Hab mich die letzten Tage schon fleißig in das Thema 'gentoo' eingelesen und meine Virtualbox haßt mich bestimmt auch schon wegen meiner ganzen Herumtesterei ;)
Aber es macht auch wahnsinnig Spaß, sich da reinzuarbeiten...:D

Ich hätte aber noch ne Frage an alle, die schon mit gentoo gearbeitet haben bzw. arbeiten...Gibt es empfehlenswerte Literatur (egal ob im Netz oder in klassischer Buchform), welche sich speziell mit gentoo beschäftigt?
 
Ich stelle als langjähriger Gentoo-User bei deiner Frage gerade erstaunt fest, dass unter all den Büchern, die ich mir in meinen Kopf getan habe, nie eins über Gentoo dabei war und ich allein aus der offiziellen Doku und dem Gentoo-Wiki lebe.
 
Ich stelle als langjähriger Gentoo-User bei deiner Frage gerade erstaunt fest, dass unter all den Büchern, die ich mir in meinen Kopf getan habe, nie eins über Gentoo dabei war und ich allein aus der offiziellen Doku und dem Gentoo-Wiki lebe.
Dann werde ich mich wohl auch mit den Ressourcen aus dem Netz begnügen müssen :)

Es ist kein Problem manches selbst zu kompilieren.
Da steht dann aber die Frage, ob die Konsistenz des Gesamtsystems dadurch nicht beeinflußt bzw. gefährdet wird...
 
Ich stelle als langjähriger Gentoo-User bei deiner Frage gerade erstaunt fest, dass unter all den Büchern, die ich mir in meinen Kopf getan habe, nie eins über Gentoo dabei war und ich allein aus der offiziellen Doku und dem Gentoo-Wiki lebe.
Empfehlung, wenn auch schon etwas älter:

Gunnar Wrobel
Gentoo Linux
Installation - Konfiguration - Administration

Februar 2008
ISBN 978-3-937514-34-5
dt., 416 S.
brosch., DVD
 
Dann werde ich mich wohl auch mit den Ressourcen aus dem Netz begnügen müssen :)

Meine Aussage war auch eher so gemeint, dass ich nie eins brauchte, weil die Doku so gut ist. Wäre das anders, hätte ich mir sicher was in Hardware besorgt.
 
Bei den Gentoo-Wikis achte aber bitte darauf, die englischen zu nehmen, da die deutschen Handbücher öftermals nicht so gepflegt sind/auf dem neuesten Stand, meine ich. Sieht man daran, das in der "Deutschen" HowTo für den X-Server noch von "HAL" die Rede ist, was aber schon lange durch udev abgelöst wurde..

Derzeit ist auch noch im Gange, was Zukunft hat, Systemd oder OpenRC. Aber das ist jetzt bei der Installation erstmal nicht relevant. Systemd ist bei gentoo aber Zukunftsmusik. Arch setzt auf Systemd.

Zu den Fragen: Welche HowTo´s: Einfach im google "gentoo-wiki Suchbegriff" oder "gentoo Suchbegriff" angeben.

Dann wird allesmögliche gefunden, was sicher hilfreich ist. Ich bin auch in einigen gentooforen angemeldet, für "die ganz spezielle Frage X" ;)
 
Da steht dann aber die Frage, ob die Konsistenz des Gesamtsystems dadurch nicht beeinflußt bzw. gefährdet wird...
Wer selbst für Server kompiliert sollte schon mehr wissen als nur wie gcc + make gestartet wird.
Jeder der auf einem Rechner als Admin rumfuhrwerkt ohne fachwissen, gefährdet das System.
 
Back
Top