🚀 go-pugleaf

["Followup-To:" header set to de.comp.os.unix.networking.misc.]
Stefan Zinn schrieb:

> Das Problem ist nun, wenn ich mich von einer Linuxworkstation oder von
> einer Sunworkstation (via ssh) aus auf eine Linuxworkstation einloggen
> m�chte, dauert es mindestens 15 Sekunden bis es m�glich ist das
> Passwort f�r die Authentifizierung einzugeben. Beim einloggen auf eine
> Sunworkstation (auch mit ssh) l�uft dieser Vorgang sehr z�gig ab!!

Klingt so, als sei zwischen den Rechnern irgendwo ein fehlkonfigurierter
Paketfilter installiert, der ankommende SYN-Pakete lautlos ignoriert
anstatt ein "Connection Refused" zur�ckzuschicken. Der OpenSSH-Server
erfragt bei jeder neuen Verbindung per ident das Nutzerkennzeichen des
entfernten Nutzers. Wenn er darauf keine Antwort bekommt, wartet er eben
ein paar Sekunden ab.

        Tschau,
            Ingo

-- 
Hobbes: How come we play war and not peace?
Calvin: Too few role models.              -- Bill Watterson, Calvin and Hobbes

begin 1 followup to Stefan Zinn <stefan@stefanzinn.de>:
> vor ein paar Tagen habe ich in einem Netzwerk mit  Linuxclients (SuSE 8.1)
> und Solarisworkstations (Solaris 8) einen DNS-Server (auf  Solaris 8 und
> dem mitgelieferten Bind 8.2) konfiguriert, der auch funkioniert.
> Vorher wurden hier Hosttabllen  eingesetzt, welche auf jeder Maschine
> gepflegt wurden mussten.

Hast du auch die reverse Zonen? (20.168.192.in-addr.arap. genau genommen)

> 18:23:59.573618 192.168.20.7.53 > 192.168.20.57.32817:  1311 ServFail 0/0/0
> (33) (DF)
> 18:23:59.573669 192.168.20.57 > 192.168.20.7: icmp: 192.168.20.57 udp port
> 32817 unreachable [tos 0xc0]

Dein DNS setup ist im auch nicht das Gelbe vom Ei...

Der DNS-server antwortet mit ServFail DNS-Diagnostics, und dein Client
tut so als ob er nie gefragt hat. Gut, kann ein Seiteneffekt sein.

> 18:24:21.804651 192.168.20.57.32817 > 192.168.20.7.53:  45028+ SRV?
> _kerberos._http.NOC.DOMAIN.NETW. (50) (DF)
> 18:24:21.804966 192.168.20.7.53 > 192.168.20.57.32817:  45028 NXDomain*
> 0/1/0 (124) (DF)
> 18:24:21.805315 192.168.20.57.32817 > 192.168.20.7.53:  45029+ A?
> kerberos.NOC.DOMAIN.NETW. (43) (DF)
> 18:24:21.806294 192.168.20.7.53 > 192.168.20.57.32817:  45029 NXDomain*
> 0/1/0 (117) (DF)

Dein DNS-client (resolver) unter linux ist reichlich Begriffstutzig.
Desweiteren solltest du Kerberos-Auth abschalten, sofern du sie nicht
benutzt, oder aber ordentlich konfigurieren. Das oben zeugt von einem
kaputten Kerberos Setup.

> So wie das hier aussieht versucht der SSH-Server auf der Linuxkiste Kerberos
> mit ins Spiel zu bringen.

Ach. Weil du ihm das so sagst. Schalte Kerberos in der SSH bzw.
der SSH-PAM-Config aus.

> Auf dem SSH-Server der Linuxkisten habe ich folgende Konfigurationen am
> SSH-Server ver�ndert:
>
> KerberosAuthentication no
> KerberosTgtPassing no
>
> Allerdings ohne Erfolg (den SSH-Daemon habe ich dazu neu gestartet!!!).

Verwendest du PAM? Dann musst du kerberos auch im PAM entsorgen.
(/etc/pam* genauer: pam.conf und/oder pam.d/sshd)

> F�r einen hilfreichen Tip oder einen guten L�sungsansatz w�re ich sehr
> dankbar.

SSH benutzt bei Linux PAM, d.h. du musst die Auth-sachen dort und
nicht in der sshd_config einstellen.

Xpost mit korrigiertem fup2 -  bitte in zukunft keine so krassen
Crossposts!

HTH,
Juegen
-- 
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems.  (Bruce Schneier)

Stefan Zinn wrote:
> Hallo zusammen,
> 
> vor ein paar Tagen habe ich in einem Netzwerk mit  Linuxclients (SuSE 8.1)
> und Solarisworkstations (Solaris 8) einen DNS-Server (auf  Solaris 8 und
> dem mitgelieferten Bind 8.2) konfiguriert, der auch funkioniert.
> Vorher wurden hier Hosttabllen  eingesetzt, welche auf jeder Maschine
> gepflegt wurden mussten.
> 

ich hatte mal das gleiche verhalten. bei mir waren die ursache 
nicht-funktionierende dns reverse-lookups. das ist recht einfach zu 
�berpr�fen, indem man sshd mit dem parameter -u0 aufruft (verhindert dns 
lookups).

 > <snip>

j�rgen

Hallo,
das Problem hat sich mittlerweile gel�st. Grund daf�r war ein Fehler im
SSH-Server.
Hab daraufhin von SuSE einen entsprechenden SSH-Patch eingespielt und dann
funzte es auch auch wieder auf schnellem Wege.
Vielen Dank aber auch f�r die Tips und Hilfestellungen an alle die sich mit
dem
Problem auseinandergesetzt haben.

Gruss

Stefan




Stefan Zinn <stefan@stefanzinn.de> schrieb in im Newsbeitrag:
c5g97d$15u3b$1@ID-208955.news.uni-berlin.de...
> Hallo zusammen,
>
> vor ein paar Tagen habe ich in einem Netzwerk mit  Linuxclients (SuSE 8.1)
> und Solarisworkstations (Solaris 8) einen DNS-Server (auf  Solaris 8 und
> dem mitgelieferten Bind 8.2) konfiguriert, der auch funkioniert.
> Vorher wurden hier Hosttabllen  eingesetzt, welche auf jeder Maschine
> gepflegt wurden mussten.
>
> Das Problem ist nun, wenn ich mich von einer Linuxworkstation oder von
einer
> Sunworkstation (via ssh) aus auf eine Linuxworkstation einloggen m�chte,
> dauert es
> mindestens 15 Sekunden bis es m�glich ist das Passwort f�r die
> Authentifizierung
> einzugeben. Beim einloggen auf eine Sunworkstation (auch mit ssh) l�uft
> dieser Vorgang
> sehr z�gig ab!!
>
> Um das Problem einzugrenzen habe zus�tzlich auf den Linuxclients noch
einen
> Telnetserver nachinstalliert. Wenn man sich nun via Telnet (von einer
> Linuxworkstation
> oder Sunworkstation) auf einen SuSE-Client verbinden m�chte tritt dieses
> Verhalten
> nicht auf. Man kann sofort den Benutzernamen und das Passwort eingeben und
> landet
> auf der Maschine.
>
> Momentan vermute ich, dass es sich hier um ein Problem mit den SSH-Servern
> auf den
> Linuxworkstations handelt. Auf denen l�uft die Version:
> SSH-2.0-OpenSSH_3.4p1!
>  (also die RPM�s von 8.1!!). Kann es evtl. sein das diese Version Fehler
> hat???
>
>
> Bei einem Verdingungsaufbau von einem anderen Host zu einer
Linuxworkstation
> spielt sich laut tcpdump folgendes ab:
>
> 18:23:57.927731 192.168.20.7.33394 > 192.168.20.57.22: . ack 273 win 24820
> (DF) [tos 0x10]
> 18:23:57.928135 192.168.20.7.33394 > 192.168.20.57.22: P 96:128(32) ack
273
> win 24820 (DF) [tos 0x10]
> 18:23:57.928343 192.168.20.7.33394 > 192.168.20.57.22: F 128:128(0) ack
273
> win 24820 (DF) [tos 0x10]
> 18:23:57.929012 192.168.20.57.22 > 192.168.20.7.33394: F 273:273(0) ack
129
> win 8704 (DF) [tos 0x10]
> 18:23:57.929164 192.168.20.7.33394 > 192.168.20.57.22: . ack 274 win 24820
> (DF) [tos 0x10]
> 18:23:59.257256 192.168.20.4.520 > 192.168.20.255.520:  RIPv1-resp [items
> 1]: {50.0.0.0}(1) (DF) [ttl 1]
> 18:23:59.573618 192.168.20.7.53 > 192.168.20.57.32817:  1311 ServFail
0/0/0
> (33) (DF)
> 18:23:59.573669 192.168.20.57 > 192.168.20.7: icmp: 192.168.20.57 udp port
> 32817 unreachable [tos 0xc0]
> 18:24:01.573396 192.168.20.7.53 > 192.168.20.57.32817:  1312 ServFail
0/0/0
> (32) (DF)
> 18:24:01.573433 192.168.20.57 > 192.168.20.7: icmp: 192.168.20.57 udp port
> 32817 unreachable [tos 0xc0]
> 18:24:01.754601 192.168.20.7.33395 > 192.168.20.57.22: S
> 736442165:736442165(0) win 24820 <nop,nop,sackOK,mss 1460> (DF)
> 18:24:01.754636 192.168.20.57.22 > 192.168.20.7.33395: S
> 3148907074:3148907074(0) ack 736442166 win 5840 <mss 1460,nop,nop,sackOK>
> (DF)
> 18:24:01.754787 192.168.20.7.33395 > 192.168.20.57.22: . ack 1 win 24820
> (DF)
> 18:24:01.756834 192.168.20.57.22 > 192.168.20.7.33395: P 1:23(22) ack 1
win
> 5840 (DF)
> 18:24:01.756973 192.168.20.7.33395 > 192.168.20.57.22: . ack 23 win 24820
> (DF)
> 18:24:01.757257 192.168.20.7.33395 > 192.168.20.57.22: P 1:23(22) ack 23
win
> 24820 (DF)
> 18:24:01.757273 192.168.20.57.22 > 192.168.20.7.33395: . ack 23 win 5840
> (DF)
> 18:24:01.759018 192.168.20.7.33395 > 192.168.20.57.22: P 23:567(544) ack
23
> win 24820 (DF)
> 18:24:01.759033 192.168.20.57.22 > 192.168.20.7.33395: . ack 567 win 6528
> (DF)
> 18:24:01.762284 192.168.20.57.32817 > 192.168.20.7.53:  45018+ TXT?
> krb5-realm.li7.noc.domain.netw. (53) (DF)
> 18:24:01.763680 192.168.20.7.53 > 192.168.20.57.32817:  45018 NXDomain*
> 0/1/0 (127) (DF)
> 18:24:01.763861 192.168.20.57.32817 > 192.168.20.7.53:  45019+ TXT?
> _kerberos.li7.noc.domain.netw. (52) (DF)
> 18:24:01.764122 192.168.20.7.53 > 192.168.20.57.32817:  45019 NXDomain*
> 0/1/0 (126) (DF)
> 18:24:01.764199 192.168.20.57.32817 > 192.168.20.7.53:  45020+ TXT?
> krb5-realm.noc.domain.netw. (45) (DF)
> 18:24:01.765460 192.168.20.7.53 > 192.168.20.57.32817:  45020 NXDomain*
> 0/1/0 (119) (DF)
> 18:24:01.765539 192.168.20.57.32817 > 192.168.20.7.53:  45021+ TXT?
> _kerberos.noc.domain.netw. (44) (DF)
> 18:24:01.765756 192.168.20.7.53 > 192.168.20.57.32817:  45021 NXDomain*
> 0/1/0 (118) (DF)
> 18:24:01.765824 192.168.20.57.32817 > 192.168.20.7.53:  45022+ TXT?
> krb5-realm.domain.netw. (41) (DF)
> 18:24:01.766132 192.168.20.7.53 > 192.168.20.57.32817:  45022 NXDomain*
> 0/1/0 (115) (DF)
> 18:24:01.766207 192.168.20.57.32817 > 192.168.20.7.53:  45023+ TXT?
> _kerberos.domain.netw. (40) (DF)
> 18:24:01.766510 192.168.20.7.53 > 192.168.20.57.32817:  45023 NXDomain*
> 0/1/0 (114) (DF)
> 18:24:01.766582 192.168.20.57.32817 > 192.168.20.7.53:  45024+ TXT?
> krb5-realm.netw. (33) (DF)
> 18:24:06.768070 192.168.20.57.32817 > 192.168.20.7.53:  45024+ TXT?
> krb5-realm.netw. (33) (DF)
> 18:24:08.605645 192.168.20.3.520 > 192.168.20.255.520:  RIPv1-resp [items
> 1]: {50.0.0.0}(1) (DF) [ttl 1]
> 18:24:11.778172 192.168.20.57.32817 > 192.168.20.7.53:  45025+ TXT?
> _kerberos.netw. (32) (DF)
> 18:24:16.266034 192.168.20.2.520 > 192.168.20.255.520:  RIPv1-resp [items
> 1]: {90.0.0.0}(1) (DF) [ttl 1]
> 18:24:16.788069 192.168.20.57.32817 > 192.168.20.7.53:  45025+ TXT?
> _kerberos.netw. (32) (DF)
> 18:24:21.262658 192.168.20.5.520 > 192.168.20.255.520:  RIPv1-resp [items
> 2]: {50.0.0.0}(1) {90.0.0.0}(1) (DF) [ttl 1]
> 18:24:21.800235 192.168.20.57.32817 > 192.168.20.7.53:  45026+ SRV?
> _kerberos._udp.NOC.DOMAIN.NETW. (49) (DF)
> 18:24:21.801785 192.168.20.7.53 > 192.168.20.57.32817:  45026 NXDomain*
> 0/1/0 (123) (DF)
> 18:24:21.803019 192.168.20.57.32817 > 192.168.20.7.53:  45027+ SRV?
> _kerberos._tcp.NOC.DOMAIN.NETW. (49) (DF)
> 18:24:21.804315 192.168.20.7.53 > 192.168.20.57.32817:  45027 NXDomain*
> 0/1/0 (123) (DF)
> 18:24:21.804651 192.168.20.57.32817 > 192.168.20.7.53:  45028+ SRV?
> _kerberos._http.NOC.DOMAIN.NETW. (50) (DF)
> 18:24:21.804966 192.168.20.7.53 > 192.168.20.57.32817:  45028 NXDomain*
> 0/1/0 (124) (DF)
> 18:24:21.805315 192.168.20.57.32817 > 192.168.20.7.53:  45029+ A?
> kerberos.NOC.DOMAIN.NETW. (43) (DF)
> 18:24:21.806294 192.168.20.7.53 > 192.168.20.57.32817:  45029 NXDomain*
> 0/1/0 (117) (DF)
> 18:24:21.806780 192.168.20.57.22 > 192.168.20.7.33395: P 23:567(544) ack
567
> win 6528 (DF)
> 18:24:21.807321 192.168.20.7.33395 > 192.168.20.57.22: P 567:591(24) ack
567
> win 24820 (DF)
> 18:24:21.807344 192.168.20.57.22 > 192.168.20.7.33395: . ack 591 win 6528
> (DF)
> 18:24:21.814521 192.168.20.57.22 > 192.168.20.7.33395: P 567:991(424) ack
> 591 win 6528 (DF)
> 18:24:21.911295 192.168.20.7.33395 > 192.168.20.57.22: . ack 991 win 24820
> (DF)
>
>
> 192.168.20.57 -> hierbei handelt es sich um einen Linuxclient
>
> 192.168.20.7   -> dies ist der DNS-Server
>
> So wie das hier aussieht versucht der SSH-Server auf der Linuxkiste
Kerberos
> mit ins Spiel zu bringen.
>
> Auf dem SSH-Server der Linuxkisten habe ich folgende Konfigurationen am
> SSH-Server ver�ndert:
>
> # Kerberos options
> # KerberosAuthentication automatically enabled if keyfile exists
> KerberosAuthentication no
> #KerberosOrLocalPasswd yes
> #KerberosTicketCleanup yes
>
> # Kerberos TGT Passing only works with the AFS kaserver
> KerberosTgtPassing no
>
> Allerdings ohne Erfolg (den SSH-Daemon habe ich dazu neu gestartet!!!).
>
> F�r einen hilfreichen Tip oder einen guten L�sungsansatz w�re ich sehr
> dankbar.
>
> MFG
>
> Stefan
>
>
>
>
>
>