SSH geht nicht richtig

[maceis]

diff ssh_config1 ssh_config.applesaved
[...]

Danke

...
Es liegt wohl nur an der Versionsnummer.
...

Bleibt die Frage, warum das Problem bei mir unter der Originalversion nicht auftritt.

...
Und ja ich habe auch den Server installiert

Dann wären die Unterschiede in der Serverkonfiguration vermutlich interessanter.
Insbesondere würde mich interessieren wie "UseDNS" bei der neuen Serverkonfiguration gesetzt ist.

 

[Wolfsbein]

Warums nicht bei jedem auftritt, weiß ich natürlich auch nicht.

diff sshd_config sshd_config.applesaved 
1c1
< #     $OpenBSD: sshd_config,v 1.68 2003/12/29 16:39:50 millert Exp $
---
> #     $OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $
25c25
< #KeyRegenerationInterval 1h
---
> #KeyRegenerationInterval 3600
35c35
< #LoginGraceTime 2m
---
> #LoginGraceTime 120
42a43,46
> # rhosts authentication should not be used
> #RhostsAuthentication no
> # Don't read the user's ~/.rhosts and ~/.shosts files
> #IgnoreRhosts yes
50,51d53
< # Don't read the user's ~/.rhosts and ~/.shosts files
< #IgnoreRhosts yes
57,59d58
< # SACL options
< #SACLSupport yes
< 
67d65
< #KerberosGetAFSToken no
69,76c67,74
< # GSSAPI options
< #GSSAPIAuthentication no
< #GSSAPICleanupCredentials yes
< 
< # Set this to 'yes' to enable PAM authentication (via challenge-response)
< # and session processing. Depending on your PAM configuration, this may
< # bypass the setting of 'PasswordAuthentication' and 'PermitEmptyPasswords'
< #UsePAM no
---
> #AFSTokenPassing no
> 
> # Kerberos TGT Passing only works with the AFS kaserver
> #KerberosTgtPassing no
> 
> # Set this to 'yes' to enable PAM keyboard-interactive authentication 
> # Warning: enabling this may bypass the setting of 'PasswordAuthentication'
> #PAMAuthenticationViaKbdInt no
78,79d75
< #AllowTcpForwarding yes
< #GatewayPorts no
85c81
< #TCPKeepAlive yes
---
> #KeepAlive yes
90,94d85
< #ClientAliveInterval 0
< #ClientAliveCountMax 3
< #UseDNS yes
< #PidFile /var/run/sshd.pid
< #MaxStartups 10
95a87
> #MaxStartups 10
97a90
> VerifyReverseMapping yes

UseDNS ist also auskommentiert.

 

[maceis]

...
UseDNS ist also auskommentiert.

Das heisst nur, dass UseDNS auf dem default Wert (yes) eingestellt ist.
Wenn man den ändern will, müsste man auskommentieren und auf no schalten.
Damit wäre u. U. das Problem schon zu lösen gewesen.

Deine Ausgabe verwirrt mich aber insofern, als "$OpenBSD: sshd_config,v 1.68 2003/12/29 16:39:50 millert Exp $" die applesaved sein müsste.
Das würde dann aber bedeuten, dass Du eine ältere Version nachinstalliert hast (die Version, die in Panther installiert war) und dass Du die Spalten der diff Ausgabe vertauscht hast.
Ist das so?
Oder hast Du etwa Tiger nur aktualisiert?

 

[ratti]

lieber ratti,

Wolfsbein hat, wenn ich das richtig verstanden habe "lediglich" das Problem des langsamen Verbindungsaufbaus. Dahinter vermute ich nach wie vor ein DNS Problem, im Grunde also eine Fehlkonfiguration.

Du bist nicht du selbst, wenn du so streng bist.
Das war doch nur Spaß.

Mit dem Begriff "Bug" sollte man meiner bescheidenen Meiung nach sehr vorsichtig umgehen.
Damit wird die Arbeit von inteligenten und engagierten Menschen herabgewürdigt, die noch dazu für Ihre großartigen Leistungen nicht mehr als deren Anerkennung fordern.
Dafür sollte man schon sehr sehr gute Gründe haben.

