.titleBar { margin-bottom: 5px!important; }

[Erledigt] SSHFS mit Trickle funktioniert nach Firmware update nicht mehr

Dieses Thema im Forum "Freetz" wurde erstellt von level20peon, 23 Okt. 2017.

  1. level20peon

    level20peon Mitglied

    Registriert seit:
    11 Juli 2007
    Beiträge:
    270
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    127.0.0.1
    Zuvor habe ich Folgendes gemacht, was wunderbar funktionierte:

    Code:
    /usr/bin/trickle -s -d 35 -u 0 /usr/bin/sshfs user@192.168.0.3:/pub /home/user/pub -odebug,sshfs_debug,loglevel=debug,reconnect,allow_other,nonempty,IdentityFile=/home/user/.ssh/rsa,sync_read
    
    Nach dem update auf 6.90 kommt die Verbindung nicht mehr zustande:

    Code:
    SSHFS version 2.4
    FUSE library version: 2.9.7
    nullpath_ok: 0
    nopath: 0
    utime_omit_ok: 0
    executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-oIdentityFile=/home/user/.ssh/rsa> <-2> <user@192.168.0.3> <-s> <sftp>
    debug1: Connecting to 192.168.0.3 [192.168.0.3] port 22.
    debug1: Connection established.
    debug1: permanently_set_uid: 0/0
    debug1: key_load_public: No such file or directory
    debug1: identity file /home/user/.ssh/rsa type -1
    debug1: key_load_public: No such file or directory
    debug1: identity file /home/user/.ssh/rsa-cert type -1
    debug1: Local version string SSH-2.0-OpenSSH_7.6
    debug1: Remote protocol version 2.0, remote software version OpenSSH_6.4
    debug1: match: OpenSSH_6.4 pat OpenSSH* compat 0x04000000
    debug1: Authenticating to 192.168.0.3:22 as 'user'
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
    debug1: kex: host key algorithm: ssh-rsa
    debug1: kex: server->client cipher: aes128-ctr MAC: umac-64-etm@openssh.com compression: none
    debug1: kex: client->server cipher: aes128-ctr MAC: umac-64-etm@openssh.com compression: none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
    ssh_dispatch_run_fatal: Connection to 192.168.0.3 port 22: Resource temporarily unavailable
    read: Connection reset by peer
    
    ... das Serverlog sagt:
    Code:
    Oct 23 07:53:11 SRV sshd: PID 4308: fatal: Read from socket failed: Connection reset by peer [preauth]
    
    Ohne trickle funktioniert die Verbindung:
    Code:
    SSHFS version 2.4
    FUSE library version: 2.9.7
    nullpath_ok: 0
    nopath: 0
    utime_omit_ok: 0
    executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-oIdentityFile=/home/user/.ssh/rsa> <-2> <user@192.168.0.3> <-s> <sftp>
    debug1: Connecting to 192.168.0.3 [192.168.0.3] port 22.
    debug1: Connection established.
    debug1: permanently_set_uid: 0/0
    debug1: key_load_public: No such file or directory
    debug1: identity file /home/user/.ssh/rsa type -1
    debug1: key_load_public: No such file or directory
    debug1: identity file /home/user/.ssh/rsa-cert type -1
    debug1: Local version string SSH-2.0-OpenSSH_7.6
    debug1: Remote protocol version 2.0, remote software version OpenSSH_6.4
    debug1: match: OpenSSH_6.4 pat OpenSSH* compat 0x04000000
    debug1: Authenticating to 192.168.0.3:22 as 'user'
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
    debug1: kex: host key algorithm: ssh-rsa
    debug1: kex: server->client cipher: aes128-ctr MAC: umac-64-etm@openssh.com compression: none
    debug1: kex: client->server cipher: aes128-ctr MAC: umac-64-etm@openssh.com compression: none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
    debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
    debug1: Server host key: ssh-rsa SHA256:rKSdHbdwOmRkAovNlrxvWrA7WB4zQf4pLVLIly836y8
    debug1: Host '192.168.0.3' is known and matches the RSA host key.
    debug1: Found key in /mod/root/.ssh/known_hosts:3
    debug1: rekey after 4294967296 blocks
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: rekey after 4294967296 blocks
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey,password,keyboard-interactive
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home/user/.ssh/rsa
    debug1: Authentication succeeded (publickey).
    Authenticated to 192.168.0.3 ([192.168.0.3]:22).
    debug1: channel 0: new [client-session]
    debug1: Requesting no-more-sessions@openssh.com
    debug1: Entering interactive session.
    debug1: pledge: network
    debug1: Sending subsystem: sftp
    Server version: 3
    Extension: posix-rename@openssh.com <1>
    Extension: statvfs@openssh.com <2>
    Extension: fstatvfs@openssh.com <2>
    Extension: hardlink@openssh.com <1>
    unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
    INIT: 7.22
    flags=0x0000f7fb
    max_readahead=0x00020000
       INIT: 7.19
       flags=0x00000010
       max_readahead=0x00020000
       max_write=0x00020000
       max_background=0
       congestion_threshold=0
       unique: 1, success, outsize: 40
    
    Nun habe ich schon recherchiert, was da zu recherchieren war, leider ohne Ergebnis. Vorgeschlagen wurde z.B. die Cipher fix vorzugeben, was ich mit einer Reihe verschiedener Cipher versucht habe - ohne Erfolg.

    Hat von euch noch jemand eine Idee?
     
  2. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    996
    Zustimmungen:
    18
    Punkte für Erfolge:
    18
    Scheint ein trickle-Problem zu sein, s. Fedora und upstream bug reports.

    Edit: Ich weiß jetzt nicht, ob "-u 0" unlimited bedeutet (bzw. gleich dem Weglassen von -u ist), teste aber bitte das Verhalten mit einer konkreten Zahl so wie im upstream Ticket vorgeschlagen wird.
     
  3. level20peon

    level20peon Mitglied

    Registriert seit:
    11 Juli 2007
    Beiträge:
    270
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    127.0.0.1
    Habe das erfolglos getestet. Dazu sei gesagt, dass sich die trickle Version auf der Box nicht geändert hat (und vorher funktionierte der selbe Befehl) - lediglich die openssh Version ist neuer als vor dem update. Es spielt übrigens keine Rolle, ob ich nun sshfs oder plain ssh benutze, der Fehler ist in beiden Fällen gleich.

    Was könnte ich sonst noch ausprobieren?
     
  4. level20peon

    level20peon Mitglied

    Registriert seit:
    11 Juli 2007
    Beiträge:
    270
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    127.0.0.1
    Wie sich herausstellt, kommt die Verbindung zustande, wenn man es 20-30 mal probiert. Ich packe das Ganze jetzt einfach in ein script und belasse es dabei.

    Vielen Dank trotzdem für den input :)