Understanding sshd logs





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







4















I understand where to find the logs, but I am not always sure what they mean. And I can't exactly find a comprehensive guide on sshd logs explaining what they mean.



I am particularly concerned with this set of log attempts:



Feb 03 01:08:47 malan-server sshd[8110]: Invalid user centos from 193.106.58.90 port 34574
Feb 03 01:08:47 malan-server sshd[8110]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:08:48 malan-server sshd[8110]: Failed password for invalid user centos from 193.106.58.90 port 34574 ssh2
Feb 03 01:08:49 malan-server sshd[8110]: Connection closed by invalid user centos 193.106.58.90 port 34574 [preauth]
Feb 03 01:14:30 malan-server sshd[8114]: Invalid user centos from 193.106.58.90 port 39249
Feb 03 01:14:30 malan-server sshd[8114]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:14:32 malan-server sshd[8114]: Failed password for invalid user centos from 193.106.58.90 port 39249 ssh2
Feb 03 01:14:34 malan-server sshd[8114]: Connection closed by invalid user centos 193.106.58.90 port 39249 [preauth]
Feb 03 01:20:18 malan-server sshd[8118]: Invalid user centos from 193.106.58.90 port 43934
Feb 03 01:20:18 malan-server sshd[8118]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:20:20 malan-server sshd[8118]: Failed password for invalid user centos from 193.106.58.90 port 43934 ssh2
Feb 03 01:20:22 malan-server sshd[8118]: Connection closed by invalid user centos 193.106.58.90 port 43934 [preauth]
Feb 03 01:26:06 malan-server sshd[8121]: Invalid user centos from 193.106.58.90 port 48611
Feb 03 01:26:06 malan-server sshd[8121]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:26:08 malan-server sshd[8121]: Failed password for invalid user centos from 193.106.58.90 port 48611 ssh2
Feb 03 01:26:08 malan-server sshd[8121]: Connection closed by invalid user centos 193.106.58.90 port 48611 [preauth]


There are plenty that day from that same IP address, 193.106.58.90 in Kiev, Ukraine.



Another set of scary looking logs are these:



Feb 04 19:58:29 malan-server sshd[9725]: Bad protocol version identification 'RFB 003.003' from 142.44.253.51 port 36772
Feb 04 23:47:52 malan-server sshd[9762]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
Feb 05 06:40:36 malan-server sshd[9836]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 186.4.174.94 port 34515
Feb 05 07:59:13 malan-server sshd[9850]: Bad protocol version identification 'GET / HTTP/1.1' from 209.17.97.34 port 43944
Feb 05 09:09:48 malan-server sshd[9863]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 98.150.93.187 port 60182
Feb 05 14:09:45 malan-server sshd[9911]: Did not receive identification string from 191.232.54.97 port 63982
Feb 05 14:09:45 malan-server sshd[9912]: Bad protocol version identification '03' from 191.232.54.97 port 64044
Feb 05 14:09:45 malan-server sshd[9913]: Bad protocol version identification '03' from 191.232.54.97 port 64136
Feb 05 14:33:37 malan-server sshd[9919]: Bad protocol version identification '' from 198.108.67.48 port 56086


What do these mean?



I understand that the Internet is a big bad mean scary place where public-facing IP addresses constantly get bombarded with bot-attacks. But I have my router configured to forward connections on port 9000 to my server's port 22, so I am not entirely sure how there are still bot-attacks. It seemed unlikely to me that they would be port scanning all 65,535 possible ports.



I'll write a list of questions:




  1. Did I just choose a port that's too easy to guess? What would be a better port number?

  2. What do the port numbers in these sshd logs even mean? How can they have access to port 44493 if my router is only configured to forward port 9000 to port 22? It seems obvious to me that the port number listed is not the same thing as the outward-facing computer port, because I only access through port 9000, yet the port number listed for my own external logins is not 9000.

  3. What does [preauth] mean?

  4. What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?










share|improve this question

























  • One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.

    – malan
    Feb 11 at 16:36






  • 1





    By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.

    – Kusalananda
    Feb 11 at 16:43






  • 1





    and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.

    – Jeff Schaller
    Feb 11 at 16:44






  • 1





    note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.

    – Jeff Schaller
    Feb 11 at 17:07






  • 1





    @Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).

    – Stephen Kitt
    Feb 11 at 17:22




















4















I understand where to find the logs, but I am not always sure what they mean. And I can't exactly find a comprehensive guide on sshd logs explaining what they mean.



I am particularly concerned with this set of log attempts:



Feb 03 01:08:47 malan-server sshd[8110]: Invalid user centos from 193.106.58.90 port 34574
Feb 03 01:08:47 malan-server sshd[8110]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:08:48 malan-server sshd[8110]: Failed password for invalid user centos from 193.106.58.90 port 34574 ssh2
Feb 03 01:08:49 malan-server sshd[8110]: Connection closed by invalid user centos 193.106.58.90 port 34574 [preauth]
Feb 03 01:14:30 malan-server sshd[8114]: Invalid user centos from 193.106.58.90 port 39249
Feb 03 01:14:30 malan-server sshd[8114]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:14:32 malan-server sshd[8114]: Failed password for invalid user centos from 193.106.58.90 port 39249 ssh2
Feb 03 01:14:34 malan-server sshd[8114]: Connection closed by invalid user centos 193.106.58.90 port 39249 [preauth]
Feb 03 01:20:18 malan-server sshd[8118]: Invalid user centos from 193.106.58.90 port 43934
Feb 03 01:20:18 malan-server sshd[8118]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:20:20 malan-server sshd[8118]: Failed password for invalid user centos from 193.106.58.90 port 43934 ssh2
Feb 03 01:20:22 malan-server sshd[8118]: Connection closed by invalid user centos 193.106.58.90 port 43934 [preauth]
Feb 03 01:26:06 malan-server sshd[8121]: Invalid user centos from 193.106.58.90 port 48611
Feb 03 01:26:06 malan-server sshd[8121]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:26:08 malan-server sshd[8121]: Failed password for invalid user centos from 193.106.58.90 port 48611 ssh2
Feb 03 01:26:08 malan-server sshd[8121]: Connection closed by invalid user centos 193.106.58.90 port 48611 [preauth]


There are plenty that day from that same IP address, 193.106.58.90 in Kiev, Ukraine.



Another set of scary looking logs are these:



Feb 04 19:58:29 malan-server sshd[9725]: Bad protocol version identification 'RFB 003.003' from 142.44.253.51 port 36772
Feb 04 23:47:52 malan-server sshd[9762]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
Feb 05 06:40:36 malan-server sshd[9836]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 186.4.174.94 port 34515
Feb 05 07:59:13 malan-server sshd[9850]: Bad protocol version identification 'GET / HTTP/1.1' from 209.17.97.34 port 43944
Feb 05 09:09:48 malan-server sshd[9863]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 98.150.93.187 port 60182
Feb 05 14:09:45 malan-server sshd[9911]: Did not receive identification string from 191.232.54.97 port 63982
Feb 05 14:09:45 malan-server sshd[9912]: Bad protocol version identification '03' from 191.232.54.97 port 64044
Feb 05 14:09:45 malan-server sshd[9913]: Bad protocol version identification '03' from 191.232.54.97 port 64136
Feb 05 14:33:37 malan-server sshd[9919]: Bad protocol version identification '' from 198.108.67.48 port 56086


What do these mean?



I understand that the Internet is a big bad mean scary place where public-facing IP addresses constantly get bombarded with bot-attacks. But I have my router configured to forward connections on port 9000 to my server's port 22, so I am not entirely sure how there are still bot-attacks. It seemed unlikely to me that they would be port scanning all 65,535 possible ports.