Hihi. Da hat aber jemand olle Hackertexte gelesen. Hast ja recht. Solang man nicht in der Lage ist, den Quelltext zu debuggen und das Problem gezielt als Bug nachzuweisen, sollte man eigenttlich nicht von einem Bug sprechen, sondern den Fehler bei sich selbst suchen. Korrekt.

Man muss allerdings auch mal sehen, dass diese Ethik aus einer Zeit stammte, als Software noch deutlich bugfreier war als heutzutage. Wieviel Bugs bleiben bekannterweise liegen, weil die Behebung nicht "lohnt", oder schlimmer, damit das Upgrade verkauft werden kann. Deswegen liegt man inzwischen leider meist richtig, wenn man "Bug" schreit.

Deinen Sarkasmus halte ich darum für ... ähm ... etwas unpassend .

Ts-ts-ts. Wir müssen wirklich mal ein paar Lockerungsübungen machen.
Nix für Ungut.


Gruß,
Ratti

 

[Wolfsbein]

.... Hast ja recht. Solang man nicht in der Lage ist, den Quelltext zu debuggen und das Problem gezielt als Bug nachzuweisen, sollte man eigenttlich nicht von einem Bug sprechen, sondern den Fehler bei sich selbst suchen...

Ihr werdets kaum glauben, aber ich komme soeben von einer vierstündigen Debug Session. Zwar war das Java und kein C, aber es war wohl doch Code. Und mein spezieller Fall war jetzt wohl doch kein Bug, sondern ein Configfehler. Ihr habt mich erwischt. Trotzdem habe ich mir als Switcher eben gedacht, kaufst du dir einen Apple und alles geht. Ich weiß es mittlerweile besser.

 

[Luke1]

Dann lauscht da nichts. Es findet keine Umleitung statt

Genau. Eintippen und Antwort abwarten.
Es gab mal einen schönen Text dazu im Web, der sich "SMTP per Hand" nannte. Leider ist der irgendwann offline gegangen.

Die wayback-machine von archive.org hat allerdings noch eine gecachte Version davon:

http://web.archive.org/web/20010819075331/thojens.de/iph/smtp.html

Scroll nach ganz unten, hinter "ENDE" steht eine komplette SMTP-Session, die kannst du ggf. durchspielen.
Bevor allerdings die Gegenstelle nicht erreicht werden kann, ist das völlig sinnlos.

Gruß,
Ratti

Hi Ratti,

also ich habe jetzt endlich Zeit gefunden nach Deiner Anleitung "smtp per Hand", mal fleißig Mails zu verschicken. Klappt ganz hervorragend! Einige Freunde hatten sich schon gewundert, warum sie auf einmal Post von Darth.Vader@Deathstar.de hatten...

Ist in der Tat erschreckend wie einfach man eine E-Mail-Adresse fälschen kann.

Leider hat mich das ganze einer Lösung für mein Problem überhaupt nicht näher gebracht. Das Versenden von E-Mails in Mail durch eine ssh-Tunnel funktioniert leider immer noch nicht.

Ich hatte, bevor ich Tiger 10.4. aufgespielt habe, aber mein altes 10.3.9 geclont. Also habe ich noch mal darunter gebootet und den ssh-Tunnel dort nochmals getestet. Und siehe da: dort funktioniert sowohl der Versand von Mails in Mail als auch das Aufrufen einer Intranetseite über einen lokalen Port als Proxy ganz hervorragend. Beides geht unter Tiger definitiv nicht.
Nach meinem Endruck haben sowohl Mail als auch Safari ein Problem damit, den jeweiligen ssh-Tunnel zu erkennen. Denn der Tunnel selbst kommt nach meiner Bobachtung zu Stande.
Also ich weiß nicht, was ich noch machen könnte. Kann es sein, dass die von mir bislang genutzten lokalen Ports (1080, 8080) seit 10.4 in irgendeiner Weise reserviert sind? Falls ja, gibt es welche die für den Nutzer frei wählbar sind.

