Testing SSH security

Discussion in 'Tomato Firmware' started by Mangix, Dec 29, 2012.

  1. Mangix

    Mangix Networkin' Nut Member


    I found this after watching a recent presentation at 29c3 on the security of RSA 1024-bit. One of the claims in that presentation was that the keys generated on small routers is not as good as a general purpose desktop. That and currently, bruteforcing an RSA key is feasible within a year.

    As such I am curious if anyone is able to test and discover that their host key is compromised. I tested two routers running tomato and the keys were fine according to the website.

    To test in case the publicly available ssh server test fails(as it did for me), log in to ssh(or tools > system) and type 'nvram show | grep sshd_hostkey' and copy everything after the = sign.

    On a second note, any way to change the host key to a 2048-bit one?
  2. koitsu

    koitsu Network Guru Member

    That site is a general bunch of hogwash. "Host key is compromised" is hilarious -- how would they know if a private SSH key (either used for the SSH server, or as a private key itself) was "compromised"? They wouldn't. Just utter nonsense. Yes, they can look for badly-generated keys (1023-bit vs. 1024-bit) and some other things, but this "compromised" statement is a farce. Sigh.

    Furthermore, are you aware that by doing what you did, re: "nvram show | grep sshd_hostkey' and copy everything after the = sign", that you just gave them a copy of your SSH servers' private key? Why would you do that? Sigh.

    Finally, no, there is no way to "change" a key's bitdepth. You get to re-generate a key.

    And stop worrying about 1024 vs. 2048-bit keys. For consumer routers and so on, it's really not worth bothering with, IMO. You're worried about key length with regards to brute-force, yet nobody is going to be able to brute-force your key as long as you don't give it to them. Another sigh. You're more likely to get compromised by someone brute-force-guessing root's password on your router, which is why you should use password-protected key-based authentication and not exclusively passwords.

    The post subject line is highly misleading and caught my eye. There's nothing "to test" about SSH security. If your paranoia stemmed from this article:


    Then the problem has nothing to do with SSH, but rather with people keeping their private keys (not public keys) on systems which are compromised, having their private key on a shared (multi-user) system where file permissions permit them to be read by any user, or other such things. It doesn't mean SSH is insecure, it just means people are irresponsible about managing their private SSH keys.
  3. Mangix

    Mangix Networkin' Nut Member

    My understanding is that the nvram value has the public key and not the private. i only verified this by looking at the length. the private key is about twice as long.

    As for the "compromised" portion, they claimed that it's due to misbehaving random number generators generating the same primes(at least one of them). When collecting multiple keys, various attacks can be performed on them(batch NFS being the fanciest one).

    This topic stemmed from this video:


    There was a section near the end where they were taking questions and specifically mentioned SOHO routers as having bad RNGs. This video:

    is somewhat similar.

    I will admit that I have a preference towards using ECC as public key crypto.

    edit: nice formating...
  4. koitsu

    koitsu Network Guru Member

    If it's just the public key then there's really nothing to worry about. *shrug* At least from a pragmatic standpoint.

    The first video is just about crappy entropy harvesting. That's really what it boils down to. Like with most things in security: you're only as secure as your weakest link. SSH isn't be to blame for crappy entropy harvesting. :) It's not a problem specific to consumer routers either:


    Generally speaking on these routers, /proc/sys/kernel/random/poolsize should be at least 4096 (using Linux 2.6), and /proc/sys/kernel/random/entropy_avail should return a number above 100 (anything lower and that's not ideal). On my RT-N16, for example, entropy_avail returns 175. There are ways to adjust the entropy sources/pool as well, but it's not really worth getting into because I don't see this being a problem.
  5. Mangix

    Mangix Networkin' Nut Member

    I did a 'cat /proc/sys/kernel/random/entropy_avail' on two routers running tomato and got 146 and 180. But with two other routers running dd-wrt, i got 3605 and 3909. that's....a rather large discrepancy.
  6. koitsu

    koitsu Network Guru Member

    It just indicates the amount of entropy "available", so it's very possible that DD-WRT has further adjustments to increase entropy variance from different sources: meaning, /dev/random and /dev/urandom return "more random" values on DD-WRT than TomatoUSB.

    The only time this really matters is for things that make use of random(4). The more entropy sources, the more CPU time gets wasted harvesting data from those sources (interrupts, clock timer, etc. are all common sources combined in "algorithmic ways" to make a random result). So DD-WRT is "more random", at the cost of greatly increased CPU time any time an application calls random(4).

    It really doesn't worry me in the least that the entropy sources on Tomato are significantly lessened or smaller -- these devices are home consumer routers intended for NAT + LAN (i.e. multiple computers talking to one another or to the Internet), they are in no way/shape/form equivalent to that of, say, a Juniper Netscreen (VPN) device. The processing power and capability of those devices is significantly improved, plus many of them have hardware RNGs for entropy too. I keep trying to tell people who throw all this crap into TomatoUSB (VPNs, other nonsense) that these devices just really aren't made for that. They're very small, very lightweight, very minimalistic hardware with hardware offloading for very, very specific purposes and only on some models of routers (even the Ethernet switches on some of them aren't that great).

    You would need to ask the DD-WRT folks what they did to increase the entropy source list -- note this is not the same thing as the entropy pool size, which is in the proc shim called "poolsize" and should be 4096 on Linux 2.6 kernels. Remember that kernel changes are generally a no-no and have to be examined very carefully, i.e. if DD-WRT folks just say "we upgraded the kernel to 2.6.23", that isn't a viable option for Tomato because of the binary blob wireless drivers handed over by Broadcom. (I have no idea why DD-WRT risks that either)

    Please refer to the Linux random(4) man page for further details on how all of this works. Wikipedia's article is short but sums it up.
  7. Mangix

    Mangix Networkin' Nut Member

    I really doubt it has to do with bumping the kernel version. Backtrack in a VM gives similar results to tomato. dd-wrt's got some magic sauce they added. Poolsize is 4096 on everything.

    The solution that i'm liking right now is to generate an RSA key on a desktop computer and transfer it to tomato. No idea how to accomplish this though. Oh well.

    I guess I won't care about a small issue like this.

    edit: now this is rather interesting. Backtrack in a VM gives a different value every time 'cat /proc/sys/kernel/random/entropy_avail' is ran but every Broadcom unit returns the same exact value every time the command is run. That's 3 of those routers I mentioned. The fourth one running dd-wrt is Atheros based(TP-Link TL-WR740N) and acts the same as backtrack.

    actually nvm. The broadcom routers also change this value but much more slowly than others.

    edit2: after trying a bunch of stuff, i managed to reduce the available entropy of two tomato routers to 2 and 4 respectively. I also brought the atheros router to tomato levels of available entropy. I'm stopping now.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice