# ssh: Write failed: Broken pipe

## Royal

Moin,

Schaut euch mal bitte folgendes Problem an:

Gestern verweigerte der CVS Server (2.6 dev Kernel gentoo2004.2) die ssh verbindung. Schlüssel erkennt er nicht und das Passwort möchte er auch nicht haben. Geändert wurde überhaupt nichts... Denke ich : ) Und die Platten sind auch nicht voll, was ein Leeren der passwd verursachen könnte.

Lokal geht der login. (hatte ich zuerst auch problem emit)

Nach der Passworteingabe folgen diese Zeilen:

Password:

debug1: packet_send2: adding 32 (len 18 padlen 14 extra_pad 64)

Write failed: Broken pipe

debug1: Calling cleanup 0x8063510(0x0)

Der public key liegt in /home/root/.ssh/authorized_keys.

Aber auch in /root/.ssh/authorized_keys liegt der key.

Hier die Ausgabe von # ssh -vvv IP

--snip--

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: dh_gen_key: priv key bits set: 136/256

debug1: bits set: 1053/2048

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts

debug3: check_host_in_hostfile: match line 9

debug1: Host '192.168.150.35' is known and matches the RSA host key.

debug1: Found key in /root/.ssh/known_hosts:9

debug1: bits set: 954/2048

debug1: ssh_rsa_verify: signature correct

debug1: kex_derive_keys

debug1: newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: waiting for SSH2_MSG_NEWKEYS

debug1: newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: done: ssh_kex2.

debug1: send SSH2_MSG_SERVICE_REQUEST

debug1: service_accept: ssh-userauth

debug1: got SSH2_MSG_SERVICE_ACCEPT

debug1: authentications that can continue: publickey,keyboard-interactive

debug3: start over, passed a different list publickey,keyboard-interactive

debug3: preferred publickey,keyboard-interactive,password

debug3: authmethod_lookup publickey

debug3: remaining preferred: keyboard-interactive,password

debug3: authmethod_is_enabled publickey

debug1: next auth method to try is publickey

debug1: try privkey: /root/.ssh/identity

debug3: no such identity: /root/.ssh/identity

debug1: try pubkey: /root/.ssh/id_rsa

debug3: send_pubkey_test

debug2: we sent a publickey packet, wait for reply

debug1: authentications that can continue: publickey,keyboard-interactive

debug1: try privkey: /root/.ssh/id_dsa

debug3: no such identity: /root/.ssh/id_dsa

debug2: we did not send a packet, disable method

debug3: authmethod_lookup keyboard-interactive

debug3: remaining preferred: password

debug3: authmethod_is_enabled keyboard-interactive

debug1: next auth method to try is keyboard-interactive

debug2: userauth_kbdint

debug2: we sent a keyboard-interactive packet, wait for reply

debug2: input_userauth_info_req

debug2: input_userauth_info_req: num_prompts 1

Password:

debug1: packet_send2: adding 32 (len 18 padlen 14 extra_pad 64) 

Write failed: Broken pipe

debug1: Calling cleanup 0x8063510(0x0)

Schönen dank für eure Hilfe.

Thorsten

----------

## dakjo

Kann es sein das deine Netzwerkverbindung Packete verliert?

Ich hatte mal ein ähnliches Problem und konnte es auf ein defektes CAT5 Kabel zurückführen.

HTH

----------

## Royal

Guter Tip, meistenst sinds Banalitäten an die man nicht denkt. Aber leider (naja...) läufts einwandfrei. ich update gerade ssh und das läuft ohne probleme.

----------

## dakjo

Diese Zeile gibt mir irgendwie zu denken

 *Quote:*   

> debug2: we did not send a packet, disable method 

 

----------

## Royal

Ich habe jetzt ein emerge -u openssh durchgeführt und kann wieder mit passwort connecten. Nicht mit Keys, was nötig ist, für CVS.

Die Nachricht 

```

debug2: we did not send a packet, disable method

```

erscheint immer noch beim prüfen der Keys.

Mich wundert, dass er die authorized_keys in /home/root/.ssh nicht prüft, obwohl das in der sshd_conf so angegeben ist.

```

AuthorizedKeysFile      /home/%u/.ssh/authorized_keys

```

Allerdings ist auch komisch, dass er das passwort vom bu server annahm, obwohl das nicht zulässig ist war:

```

PasswordAuthentication no

```

(ist jetzt natürlich auf yes gesetzt)

----------