Nochmals vielen Dank für Deine Hilfe,
Gruß,
Luke1

 

[ratti]

Hi,

Nach meinem Endruck haben sowohl Mail als auch Safari ein Problem damit, den jeweiligen ssh-Tunnel zu erkennen. Denn der Tunnel selbst kommt nach meiner Bobachtung zu Stande.

Warum glaubst du das? Wenn keine Daten durchgehen, würde ich eher vermuten, der Tunnel käme nicht zustande.

Also ich weiß nicht, was ich noch machen könnte. Kann es sein, dass die von mir bislang genutzten lokalen Ports (1080, 8080) seit 10.4 in irgendeiner Weise reserviert sind? Falls ja, gibt es welche die für den Nutzer frei wählbar sind.

Die belegten Ports erfährst du im Terminal mit "netstat".

Unter Linux lautet der Befehl, herrlich leicht zu merken, "netstat -tulpen" als root. Wenn man das "n" weglässt, bekommt man statt der portnummern Namen.
Unter OS X wird ein anderes netstat verwendet, aber ein simples "netstat" bzw. "netstat -n" wird dich ver,utlich darüber informieren. Zum Beispiel bei mir:

ratti:~# netstat -tulpen
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       Benutzer   Inode      PID/Program name
tcp        0      0 127.0.0.1:833           0.0.0.0:*               LISTEN     0          8842       5321/famd
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN     0          8364       5074/mysqld
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN     0          7159       4699/portmap
tcp6       0      0 :::80                   :::*                    LISTEN     0          8931       5389/apache2
tcp6       0      0 :::22                   :::*                    LISTEN     0          8680       5192/sshd
udp        0      0 0.0.0.0:68              0.0.0.0:*                          0          7055       4694/dhclient
udp        0      0 0.0.0.0:111             0.0.0.0:*                          0          7158       4699/portmap

Interessant sind hier die tcp-Ports, belegt sind 833, 3306 und 111, benutzt von fam, mysql und portmap.

Welche Ports womit belegt sein können, steht in /etc/services, und eine "offizielle" Liste wird maintained unter http://www.iana.org/assignments/port-numbers . Die Existenz dieser Liste hält aber nicht zwingend irgendein Eimerprogramm davon ab "irgendwas" zu benutzen. Prinzipiell ein guter Rat steht im Header der Tabelle:

The Well Known Ports are those from 0 through 1023.
The Registered Ports are those from 1024 through 49151
The Dynamic and/or Private Ports are those from 49152 through 65535

Nimm einen private Port. Und benutze keine "runde" Zahl wie 50000.

1080 und 8080 sind eigentlich beliebte Ports für Proxys, siehe Tabelle. Ich nehme an, die hast du gewählt, weil irgendwo stand, damit käme man besser durch eine Firewall? Die hast du doch hoffentlich deaktiviert, oder?

Gruß,
Ratti

 

[Luke1]

Hi,

Warum glaubst du das? Wenn keine Daten durchgehen, würde ich eher vermuten, der Tunnel käme nicht zustande.

Weil der remote Server, durch den ich den Tunnel errichten will, antwortet und nach dem Passwort fragt. Kann ich den Tunnel mittels Ping testen?

Die belegten Ports erfährst du im Terminal mit "netstat".

Unter Linux lautet der Befehl, herrlich leicht zu merken, "netstat -tulpen" als root. Wenn man das "n" weglässt, bekommt man statt der portnummern Namen.
Unter OS X wird ein anderes netstat verwendet, aber ein simples "netstat" bzw. "netstat -n" wird dich ver,utlich darüber informieren. Zum Beispiel bei mir:

1080 und 8080 sind eigentlich beliebte Ports für Proxys, siehe Tabelle. Ich nehme an, die hast du gewählt, weil irgendwo stand, damit käme man besser durch eine Firewall? Die hast du doch hoffentlich deaktiviert, oder?

1. netstat -n habe ich gemacht und es sieht so aus, als ob beide Ports nicht anderweitig genutzt würde.
Mir ist aber noch aufgefallen, dass in der UNIX-Befehlszeile statt "iBookG4:~ user$" manchmal folgendes steht:

pd9f5141f:~ user$

Hat das irgendeine Bedeutung?

2. Die Firewall und little Snitch sind abgeschaltet. Ich hatte beide unter OS 10.3.X aber immer an, und der Tunnel funktionierte trotzdem.

3. Ach ja, kannst Du ein gutes Buch empfehlen, mit dem ich mich mal näher mit UNIX für Mac beschäftigen kann? Dann kann ich mal versuchen, selbst eine Lösung zu finden, und muss dich nicht länger behelligen.

Gruß,
Luke1

 

[ratti]

Weil der remote Server, durch den ich den Tunnel errichten will, antwortet und nach dem Passwort fragt. Kann ich den Tunnel mittels Ping testen?

Jetzt steig ich nicht mehr durch. Laut Posting #32 wird die connection refused. Jetzt antwortet doch was?

Nein, Ping geht nicht. Ping ist ein ICMP-Request und hat mit TCP oder UDP nichts zu tun.

Mir ist aber noch aufgefallen, dass in der UNIX-Befehlszeile statt "iBookG4:~ user$" manchmal folgendes steht:

pd9f5141f:~ user$

Hat das irgendeine Bedeutung?

Ja, hat es. Dein Rechner hat seinen Namen gewechselt. Das sollte er nun wirklich nicht tun. Kann es sein, dass z.B. durch den Tunnel ein DHCP-Server erreicht wird und deinen Rechner umkonfiguriert?
Wenn das passiert, solltest du mal gucken, ob evtl. deine IP oder Route anders ist, als zu dem Zeitpunkt, wo dein Rechner seinen normalen Namen hat.

Möglich wäre auch, dass plötzlich ein anderer DNS verwendet wird, der den Namen anders revers auflöst.

Vielleicht kann jemand sagen, wie das auf dem Mac läuft (Nein, nicht durch gucken in die Systemeinstellung "Netzwerk", da steht Blödsinn). Ich selbst weiss es leider nicht, gesucht werden die Mac-Entsprechungen der Linuxbefehle

route -n

und

cat /etc/resolv.conf

2. Die Firewall und little Snitch sind abgeschaltet. Ich hatte beide unter OS 10.3.X aber immer an, und der Tunnel funktionierte trotzdem.

Es geht auch nur darum, sicherzustellen, dass nicht im Wege ist. Wenn's läuft, kannst du ja beides benutzen.

3. Ach ja, kannst Du ein gutes Buch empfehlen, mit dem ich mich mal näher mit UNIX für Mac beschäftigen kann?

Das ist im Augenblick alles allgemeiner Netzwerkkram und nichts Mac-Spezifisches.
Empfehlen kann ich nichts, ich hole mir alle Infos aus dem Netz.

Gruß,
Ratti

 

[maceis]

...
Ja, hat es. Dein Rechner hat seinen Namen gewechselt. Das sollte er nun wirklich nicht tun. Kann es sein, dass z.B. durch den Tunnel ein DHCP-Server erreicht wird und deinen Rechner umkonfiguriert?
...

Ah ja, die unbefleckte Empfängnis!

 

[ratti]

Ah ja, die unbefleckte Empfängnis!

Ehrlich gesagt: Beflecken ohne Empfängnis ist am spassigsten...

 

[maceis]

Um wieder zur Sache zu kommen.
Der Gedanke mit der Namensauflösung war deutlich (!) realistischer.
Vermutlich bekommt Dein Rechner dann den hostname "pd9f5141f", wenn Du ein Terminal öffnest, während Du im Internet bist und daher der DNS Server Deines Providers deine IP Adresse auflöst.
Prüfen kannst Du das z. B. auf http://www.wieistmeineip.com/

 

[Luke1]

Jetzt steig ich nicht mehr durch. Laut Posting #32 wird die connection refused. Jetzt antwortet doch was?

Das mit der fehlerhaften Verbindung in Posting #32 bezog sich auf einen telnet-Befehl. Dort bekomme ich immer die genannte Antwort. Unter ssh und dem in Posting # 26 genannten Befehl hingegen meldet sich der remote-host, über den ich meinen lokalen Port 1080 zum SMTP-Server weiterleiten will. Ich kann dort mein Passwort eingeben und bekomme bei einer Falscheingabe auch eine Rückantwort. Nur wenn ich das Passwort richtig eingebe "passiert" im Shell-Fenster nichts. Das ist aber immer so gewesen, wenn der Tunnel zu Stande kommt.

Daher vermute ich, dass der Tunnel zu Stande kommt. Wenn es mit dem Ping nicht geht, gibt es denn eine andere Möglichkeit, zu testen ob der Tunnel besteht oder nicht?

Um wieder zur Sache zu kommen.
Der Gedanke mit der Namensauflösung war deutlich (!) realistischer.
Vermutlich bekommt Dein Rechner dann den hostname "pd9f5141f", wenn Du ein Terminal öffnest, während Du im Internet bist und daher der DNS Server Deines Providers deine IP Adresse auflöst.
Prüfen kannst Du das z. B. auf http://www.wieistmeineip.com/

Ja stimmt, ich habe das auf der angegebenen Seite überprüft. Und dort habe ich u.a. folgende Angabe gefunden: "pD9F50E82.dip.t-dialin.net"
Und tatsächlich heißt mein Rechner im Terminal zur Zeit "pD9F50E82"! Das Phänomen tritt mit je anderen Namen auch immer auf, wenn ich im Internet bin.

Mein Fragen lauten nun:
1. Kann das der Grund für mein Problem mit dem Tunnel sein? Denn der Tunnel soll ja über iBookG4.local und nicht über pD9F50E82 zu Stande kommen.
2. Warum habe ich dieses Phänomen nicht unter 10.3.9?

Danke an Euch beide für Eure Hilfe.
Gruß,
Luke1

 

[Luke1]

Hallo,
ich greife noch mal meine Frage aus dem vorigen Posting auf.

Weiß irgendjemand, wie ich verhindern kann, dass der Server den Namen meines Rechners auflöst?


Gruß,
Luke1

 

[maceis]

Ja, indem Du den gewünschten hostname in der Datei /etc/hostconfig fest einträgst.

HOSTNAME=host.domain.dom

 

[ratti]

Ja, indem Du den gewünschten hostname in der Datei /etc/hostconfig fest einträgst.

HOSTNAME=host.domain.dom

Das scheint mir nicht richtig.

Der Fehler ist ja (und deswegen ist m.E. schon die Frage falsch) nicht, dass der DNS-Server in der Lage ist, den Client aufzulösen. Soll er doch tun, egal.

Die Frage ist doch - wieso *benutzt* der Client plötzlich DIESEN Server, um seinen Namen entsprechend zu ändern? Das lässt doch darauf schliessen, dass der Client sich selbsttätig umkonfiguriert. Und das wiederum könnte diverse Ursachen haben. Möglicherweise kommt mit dem Tunnel ein DHCP-Server ins Haus, der fälschlicherweise auch benutzt wird. Oder in der VPN-Konfig ist etwas konfiguriert, was in der Priorität die "normale" Konfig übersteigt. Oder eine falsche Einstellung kommt erst zum Zuge, wenn durch den Aufbau des Tunnels eine Gegenstelle erreichbar wird.

Siehst du das auch so?

Ich bin jetzt nicht so firm, dass ich sofort die Lösung parat hätte. Aber ein Ansatz wäre m.E., erstmal sicherzustellen, dass nirgendwo eine Netzwerkkonfiguration per DHCP stattfindet, weder im Tunnel noch in der normalen TCP/IP-Einstellung. Überall feste IPs verwenden, und durch Kontrolle der Settings sicherstellen, dass Name und IP bleiben, wie sie sollen. Die DNS-Server ebenfalls fest einstellen.

Gruß,
Ratti

 

[maceis]

Ich hatte die Frage von Luke1 frei so interpretiert, dass er nicht möchte, dass der Rechnername, der im Terminal angezeigt wird, mal so mal so ist.
Ich weiss, so hat er die Frage nicht gestellt, aber ich habe angenommen, dass es das ist, was er meinte.

Das scheint mir nicht richtig.

Der Fehler ist ja (und deswegen ist m.E. schon die Frage falsch) nicht, dass der DNS-Server in der Lage ist, den Client aufzulösen. Soll er doch tun, egal.
...

Ich hatte die Frage von Luke1 frei so interpretiert, dass er nicht möchte, dass der Rechnername, der im Terminal angezeigt wird, mal so mal so ist.
Ich weiss, so hat er die Frage nicht gestellt, aber ich habe angenommen, dass es das ist, was er meinte.

...
Die Frage ist doch - wieso *benutzt* der Client plötzlich DIESEN Server, um seinen Namen entsprechend zu ändern? Das lässt doch darauf schliessen, dass der Client sich selbsttätig umkonfiguriert. Und das wiederum könnte diverse Ursachen haben. Möglicherweise kommt mit dem Tunnel ein DHCP-Server ins Haus, der fälschlicherweise auch benutzt wird.
...

Meiner Ansicht nach ist das ziemlich offensichtlich.
Luke1 hat vermutlich in seinen Einstellungen für die Internetverbindung DHCP konfiguriert und keinen DNS Server eingetragen.
Sobald er sich mit dem Internet verbindet, setzt der ISP die Konfiguration auf seinen DNS Server, der dann verwendet wird.

Deine Theorie mit dem DHCP Server, der plözlich durch den Tunnel gekrochen kommt ist IMHO völlig haltlos (daher auch mein spöttscher Kommentar oben).

Warum?
Üblicherweise funktioniert DHCP über Layer 2 Broadcasts. Nur in Ausnahmefällen wird eine DHCP Server über die IP Adresse angesprochen.
Das geht logischerweise nur innerhalb des lokalen Subnetzes (ich weiss, es gibt ganz spezielle Ausnahmen) und üblicherweise wird da nur ein DHCP Server kontaktiert, der schon die Erstkonfiguration vorgenommen hat.

Nichts und niemand bewegt den Client dazu, nur weil mal eben ein Tunnel aufgemacht wird, ein DHCP REQUEST an einen bestimmten (!) Server abzusenden.
Dass der Client einen DHCP REQUEST an einen lokalen Port (lokales Tunnelende) sendet ist noch wesentlich unwahrscheinlicher.
Ebenso unwahrscheinlich, ist dass es da draußen irgendwo einen DHCP Server gibt, der auf dem Port 25 lauscht.
Zu berücksichtigen ist dabei auch, dass dieser Server ja anscheinend als SMTP Server arbeitet, wenn Luke1 mit 10.3 bootet.

 

[ratti]

Deine Theorie mit dem DHCP Server, der plözlich durch den Tunnel gekrochen kommt ist IMHO völlig haltlos (daher auch mein spöttscher Kommentar oben).

Warum?
Üblicherweise funktioniert DHCP über Layer 2 Broadcasts. Nur in Ausnahmefällen wird eine DHCP Server über die IP Adresse angesprochen.
Das geht logischerweise nur innerhalb des lokalen Subnetzes (ich weiss, es gibt ganz spezielle Ausnahmen) und üblicherweise wird da nur ein DHCP Server kontaktiert, der schon die Erstkonfiguration vorgenommen hat.

Nichts und niemand bewegt den Client dazu, nur weil mal eben ein Tunnel aufgemacht wird, ein DHCP REQUEST an einen bestimmten (!) Server abzusenden.
Dass der Client einen DHCP REQUEST an einen lokalen Port (lokales Tunnelende) sendet ist noch wesentlich unwahrscheinlicher.
Ebenso unwahrscheinlich, ist dass es da draußen irgendwo einen DHCP Server gibt, der auf dem Port 25 lauscht.

DHCP funktioniert über Broadcasts, und die /können/ durch einen Tunnel kommen, wenn er entsprechend konfiguriert ist. Gerade auf dem Mac will man das möglicherweise sogar, weil man sonst im Netzwerk, Filemaker und sonstwo die anderen Kisten nicht sieht.

Wenn Luke DHCP konfiguriert hat, aber kein DHCP-Server erreichbar ist, dann funkt der Mac immer schön weiter. In dem Augenblick, wo Luke den Tunnel aufmacht, wird dahinter der DHCP erreicht, der tut seine Arbeit, dadurch wird Lukes Mac umkonfiguriert und der Tunnel ist im Eimer.

Der Broadcast geht sicherlich an 0.0.0.0/32 auf allen Netzwerken. Gut möglich, dass der Tunnel erreicht wird.

Du hast aber Recht mit Deiner Annahme, dass der Name vom Provider kommt. Ich hatte nur "pD9F50E82" gelesen, und das klingt eigentlich ganz und gar nicht nach einem Providernamen, der i.d.R. ja eher ähnlich "dial-123-12-22-13.example-com" klingt. Inzwischen habe ich aber auch gesehen (das folgte er später), dass der FQDN "pD9F50E82.dip.t-dialin.net" ist. Also klar: Provider.

Ist das normal für Macs, dass plötzlich die Reversauflösung für externe IPs für den Hostname herhalten muss? Auf anderen Systemen kenne ich das nicht, und ich habe doch tatsächlich noch nie einen Mac "direkt" im Internet gehabt.

Gruß,
Ratti

 

[Luke1]

Lieber Ratti, lieber maceis,

besten Dank für Eure ausführlichen Erklärungen. Für mich stellt sich mein Problem nunmehr so dar:
Mac OS 10.4. löst den Namen des Computers im Terminal auf, wenn der Rechner online ist. Dies ist eine Änderung gegenüber 10.3. Diese Information habe ich einem anderen Thread hier und einem Beitrag im Diskussionsforum auf apple.com entnommen. Da ich selbst keine Änderungen welcher Art auch immer an den Netzwerkeinstellungen vorgenommen habe, seit ich OS 10.4. installiert habe und ich auch kein DHCP konfiguriert habe, schließe ich daraus, dass die Namensauflösung eine sehr wahrscheinliche Ursache für mein Problem ist.

Daher werde ich den Namen fest auf IBookG4 ändern.

Melde mich dann noch mal, mit dem Ergebnis.

Gruß,
Luke1

 

[maceis]

...
Wenn Luke DHCP konfiguriert hat, aber kein DHCP-Server erreichbar ist, dann funkt der Mac immer schön weiter. In dem Augenblick, wo Luke den Tunnel aufmacht, wird dahinter der DHCP erreicht, der tut seine Arbeit, dadurch wird Lukes Mac umkonfiguriert und der Tunnel ist im Eimer.
...

Nicht, wenn DHCP auf dem PPP konfiguriert wird und kein Ethernet angeschlossen ist.
Aber es gibt noch ein anderes Problem. Wie soll denn die Antwort des DHCP Servers zurück kommen?
Bin gespannt auf Deine diesbezügliche Theorie.
(Mal ganz abgesehen davon, dass der SMTP Server der Uni kein DHCP anbietet).

Frage an Luke1: wie bist Du mit dem Internet verbunden.
Ich wette über ein Analog- oder DSL-Modem direkt (also kein Router).

...Ist das normal für Macs, dass plötzlich die Reversauflösung für externe IPs für den Hostname herhalten muss? Auf anderen Systemen kenne ich das nicht, und ich habe doch tatsächlich noch nie einen Mac "direkt" im Internet gehabt.

Ja, das ist normal.
Es ist irgendwo dokumentiert, wie der Mac seinen eigenen hostname feststellt. Das war übrigens unter Panther auch nicht anders.
Kann höchstens sein, dass unter Panther im Terminal nicht der DNS hostname sondern der Gerätename, der im Sharing Kontrollfeld eingetragen wird, verwendet wurde.
Wo genau das dokumentiert ist, weiss ich nicht mehr