RE: unexplained pausing/freezing of SSH Terminal Sessions ?

From: Piszcz, Justin Michael (justin.piszcz_at_mitretek.org)
Date: 05/24/04

  • Next message: Darren Tucker: "Re: unexplained pausing/freezing of SSH Terminal Sessions ?"
    Date: Mon, 24 May 2004 07:20:43 -0400
    To: "OpenMacNews" <secureshell.20.openmacnews@spamgourmet.com>, <secureshell@securityfocus.com>
    
    

    I may know the exact cause...
    Do you use expect (scripting language) to initiate your SSH connections?
    If not, I am not sure.
    Something to try if not using expect, try telnet and see if it hangs, I
    also have had the same problem for years, the problem is (for me) I use
    expect, and it does not like certain characters and it will hang if it
    comes across them.
    Using telnet or ssh ip without expect works fine.

    -----Original Message-----
    From: OpenMacNews [mailto:secureshell.20.openmacnews@spamgourmet.com]
    Sent: Sunday, May 23, 2004 2:29 PM
    To: secureshell@securityfocus.com
    Subject: unexplained pausing/freezing of SSH Terminal Sessions ?

    hi all,

    i'm having an SSH Terminal Session "issue".

    i'm honestly not sure where to turn on this one. I *think* it may be an
    SSH issue, but ...

    Any pointers/ideas/solution/etc are much appreciated!

    I've a 4 machine setup. These machines define an internal/private
    network w/ internet access:

              Public Internet
                     |
                 DSL Modem
                     |
                     |
        (2) IPFW firewall & NATD instance
                     |
                     |
            10/100bT Ethernet Switch
                     |
                     |
                     |------- (1)
                     |
                     |
                     |------- (3)
                     |
                     |
                     |------- (4)

    /*

    FWIW, these machines are:

        (1) G4 PowerBook
            OSX 10.3.3

        (2) Mac 8500
            Sonnet G3/333 upgrade
            Sonnet TEMPO 66 ATA card (2 drives on Sonnet ... none on
    internal bus)
        2 Asante 696 10/100 Ethernet Cards (manually config'd to 100bT &
    FullDuplex)
            OSX 10.2.8 w/ XPF 3.0a17 & L2CacheConfig

        (3) Mac 8500
            Sonnet G3/333 upgrade
            Sonnet TEMPO 66 ATA card (2 drives on Sonnet ... none on
    internal bus)
            Asante 690 10/100 Ethernet Card (manually config'd to 100bT &
    FullDuplex)
            OSX 10.2.8 w/ XPF 3.0a17 & L2CacheConfig

        (4) Mac Beige G3
            Sonnet G4/500 upgrade
            Sonnet TEMPO 66 ATA card (2 drives on Sonnet ... ONE on internal
    bus)
            Asante 590 10/100 Ethernet Card (manually config'd to 100bT &
    FullDuplex)
            OSX 10.3.3 w/ XPF 3.0a17 & PowerLogix CPU Director 1.5.2
    */

    All machines have OpenSSL 0.9.7d + OpenSSH 3.8.1p1 locally
    compiled/installed ...

    OpenSSH is configured to use only Protocol2, PublicKeyAuthentication
    (1024 bit RSA keys), and TCP Wrappers.

    SSHD runs as an 'on demand' service via xinetd, with TCP Wrappers
    controlling/limiting access via the usual hosts.allow/hosts.deny
    configs.

    With my authentication/access scheme, I can SSH FROM any machine TO any
    machine, as expected.

    The "issue" arises in SSH'ing *TO* (4) from any/every other machine.

    Specifically, once an SSH session is open/active, any task requiring a
    "lot" of data (example: "ls -al" of a large DIR) to be transferred via
    terminal session pauses (always) after a fraction of the expected data
    is transferred and (frequently) hangs the session.

    Again, this ONLY happens in sessions TO machine (4) from OTHER machines.
    Sessions opened:
        (a) between other machines
        (b) from (4) to other machines
        (c) from (4) to itself
    ... ALL operate at "full speed" with NO apparent pauses/hangs in the
    terminal sessions.

    So far, in efforts to remediate, I've:
        (a) changed Ehternet MTU settings from 1500 to 576, both in pair
    combinations and 'en masse'
        (b) varied Client, Server and TCP timeouts in ssh_config &
    sshd_config
        (c) Turned session Compression "off"
        (c) turned off xinetd service of sshd, and reverted to standard
    daemon mode

    NONE of these effort changed/improved the session behavior TO (4).

    Any suggestions as to where to look next? I'm not even certain, yet,
    whether I'm missing something, or whether there actually is an issue
    here ....

    Thanks,

    Richard


  • Next message: Darren Tucker: "Re: unexplained pausing/freezing of SSH Terminal Sessions ?"

    Relevant Pages

    • Re: SSH through a proxy
      ... >Can the network administrator detect the difference between a simple SSH ... >session from B to C and a session from B to C which has ports forwarded? ... assuming that he has access to at least one of those machines. ...
      (comp.security.ssh)
    • Re: SSH through a proxy
      ... >Can the network administrator detect the difference between a simple SSH ... >session from B to C and a session from B to C which has ports forwarded? ... assuming that he has access to at least one of those machines. ...
      (comp.security.ssh)
    • Re: scp. I dont get it
      ... And you are not going to derive the private key from the public key, ... I have an unsecured public SSH key. ... new machines all the time. ... My SSH key loaded active session is now available on the trojaned client to ...
      (comp.os.linux.security)
    • Re: Can Exceed connect to linux (running Gnome) through SSH?
      ... > -These machines are in two separate physical locations and separated ... Each firewall allows SSH ... Now start xterm and you should see a window pop up" ... > I simply log in through the Gnome login screen and it works. ...
      (comp.os.linux.security)
    • (no subject)
      ... > -These machines are in two separate physical locations and separated ... Each firewall allows SSH ... Now start xterm and you should see a window pop up" ... > I simply log in through the Gnome login screen and it works. ...
      (comp.os.linux.security)