147 entries in 0.066s
: ty diana_coman. sad to see the state of tmsr isp affairs. i suppose it was kind of always like this, the state simply got.. actualised, so to speak. still, am planning on giving small talk on ssh
scan to hackerspace people, wanted to link to phuctor, now - can't. :( ☟︎
: PSA, the `!$ssh
` command may go offline for a while "soon", moving the db server which is used for this to a better, more tremendous place
: i just mean that a box behind NAT won't show up in that !$ssh
: you may not use it yourself because, barf, (1) "just get a real thing already", and (2) "i have more things to host, so why should i pay for this AND that, separately". but for someone who only needs bouncer and maybe-sometimes-ssh
(writing small bot in vim, connecting it to irc, etc.), it makes sense to pay very-little for a very-little-thing.
: mircea_popescu: yes, something like that. same !!v principle. user gets ssh
login. billed (if at all) by the minute, or the likes.
: ^ SSH
-1.99-HUAWEI-1.5 & SSH
-1.99-DOPRA-1.5 (respectively), heh
: look, i agree with this attitude; the ssh
banners, etc etc are and will remain publicly available. these are *important* standards to have.
: mircea_popescu: shit i meant `!$ ssh
` not getarchive, i'm forgetting myself lol.
: "you using ssh
-keygen, are you out of your mind!1"
: then i retract my previous snappy remark. ssh
: (i wonder if he tried just-ssh
'ing, no autossh first. because he needs to answer "yes" to "trust this fingerprint?" prompt first, it seems. just that.)
: i expect most of those broken openssh keys were generated by ssh
: snarky trinque uses ssh
and bash for 100 machine setups, too
` won't work for a bit, database server which scriba connects to needs to be reinstalled from the ground up)
: fromsiphnos: you'll need to learn things, this is not a (completely) trivial hacker-kiddo thing, in the sense of finding a list of "hackable" IPs on a forum and then trying user/pass pairs. :) you'd need to be understand how public key based authentication works, and what the distinction between a server ssh
key and a client ssh
: fromsiphnos: no, not user/pass, though one could try a bit of that, too, but as in, generate small set of "debianized" ssh
client keys, and try all of'em. much smaller set. see logs above
: so basically that's the kind of info available. more later, hopefully. there have been some scans of other ports on the ssh
-broken (phucted, as in http://phuctor.nosuchlabs.com/
) boxes, etc.; but no central place for those scans.
: but good news, as asciilifeform et al. have pointed out before, a lot of client keys get generated on ssh
servers. if random number generation or other things are broken on the latter, you can *derive* the (set of) the former, in some cases :)
: fromsiphnos: what do you mean by access? connect to, and get a login challenge from server? yes. access as in "hack da system" login access? no - this is *server* ssh
key, not client
: (the siphnos datadrop (http://siphnos.mkj.lt/datadrop/)
gives the banners ("banners" folder) and keys (in various formats), including raw ssh
-keyscan output (*_scan.tar.bz2), as e,N,IP CSVs (e-N-IP*), a.k.a. tmsr format, and converted openpgp (rfc4880) format.)
: the former (ssh
-keyscan output) is basically, ssh
-rsa public keys, plus ssh
server banners (ssh
: i suppose it's not documented anywhere properly as of yet, hm! fromsiphnos, are you by chance familiar with the `ssh
-keyscan` tool (bundled in by default in the openssh package). it's basically output from that tool, plus a list of all IP addresses which can be connected to on port 22.
: the `ssh
` command should take multiple IPs per msg, btw
: will check later! main guess is that there's no actuall ssh
server running on port 22 (or rather, there was none at time of scan.) would be great to know the overall statistics, yes.
: also, as you noted earlier, there's a good chance a bunch of ssh
*client* keys were generated on those machines, too, so also possible to try to bruteforce-login with generated keys (to servers which have broken rngs)
: well. for one, it's nice if you can distinguish between different keyholders, no? in the particular case of ssh
-rsa keys, "which ip used this key?"
: i think some sysadmins may want to be able to submit their ssh
-rsa pubkeys themselves. and phuctor only accepts openpgp format, this needs to be converted (ssh
pubkey -> gpg pubkey). so i'm adapting/stealing jurov's script and cleaning it up.
: this was while testing a script to be given to this austrian dude who wrote me, asking how to submit his server's ssh
server running on a nonstandard port)
: i guess one should standardise terms here. the larger number corresponds to "something's running there" servers, found via 1st scan phase. the lower 15M number corresponds to "actually speaks ssh
protocol" servers, found via 2nd (ssh
-keyscan) scan phase.
: mircea_popescu: the 20M or so servers which responded to TCP SYNs sent to port 22. however, out of those, about 5M (or however many) did not respond to ssh
handshakes, hence the lower number in the banners and phuctor payloads.
: (i should write down some stuff before i forget, such as, figuring out ssh
-keyscan limits etc.; luckily i wasn't dumb enough to delete any scripts written etc...)
: (note, some of those version strings contain OS string, some of them don't; these TXTs store versionstrings-as-they-were-seen, without any ssh
-server/OS version separation.)
: imma dump all this in a nice format now, i'll separate OS string from ssh
versionstring i guess
: but it also does shit like [SSH
-2.0-OpenSSH_5.1p1 Debian-5] vs. older [SSH
: btw i'm going thru those ssh
banners from ssh
scan logs finally, and there's some inconsistent crap there (thanks openssh): same ip&port may respond with two different banners during same scan (the ssh
-keyscan utility may spit banners for same server multiple times). it seems usually the mismatch is in adding a minor version onto ssh
server string only (e.g. [SSH
-2.0-OpenSSH_5.8] vs. older [SSH
host key not automatically regenned upon upgarde, is it
: or windows admin running ssh
server so he can actually get work done :p
will try to find time to tie up some loose ends (log, ssh
banners in nice format, etc)
: (the 220.127.116.11 pop is interesting tho, as some of these hosting-company-i-use boxen get provisioned with everything installed, and i'm sure as fuck that "not all" customers regen ssh
host keys. so there may be more pops, or other interesting goodness. probably the whole /16 is worthy of getting properly port-scanned, lots of broken stuff there i'm sure - if anyone has time etc)
: in retrospect, gpg comments were too long.. i've made them shorter for the 'additional' ssh
key bundle (last ~3M keys), but that won't be ingested for a while
: asciilifeform: wouldn't be sure re. costs. vps can be $5/$10 a month, and stuff i used for ssh
key crawling (scaleway) can bill hourly
: ben_vulpes: i'll think about this next week. it may be that it's not really needed, yeah - i agree. and integration of things such as ssh
server banners with phuctor keys is something that asciilifeform said he'd be up to do on phuctor's db itself..
: gabriel_laddel: you need an ssh
account on a vps?
: this reminds me, i've got all teh ecdsa ssh
keys, too. to be looked at one day..
: asciilifeform: makes me want to try top 100 password lists on telnet/ssh
/etc on the whole ipv4, you know
: in fact.. due to https://hdm.io/tools/debian-openssl/
correctly pointing out that "This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system.", someone should attempt botnet-brute-login to all 13M+ (i forget lol) ssh
hosts with rng-fucked client keys. ☟︎
: (though, iirc github removed shitty ssh
client keys - don't recall when jurov collected them, i think he mentioned this)
: btw, afaik lots of ssh
*client* keys got generated this way. soo, ssh
client key dump should be interesting... and it can also be used to, you know, directly own boxes.
: ye olde debian prng bug => small set of possible ssh
keys => factors extracted for keys => factors inserted into db?
: but the 2nd ssh
-key-extractor stage can do the stuff you want, yes.
: also, i may want to re-run the base ipv4 ssh
server finder at some point, i'm sure i'll get some more keys :p
: well for one ssh
client keys normally have an email/ID associated with them, not sure if ssh
agent would like an ssh
server key. in theory, yes, sure
: i mean in practical terms, of course, theoretically, but as in, would a canonical ssh
agent eat it up
: can you even use an ssh
server key as ssh
client key (and yes i agree if it's easy to do, someone will have done it)
: mircea_popescu: absolutely - will do! though, those 22mil boxes have ssh
running on them; there's prob a semi-quick way to get a broader "is it generally online" list, too. but, gotta start somewhere
: [things are back up. also, doing ssh
stuff via shitphone sometimes worx.]
: (crazy. i'm dumping the contents of vim buffer through the literal ssh
terminal, by hand, 'cause i can't save them and i need to. good times!)
: asciilifeform: btw i have all the version banners (for all the hosts in the ssh
keyset) stored, probably a good idea to make that available i guess?
: wonder what tmsr thinks of ipython notebooks. basically you go to website and are presented with python interpreter, and a ready-made list of commands for graphing, doing stats etc. thinking of doing one of these for some initial ssh
keyset analysis. nothing too serious at all ☟︎☟︎
: example: 18.104.22.168 (ssh
-rsa key from 22.214.171.124 (12 July 2016 extraction)) <firstname.lastname@example.org>
: *to include the new ssh_openpgp_diff_2016-07-13.tar is what i meant
: this concludes the ipv4 ssh
key scan (the new keys are due to re-scan + the previously-excluded hetzner hosting ip ranges). i may rescan in a couple of weeks or a month to see how many new etc (and in general it would be a good and interesting exercise, etc.) some kind of writeup will follow...eventually
: from rescan of ipv4, from 'untainted' ip addresses. the ">1M" is due not only to rescan itself, but also because i had excluded ipv4 ranges for hetzner which had been sending tons of abuse complaintz. i can handle those complaints now. but i had forgotten about exclusion of hetzner ssh
hosts. the new tarball will fix this (it won't include any old ssh
keys, only new ones).
: trinque: re. "ssh
ones are a bit long." << yeah you're right, need to shorten them..
<< yeah, hm. suggestions? a non-ad-hoc solution would be to make deedbot split its irc lines as needed i suppose; or for this particular case, not to mention the comment in the gpg key if it's too long, or to truncate it; or to consider shorter gpg comments for these ssh
keys in the future i guess.. ☝︎
: woohoo re. ssh
keys :) good stuff. lol @ teh dsl provider.
: hm, box.cock.li seems to be down, and ssh
host key on vc's vps seems to have changed :/ hrmph.
: ..so no truly-broken keys from the ssh
keyset yet, i take it! :)
: i would like to scan the whole /0 0:65535 range some time though, i'm sure there'd be quite a few ssh
servers lurking behind strange ports, and quite a lot of them could be old embedded gadgets. just speculation tho