I'll write a list of questions:




  1. Did I just choose a port that's too easy to guess? What would be a better port number?

  2. What do the port numbers in these sshd logs even mean? How can they have access to port 44493 if my router is only configured to forward port 9000 to port 22? It seems obvious to me that the port number listed is not the same thing as the outward-facing computer port, because I only access through port 9000, yet the port number listed for my own external logins is not 9000.

  3. What does [preauth] mean?

  4. What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?










share|improve this question

























  • One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.

    – malan
    Feb 11 at 16:36






  • 1





    By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.

    – Kusalananda
    Feb 11 at 16:43






  • 1





    and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.

    – Jeff Schaller
    Feb 11 at 16:44






  • 1





    note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.

    – Jeff Schaller
    Feb 11 at 17:07






  • 1





    @Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).

    – Stephen Kitt
    Feb 11 at 17:22
















4












4








4








I understand where to find the logs, but I am not always sure what they mean. And I can't exactly find a comprehensive guide on sshd logs explaining what they mean.



I am particularly concerned with this set of log attempts:



Feb 03 01:08:47 malan-server sshd[8110]: Invalid user centos from 193.106.58.90 port 34574
Feb 03 01:08:47 malan-server sshd[8110]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:08:48 malan-server sshd[8110]: Failed password for invalid user centos from 193.106.58.90 port 34574 ssh2
Feb 03 01:08:49 malan-server sshd[8110]: Connection closed by invalid user centos 193.106.58.90 port 34574 [preauth]
Feb 03 01:14:30 malan-server sshd[8114]: Invalid user centos from 193.106.58.90 port 39249
Feb 03 01:14:30 malan-server sshd[8114]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:14:32 malan-server sshd[8114]: Failed password for invalid user centos from 193.106.58.90 port 39249 ssh2
Feb 03 01:14:34 malan-server sshd[8114]: Connection closed by invalid user centos 193.106.58.90 port 39249 [preauth]
Feb 03 01:20:18 malan-server sshd[8118]: Invalid user centos from 193.106.58.90 port 43934
Feb 03 01:20:18 malan-server sshd[8118]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:20:20 malan-server sshd[8118]: Failed password for invalid user centos from 193.106.58.90 port 43934 ssh2
Feb 03 01:20:22 malan-server sshd[8118]: Connection closed by invalid user centos 193.106.58.90 port 43934 [preauth]
Feb 03 01:26:06 malan-server sshd[8121]: Invalid user centos from 193.106.58.90 port 48611
Feb 03 01:26:06 malan-server sshd[8121]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:26:08 malan-server sshd[8121]: Failed password for invalid user centos from 193.106.58.90 port 48611 ssh2
Feb 03 01:26:08 malan-server sshd[8121]: Connection closed by invalid user centos 193.106.58.90 port 48611 [preauth]


There are plenty that day from that same IP address, 193.106.58.90 in Kiev, Ukraine.



Another set of scary looking logs are these:



Feb 04 19:58:29 malan-server sshd[9725]: Bad protocol version identification 'RFB 003.003' from 142.44.253.51 port 36772
Feb 04 23:47:52 malan-server sshd[9762]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
Feb 05 06:40:36 malan-server sshd[9836]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 186.4.174.94 port 34515
Feb 05 07:59:13 malan-server sshd[9850]: Bad protocol version identification 'GET / HTTP/1.1' from 209.17.97.34 port 43944
Feb 05 09:09:48 malan-server sshd[9863]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 98.150.93.187 port 60182
Feb 05 14:09:45 malan-server sshd[9911]: Did not receive identification string from 191.232.54.97 port 63982
Feb 05 14:09:45 malan-server sshd[9912]: Bad protocol version identification '03' from 191.232.54.97 port 64044
Feb 05 14:09:45 malan-server sshd[9913]: Bad protocol version identification '03' from 191.232.54.97 port 64136
Feb 05 14:33:37 malan-server sshd[9919]: Bad protocol version identification '' from 198.108.67.48 port 56086


What do these mean?



I understand that the Internet is a big bad mean scary place where public-facing IP addresses constantly get bombarded with bot-attacks. But I have my router configured to forward connections on port 9000 to my server's port 22, so I am not entirely sure how there are still bot-attacks. It seemed unlikely to me that they would be port scanning all 65,535 possible ports.



I'll write a list of questions:




  1. Did I just choose a port that's too easy to guess? What would be a better port number?

  2. What do the port numbers in these sshd logs even mean? How can they have access to port 44493 if my router is only configured to forward port 9000 to port 22? It seems obvious to me that the port number listed is not the same thing as the outward-facing computer port, because I only access through port 9000, yet the port number listed for my own external logins is not 9000.

  3. What does [preauth] mean?

  4. What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?










share|improve this question
















I understand where to find the logs, but I am not always sure what they mean. And I can't exactly find a comprehensive guide on sshd logs explaining what they mean.



I am particularly concerned with this set of log attempts:



Feb 03 01:08:47 malan-server sshd[8110]: Invalid user centos from 193.106.58.90 port 34574
Feb 03 01:08:47 malan-server sshd[8110]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:08:48 malan-server sshd[8110]: Failed password for invalid user centos from 193.106.58.90 port 34574 ssh2
Feb 03 01:08:49 malan-server sshd[8110]: Connection closed by invalid user centos 193.106.58.90 port 34574 [preauth]
Feb 03 01:14:30 malan-server sshd[8114]: Invalid user centos from 193.106.58.90 port 39249
Feb 03 01:14:30 malan-server sshd[8114]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:14:32 malan-server sshd[8114]: Failed password for invalid user centos from 193.106.58.90 port 39249 ssh2
Feb 03 01:14:34 malan-server sshd[8114]: Connection closed by invalid user centos 193.106.58.90 port 39249 [preauth]
Feb 03 01:20:18 malan-server sshd[8118]: Invalid user centos from 193.106.58.90 port 43934
Feb 03 01:20:18 malan-server sshd[8118]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:20:20 malan-server sshd[8118]: Failed password for invalid user centos from 193.106.58.90 port 43934 ssh2
Feb 03 01:20:22 malan-server sshd[8118]: Connection closed by invalid user centos 193.106.58.90 port 43934 [preauth]
Feb 03 01:26:06 malan-server sshd[8121]: Invalid user centos from 193.106.58.90 port 48611
Feb 03 01:26:06 malan-server sshd[8121]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:26:08 malan-server sshd[8121]: Failed password for invalid user centos from 193.106.58.90 port 48611 ssh2
Feb 03 01:26:08 malan-server sshd[8121]: Connection closed by invalid user centos 193.106.58.90 port 48611 [preauth]


There are plenty that day from that same IP address, 193.106.58.90 in Kiev, Ukraine.



Another set of scary looking logs are these:



Feb 04 19:58:29 malan-server sshd[9725]: Bad protocol version identification 'RFB 003.003' from 142.44.253.51 port 36772
Feb 04 23:47:52 malan-server sshd[9762]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
Feb 05 06:40:36 malan-server sshd[9836]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 186.4.174.94 port 34515
Feb 05 07:59:13 malan-server sshd[9850]: Bad protocol version identification 'GET / HTTP/1.1' from 209.17.97.34 port 43944
Feb 05 09:09:48 malan-server sshd[9863]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 98.150.93.187 port 60182
Feb 05 14:09:45 malan-server sshd[9911]: Did not receive identification string from 191.232.54.97 port 63982
Feb 05 14:09:45 malan-server sshd[9912]: Bad protocol version identification '03' from 191.232.54.97 port 64044
Feb 05 14:09:45 malan-server sshd[9913]: Bad protocol version identification '03' from 191.232.54.97 port 64136
Feb 05 14:33:37 malan-server sshd[9919]: Bad protocol version identification '' from 198.108.67.48 port 56086


What do these mean?



I understand that the Internet is a big bad mean scary place where public-facing IP addresses constantly get bombarded with bot-attacks. But I have my router configured to forward connections on port 9000 to my server's port 22, so I am not entirely sure how there are still bot-attacks. It seemed unlikely to me that they would be port scanning all 65,535 possible ports.



I'll write a list of questions:




  1. Did I just choose a port that's too easy to guess? What would be a better port number?

  2. What do the port numbers in these sshd logs even mean? How can they have access to port 44493 if my router is only configured to forward port 9000 to port 22? It seems obvious to me that the port number listed is not the same thing as the outward-facing computer port, because I only access through port 9000, yet the port number listed for my own external logins is not 9000.

  3. What does [preauth] mean?

  4. What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?







ssh logs






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 11 at 16:32







malan

















asked Feb 11 at 16:25









malanmalan

667622




667622













  • One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.

    – malan
    Feb 11 at 16:36






  • 1





    By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.

    – Kusalananda
    Feb 11 at 16:43






  • 1





    and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.

    – Jeff Schaller
    Feb 11 at 16:44






  • 1





    note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.

    – Jeff Schaller
    Feb 11 at 17:07






  • 1





    @Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).

    – Stephen Kitt
    Feb 11 at 17:22





















  • One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.

    – malan
    Feb 11 at 16:36






  • 1





    By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.

    – Kusalananda
    Feb 11 at 16:43






  • 1





    and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.

    – Jeff Schaller
    Feb 11 at 16:44






  • 1





    note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.

    – Jeff Schaller
    Feb 11 at 17:07






  • 1





    @Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).

    – Stephen Kitt
    Feb 11 at 17:22



















One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.

– malan
Feb 11 at 16:36





One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.

– malan
Feb 11 at 16:36




1




1





By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.

– Kusalananda
Feb 11 at 16:43





By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.

– Kusalananda
Feb 11 at 16:43




1




1





and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.

– Jeff Schaller
Feb 11 at 16:44





and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.

– Jeff Schaller
Feb 11 at 16:44




1




1





note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.

– Jeff Schaller
Feb 11 at 17:07





note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.

– Jeff Schaller
Feb 11 at 17:07




1




1





@Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).

– Stephen Kitt
Feb 11 at 17:22







@Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).

– Stephen Kitt
Feb 11 at 17:22












3 Answers
3






active

oldest

votes


















7















  1. There is no good port to use, only good SSH configurations. If you disable password-based logins and only allow key-based authentication, you won’t risk much from such brute-forcing attempts. You could add port-knocking, but that’s security by obscurity.


  2. The port numbers listed on the right of the logs are the source ports; these are dynamically allocated and are on the source system, not the target system.


  3. [preauth] means that the logged event happened before the connection was authenticated — i.e. in this case that the connection is closed before being authenticated.


  4. All the logs from your second set of logs correspond to non-SSH traffic sent to your dæmon. You’ll see this happen quite a lot, especially since you’re listening on a non-standard port — various scanners will send requests without knowing what is listening on the other end.



Scanning large portions of the Internet, on a variety of ports, doesn’t take very long if you have well-connected systems to scan from, or a large number of compromised hosts in a botnet. See massscan for an example of a mass-scanning tool. There are also lists of known-open IP addresses and ports which are circulated; so all it takes is for one scan to find your open port 9000.






share|improve this answer
























  • I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).

    – malan
    Feb 11 at 17:17











  • As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.

    – Gerald Combs
    Feb 11 at 21:36











  • @Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something like fwknop can be useful. I tend to favour other approaches which don’t involve too much setup on the client...

    – Stephen Kitt
    Feb 11 at 21:50



















5














Short of a comprehensive guide to sshd logs, but addressing your points:




Did I just choose a port that's too easy to guess? What would be a better port number?




There's "only" 65,535 ports, and scanners are good at finding them, so once you've moved beyond port 22 to avoid the simplest scans, there's not a whole lot of benefit to picking one arbitrary port over another.




What do the port numbers in these sshd logs even mean? How can they have access to port (43944) if my router is only configured to forward port 9000 to port 22? I




The port numbers after the IP's, such as 209.17.97.34 port 43944 indicate the source-side's port that was likely arbitrarily chosen by the kernel on that side. It means next to nothing to you.




What does [preauth] mean?




It's short for "pre (before) authentication"; ssh performs in stages, and this is one. There are other, similar questions here at U&L.




What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?




A quick Google search turned up this
strange query in server logs REMOTE HI_SRDK_DEV_GetHddInfo
in Stack Overflow -- reinforcing the idea that this is a scanner looking for "opportunities".






share|improve this answer































    2














    Well your bad protocol stuff is scanning for Kguard Digital Video Recorders vulnerable to CVE-2015-4464. They just happen to default to port 9000..



    https://dl.packetstormsecurity.net/1506-exploits/kdvr-authorization.txt






    share|improve this answer
























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "106"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499982%2funderstanding-sshd-logs%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      7















      1. There is no good port to use, only good SSH configurations. If you disable password-based logins and only allow key-based authentication, you won’t risk much from such brute-forcing attempts. You could add port-knocking, but that’s security by obscurity.


      2. The port numbers listed on the right of the logs are the source ports; these are dynamically allocated and are on the source system, not the target system.


      3. [preauth] means that the logged event happened before the connection was authenticated — i.e. in this case that the connection is closed before being authenticated.


      4. All the logs from your second set of logs correspond to non-SSH traffic sent to your dæmon. You’ll see this happen quite a lot, especially since you’re listening on a non-standard port — various scanners will send requests without knowing what is listening on the other end.



      Scanning large portions of the Internet, on a variety of ports, doesn’t take very long if you have well-connected systems to scan from, or a large number of compromised hosts in a botnet. See massscan for an example of a mass-scanning tool. There are also lists of known-open IP addresses and ports which are circulated; so all it takes is for one scan to find your open port 9000.






      share|improve this answer
























      • I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).

        – malan
        Feb 11 at 17:17











      • As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.

        – Gerald Combs
        Feb 11 at 21:36











      • @Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something like fwknop can be useful. I tend to favour other approaches which don’t involve too much setup on the client...

        – Stephen Kitt
        Feb 11 at 21:50
















      7















      1. There is no good port to use, only good SSH configurations. If you disable password-based logins and only allow key-based authentication, you won’t risk much from such brute-forcing attempts. You could add port-knocking, but that’s security by obscurity.


      2. The port numbers listed on the right of the logs are the source ports; these are dynamically allocated and are on the source system, not the target system.


      3. [preauth] means that the logged event happened before the connection was authenticated — i.e. in this case that the connection is closed before being authenticated.


      4. All the logs from your second set of logs correspond to non-SSH traffic sent to your dæmon. You’ll see this happen quite a lot, especially since you’re listening on a non-standard port — various scanners will send requests without knowing what is listening on the other end.



      Scanning large portions of the Internet, on a variety of ports, doesn’t take very long if you have well-connected systems to scan from, or a large number of compromised hosts in a botnet. See massscan for an example of a mass-scanning tool. There are also lists of known-open IP addresses and ports which are circulated; so all it takes is for one scan to find your open port 9000.






      share|improve this answer
























      • I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).

        – malan
        Feb 11 at 17:17











      • As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.

        – Gerald Combs
        Feb 11 at 21:36











      • @Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something like fwknop can be useful. I tend to favour other approaches which don’t involve too much setup on the client...

        – Stephen Kitt
        Feb 11 at 21:50














      7












      7








      7








      1. There is no good port to use, only good SSH configurations. If you disable password-based logins and only allow key-based authentication, you won’t risk much from such brute-forcing attempts. You could add port-knocking, but that’s security by obscurity.


      2. The port numbers listed on the right of the logs are the source ports; these are dynamically allocated and are on the source system, not the target system.


      3. [preauth] means that the logged event happened before the connection was authenticated — i.e. in this case that the connection is closed before being authenticated.


      4. All the logs from your second set of logs correspond to non-SSH traffic sent to your dæmon. You’ll see this happen quite a lot, especially since you’re listening on a non-standard port — various scanners will send requests without knowing what is listening on the other end.



      Scanning large portions of the Internet, on a variety of ports, doesn’t take very long if you have well-connected systems to scan from, or a large number of compromised hosts in a botnet. See massscan for an example of a mass-scanning tool. There are also lists of known-open IP addresses and ports which are circulated; so all it takes is for one scan to find your open port 9000.






      share|improve this answer














      1. There is no good port to use, only good SSH configurations. If you disable password-based logins and only allow key-based authentication, you won’t risk much from such brute-forcing attempts. You could add port-knocking, but that’s security by obscurity.


      2. The port numbers listed on the right of the logs are the source ports; these are dynamically allocated and are on the source system, not the target system.


      3. [preauth] means that the logged event happened before the connection was authenticated — i.e. in this case that the connection is closed before being authenticated.


      4. All the logs from your second set of logs correspond to non-SSH traffic sent to your dæmon. You’ll see this happen quite a lot, especially since you’re listening on a non-standard port — various scanners will send requests without knowing what is listening on the other end.



      Scanning large portions of the Internet, on a variety of ports, doesn’t take very long if you have well-connected systems to scan from, or a large number of compromised hosts in a botnet. See massscan for an example of a mass-scanning tool. There are also lists of known-open IP addresses and ports which are circulated; so all it takes is for one scan to find your open port 9000.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Feb 11 at 17:00









      Stephen KittStephen Kitt

      181k25414493




      181k25414493













      • I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).

        – malan
        Feb 11 at 17:17











      • As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.

        – Gerald Combs
        Feb 11 at 21:36











      • @Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something like fwknop can be useful. I tend to favour other approaches which don’t involve too much setup on the client...

        – Stephen Kitt
        Feb 11 at 21:50



















      • I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).

        – malan
        Feb 11 at 17:17











      • As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.

        – Gerald Combs
        Feb 11 at 21:36











      • @Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something like fwknop can be useful. I tend to favour other approaches which don’t involve too much setup on the client...

        – Stephen Kitt
        Feb 11 at 21:50

















      I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).

      – malan
      Feb 11 at 17:17





      I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).

      – malan
      Feb 11 at 17:17













      As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.

      – Gerald Combs
      Feb 11 at 21:36





      As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.

      – Gerald Combs
      Feb 11 at 21:36













      @Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something like fwknop can be useful. I tend to favour other approaches which don’t involve too much setup on the client...

      – Stephen Kitt
      Feb 11 at 21:50





      @Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something like fwknop can be useful. I tend to favour other approaches which don’t involve too much setup on the client...

      – Stephen Kitt
      Feb 11 at 21:50













      5














      Short of a comprehensive guide to sshd logs, but addressing your points:




      Did I just choose a port that's too easy to guess? What would be a better port number?




      There's "only" 65,535 ports, and scanners are good at finding them, so once you've moved beyond port 22 to avoid the simplest scans, there's not a whole lot of benefit to picking one arbitrary port over another.




      What do the port numbers in these sshd logs even mean? How can they have access to port (43944) if my router is only configured to forward port 9000 to port 22? I




      The port numbers after the IP's, such as 209.17.97.34 port 43944 indicate the source-side's port that was likely arbitrarily chosen by the kernel on that side. It means next to nothing to you.




      What does [preauth] mean?




      It's short for "pre (before) authentication"; ssh performs in stages, and this is one. There are other, similar questions here at U&L.




      What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?




      A quick Google search turned up this
      strange query in server logs REMOTE HI_SRDK_DEV_GetHddInfo
      in Stack Overflow -- reinforcing the idea that this is a scanner looking for "opportunities".






      share|improve this answer




























        5














        Short of a comprehensive guide to sshd logs, but addressing your points:




        Did I just choose a port that's too easy to guess? What would be a better port number?




        There's "only" 65,535 ports, and scanners are good at finding them, so once you've moved beyond port 22 to avoid the simplest scans, there's not a whole lot of benefit to picking one arbitrary port over another.




        What do the port numbers in these sshd logs even mean? How can they have access to port (43944) if my router is only configured to forward port 9000 to port 22? I




        The port numbers after the IP's, such as 209.17.97.34 port 43944 indicate the source-side's port that was likely arbitrarily chosen by the kernel on that side. It means next to nothing to you.




        What does [preauth] mean?




        It's short for "pre (before) authentication"; ssh performs in stages, and this is one. There are other, similar questions here at U&L.




        What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?




        A quick Google search turned up this
        strange query in server logs REMOTE HI_SRDK_DEV_GetHddInfo
        in Stack Overflow -- reinforcing the idea that this is a scanner looking for "opportunities".






        share|improve this answer


























          5












          5








          5







          Short of a comprehensive guide to sshd logs, but addressing your points:




          Did I just choose a port that's too easy to guess? What would be a better port number?




          There's "only" 65,535 ports, and scanners are good at finding them, so once you've moved beyond port 22 to avoid the simplest scans, there's not a whole lot of benefit to picking one arbitrary port over another.




          What do the port numbers in these sshd logs even mean? How can they have access to port (43944) if my router is only configured to forward port 9000 to port 22? I




          The port numbers after the IP's, such as 209.17.97.34 port 43944 indicate the source-side's port that was likely arbitrarily chosen by the kernel on that side. It means next to nothing to you.




          What does [preauth] mean?




          It's short for "pre (before) authentication"; ssh performs in stages, and this is one. There are other, similar questions here at U&L.




          What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?




          A quick Google search turned up this
          strange query in server logs REMOTE HI_SRDK_DEV_GetHddInfo
          in Stack Overflow -- reinforcing the idea that this is a scanner looking for "opportunities".






          share|improve this answer













          Short of a comprehensive guide to sshd logs, but addressing your points:




          Did I just choose a port that's too easy to guess? What would be a better port number?




          There's "only" 65,535 ports, and scanners are good at finding them, so once you've moved beyond port 22 to avoid the simplest scans, there's not a whole lot of benefit to picking one arbitrary port over another.




          What do the port numbers in these sshd logs even mean? How can they have access to port (43944) if my router is only configured to forward port 9000 to port 22? I




          The port numbers after the IP's, such as 209.17.97.34 port 43944 indicate the source-side's port that was likely arbitrarily chosen by the kernel on that side. It means next to nothing to you.




          What does [preauth] mean?




          It's short for "pre (before) authentication"; ssh performs in stages, and this is one. There are other, similar questions here at U&L.




          What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?




          A quick Google search turned up this
          strange query in server logs REMOTE HI_SRDK_DEV_GetHddInfo
          in Stack Overflow -- reinforcing the idea that this is a scanner looking for "opportunities".







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Feb 11 at 17:06









          Jeff SchallerJeff Schaller

          45k1164147




          45k1164147























              2














              Well your bad protocol stuff is scanning for Kguard Digital Video Recorders vulnerable to CVE-2015-4464. They just happen to default to port 9000..



              https://dl.packetstormsecurity.net/1506-exploits/kdvr-authorization.txt






              share|improve this answer




























                2














                Well your bad protocol stuff is scanning for Kguard Digital Video Recorders vulnerable to CVE-2015-4464. They just happen to default to port 9000..



                https://dl.packetstormsecurity.net/1506-exploits/kdvr-authorization.txt






                share|improve this answer


























                  2












                  2








                  2







                  Well your bad protocol stuff is scanning for Kguard Digital Video Recorders vulnerable to CVE-2015-4464. They just happen to default to port 9000..



                  https://dl.packetstormsecurity.net/1506-exploits/kdvr-authorization.txt






                  share|improve this answer













                  Well your bad protocol stuff is scanning for Kguard Digital Video Recorders vulnerable to CVE-2015-4464. They just happen to default to port 9000..



                  https://dl.packetstormsecurity.net/1506-exploits/kdvr-authorization.txt







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Feb 11 at 23:09









                  RichUKRichUK

                  211




                  211






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Unix & Linux Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499982%2funderstanding-sshd-logs%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Human spaceflight

                      Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

                      File:DeusFollowingSea.jpg