On Fri, May 6, 2011 at 6:14 AM, George <pinkisntw...@gmail.com> wrote: > I have a computer at home that I'm doing some research on and I set up > an SSH server on it so I can access it from other computers at home. I > haven't opened up the network to the internet yet though, as I'm not > confident enough that it is safe. > > What are the configuration steps that I will need to do on the server > and the client to be able to work access the computer from my > workplace?
Late to the party and I'm sure I'm going to generate some heat, but there's sure a lot of misinformation in this thread. First, don't trust anything you read in this thread, including what I'm telling you, without checking in the usual places. (Remember that wikipedia can be edited by people you don't trust, so check the references, check back on different days.) The openbsd project is where openssh came from, so resources under openbsd.org probably deserve a bit more weight than this list, even though you think you know many people here (and you don't know me). openssh.com is the official site for openssh. Disable root login on ssh entirely. (/etc/ssh/sshd_config has that enabled in my more-or-less default install. That is, I think, so you don't find yourself in a catch-22 when installing remotely. Should be in a list of things to do afterboot.) Don't use port 22. I know that it's just obfuscation, but every speed bump helps. You will definitely get probed regular on port 22. Probes on higher ports will be fewer, and that helps. And you can put tarpitting firewall rules on port 22, for a little spitting-in-the-face-of-the-enemy. Just for fun, you can port-forward from a different external port to give the intruders more to think about when they succeed in compromising other internal boxes. On the other hand, you than have to remember what you did, which is one of the down-sides to obscurity. Anyway, look up the uses of the port you decide to use instead, you probably don't want to use one that is typically used as in botnets and their control networks. Port knocking is useful, particularly if you aren't ssh-ing all the time. On the other hand, if you have reason to think an attacker is targeting your box specifically, recognize that port knocking can be spotted. If you have reason to worry about that sort of stuff, customize your port-knocker so that it changes the pattern in a pseudo-random one-time-pad sort of way. (More things to keep track of, yes. Don't do this unless you really have to worry about observers and attackers.) Keys+passphrases vs. passwords, well, break out bc to do the calculation: Using the full keyboard, you're working on 95 ^ 15 possible combinations on a 15-letter password: (95^15)/(1024*1024*60*60*24*365) 14010304008739644 We're not talking about ten or a hundred years to even a highly likely successful attack. Still, since that pair of 1024s in the denominator is a lot more tries than once a second, use the usual suspects to keep sshd from accepting more than one login attempt per second total (adjust that by the actual number of near concurrent valid login attempts you actual expect, but more than one second between should be unnecessary) and temporarily drop repeated attempts from the same IP. Temporary because you know you're going to mess it up three times in a row sometimes, and a five-minute wait is better than having to go home and edit a block rules list. But recognize that your brain has entropy eaters. l33t5p3@|< can actually reduce entropy if the attacker has seen some of the passwords your brain has generated in the past. Probably wisest to use a random password generator that someone you trust wrote. The problem I have with keys is that MSWindows boxes tend to grow weeds. Even the BIOS is not necessarily safe any more. And bugged keyboards have been mentioned. (Weird. Did you know that standard keyboards can have their controllers re-written remotely via flash vulnerabilities?) Depending on your work environment, you may want to assume that even booting a liveCD is not going to clear the keyloggers. So, okay, having both the physical key (on a hardware write-protectable key) and a strong passphrase for the key can raise a speedbump because it requires two pieces of malware to be on the machine. But anything running in a compromised machine can be compromised, so we assume that the machine itself can grab the key at some point in the retrieval and transmission. One of those dedicated key devices with a keypad that requires you to type you pin in t get out he passphrase does avoid all keyloggers on the MSWindows machine. With a liveCD (or hardware write-protected liveUSB) you have slightly better odds of beating the malware on the host, and you could have an encrypted one-time-pad on the CD or USB. And only malware in the BIOS could get close to the one-time pad. Frankly, I'm more inclined to spring for an Android phone if I really need to log in from home. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktinfjxrzceixuft-gwo_n-jwj1x...@mail.gmail.com