Discovery of Linux servers with MACs and ciphers enabled for SSH connections

chodavarapu · ‎11-21-2017

Linux Engineering Team want to enable MACs and ciphers for all SSH connections to all Linux servers. We tried discovering one of the test servers with MACs and ciphers enabled. The discovery failed on SSH authentication. Please suggest on how we overcome this issue.

bhanupratap2203 · ‎12-11-2017

Hi Timothy,

Your responses seem to be very helpful to me. I am having same issue that Windows MID server to Linux target machine is not establishing connection. On asking logs , Infra team sent below bunches of lines.

debug3: fd 4 is not O_NONBLOCK

debug1: Server will not fork when running in debugging mode.

debug3: send_rexec_state: entering fd = 7 config len 1100

debug3: ssh_msg_send: type 0

debug3: send_rexec_state: done

debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7

debug1: inetd sockets after dupping: 3, 3

Connection from 172.21.65.2 port 18384

debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60

debug1: no match: PuTTY_Release_0.60

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_5.3

debug2: fd 3 setting O_NONBLOCK

debug2: Network child is on pid 48143

debug3: preauth child monitor started

debug3: mm_request_receive entering

debug3: privsep user:group 74:74

debug1: permanently_set_uid: 74/74

debug1: list_hostkey_types: ssh-rsa,ssh-dss

debug1: SSH2_MSG_KEXINIT sent

debug3: Wrote 360 bytes for a total of 381

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-ctr,aes256-ctr,aes192-ctr

debug2: kex_parse_kexinit: hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128

debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: mac_setup: found hmac-sha1

debug1: kex: client->server aes256-ctr hmac-sha1 none

debug3: mm_request_send entering: type 78

debug3: mm_request_receive_expect entering: type 79

debug3: mm_request_receive entering

debug3: monitor_read: checking request 78

debug3: mm_request_send entering: type 79

debug3: mm_request_receive entering

debug2: mac_setup: found hmac-sha1

debug1: kex: server->client aes256-ctr hmac-sha1 none

debug3: mm_request_send entering: type 78

debug3: mm_request_receive_expect entering: type 79

debug3: mm_request_receive entering

debug3: monitor_read: checking request 78

debug3: mm_request_send entering: type 79

debug3: mm_request_receive entering

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received

debug3: mm_request_send entering: type 0

debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI

debug3: mm_request_receive_expect entering: type 1

debug3: mm_request_receive entering

debug3: monitor_read: checking request 0

debug3: mm_answer_moduli: got parameters: 1024 4096 8192

debug3: mm_request_send entering: type 1

debug2: monitor_read: 0 used once, disabling now

debug3: mm_request_receive entering

debug3: mm_choose_dh: remaining 0

debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent

debug3: Wrote 536 bytes for a total of 917

debug2: dh_gen_key: priv key bits set: 271/512

debug2: bits set: 2043/4096

debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT

debug2: bits set: 2081/4096

debug3: mm_key_sign entering

debug3: mm_request_send entering: type 5

debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN

debug3: mm_request_receive_expect entering: type 6

debug3: mm_request_receive entering

debug3: monitor_read: checking request 5

debug3: mm_answer_sign

debug3: mm_answer_sign: signature 0x7f3ef40b2ea0(271)

debug3: mm_request_send entering: type 6

debug2: monitor_read: 5 used once, disabling now

debug3: mm_request_receive entering

debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent

debug2: kex_derive_keys

debug2: set_newkeys: mode 1

debug2: cipher_init: set keylen (16 -> 32)

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug3: Wrote 1104 bytes for a total of 2021

debug2: set_newkeys: mode 0

debug2: cipher_init: set keylen (16 -> 32)

debug1: SSH2_MSG_NEWKEYS received

debug1: KEX done

debug3: Wrote 52 bytes for a total of 2073

debug1: userauth-request for user kjj service ssh-connection method none

debug1: attempt 0 failures 0

debug3: mm_getpwnamallow entering

debug3: mm_request_send entering: type 7

debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM

debug3: mm_request_receive_expect entering: type 8

debug3: mm_request_receive entering

debug3: monitor_read: checking request 7

debug3: mm_answer_pwnamallow

debug2: parse_server_config: config reprocess config len 1100

debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1

debug3: mm_request_send entering: type 8

debug2: monitor_read: 7 used once, disabling now

debug3: mm_request_receive entering

debug2: input_userauth_request: setting up authctxt for kjj

debug3: mm_start_pam entering

debug3: mm_request_send entering: type 50

debug3: mm_inform_authserv entering

debug3: monitor_read: checking request 50

debug3: mm_request_send entering: type 3

debug1: PAM: initializing for "kjj"

debug3: mm_inform_authrole entering

debug3: mm_request_send entering: type 4

debug3: mm_auth2_read_banner entering

debug3: mm_request_send entering: type 9

debug3: mm_request_receive_expect entering: type 10

debug3: mm_request_receive entering

debug1: PAM: setting PAM_RHOST to "172.21.65.2"

debug1: PAM: setting PAM_TTY to "ssh"

debug2: monitor_read: 50 used once, disabling now

debug3: mm_request_receive entering

debug3: monitor_read: checking request 3

debug3: mm_answer_authserv: service=ssh-connection, style=

debug2: monitor_read: 3 used once, disabling now

debug3: mm_request_receive entering

debug3: monitor_read: checking request 4

debug3: mm_answer_authrole: role=

debug2: monitor_read: 4 used once, disabling now

debug3: mm_request_receive entering

debug3: monitor_read: checking request 9

debug3: mm_request_send entering: type 10

debug2: monitor_read: 9 used once, disabling now

debug3: mm_request_receive entering

debug1: userauth_send_banner: sent

debug2: input_userauth_request: try method none

debug3: Wrote 584 bytes for a total of 2657

bhanupratap2203 · ‎12-11-2017

Please suggests what needs to be done to fix this. We are using Jakarta version. And where can I see the supported Ciphers in Servicenow Discovery.

Dave Smith1 · ‎12-11-2017

Bhanupratap Rathor wrote:

Hi Timothy,

Your responses seem to be very helpful to me. I am having same issue that Windows MID server to Linux target machine is not establishing connection.

Can you try logging into that Linux node from the Windows MID using PuTTY and the keys provided?

In most cases I've found, diagnosing SSH connections without an SSH client can be tricky.

bhanupratap2203 · ‎12-11-2017

Client have not shared credentials with me for target linux machine. Will check with client tomorrow. Meanwhile please share some steps to check once i am woth client.

tim_broberg · ‎12-11-2017

No credentials - ok, that fits - "input_userauth_request: try method none"

What I'm seeing is, you're getting past KEXINIT, and you're trying userauth, but no credentials are authenticating.

It looks to me like you're to the point of debugging the credentials themselves, which should just work.

All the algorithm negotiations are clearing just fine.