Ankündigung

Einklappen
Keine Ankündigung bisher.

64Bit Server SSH-Agent-Forwarding nicht verfügbar

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    64Bit Server SSH-Agent-Forwarding nicht verfügbar

    Hallo,

    Gestern wurde unser Server mehr oder weniger auf 64 Bit migriert und es gibt noch ziemliche Kinderkrankheiten, die noch nicht behoben sind.
    • plötzlich geht euer Ticketsystem nicht mehr ( #9724200 )
    • der Server kann nicht per curl auf die eigenen gehostete Webseiten zugreifen ( #9724559 )
    Aber was mir heute noch aufgefallen ist, ist eigentlich ein nogo und es ist nicht in der Server-FAQ verzeichnet.
    SSH Agent Forwarding geht nicht ( #9726900 )
    Code:
    $ ssh -A -v [email protected]
    ...
    debug1: Remote: Agent forwarding disabled: mkdtemp() failed:
    Permission denied
    Last login: Wed Feb 16 14:10:24 2022 from 1.2.3.4
    [email protected] ~ % ssh-add -l
    Could not open a connection to your authentication agent.
    Support meldet dazu.
    Das Verhalten der 64bit-Server ist hier leider anders als bei 32bit, in openssh ist /tmp hardcoded festgelegt, das Verzeichnis gibt es auf 64bit aber aus Sicherheitsgründen aber nicht mehr - daher der Fehler "mkdtemp() failed: Permission denied". Sie müssten ggf. den Private-Key für Ihre Repos auf den Server bei uns ablegen damit Sie Ihn verwenden können.
    Ich soll also meinen privaten SSH-Key in den Kundenprojekten auf dem Server ablegen, da das sicherer ist?
    Nur weil jetzt nicht erlaubt wird, in /tmp/ subdirs anzulegen (siehe man mkdtemp)

    Das kann doch nicht euer ernst sein?

    viele Grüße

    boecko

    #2
    Hallo boecko,

    auch wenn Dein Fokus in diesem Thread sicherlich auf SSH liegt, würde mich interessieren, was Du mit

    Zitat von boecko Beitrag anzeigen
    plötzlich geht euer Ticketsystem nicht mehr ( #9724200 )
    meinst?
    Ich habe derzeit nämlich mit dem Ticketsystem - auf 32bit Plattform - auch ein Problem. Bisherige Anfragen lassen sich nicht mehr einsehen, man kann nur neue Tickets eröffnen.
    Falls Du das gleiche Problem hast, ist das also unabhängig von der Plattform.

    Gruß zzet

    Kommentar


      #3
      Zitat von zzet Beitrag anzeigen
      Hallo boecko,

      auch wenn Dein Fokus in diesem Thread sicherlich auf SSH liegt, würde mich interessieren, was Du mit



      meinst?
      Ich habe derzeit nämlich mit dem Ticketsystem - auf 32bit Plattform - auch ein Problem. Bisherige Anfragen lassen sich nicht mehr einsehen, man kann nur neue Tickets eröffnen.
      Falls Du das gleiche Problem hast, ist das also unabhängig von der Plattform.

      Gruß zzet
      Hi,

      genau das meine ich
      Es gibt aber einen Workaround, den ich DF im Ticket zum Ticketsystem schon mitgeteilt habe .

      Wenn Du auf der Seite /kunde/support_mail.php bist in Zeile 370 einen JS-Breakpoint setzen
      Klicken Sie bitte auf die Grafik für eine vergrößerte Ansicht  Name: workaround.png Ansichten: 0 Größe: 219,2 KB ID: 10926

      iBlockSize von 100 auf z.b 25 ändern und play drücken.

      Ja .. ich verstehe auch nicht, warum das ein Problem ist ¯\_(ツ)_/¯
      Angehängte Dateien
      Zuletzt geändert von boecko; 16.02.2022, 16:08.

      Kommentar


        #4
        Okay, dann sprechen wir vom gleichen Problem - d.h. unabhängig von der Plattform und nur zeitlich zufällig mit Deiner Umstellung zusammen aufgetreten.
        Problem ist bei dF bekannt und bei der Entwicklung adressiert. Dank Dir können sich die Entwickler jetzt auch gleich noch das Debugging sparen 😁

        Kommentar


          #5
          Zitat von zzet Beitrag anzeigen
          Dank Dir können sich die Entwickler jetzt auch gleich noch das Debugging sparen 😁
          Ehrlich gesagt, weiss ich nicht mal, was da von Serverseite groß debuggt werden müsste.

          support_mail.php?action=read_ticket&iPageSize=100& iShowHidden=0&iStart=0 -> liefert nix

          support_mail.php?action=read_ticket&iPageSize=25&i ShowHidden=0&iStart=0 -> liefert


          Kommentar


            #6
            Hallo boecko,

            ich würde Sie gerne bitten, die Fragen direkt im Ticket zu klären, da Sie ja schon bei der Technik adressiert sind. Sollte sich etwas nicht klären lassen, können Sie sich natürlich gerne melden und ich schaue, was sich machen lässt.

            Mit freundlichen Grüßen

            Nils Dornblut
            Blog - Facebook - Twitter
            Communitybetreiber: domainfactory GmbH
            Impressum / Pflichtangaben

            Kommentar


              #7
              Also die Problematik mit dem Agent Forwarding fänden bestimmt einige andere Kunden auch interessant.

              Kommentar


                #8
                Zitat von Lukas M. Beitrag anzeigen
                Also die Problematik mit dem Agent Forwarding fänden bestimmt einige andere Kunden auch interessant.
                Ergebnisse können ja auch gerne hier dann veröffentlicht werden, ich möchte aber nicht parallele Klärungen anstoßen, wenn es schon entsprechende Tickets gibt.

                Mit freundlichen Grüßen

                Nils Dornblut
                Blog - Facebook - Twitter
                Communitybetreiber: domainfactory GmbH
                Impressum / Pflichtangaben

                Kommentar


                  #9
                  Probier mal ob das hier dein Problem lösen kann.
                  http://www.vilain.net/2015/12/ssh-auth-forwarding/
                  MfG,
                  masterframe

                  Kommentar


                    #10
                    Zitat von masterframe Beitrag anzeigen
                    Probier mal ob das hier dein Problem lösen kann.
                    http://www.vilain.net/2015/12/ssh-auth-forwarding/
                    Das mit den proxyCommand ist ja ein alter cooler Trick. (Funfact: das hat bei OpenBSD mit SOCKS vor ca 20 Jahren zu einen reproduzierbaren Kernelpanic geführt).
                    Aber halt nicht praktikabel.
                    Ich will ja den DF-Server nicht als GATE nutzen, sondern u.a. Repos von unseren gitlab - Server auf dem DF-Server auschecken und evtl pushen.
                    Und am gitlab authentifiziert man sich halt via ssh-pubkey. Ich will nicht jetzt den Workflow und und git submodule auf https umstellen.

                    Eigentlich sind wir nur ein
                    Code:
                    chmod o+wX /tmp
                    von der Lösung entfernt.

                    ¯\_(ツ)_/¯
                    Zuletzt geändert von boecko; 17.02.2022, 08:36.

                    Kommentar


                      #11
                      Hallo,

                      Zitat von boecko Beitrag anzeigen
                      [*]der Server kann nicht per curl auf die eigenen gehostete Webseiten zugreifen ( #9724559 )
                      Dazu wäre den Ergebnis vom DF-Support auf jeden Fall auch interessant ;-)

                      Danke

                      Kommentar


                        #12
                        Hallo boecko,

                        gibt es dazu inzwischen vielleicht schon ein Ergebnis? ;-)

                        Zitat von boecko Beitrag anzeigen
                        der Server kann nicht per curl auf die eigenen gehostete Webseiten zugreifen ( #9724559 )
                        Vielen Dank

                        Kommentar


                          #13
                          Zitat von jonguerre Beitrag anzeigen
                          Hallo boecko,

                          gibt es dazu inzwischen vielleicht schon ein Ergebnis? ;-)

                          Zitat von boecko Beitrag anzeigen
                          der Server kann nicht per curl auf die eigenen gehostete Webseiten zugreifen ( #9724559 )
                          Vielen Dank
                          Ja, das Problem wurde am 16.02.2022 gelöst und durch den Kunden erfolgreich getestet. Wir versuchen natürlich Probleme dieser Art für spätere Umzüge zu vermeiden. Sollte das im Individualfall nicht klappen, zögern Sie bitte nicht sich an uns zu wenden.

                          Mit freundlichen Grüßen

                          Nils Dornblut

                          Blog - Facebook - Twitter
                          Communitybetreiber: domainfactory GmbH
                          Impressum / Pflichtangaben

                          Kommentar

                          Lädt...
                          X