SSH geht nicht richtig

Naja jut, ich geb scho zu ... war n bischen blöd von meiner Wenigkeit, da der Thread ja nunmal darum ging ...

Trotzdem ;)

case
 
case schrieb:
...
Und zwar (zum mitdenken :) Client will per SSH auf den Server zugreifen.
Also geben wir auf Clientseite ein :
ssh -l user host.domain.tld

Zu diesem Zeitpunkt kennt er noch keine IP des Servers. Da sind wir uns einig, oder ?
Okay ... also ein nslookup ... dadurch findet er naemlich die IP heraus, deshalb auch lookup.
So, wenn das nun laenger dauert dauert es logischerweise auch laenger bis er die Verbindung aufbauen kann, egal ob der Client nun FTP, ssh, HTTP, ICA oder sonstwas verwendet, richtig ?
...
Richtig, aber bis hierher ist noch alles okay, sonst würde sehr schnell (etwa nach ca. 8-10 Sekunden) die Meldung kommen
ssh: host.domain.tld: No address associated with nodename

case schrieb:
...
Der Reverselookup, mein Bester, kommt erst nachdem du mit dem Server connected bist. Naemlich genau nach der Eingabe des Usernamen.
...
Ist IMO so leider auch nicht ganz richtig. Den Usernamen gibst Du ja beim Verbindungsversuch schon mit an (bzw. lässt ihn weg, dann wird er automatisch ermittelt). Solange das delay anhält bist Du auch noch nicht wirklich mit dem ssh-Server verbunden. Eine Verbindung erhältst Du erst, nachdem Dein Passwort akzeptiert wurde.

case schrieb:
...Hab mir das öfter durchs Hirn gehen lassen, und Du solltest selbiges vielleicht ein wenig mehr benutzen und Dir nicht anmaßen, du könntest nach drei mißverstandenen Postings eines Users beurteilen ob der Ahnung hat, oder nicht.
...
War nicht bös gemeint; allerdings lagst Du zwei mal hintereinander daneben. Bitte den ;) dabei nicht übersehen.

case schrieb:
...
Wenn ich mir jetzt über Dich ein Urteil fällen müßte von wegen ReverseIPv6 könnte ja dazwischen kommen oder so ... naja, dann kannste Dir sicher vorstellen, wie das ausfallen würde.
......
Ich habe kein Wort über "ReverseIPv6" gepostet.
Insofern fühle ich mich nicht angesprochen.
Aber mal ganz abgesehen davon wurde bereits an diversen Stellen (z. B. discussions.info.apple.com, www.macosxhints.com), dass IPv6 an der Problematik beteiligt sein kann.
 
case schrieb:
SSH nutzt ja auch kein DNS ... mal ganz logisch gedacht ... du connectest von einem Rechner auf einen Rechner, Port 22. Wo soll denn da jetzt irgendwie etwas reverse aufgelöst werden müssen ?

Wenn Du dich dann im Ton etwas beruhigt hast... googeln.
"ssh reverse dns", 151.000 Fundstellen.


ssh nutzt DNS, weil der Server eine reverse Auflösung auf die ip des Clients machen will, weil er wissen will, WER da auf ihn connected. Das gleiche passiert übrigens auch bei POP3, telnet und diversen anderen Diensten.

man 5 sshd_config:

UseDNS
Specifies whether sshd should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is “yes”.




Was ipV6 angeht - im Logfile meines Servers steht beispielsweise:

Jun 28 21:24:04 g3 sshd[17273]: Accepted keyboard-interactive/pam for ratti from ::ffff:192.168.2.169 port 40993 ssh2
(Debian Linux PowerPC)

...ein v6 IP. Es waren übrigens auch ipV6-Probleme, die unter OS X 10.3.7 zu minutenlangen Verzögerungen mit einigen Routern geführt haben, weil auch in v4-Netzen v6 präferiert wurde.

ipV6 wird in letzter Zeit vermehrt "unbemerkt" eingesetzt, selbst in reinen ipv4-Netzen, weil v4 als Untermenge von v6 abgehandelt werden kann. In einigen Linux-Systemen kann man v6 nicht mal mehr abstellen.

Gruß,
Ratti
 
Keine ssh Tunnel mehr unter Tiger!

Okay,

Ich glaube mein Problem gehört hierhin:
Von Unix versteh ich nichts. Ich hatte es unter 10.3.9. aber geschafft einen ssh Tunnel zum smtp-server meiner Uni zu legen. Nach Vornahme der entsprechenden Einstellungen in Mail (smtp-server=xxx.local) konnte ich auf diese Art Emails über meine Dienstadresse verschicken, auch wenn ich zuhause war. Unter 10.3.9. (Clone auf der externen Platte) funktioniert das auch noch ganz wunderbar. Nur unter Tiger kann ich keine Mails mehr verschicken. Wohlgemerkt den Tunnel kriegt das Terminal noch hin, jedenfalls gibt es keine Fehlermeldung. Aber Mail sagt mir immer, die Mail könne über den Server XXX.local nicht verschickt werden.

Ich hoffe ich konnte mein Problem verständlich machen. Kapiert das einer von Euch, warum unter Tiger kein Mailversand durch den ssh Tunnel mehr möglich ist?
 
Zuletzt bearbeitet:
Luke1 schrieb:
...
Von Unix versteh ich nichts. Ich hatte es unter 10.3.9. aber geschafft einen ssh Tunnel zum smtp-server meiner Uni zu legen.
Wie?
Luke1 schrieb:
...
Kapiert das einer von Euch, warum unter Tiger kein Mailversand durch den ssh Tunnel mehr möglich ist?
Ohne weitere Informationen wird das kaum möglich sein.

[standardtext]
Mindestens solltest Du beschreiben,
- was Du genau erreichen möchtest
- was Du bisher genau gemacht hast (z. B. welche Einstellungen Du vorgenommen hast und welche Kommandos Du ausgeführt hast),
- welches Ergebnis Du erhalten hast (ggf. Fehlermeldungen etc.), und
- wie dieses Ergebnis verschieden war, von dem, was Du erwartet hast?
- evtl. noch Version der verwendeten Programme, besondere Einstellungen, Umgebung und sonstige Besonderheiten
[/standardtext]
 
Hi,

da waren meine Informationen wohl viel zu spärlich... Danke für den Hinweis.

Also daher jetzt ausführlich:

1. Ich habe bislang unter 10.3.9. in einem Terminal Fenster einen Befehl nach folgender Art eingeben eingeben:

(iBookG4:~ name$) ssh -N -L 1080: os9.server.lan:25 user@firewall.company.com

(Die Leerzeichen stimmen hier nicht, da ich sie ändern musste um zu verhindern, dass mittendrin ein Smiley erscheint)


Erklärung:

-N tells ssh to only handle tunnel, we do not want a shell on this host
-L specifies the kind of tunnel (Local port forwarding)
1080 is the local port to use
os9.server.lan is a host reachable by the firewall
25 is the port you want to reach.
user is the user you want to connect as.
firewall.company.com is the public server you will jump by.

Wenn ich das richtig verstanden habe handelt es sich dabei um local port forwarding. (Forward local port 1080 to firewall.company.com, and tell him to send this to os9.server.lan, on port 25)

Nachdem ich diesen Befehl mit der Eingabetaste bestätigt habe, musste ich mein Passwort eingeben. Dann stand der Tunnel.

2. In Mail > Einstellungen > Accounts > Account-Information habe ich dann bei SMTP-Server mein iBook als neuen Server erstellt ("iBookG4.local"). Unter Servereinstellungen habe ich schließlich 25 als Serverport eingetragen.

3. Damit konnte ich dann über den oben "os9.server.lan" genannten SMTP-Server meine Emails verschicken. Das ganze ist notwendig, weil dieser Server nicht über das Internet, sondern nur intern oder eben durch den Tunnel über den Server "firewall.company.com" angesprochen werden kann. Daher muss ich meinen Port sozusagen hinter die Firewall legen.

Wie gesagt unter Tiger 10.4.1. geht das nun nicht mehr. In Mail kommt folgende Fehlermeldung:

"Die E-Mail kann nicht über den Server "iBookG4.local" gesendet werden"

Hab heute nochmal unter 10.3.9. gebootet und da klappt es einwandfrei.

Jemand eine Idee?

Gruß,
Luke1
 
Zuletzt bearbeitet:
Hm, also bei mir funktioniert das ganze problemlos.

Gib mal anstelle von "iBookG4.local" localhost ein.
Wenn das auch nicht geht, poste doch mal einen Screenshot von den Einstellungen in Mail (den Port 1080 hast Du angegeben?).
 
Luke1 schrieb:
2. In Mail > Einstellungen > Accounts > Account-Information habe ich dann bei SMTP-Server mein iBook als neuen Server erstellt ("iBookG4.local"). Unter Servereinstellungen habe ich schließlich 25 als Serverport eingetragen.

Irre ich mich oder muss es nicht Port 1080 sein?
 
*-jalapeno-* schrieb:
Irre ich mich oder muss es nicht Port 1080 sein?
ja, so ist es.
Luke1 schreibt ja selbst oben: "1080 is the local port to use".
 
maceis schrieb:
ja, so ist es.
Luke1 schreibt ja selbst oben: "1080 is the local port to use".

Ja das war ein Fehler in der Darstellung hier. Es ist der Port 1080. Leider klappt es auch mit localhost nicht.

Die Screenshots würde ich hier nicht so gerne öffentlich posten. Sind ja doch eher persönliche Daten. Trotzdem besten Dank für Eure Hilfe. Wenn's bei Euch geht, muss ich es ja auch irgendwie zum laufen kriegen. Mal sehen...

Gruß,
Luke1
 
Zuletzt bearbeitet:
Luke1 schrieb:
Ich glaube mein Problem gehört hierhin:

Nein, es gehört nirgendwo hin, es gehört GELÖST. :)))

Im Ernst: Mailprogramme können bisweile sehr nervig sein, wenn es darum geht, exakte Fehlermeldungen auszugeben. Apples Mail ist da auf meiner persönlichen Rangliste führend und bewegt sich ungefähr auf dem Niveau von "Das geht nicht. Frag jemanden mit Ahnung." :)

Daher würde ich bei solchen Problemen erstmal "händisch" auf den SMTP-Server kontakten. Das geht in der Konsole mit

telnet DerRechner DerPort

Also bei dir mit Umleitung

telnet localhost 1080

und falls das nicht läuft, gleich auch nochmal ohne Umleitung testen:

telnet os9.server.lan 25


Sollte tatsächlich eine Verbindung zustande kommen, kannst du mal testweise eine Mail verschicken:

Code:
HELO dein.host.name
MAIL FROM: DeineMail@adresse.foo
RCPT TO: DeineMail@adresse.foo
DATA
Hier tippen wir mal
einen kleinen testtext
ein.
.

(Der einsame Punkt in der letzten Zeile beendet die Eingabe)
QUIT


Sollte irgendwas davon eine Fehlermeldung werfen - aufhören, "QUIT", keine weiteren Befehle eingeben. Resultat hier posten.

Gruß,
Ratti

P.S.: Und anhand dieses Beispiels sieht man, wie simpel man jede Mailadresse als Absender fälschen kann...

P.P.S.: Es gibt da unten übrigens eine Checkbox zum Abschalten der idiotischen Smilie-Bildchen. Ich wünschte, sie wäre von Dauer.
 
ratti schrieb:
telnet DerRechner DerPort

Also bei dir mit Umleitung

telnet localhost 1080

Hi Ratti,

besten Dank für Deine Hinweise. Jetzt weiß ich schon, dass man mit dem Terminal dem Problem auf die Schliche kommen kann.

Also der Befehl

telnet localhost 1080

funktioniert leider gar nicht. Ich krige dabei folgendes Ergebnis zurück:

Welcome to Darwin!
iBookG4:~ user$ telnet iBookG4.local 1080
Trying fe80:1::1...
telnet: connect to address fe80:1::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host

oder

iBookG4:~ user$ telnet localhost 1080
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host

Was mir hier komisch vorkommt ist die Tatasche, dass am Ende die Meldung kommt: "unable to connect to remote host", wo ich doch gerade auf den localhost zugreifen möchte.


Was den direkten Zugriff auf den remote smtp-server angeht, so kann ich damit eine Verbindung herstellen, nachdem ich in der beschriebenen Weise einen Tunnel gelegt habe.
Eine Mail zu schicken habe ich allerdings noch nicht probiert, da ich nicht so ganz verstanden habe wie das geht. Muss ich nach jeder Zeile in Deiner Anleitung die Eingabetaste drücken? Wie dem auch sei, glaube ich das Problem liegt nicht beim smtp-server. Heute bin ich nämlich im Büro und der direkte interne Zugriff klappt problemlos, d.h. ich wähle in Mail>Einstellungen den smtp-server aus und kann dann problemlos E-mails verschicken.
 
Luke1 schrieb:
Hi Ratti,

besten Dank für Deine Hinweise. Jetzt weiß ich schon, dass man mit dem Terminal dem Problem auf die Schliche kommen kann.

Also der Befehl

telnet localhost 1080

funktioniert leider gar nicht. Ich krige dabei folgendes Ergebnis zurück:

Welcome to Darwin!
iBookG4:~ user$ telnet iBookG4.local 1080
Trying fe80:1::1...
telnet: connect to address fe80:1::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host

oder

iBookG4:~ user$ telnet localhost 1080
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host

Dann lauscht da nichts. Es findet keine Umleitung statt

Das ist zumindest mal eine Erkenntnis - es hat jetzt überhaupt keinen Sinn, mit Authentifizierungen rumzuspielen oder so. Da geht überhaupt keine Gegenstelle dran.

Luke1 schrieb:
Was mir hier komisch vorkommt ist die Tatasche, dass am Ende die Meldung kommt: "unable to connect to remote host", wo ich doch gerade auf den localhost zugreifen möchte.

:)
Das ist schon OK. Die Zeichenkette ist fest einprogrammiert. Wenn man mit sich selbst spricht, ist man trotzdem seine eigene Gegenstelle.

Luke1 schrieb:
Was den direkten Zugriff auf den remote smtp-server angeht, so kann ich damit eine Verbindung herstellen, nachdem ich in der beschriebenen Weise einen Tunnel gelegt habe.

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
 
Um nochmal zu meinem Problem zu kommen: Heute habe ich über Fink OpenSSH installiert. Und es geht problemlos und sofort. Ergo: Bug bei Apple.
 
Wolfsbein schrieb:
Um nochmal zu meinem Problem zu kommen: Heute habe ich über Fink OpenSSH installiert. Und es geht problemlos und sofort. Ergo: Bug bei Apple.
Unsinn.
Das ist kein Bug bei Apple sondern schlimmstenfalls eine ungünstige Voreinstellung.
Wie schon gesagt: Bei mir gibt es das Problem gar nicht.
 
maceis schrieb:
Das ist kein Bug bei Apple sondern schlimmstenfalls eine ungünstige Voreinstellung.

Wieso "ungünstig"?

Ist doch verdammt sicher, einfach alle Verbindungen zu verbieten. Jetzt nur noch den Port in der Firewall blocken, den Netzwerkstecker verspachteln, die Kiste durch den Schredder schieben, die Teile auf fünf Kontinenten vergraben und die CPU in die Sonne schiessen. DEN hackt keiner mehr!

:)


Gruß,
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.

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.

Wolfsbein sagt nun, er habe das Problem gelöst (was mich freut), indem er OpenSSH installiert habe und schließt daraus auf einen "Bug bei Apple".
Möglicherweise weiß er nicht einmal, dass in Mac OS X OpenSSH implementiert ist, und er somit nicht etwa das Programm gewechselt hat, sondern nur andere Konfigurationsdateien und höchstens noch eine andere Versionsnummer verwendet.

Deinen Sarkasmus halte ich darum für ... ähm ... etwas unpassend :D.
 
Der Wolfsbein weiß sehr wohl, dass Darwin OpenSSH verwendet. Er meint mit Bug wohl auch eher, dass Apple keine aktuelle Version verwendet, bzw. gängige Unix Konventionen verwässert und Pfade, Namen, Logfiles leicht abändert :D.
 
Wolfsbein schrieb:
...
Er meint mit Bug wohl auch eher, dass Apple keine aktuelle Version verwendet,...
Das finde ich auch nicht so toll.
Wolfsbein schrieb:
...bzw. gängige Unix Konventionen verwässert
...
Welche "gängigen Unix Konventionen" meinst Du?
Wolfsbein schrieb:
...
und Pfade, Namen, Logfiles leicht abändert :D.
Es ist IMHO berechtigt bei jeder Unix Variante bestimmte logische und strukturelle "Eigenheiten" zu entwickeln; wenn das nicht so wäre, würde eine Unix Variante genügen.
Als aktuelles Beispiel möchte ich mal die (IMO sehr positive) Entwicklung von launchd nennen.
Wo bei ssh irgendetwas abgeändert wurde, ist mir nicht bekannt.

Ich kann mir auch nur schwer vorstellen, dass Dein Problem irgendetwas mit Dateipfaden und logfiles zu tun hat (auch nicht mit der Versionsnummer).
Wo wir schon einmal dabei sind: hast Du Dir mal die Mühe gemacht die Konfigurationsdateien zu vergleichen (z. B. mit diff)?
Hast Du den Client oder den Server nachinstalliert (oder beides)?
 
Code:
diff ssh_config1 ssh_config.applesaved 
1c1
< #     $OpenBSD: ssh_config,v 1.19 2003/08/13 08:46:31 markus Exp $
---
> #     $OpenBSD: ssh_config,v 1.16 2002/07/03 14:21:05 markus Exp $
20a21
> #   RhostsAuthentication no
27,28d27
< #   AddressFamily any
< #   ConnectTimeout 0
Es liegt wohl nur an der Versionsnummer. Und ja ich habe auch den Server installiert
 
Zurück
Oben Unten