Don't think that because the small circle of people you know in the US don't know Linux that the majority of malicious attackers out there don't know about it. After all, you're not worried about the average person you meet on the street, what you should be worried about is kids in Romania, China, Korea, etc who have nothing better to do (especially the first two).
In many cases there are foreign countries with excellent Computer Science programs, but very poor economies and few jobs (thinking specifically of Romania here). What happens when those kids graduate university and realize there are no jobs for them? Hmm. Countries like Romania, India, and China do
teach Linux skills. In fact there's a Red Flag distribution of Linux that comes from China and the Chinese government is very keen on replacing Microsoft products in their country.
But forget all that for right now, let's go back to the basics. You are not worried because there aren't many people out there who know Linux, but how many does it take to be dangerous? Considering most people who are serious about computers now have broadband connections with a lot of bandwidth, and they often have multiple machines at their disposal (and a lot
more if they have created any zombies) we have to assume that a single person can hold vast amounts of computing power and bandwidth. Now will these people be randomly trying to telnet to IPs by hand? No. Surely you must be familiar with nmap? As you know it makes scanning networks trivial.
Now suppose they're only looking for a few specific things to exploit. Let's assume that the attacker looking for a sendmail vulnerability, Sun RPC vuln, and OpenSSL vuln. Now we can further assume that the vast majority of the people using these services are going to do so on the default ports. In fact, the attacker happens to be very lucky because running any of these services on something other than the default port will cause a lot of problems. In fact, I don't think it's possible for RPC services to work at all if you don't run portmapper on 111. Sendmail can still accept mail, but remote MTAs only deliver to port 25, and HTTPS will run on other ports, but then the person has to type the port number in their browser instead of just https://.
All the attacker has to do is run an nmap over night on several huge blocks of IPs looking for responses on ports 25/tcp, 111/tcp, 111/udp, and 443/tcp. More over he can write a script to parse the response banners and filter out any responses that don't look like they came from software he's looking for (i.e. only leave sendmail, sunrpc, and openssl).
Now when Mr. Cracker wakes up he has a neat and tidy list of only those few hosts out of hundreds of thousands that are running exactly the software he knows how to exploit. In fact, it may be even easier if he has tools that can run the exploits for him, he can have the tools run automatically against the list of target boxes and if they succeed, print him out a list of IPs that he now has the root password for. It could be as simple as waking up and just logging into your box like he owned it.
So let's examine the specific example of OpenSSH. Well a while back there was a vulnerabilty with OpenSSH and PAM authentication that would let an attacker enumerate a list of local users by using a dictionary username attack and measuring the length of time it took to generate the "password failed" message. With that method you could very quickly build a list of all the user accounts on the system (this is much easier than passwords, because usernames are nearly always dictionary words, or a combination of names and initials). Another method for building a user list would be to scan mail archives for headers indicating the message was generated from a particular distribution of Linux and/or sent through a particular MTA. The originating IP could be used to either scan that network (in case the host moved due to DHCP) or simply use that IP directly. In any case those are two methods an attacker could use to build a known good user list. After that he just has to try brute force password methods on the known user accounts. If you have a user with a weak password, hey presto: Local access!
One last word on password length. The traditional UNIX crypt() function would only DES hash up to 8 characters of the password. That meant that anything over 8 characters was just discarded prior to the hashing, so it wasn't compared at login. Less than 8 characters left few unique possibilities for the hash so it's recommended to use at least 8 to get the full benefit (more than 8 don't matter and sometimes it's easier to remember the full password even if part of it is irrelevant, much like telephone numbers that are spelled out in words are easy to remember, but if they're longer than 7 numbers the last part is actually discarded when you dial). I *think* (although I haven't confirmed) that newer methods like md5 and blowfish actually hash more than 8 characters, but I would need to check on that.