On Mon, 2009-03-23 at 14:31 +0000, Anne Wilson wrote: > On Tuesday 23 December 2008 15:38:17 Warren Young wrote: > > Michael Simpson wrote: > > >> GRC reports that ports are stealthed > > > > > > Try www.auditmypc.com or nmap-online.com rather than grc to look for open > > > ports > > > > What advantages do they have, in your opinion? > > > > >> there a better way than opening port 143? > > > > > > ssh tunnelling? > > > > I agree, though the default CentOS sshd configuration requires some > > tightening down to trust it on Internet-facing servers, IMHO: > > > > 1. In /etc/ssh/sshd_config, set "PasswordAuthentication no". No matter > > how good your password, it isn't as good as using keys. Remember, > > forwarding ssh opens it to pounding 24x7 from any of the millions on > > zombie boxes on the Internet. > > > > 2. On the machine(s) that you want to allow logins from, run "ssh-keygen > > -t rsa" to generate a key pair, if you haven't already. Then copy the > > contents of ~/.ssh/id-rsa.pub into ~/.ssh/authorized_keys on your home > > server. These keys are used to authenticate the remote system, in lieu > > of a password or physical token. You could put these keys on a USB > > stick instead, if you didn't want to keep them permanently on the remote > > hosts. > > > > 3. Disable SSHv1 protocol support in /etc/ssh/sshd_config: "Protocol 2", > > not "Protocol 2,1". SSHv1 has known weaknesses. Boggles my mind that > > it's still enabled by default.... > > > > 4. Same file, set "PermitRootLogin no" if it isn't already. > > > > (Aside: I also like to set up sudo with one account allowed to do > > anything, then lock the root account, so the only way to get root access > > is to log in as a regular user then sudo up, reducing the risk of > > passwordless keys.) > > > > Having done all this, you're ready to allow remote access: > > > > 5. In your router, forward a high-numbered port to 22 on the server. If > > it's not smart enough to use different port numbers on either side, you > > can change the sshd configuration so it listens on a different port > > instead. I like to use 22022 for this. > > > > This is *not* security through obscurity. It's simply a way to reduce > > the amount of log spam you have to dig through when monitoring your > > system's behavior. Everything that appears in your logs should be > > *interesting*. Constant port knocking from worms and script kiddies is > > not interesting. > > > > In case you've not done ssh tunelling, Anne, the command that does what > > you want, having done all the above is: > > > > $ ssh -p22022 -L10143:my.server.com:143 anne at my.server.com > > > > This sets up port 10143 on the local system to be redirected through the > > ssh session to the IMAP port on your home server. You don't want to > > redirect 143 to 143 because that would require you to run ssh as root. > > It also prevents you from using this on a system that itself has an IMAP > > server. > > > > With the tunnel up, you can set up your mail client to connect to port > > 10143 on localhost, and you'll be looking at your remote mail server. > > Hello again. You were kind enough to give me this advice last December. I've > another holiday approaching and thought it was time that I got this sorted. > Unfortunately, I'm not sure that I can do this, so I'm asking your opinion. > > My router is a Netgear DG834G. I can create a service, tell it which ports to > open, and say which local IP I want it sent to. However, I can't see any way > to set the port to which it should be forwarded as anything other than the > incoming port. IOW, I can enable the new service Ext-ssh, which accepts > incoming traffic on port 22022, and direct it to my server on 192.168.0.40, > but I can't see how to make it send that traffic to port 22 on the server. > > Am I totally misunderstanding this? Really all I want is to be able to log in > to the server if I get an email alert that there is a problem or security > updates pending. If I can get this sorted, I'll look again at how to route > the IMAP mail through the tunnel too. --- http://kbserver.netgear.com/kb_web_files/n101145.asp http://kbserver.netgear.com/kb_web_files/n101145.asp#FR114PAnchor JohnStanley