Analysis of SSH keys found in the wild

2 minute read

In 2018 I was contracted to help a large organization with a very distributed and remote structure. One of the things that I found was that the organization does not have a strict policy regarding the creation, storage and lifecycle of SSH keys.

I decided to look into this issue in general, so in Feb 2019 wrote a crawler that looked for SSH keys around the web - public repos, s3 bucket with bad permissions, data dumps from companies and so on.

From this I got 4807 keys. Next I wrote a small python script that tried the SSH keys - just autenticate and close the connection, without opening any channels as to not actually access the target systems which would be illegal.

I managed to authenticate into 221 hosts, 5 were FreeBSD, 1 was MacOS, 3 were Linux on ARM64, and the rest were Linux x64. This means I have 221 working keys found on the web and no way to notify their owners they should change their keys.

General interesting statistics:

  • Of the 4807 keys 966 were malformed and 1036 were encrypted (20%). Of the 1036 encrypted I could break 88 passwords using dictionaries and an additional 41 passwords using John-the-ripper on a 3-year old 8-core Xeon workstation after a month of brute-forcing.

  • Sizes (all were SHA256): 
    root@DESKTOP-MR4OQPJ:~/keys# for i in id_rsa* ; do ssh-keygen -l -f $i; done | sed 's/:.*//' | sort | uniq -c | sort -n -k 2
    2 1023 SHA256
   37 1024 SHA256
    1 2047 SHA256
 2187 2048 SHA256
    1 3000 SHA256
    1 4048 SHA256
  572 4096 SHA256
    3 8192 SHA256
    1 16384 SHA256

    I don’‘t get the wird sizes: 1023-bit, 2047-bit, 3000-bit, and 4048-bit. Anyone have an idea?

  • Encryption type: 
    root@DESKTOP-MR4OQPJ:~/enc# grep -h DEK-Info id_rsa* | sed 's/,.*//' | sort | uniq -c
  665 DEK-Info: AES-128-CBC
    2 DEK-Info: AES-256-CBC
   94 DEK-Info: DES-EDE3-CBC

    Why still use DES keys?

    for keys that I could not break:

      531 DEK-Info: AES-128-CBC
    2 DEK-Info: AES-256-CBC
   66 DEK-Info: DES-EDE3-CBC
  • Distributions (in 2019, from uname)
  • 87 were Ubuntu
  • 38 were RHEL/Centos 6
  • 25 were RHEL/Centos 7
  • 7 were Amazon
  • 5 were RHEL/Centos 5
  • 2 were Debian
  • 2 were CoreOS
  • 1 was Gentoo
  • 1 was Fedore32
  • 2 were armv7l
  • 1 was armv5tel

  • the rest I could not identify from uname -a

  • Most common kernels (in 2019, from uname)
  • 44 were Linux 2.6.x
  • 39 were Linux 4.4.x
  • 28 were Linux 4.15.x
  • 35 were Linux 3.10.x
  • 15 were Linux 3.13.x
  • 13 were Linux 4.9.x

Last week (after two years!) I reran the test against the 221 working keys and 179 still work. To make sure these are not honepots I added to the testing script a checked for the length of the remote .bash_history file, and none seem to be honeypots.

Updated: