keepalive's in SSH-1 and when to stop reading data - SSH

This is a discussion on keepalive's in SSH-1 and when to stop reading data - SSH ; >From the SSH-1 specs: It is recommended that keepalives are used, because otherwise pro- grams on the server may never notice if the other end of the connec- tion is rebooted. What would the protocol flag for such a keepalive ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: keepalive's in SSH-1 and when to stop reading data

  1. keepalive's in SSH-1 and when to stop reading data

    >From the SSH-1 specs:

    It is recommended that keepalives are used, because otherwise pro-
    grams on the server may never notice if the other end of the
    connec-
    tion is rebooted.

    What would the protocol flag for such a keepalive be? SSH_MSG_IGNORE?

    Also, say I want to execute an 'ls' on the server. As far as I know,
    the only way to do this is to request a pty and then to start a
    shell. You then send the command 'ls' in, via stdin, and read the
    output via stdout. A problem with this method, however, is that you
    have no way of knowing when ls's output is done. The output could use
    1x SSH_SMSG_STDOUT_DATA packet, or it could use 15x
    SSH_SMSG_STDOUT_DATA packets. This begs the question... how do you
    know when to stop reading? Maybe there's some other type of packet /
    protocol flag that can be used that'd tell you when to stop reading?
    eg. maybe one that sends a SSH_SMSG_SUCCESS when the output is
    finished?


  2. Re: keepalive's in SSH-1 and when to stop reading data

    yawnmoth wrote:
    > What would the protocol flag for such a keepalive be? SSH_MSG_IGNORE?


    Yes.

    > Also, say I want to execute an 'ls' on the server. As far as I know,
    > the only way to do this is to request a pty and then to start a
    > shell. You then send the command 'ls' in, via stdin, and read the
    > output via stdout. A problem with this method, however, is that you
    > have no way of knowing when ls's output is done.


    Yes, so don't do it like that. Instead of starting a shell using
    SSH_CMSG_EXEC_SHELL, you use SSH_CMSG_EXEC_CMD and send "ls" as the
    command string in that packet. Then you know when the output is done
    because the server will close the data channel and also send you
    SSH_SMSG_EXITSTATUS.

    You might find the `Logging > Session logging > SSH packets' setting
    in PuTTY to be a useful learning tool for this purpose. It creates a
    log file showing you exactly what SSH messages are sent back and
    forth during a session; so the next time you want to know how to do
    something like this, you can ask PuTTY to do whatever it is and then
    read the log file to find out how it went about it.
    --
    Simon Tatham "infinite loop _see_ loop, infinite"
    - Index, Borland Pascal Language Guide

  3. Re: keepalive's in SSH-1 and when to stop reading data

    On May 29, 5:18 pm, Simon Tatham wrote:
    >
    >
    > You might find the `Logging > Session logging > SSH packets' setting
    > in PuTTY to be a useful learning tool for this purpose. It creates a
    > log file showing you exactly what SSH messages are sent back and
    > forth during a session; so the next time you want to know how to do
    > something like this, you can ask PuTTY to do whatever it is and then
    > read the log file to find out how it went about it.

    That does indeed sound like a useful learning tool - thanks!


  4. Re: keepalive's in SSH-1 and when to stop reading data

    On May 29, 5:18 pm, Simon Tatham wrote:
    > yawnmoth wrote:
    > > What would the protocol flag for such a keepalive be? SSH_MSG_IGNORE?

    >
    > Yes.
    >
    > > Also, say I want to execute an 'ls' on the server. As far as I know,
    > > the only way to do this is to request a pty and then to start a
    > > shell. You then send the command 'ls' in, via stdin, and read the
    > > output via stdout. A problem with this method, however, is that you
    > > have no way of knowing when ls's output is done.

    >
    > Yes, so don't do it like that. Instead of starting a shell using
    > SSH_CMSG_EXEC_SHELL, you use SSH_CMSG_EXEC_CMD and send "ls" as the
    > command string in that packet. Then you know when the output is done
    > because the server will close the data channel and also send you
    > SSH_SMSG_EXITSTATUS.

    According to the specs, "[SSH_SMSG_EXITSTATUS is] the last message
    sent by the server". As such, I have to wonder... is it possible to
    execute two commands like this? eg. can you get the output for an ls
    and then for a pwd without having to wait, unsure of whether or not
    you've reached the end?


  5. Re: keepalive's in SSH-1 and when to stop reading data

    yawnmoth wrote:
    > According to the specs, "[SSH_SMSG_EXITSTATUS is] the last message
    > sent by the server". As such, I have to wonder... is it possible to
    > execute two commands like this? eg. can you get the output for an ls
    > and then for a pwd without having to wait, unsure of whether or not
    > you've reached the end?


    Probably not very easily, no. This is one of the inconvenient things
    about SSH-1 which was rectified in SSH-2: in SSH-2 you can open
    multiple session channels, sequentially or simultaneously or both,
    in a single SSH connection.

    You could do something really hideous involving running a helper
    program on the server side which would run two commands and
    packetise their output so you could separate it when it reached you,
    but that would depend on having that program available on whatever
    server you wanted. (Though you might get away with making it a
    longish Perl one-liner...)

    If you can possibly arrange to upgrade to SSH-2, that's probably a
    better plan.
    --
    Simon Tatham "_shin_, n. An ingenious device for
    finding tables and chairs in the dark."

  6. Re: keepalive's in SSH-1 and when to stop reading data

    On May 30, 8:16 am, Simon Tatham wrote:
    > yawnmoth wrote:
    > > According to the specs, "[SSH_SMSG_EXITSTATUS is] the last message
    > > sent by the server". As such, I have to wonder... is it possible to
    > > execute two commands like this? eg. can you get the output for an ls
    > > and then for a pwd without having to wait, unsure of whether or not
    > > you've reached the end?

    >
    > Probably not very easily, no. This is one of the inconvenient things
    > about SSH-1 which was rectified in SSH-2: in SSH-2 you can open
    > multiple session channels, sequentially or simultaneously or both,
    > in a single SSH connection.
    >
    > You could do something really hideous involving running a helper
    > program on the server side which would run two commands and
    > packetise their output so you could separate it when it reached you,
    > but that would depend on having that program available on whatever
    > server you wanted. (Though you might get away with making it a
    > longish Perl one-liner...)
    >
    > If you can possibly arrange to upgrade to SSH-2, that's probably a
    > better plan.

    I'll probably do that soon enough. Thanks for the help!


+ Reply to Thread