[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Frage zur SSH Kennung



Hallo Joerg,

bitte schalt mal einen Gang runter. Ok? 

Liegt's an Wuppertal vs. Koeln? (Und ich dachte, das sei nur bei
Duesseldorf und Koeln so.) Aber da kann ich Dich beruhigen, ich bin eh'
Immi (soll heissen zugezogen, aber schon freiwillig). Ich kann also auch
mit Duesseldorfern, oder Wuppertalern oder woher auch immer die Leute
kommen.

Ich will's zumindest versuchen ;) 

Zu Deiner E-Mail:

On Thu, 7 Jul 2005, Joerg Zimmermann wrote:  
> Hi, 
> 
> Dein Zeichensatz ist immer noch kaputt.  

Hoffe das ist jetzt gefixt. 

> > Aus einem rfc-draft von T. Ylonen zu SSH:  
> > -- http://www.free.lp.se/fish/rfc.txt -- 
> > When the client connects the server, the server accepts the 
> > connection and responds by sending back its version identification 
> > string.  
> > 
> > The client parses the server's identification, and sends its own 
> > identification.  The purpose of the identification strings is to 
> > validate that the connection was to the correct port, declare the 
> > protocol version number used, and to declare the software 
> > version used on each side (for debugging purposes).  The 
> > identification strings are human-readable.  If either side fails to 
> > understand or support the other side's version, it closes the 
> > connection.  
> > 
> > Mit der ersten Implementierung von Ylonen hat sich diese 
> > Vorgehensweise eben als "common practice" durchgesetzt.  
>
> Wenn Du schon so anfängst, dann lies Dir das auch richtig durch.  
> Da steht nix davon das der SSH Server sein Betriebssystem als String 
> inclusive Version des Betriebssystems mit sendet. 

Hm. Da ist von "the server's identification" die Rede. Ich bin der
Meinung, dass man das bei einem gepatchten Debian-SSH die Aenderungen im
Versions-String auch mitteilen sollte, Du nicht.

Fuer beides gibt es stimmige Argumente. 

Auf der einen Seite Debugging und Benutzbarkeit, auf der anderen Seite die
Sicherheit und "dass es unnoetig ist". 

> > Im Prinzip: ja. In der Praxis in der Konstellation mit putty als
> > Client wohl eher: nein. Ein Java-Client wie MindTerm wird aber
> > immerhin in compat.c abgefragt, auch wenn er z.Zt. keine relevanten
> > Bugs zu haben scheint.
> 
> Zeig mir die Stelle wo im SSH Server eine Clientversion abgefragt wird.

Ok, dann mach ich mir die Muehe. Hier: 

-- sshd.c, Funktion int main(),  -- 
        /*
         * Register our connection.  This turns encryption off because we
         * do not have a key.
         */
        packet_set_connection(sock_in, sock_out, -1);

        remote_port = get_remote_port();
        remote_ip = get_remote_ipaddr();

        // ein paar Zeilen ausgelassen

        /* Log the connection. */
        verbose("Connection from %.500s port %d", remote_ip, remote_port);

        /*
         * We don\'t want to listen forever unless the other side
         * successfully authenticates itself.  So we set up an alarm which
         * is cleared after successful authentication.  
         */ 

        // ein paar Zeilen ausgelassen
        sshd_exchange_identification(sock_in, sock_out);

-- sshd.c, Funktion sshd_exchange_identification() --
static void
sshd_exchange_identification(int sock_in, int sock_out)
{
        // Zeilen ausgelassen ...

        /* Send our protocol version identification. */
        if (atomicio(vwrite, sock_out, server_version_string,
            strlen(server_version_string))
            != strlen(server_version_string)) {
                logit("Could not write ident string to %s",
                      get_remote_ipaddr());
                cleanup_exit(255);
        }

        // Zeilen ausgelassen ...

        /* Read other sides version identification. */
        memset(buf, 0, sizeof(buf));
        // Zeilen ausgelassen ... 
        buf[sizeof(buf) - 1] = 0;
        client_version_string = xstrdup(buf);

        debug("Client protocol version %d.%d; client "
              "software version %.100s",
              remote_major, remote_minor, remote_version);

        compat_datafellows(remote_version);
-- snap --

Der Aufruf compat_datafellows() setzt die Flags fuer die Bugs die der
betreffende SSH-Client hat (nach Meinung des SSH-Servers). Siehe auch
compat.c

> > Was den 'Debian-8.sarge.4'-String angeht: bei einem Release-Zyklus
> > von 3 Jahren (oder auch 18 Monaten) kann es sehr wohl sein, dass sich
> > der mit einigen Patches modifizierte Debian-OpenSSH anders benimmt,
> > als der OpenSSH-Upstream der gleichen Version.
> >
> > Da ist es geboten, dies auch beim Verbindungsaufbau kundzutun.

Ich sehe ein, da muss ich mich genauer fassen: 

1. Client und Server sollten sich zu einem gegebenen Zeitpunkt ueber das
Protokoll, die jeweils verwendete Implementierung, Version etc.
informieren. 

2. Es ist (nach der Implementierung von Ylonen, auf der OpenSSH fuer v2
aufbaut) "common practice", dies beim Verbindungsaufbau zu tun. 

Es ist natuerlich voellig denkbar, dass man das nicht beim Aufbau der
Verbindung macht, sondern zu einem spaeteren Zeitpunkt. Dann muesste man
sich anfangs nur auf "grobere" Dinge einigen (etwa das Protokoll).

Genauso ist denkbar, dass man nur den Versions-String von Upstream
mitteilt, das heisst "OpenSSH_3.8.1p1" und nicht eine Modifikation wie
"OpenSSH_3.8.1p1 Debian-8.sarge.4".

Das ist denkbar und zu einem gewissen Grad auch sicherer, da gebe ich Dir
recht. 

> Sofern Du die gleiche Protokollversion verwendest, wird sich ein SSH 
> Server beim Verbindungsaufbau nicht anders verhalten nur weil er 
> gepatcht ist. 
> 
> Und wenn Du mir jetzt noch einmal wiedersprichst, dann zeige mir bitte 
> _WO_ sich das Protokoll ändert. 
> 
> Deine Argumentation ist doch vollkommen daneben. 
> 
> Würde das so funktionieren, müsste jeder Client jeden Server kennen 
> respektive umgekehrt und dann auch noch in den jeweiligen Versionen und
> Patchständen. Achja, das Betriebssystem müsste ja auch noch 
> berücksichtigt werden. 
> 
> Selten so gelacht. 

Seufz.

Es ist meine Meinung, dass man staerkere Aenderungen im Versionsstring
dokumentieren sollte. Auch oder vor allem, damit Bug-Reports Upstream
besser verstanden werden ("Client X und Server Y klappen nicht").

Deswegen muss doch nicht jeder Client/Server eine riesen-Matrix mit sich
rumfuehren, wo alle moeglichen Kombinationen beruecksichtigt sind.  

Aber wenn eine Distribution durch Patchen des sshd einen Bock schiesst,
kann man darauf reagieren, dann wird die fehlerhafte Kombination in
zukuenftigen Implementierungen beruecksichtigt.

Denn das Problem ist klar und gut dokumentiert anhand der Log-Mitschnitte
in den Bug-Tracking-Systeme. 

Und _das_ finde ich wichtig. 

So.

Spaete Gruesse aus Koeln
Jens



Reply to: