EOL in stderr of ssh - Linux - openssh

This is a discussion on EOL in stderr of ssh - Linux - openssh ; Hello everyone, recently I've found something I consider a bug. Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A. Imagine my surprise when I saw that all messages that are being output on to the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: EOL in stderr of ssh - Linux

  1. EOL in stderr of ssh - Linux

    Hello everyone,
    recently I've found something I consider a bug.

    Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
    Imagine my surprise when I saw that all messages that are being output
    on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
    terminated with 0x0D, 0x0A.

    Maybe that's standard behaviour of all stderr messages in all Linux
    software, but I have to admin it's the first time I saw something like
    this.

    So, can anybody tell me if it's for a purpose, or is it just a plain bug?

    yours sincerely,
    Stanislaw Kaminski
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  2. Re: EOL in stderr of ssh - Linux

    On Mon, Jul 14, 2008 at 04:26:47PM +0200, Stanislaw Kaminski wrote:
    > Imagine my surprise when I saw that all messages that are being output
    > on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
    > terminated with 0x0D, 0x0A.


    How are you testing this?


    > So, can anybody tell me if it's for a purpose, or is it just a plain bug?


    I doubt ssh has \r\n in any source files.


    //Peter
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. RE: EOL in stderr of ssh - Linux

    Not on my Fedora Core 7 or my CentOS 5.2 box - both of them terminate
    with just 0x0A, as is shown below:

    ssh -v 2>&1 | xxd
    0000000: 4f70 656e 5353 485f 342e 3370 322c 204f OpenSSH_4.3p2, O
    0000010: 7065 6e53 534c 2030 2e39 2e38 6220 3034 penSSL 0.9.8b 04
    0000020: 204d 6179 2032 3030 360a 7573 6167 653a May 2006.usage:
    0000030: 2073 7368 205b 2d31 3234 3641 6143 6667 ssh [-1246AaCfg
    0000040: 6b4d 4e6e 7173 5474 5676 5878 595d 205b kMNnqsTtVvXxY] [
    0000050: 2d62 2062 696e 645f 6164 6472 6573 735d -b bind_address]
    0000060: 205b 2d63 2063 6970 6865 725f 7370 6563 [-c cipher_spec
    0000070: 5d0a 2020 2020 2020 2020 2020 205b 2d44 ]. [-D
    0000080: 205b 6269 6e64 5f61 6464 7265 7373 3a5d [bind_address:]
    0000090: 706f 7274 5d20 5b2d 6520 6573 6361 7065 port] [-e escape
    00000a0: 5f63 6861 725d 205b 2d46 2063 6f6e 6669 _char] [-F confi
    00000b0: 6766 696c 655d 0a20 2020 2020 2020 2020 gfile].
    00000c0: 2020 5b2d 6920 6964 656e 7469 7479 5f66 [-i identity_f
    00000d0: 696c 655d 205b 2d4c 205b 6269 6e64 5f61 ile] [-L [bind_a
    00000e0: 6464 7265 7373 3a5d 706f 7274 3a68 6f73 ddress:]port:hos
    00000f0: 743a 686f 7374 706f 7274 5d0a 2020 2020 t:hostport].
    0000100: 2020 2020 2020 205b 2d6c 206c 6f67 696e [-l login
    0000110: 5f6e 616d 655d 205b 2d6d 206d 6163 5f73 _name] [-m mac_s
    0000120: 7065 635d 205b 2d4f 2063 746c 5f63 6d64 pec] [-O ctl_cmd
    0000130: 5d20 5b2d 6f20 6f70 7469 6f6e 5d20 5b2d ] [-o option] [-
    0000140: 7020 706f 7274 5d0a 2020 2020 2020 2020 p port].
    0000150: 2020 205b 2d52 205b 6269 6e64 5f61 6464 [-R [bind_add
    0000160: 7265 7373 3a5d 706f 7274 3a68 6f73 743a ress:]port:host:
    0000170: 686f 7374 706f 7274 5d20 5b2d 5320 6374 hostport] [-S ct
    0000180: 6c5f 7061 7468 5d0a 2020 2020 2020 2020 l_path].
    0000190: 2020 205b 2d77 2074 756e 6e65 6c3a 7475 [-w tunnel:tu
    00001a0: 6e6e 656c 5d20 5b75 7365 7240 5d68 6f73 nnel] [user@]hos
    00001b0: 746e 616d 6520 5b63 6f6d 6d61 6e64 5d0a tname [command].

    Bill Knox
    Lead Infosec Engineer/Scientist
    The MITRE Corporation


    -----Original Message-----
    From: openssh-unix-dev-bounces+wknox=mitre.org@mindrot.org
    [mailtopenssh-unix-dev-bounces+wknox=mitre.org@mindrot.org] On Behalf
    Of Stanislaw Kaminski
    Sent: Monday, July 14, 2008 10:27 AM
    To: openssh-unix-dev@mindrot.org
    Subject: EOL in stderr of ssh - Linux

    Hello everyone,
    recently I've found something I consider a bug.

    Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
    Imagine my surprise when I saw that all messages that are being output
    on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
    terminated with 0x0D, 0x0A.

    Maybe that's standard behaviour of all stderr messages in all Linux
    software, but I have to admin it's the first time I saw something like
    this.

    So, can anybody tell me if it's for a purpose, or is it just a plain
    bug?

    yours sincerely,
    Stanislaw Kaminski
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  4. Re: EOL in stderr of ssh - Linux

    Stanislaw Kaminski wrote:
    > Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
    > Imagine my surprise when I saw that all messages that are being output
    > on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
    > terminated with 0x0D, 0x0A.


    What are your tty settings? What is the output of this command?

    stty -a

    What is the output of this command?

    echo ABC | od -tx1

    Bob
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  5. Re: EOL in stderr of ssh - Linux

    Hm, so it seems that this bug does not concern all error outputs.

    I've stumbled upon it when connecting to host which had it's ssh key
    changed or when it's not known to the client:

    ssh -v afs-krw1 2>&1 | xxd
    0000000: 4f70 656e 5353 485f 342e 3770 3120 4465 OpenSSH_4.7p1 De
    0000010: 6269 616e 2d38 7562 756e 7475 312e 322c bian-8ubuntu1.2,
    0000020: 204f 7065 6e53 534c 2030 2e39 2e38 6720 OpenSSL 0.9.8g
    0000030: 3139 204f 6374 2032 3030 370a 6465 6275 19 Oct 2007.debu
    0000040: 6731 3a20 5265 6164 696e 6720 636f 6e66 g1: Reading conf
    0000050: 6967 7572 6174 696f 6e20 6461 7461 202f iguration data /
    0000060: 6574 632f 7373 682f 7373 685f 636f 6e66 etc/ssh/ssh_conf
    0000070: 6967 0d0a 6465 6275 6731 3a20 4170 706c ig..debug1: Appl
    0000080: 7969 6e67 206f 7074 696f 6e73 2066 6f72 ying options for
    0000090: 202a 0d0a 6465 6275 6731 3a20 436f 6e6e *..debug1: Conn
    00000a0: 6563 7469 6e67 2074 6f20 6166 732d 6b72 ecting to afs-kr
    00000b0: 7731 205b 3137 322e 3137 2e34 302e 3139 w1 [172.17.40.19
    00000c0: 355d 2070 6f72 7420 3232 2e0d 0a64 6562 5] port 22...deb
    00000d0: 7567 313a 2043 6f6e 6e65 6374 696f 6e20 ug1: Connection
    00000e0: 6573 7461 626c 6973 6865 642e 0d0a 6465 established...de
    00000f0: 6275 6731 3a20 6964 656e 7469 7479 2066 bug1: identity f
    0000100: 696c 6520 2f68 6f6d 652f 7374 6b61 2f2e ile /home/stka/.
    0000110: 7373 682f 6964 656e 7469 7479 2074 7970 ssh/identity typ
    0000120: 6520 2d31 0d0a 6465 6275 6731 3a20 6964 e -1..debug1: id
    0000130: 656e 7469 7479 2066 696c 6520 2f68 6f6d entity file /hom
    0000140: 652f 7374 6b61 2f2e 7373 682f 6964 5f72 e/stka/.ssh/id_r
    0000150: 7361 2074 7970 6520 2d31 0d0a 6465 6275 sa type -1..debu
    0000160: 6731 3a20 6964 656e 7469 7479 2066 696c g1: identity fil
    0000170: 6520 2f68 6f6d 652f 7374 6b61 2f2e 7373 e /home/stka/.ss
    0000180: 682f 6964 5f64 7361 2074 7970 6520 2d31 h/id_dsa type -1
    0000190: 0d0a 6465 6275 6731 3a20 5265 6d6f 7465 ..debug1: Remote
    00001a0: 2070 726f 746f 636f 6c20 7665 7273 696f protocol versio
    00001b0: 6e20 322e 302c 2072 656d 6f74 6520 736f n 2.0, remote so
    00001c0: 6674 7761 7265 2076 6572 7369 6f6e 204f ftware version O
    00001d0: 7065 6e53 5348 5f33 2e38 2e31 7031 2044 penSSH_3.8.1p1 D
    00001e0: 6562 6961 6e2d 382e 7361 7267 652e 340d ebian-8.sarge.4.
    00001f0: 0a64 6562 7567 313a 206d 6174 6368 3a20 .debug1: match:
    0000200: 4f70 656e 5353 485f 332e 382e 3170 3120 OpenSSH_3.8.1p1
    0000210: 4465 6269 616e 2d38 2e73 6172 6765 2e34 Debian-8.sarge.4
    0000220: 2070 6174 204f 7065 6e53 5348 5f33 2e2a pat OpenSSH_3.*
    0000230: 0d0a 6465 6275 6731 3a20 456e 6162 6c69 ..debug1: Enabli
    0000240: 6e67 2063 6f6d 7061 7469 6269 6c69 7479 ng compatibility
    0000250: 206d 6f64 6520 666f 7220 7072 6f74 6f63 mode for protoc
    0000260: 6f6c 2032 2e30 0d0a 6465 6275 6731 3a20 ol 2.0..debug1:
    0000270: 4c6f 6361 6c20 7665 7273 696f 6e20 7374 Local version st
    0000280: 7269 6e67 2053 5348 2d32 2e30 2d4f 7065 ring SSH-2.0-Ope
    0000290: 6e53 5348 5f34 2e37 7031 2044 6562 6961 nSSH_4.7p1 Debia
    00002a0: 6e2d 3875 6275 6e74 7531 2e32 0d0a 6465 n-8ubuntu1.2..de
    00002b0: 6275 6731 3a20 5353 4832 5f4d 5347 5f4b bug1: SSH2_MSG_K
    00002c0: 4558 494e 4954 2073 656e 740d 0a64 6562 EXINIT sent..deb
    00002d0: 7567 313a 2053 5348 325f 4d53 475f 4b45 ug1: SSH2_MSG_KE
    00002e0: 5849 4e49 5420 7265 6365 6976 6564 0d0a XINIT received..
    00002f0: 6465 6275 6731 3a20 6b65 783a 2073 6572 debug1: kex: ser
    0000300: 7665 722d 3e63 6c69 656e 7420 6165 7331 ver->client aes1
    0000310: 3238 2d63 6263 2068 6d61 632d 6d64 3520 28-cbc hmac-md5
    0000320: 6e6f 6e65 0d0a 6465 6275 6731 3a20 6b65 none..debug1: ke
    0000330: 783a 2063 6c69 656e 742d 3e73 6572 7665 x: client->serve
    0000340: 7220 6165 7331 3238 2d63 6263 2068 6d61 r aes128-cbc hma
    0000350: 632d 6d64 3520 6e6f 6e65 0d0a 6465 6275 c-md5 none..debu
    0000360: 6731 3a20 5353 4832 5f4d 5347 5f4b 4558 g1: SSH2_MSG_KEX
    0000370: 5f44 485f 4745 585f 5245 5155 4553 5428 _DH_GEX_REQUEST(
    0000380: 3130 3234 3c31 3032 343c 3831 3932 2920 1024<1024<8192)
    0000390: 7365 6e74 0d0a 6465 6275 6731 3a20 6578 sent..debug1: ex
    00003a0: 7065 6374 696e 6720 5353 4832 5f4d 5347 pecting SSH2_MSG
    00003b0: 5f4b 4558 5f44 485f 4745 585f 4752 4f55 _KEX_DH_GEX_GROU
    00003c0: 500d 0a64 6562 7567 313a 2053 5348 325f P..debug1: SSH2_
    00003d0: 4d53 475f 4b45 585f 4448 5f47 4558 5f49 MSG_KEX_DH_GEX_I
    00003e0: 4e49 5420 7365 6e74 0d0a 6465 6275 6731 NIT sent..debug1
    00003f0: 3a20 6578 7065 6374 696e 6720 5353 4832 : expecting SSH2
    0000400: 5f4d 5347 5f4b 4558 5f44 485f 4745 585f _MSG_KEX_DH_GEX_
    The authenticity of host 'afs-krw1 (172.17.40.195)' can't be established.
    RSA key fingerprint is 89:ab:bb:88:4c:2a:99:be:00:53:a1:a1:4c:22:82:ba.
    Are you sure you want to continue connecting (yes/no)? no
    0000410: 5245 504c 590d 0a48 6f73 7420 6b65 7920 REPLY..Host key
    0000420: 7665 7269 6669 6361 7469 6f6e 2066 6169 verification fai
    0000430: 6c65 642e 0d0a led...

    As you can see, EOLs are 0d0a.
    ssh -v 2>&1 | xxd
    0000000: 4f70 656e 5353 485f 342e 3770 3120 4465 OpenSSH_4.7p1 De
    0000010: 6269 616e 2d38 7562 756e 7475 312e 322c bian-8ubuntu1.2,
    0000020: 204f 7065 6e53 534c 2030 2e39 2e38 6720 OpenSSL 0.9.8g
    0000030: 3139 204f 6374 2032 3030 370a 7573 6167 19 Oct 2007.usag
    0000040: 653a 2073 7368 205b 2d31 3234 3641 6143 e: ssh [-1246AaC
    0000050: 6667 4b6b 4d4e 6e71 7354 7456 7658 7859 fgKkMNnqsTtVvXxY
    0000060: 5d20 5b2d 6220 6269 6e64 5f61 6464 7265 ] [-b bind_addre
    0000070: 7373 5d20 5b2d 6320 6369 7068 6572 5f73 ss] [-c cipher_s
    0000080: 7065 635d 0a20 2020 2020 2020 2020 2020 pec].
    0000090: 5b2d 4420 5b62 696e 645f 6164 6472 6573 [-D [bind_addres
    00000a0: 733a 5d70 6f72 745d 205b 2d65 2065 7363 s:]port] [-e esc
    00000b0: 6170 655f 6368 6172 5d20 5b2d 4620 636f ape_char] [-F co
    00000c0: 6e66 6967 6669 6c65 5d0a 2020 2020 2020 nfigfile].
    00000d0: 2020 2020 205b 2d69 2069 6465 6e74 6974 [-i identit
    00000e0: 795f 6669 6c65 5d20 5b2d 4c20 5b62 696e y_file] [-L [bin
    00000f0: 645f 6164 6472 6573 733a 5d70 6f72 743a d_address:]port:
    0000100: 686f 7374 3a68 6f73 7470 6f72 745d 0a20 host:hostport].
    0000110: 2020 2020 2020 2020 2020 5b2d 6c20 6c6f [-l lo
    0000120: 6769 6e5f 6e61 6d65 5d20 5b2d 6d20 6d61 gin_name] [-m ma
    0000130: 635f 7370 6563 5d20 5b2d 4f20 6374 6c5f c_spec] [-O ctl_
    0000140: 636d 645d 205b 2d6f 206f 7074 696f 6e5d cmd] [-o option]
    0000150: 205b 2d70 2070 6f72 745d 0a20 2020 2020 [-p port].
    0000160: 2020 2020 2020 5b2d 5220 5b62 696e 645f [-R [bind_
    0000170: 6164 6472 6573 733a 5d70 6f72 743a 686f address:]port:ho
    0000180: 7374 3a68 6f73 7470 6f72 745d 205b 2d53 st:hostport] [-S
    0000190: 2063 746c 5f70 6174 685d 0a20 2020 2020 ctl_path].
    00001a0: 2020 2020 2020 5b2d 7720 6c6f 6361 6c5f [-w local_
    00001b0: 7475 6e5b 3a72 656d 6f74 655f 7475 6e5d tun[:remote_tun]
    00001c0: 5d20 5b75 7365 7240 5d68 6f73 746e 616d ] [user@]hostnam
    00001d0: 6520 5b63 6f6d 6d61 6e64 5d0a e [command].

    everything seems correct, and delimiters are just plain Linux 0a.

    Try it yourself.

    regards,
    Stanislaw
    but, using your example:



    2008/7/14 Knox, Bill :
    > Not on my Fedora Core 7 or my CentOS 5.2 box - both of them terminate
    > with just 0x0A, as is shown below:
    >
    > ssh -v 2>&1 | xxd
    > 0000000: 4f70 656e 5353 485f 342e 3370 322c 204f OpenSSH_4.3p2, O
    > 0000010: 7065 6e53 534c 2030 2e39 2e38 6220 3034 penSSL 0.9.8b 04
    > 0000020: 204d 6179 2032 3030 360a 7573 6167 653a May 2006.usage:
    > 0000030: 2073 7368 205b 2d31 3234 3641 6143 6667 ssh [-1246AaCfg
    > 0000040: 6b4d 4e6e 7173 5474 5676 5878 595d 205b kMNnqsTtVvXxY] [
    > 0000050: 2d62 2062 696e 645f 6164 6472 6573 735d -b bind_address]
    > 0000060: 205b 2d63 2063 6970 6865 725f 7370 6563 [-c cipher_spec
    > 0000070: 5d0a 2020 2020 2020 2020 2020 205b 2d44 ]. [-D
    > 0000080: 205b 6269 6e64 5f61 6464 7265 7373 3a5d [bind_address:]
    > 0000090: 706f 7274 5d20 5b2d 6520 6573 6361 7065 port] [-e escape
    > 00000a0: 5f63 6861 725d 205b 2d46 2063 6f6e 6669 _char] [-F confi
    > 00000b0: 6766 696c 655d 0a20 2020 2020 2020 2020 gfile].
    > 00000c0: 2020 5b2d 6920 6964 656e 7469 7479 5f66 [-i identity_f
    > 00000d0: 696c 655d 205b 2d4c 205b 6269 6e64 5f61 ile] [-L [bind_a
    > 00000e0: 6464 7265 7373 3a5d 706f 7274 3a68 6f73 ddress:]port:hos
    > 00000f0: 743a 686f 7374 706f 7274 5d0a 2020 2020 t:hostport].
    > 0000100: 2020 2020 2020 205b 2d6c 206c 6f67 696e [-l login
    > 0000110: 5f6e 616d 655d 205b 2d6d 206d 6163 5f73 _name] [-m mac_s
    > 0000120: 7065 635d 205b 2d4f 2063 746c 5f63 6d64 pec] [-O ctl_cmd
    > 0000130: 5d20 5b2d 6f20 6f70 7469 6f6e 5d20 5b2d ] [-o option] [-
    > 0000140: 7020 706f 7274 5d0a 2020 2020 2020 2020 p port].
    > 0000150: 2020 205b 2d52 205b 6269 6e64 5f61 6464 [-R [bind_add
    > 0000160: 7265 7373 3a5d 706f 7274 3a68 6f73 743a ress:]port:host:
    > 0000170: 686f 7374 706f 7274 5d20 5b2d 5320 6374 hostport] [-S ct
    > 0000180: 6c5f 7061 7468 5d0a 2020 2020 2020 2020 l_path].
    > 0000190: 2020 205b 2d77 2074 756e 6e65 6c3a 7475 [-w tunnel:tu
    > 00001a0: 6e6e 656c 5d20 5b75 7365 7240 5d68 6f73 nnel] [user@]hos
    > 00001b0: 746e 616d 6520 5b63 6f6d 6d61 6e64 5d0a tname [command].
    >
    > Bill Knox
    > Lead Infosec Engineer/Scientist
    > The MITRE Corporation
    >
    >
    > -----Original Message-----
    > From: openssh-unix-dev-bounces+wknox=mitre.org@mindrot.org
    > [mailtopenssh-unix-dev-bounces+wknox=mitre.org@mindrot.org] On Behalf
    > Of Stanislaw Kaminski
    > Sent: Monday, July 14, 2008 10:27 AM
    > To: openssh-unix-dev@mindrot.org
    > Subject: EOL in stderr of ssh - Linux
    >
    > Hello everyone,
    > recently I've found something I consider a bug.
    >
    > Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
    > Imagine my surprise when I saw that all messages that are being output
    > on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
    > terminated with 0x0D, 0x0A.
    >
    > Maybe that's standard behaviour of all stderr messages in all Linux
    > software, but I have to admin it's the first time I saw something like
    > this.
    >
    > So, can anybody tell me if it's for a purpose, or is it just a plain
    > bug?
    >
    > yours sincerely,
    > Stanislaw Kaminski
    > _______________________________________________
    > openssh-unix-dev mailing list
    > openssh-unix-dev@mindrot.org
    > https://lists.mindrot.org/mailman/li...enssh-unix-dev
    >

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  6. Re: EOL in stderr of ssh - Linux

    On Mon, 14 Jul 2008, Stanislaw Kaminski wrote:

    > Hello everyone,
    > recently I've found something I consider a bug.
    >
    > Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A.
    > Imagine my surprise when I saw that all messages that are being output
    > on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are
    > terminated with 0x0D, 0x0A.
    >
    > Maybe that's standard behaviour of all stderr messages in all Linux
    > software, but I have to admin it's the first time I saw something like
    > this.
    >
    > So, can anybody tell me if it's for a purpose, or is it just a plain bug?


    stderr logging is terminated with \r\n in case (IIRC) the terminal is
    in raw mode to prevent stair-stepping of text - e.g.

    debug1: SSH2_MSG_KEXINIT sent
    debug1: rekeying in progress
    debug1: rekeying in progress

    .... and so forth. I'm not sure why it doesn't appear in the output earlier -
    perhaps cooked terminal mode eats the \r's

    The actual code is in log.c.

    -d

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread