SSH Question

M

mdmcaf

Weaksauce
Joined
Jan 23, 2011
Messages
68
I'm using WinSSHD for my computers to connect to my file server. The file server is running Windows Storage Server 2008 and the machines that connect to it are a mix of OS X, Xubuntu, and Windows 7 machines. I can connect to the server via SSH just fine from all of my computer on the internal network (i.e. using the local IP address) but when I try to connect to the server via SSH from an external network it doesn't work - I get a 'connection refused error'. I know that it shouldn't connect to the external IP address from inside my network...this happens when I try to connect to it from my parents' house (I don't know the settings of that router but I can make changes to it if need be).

I have a dyndns updater attached to a URL that they provided for me that I thought would alleviate the problem, but it doesn't. I've noticed that all of my computers have the same external IP address so I'm thinking that that has something to do with it. To this effect I put my file server in the DMZ (i.e. outside of the firewall) of my router and tried connecting again but this had no effect and the IP address of the file server is still listed as the same IP address that all of the other machines on my network have. I'm not very experienced with networking issues as I'm mainly a hardware guy and I don't come across too many advanced networking issues in my line of work (I work at a computer repair shop).

I would really like to use SSH as I'm more comfortable with the command line and find it faster to do things that I want to do as opposed to setting up a VPN via Hamachi (plus the Hamachi client for Linux really sucks). I would like to be able to access my files from a remote location so that if I happen to be at a client's site and need files I can get them with as little trouble as possible. I'm well aware of things like VNC being able to support file transfers, and I was able to get it to work at one point but unfortunately TightVNC interferes with my backup software so I can't use that..I'm also aware that TeamViewer supports file transfers, but I can't use that as TeamViewer is only free for non-commercial use and this would be for commercial use. A solution that uses something like FileZilla for SCP transfers would be acceptable. I'm also perfectly fine with using OpenSSH or switching my file server over to a Linux flavor if that works better; I just haven't been able to find good guides on how to configure OpenSSH.

I have two questions:

1. What's the best method for testing the external connection to my file server? I have two routers and originally thought that if I put them on a different subnet that it would serve as somewhat of an external test - this has failed and made the environment more complex, so I scratched that idea. I can have someone else test my SSH connection but the only two people I trust with my authentication are my dad, who works late, and a friend in Australia who has an opposite work schedule from mine. I would prefer to be able to do the testing myself so that I don't take up their time trying to get it sorted out. I've also tried looking for settings for a proxy on my Cisco router but the only thing I could find related to proxy settings was a checkbox to enable DNS proxy...which doesn't seem to be what I want.

and more importantly...

2. How do I configure my router/file server/SSH to accept an incoming connection from a computer outside my network? I already have rules on the firewall of my file server set to accept incoming signals from port 22, and I believe that I should have the proper authentication set in place to connect to the server as I can access the computer from the LAN. I found a guide online about setting up WinSSHD and followed that, but it still doesn't work

Any help would be appreciated as I haven't been able to find information that's too useful online. I'm quite comfortable with the Linux/Unix Terminal as well as the Command Line of Windows (if that's even relevant) - I just don't know a whole lot about networking in this fashion as I've never been exposed to this kind of stuff before. Hopefully I've been clear enough but if y'all need further information I'd be happy to provide it.

My Internet connection comes from Comcast and my router is a D-Link DIR-615 running the 3.00 firmware (I haven't checked for updates in quite a while). I also have access to a Cisco RV 120W, I don't remember what firmware it's running.

Thanks.
 
you need to forward port 22 on the on the dlink to port 22 on the SSH server, sounds like you allready got everything else setup...
 
Let the brute force attacks begin. If you want to see something interesting that may change your outlook on what you want do, set up a Kippo honey pot with either an external connection and watch the logs. Setting up a vpn is really the preferred method. Openvpn server at the site you which to connect to and use a vpn client to connect. The do your sharing. Don't just open up ssh, even if you change the port it is listening on.
 
Jgedeon said:
Let the brute force attacks begin. If you want to see something interesting that may change your outlook on what you want do, set up a Kippo honey pot with either an external connection and watch the logs. Setting up a vpn is really the preferred method. Openvpn server at the site you which to connect to and use a vpn client to connect. The do your sharing. Don't just open up ssh, even if you change the port it is listening on.
Click to expand...
There are easy ways to mitigate the threat of brute force attacks to ssh on any device running iptables. On all edge facing servers I have, I limit the number of SYN packets to port 22 to 2 per any 30 minute period.
 
Congratulations. You have just discovered one of the reasons why NAT sucks.

Technically, NAT (and thus port forwards) only happen on the external interface, i.e. the address you're connecting to and the interface your connection comes in are not strictly related. So if you connect to the router's address but your packet enter the router from the internal interface, no NAT or port forward happens.

If you were to run your own packet filter, e.g. pf, you could hack it so you'd be doing NAT on the internal interface for SSH connections to the router only, which would then bounce them back to the internal network. But alas, with gimmick router hardware you're SOL, unfortunately. And strictly, you couldn't really test whether external connections work.

Another workaround commonly used is split DNS, where some fully-qualified domain name resolves to an internal address from the inside but to the global address from the outside. This still wouldn't allow you to really test if external connections work, though.

To really test external connections, you need to be "outside" your router. I don't know how your Comcast connection terminates at your location. Is it cable? Does your D-Link get an address via DHCP? What if you tried to connect your WAN interface to a test box running a DHCP server, just for the purpose of making 1 connection?
 
XOR != OR said:
There are easy ways to mitigate the threat of brute force attacks to ssh on any device running iptables. On all edge facing servers I have, I limit the number of SYN packets to port 22 to 2 per any 30 minute period.
Click to expand...

this.


for debian (prob avail for other distros aswell) fail2ban is a nice easy to set up package that monitors log files a sets a drop in iptables for x IP for x minutes.
 
cytech said:
you need to forward port 22 on the on the dlink to port 22 on the SSH server, sounds like you allready got everything else setup...
Click to expand...

Port 22 is forwarded to my file server, which has a static IP address - is there anything beyond that in the configuration of the port forwarding that I need to consider? In addition to the router forwarding port 22 I also have the firewall on the file server open up port 22?
 
mdmcaf said:
Port 22 is forwarded to my file server, which has a static IP address - is there anything beyond that in the configuration of the port forwarding that I need to consider? In addition to the router forwarding port 22 I also have the firewall on the file server open up port 22?
Click to expand...

not that I can think of, unless winsshd has some kind of access list based on IPs
 
TCM said:
To really test external connections, you need to be "outside" your router. I don't know how your Comcast connection terminates at your location. Is it cable? Does your D-Link get an address via DHCP? What if you tried to connect your WAN interface to a test box running a DHCP server, just for the purpose of making 1 connection?
Click to expand...

Yes, my D-Link gets it's address via DHCP from the cable modem. I had an interesting problem with the computers that connected to the router wirelessly getting duplicate IP addresses on a frequent basis - the only way around it was to reset the router...attempting to renew the IP address of the computer didn't have the desired effect. Could that be related? I eventually tracked it down to the cable modem and am going to have that replaced as soon as I can make it down to their offices to get a new one. When I had a Comcast tech over to move the cable modem downstairs, I asked him about it and he said that it was either an old cable modem that needs to be replaced, or my D-Link router was placed too close to my cable modem and that caused the confusion with DHCP (which doesn't make sense to me).

I've got a computer handy for turning it into a DHCP server -so maybe I'll try that for fun to see if I can't get it to work.

But I'm getting the impression that it would just be easier to go ask someone to connect to the computer for me instead of jumping through hoops to pretend like I'm coming in from the outside.

Thanks for the reply.
 
cytech said:
not that I can think of, unless winsshd has some kind of access list based on IPs
Click to expand...

It does actually appear to have access control based on IP address. Under Access Control in the configuration window it lists a field called "Hosts: IP rules". That particular field says that it enumerates IP address-based rules for accepted connections...if no match is found according to IP address, the IP address is resolved into one or more DNS names and these are tested according to the list of DNS name-based rules.

It's currently set to the IP address 0.0.0.0 and the Allow connect field is checked. There's also a field called "Hosts: DNS name rules"...could that be where I plug in the address that I get from DynDNS?
 
I got the problem figured out and am able to successfully SSH into my server from an outside connection. I didn't get the issue with pretending that an inside connection was really coming from the outside but that seems to be to be more complex than I'm ready for - I ended up just going to my parents' house and connecting to the server remotely to configure the SSH server.

The solution ended up being adding my DynDNS domain name to the DNS rules of the SSH server - it's configured so that I can connect to the server via that domain and it only accepts connections from my user name and password, everything else gets blocked.

I am, however, curious to know why SSH is so insecure and what I can do to lock it down. From the research that I've done (with most of it coming from the O'Reilly book on SSH), it seems to me that SSH is a secure way for me to connect to my server. I am genuinely concerned about my data being compromised by an outside source so any information y'all might have on securing that connection would be very helpful.

Thanks for all your help.
 
SSH is secure in most ways. The data flow is encrypted between the two end points, it can be subjected to man in the middle attacks though.

The usual issue is weak passwords. There were some buffer overflow issues in older versions of SSH. But you will see a lot of people hitting your SSH server to see if they can get in, if you left an account open with a known password or no password, or a weak password.

I do suggest you lock it down with only version 2 of the SSH protocol, also make it so Root can not SSH into the box.
 
Use strong passwords, only allow version 2, and implement fail2ban to mitigate brute force attacks. Those three things are the key. Out of box, OpenSSH is reasonably secure.

You could go farther by blocking root logins or limiting access to specific accounts, or by e. g. preventing port forwarding, proxying, keys, etc, but those are more to protect you by limiting rights in cases where an account has already been compromised and SSH is being used as a conduit.
 
damacus said:
Use strong passwords, only allow version 2, and implement fail2ban to mitigate brute force attacks. Those three things are the key. Out of box, OpenSSH is reasonably secure.

You could go farther by blocking root logins or limiting access to specific accounts, or by e. g. preventing port forwarding, proxying, keys, etc, but those are more to protect you by limiting rights in cases where an account has already been compromised and SSH is being used as a conduit.
Click to expand...

I have my SSH server set up to use SSH-2; I'm not familiar with fail2ban but I've put it on my list of things to check out. My password is a ~25 character password that's pretty strong (using numbers, letters in different cases, and symbols) and I've set it up so that only one account has access to the server. I've been following the O'Reilly book "SSH, The Secure Shell" and the only way I've been deviating from the advice in the book is that I use WinSSHD as my server instead of OpenSSH. WinSSHD has a nicer interface that I'm more able to understand. I plan on learning OpenSSH, however, on a different box in order to lean it as that seems to be the standard that people are using.

Thanks for the info.
 
If possible, ditch passwords entirely and use keys. Then, password protect your key file.

S'right, I went there.
 
You must log in or register to reply here.
Back
Top