Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Greetings,

the server admin for our company suddenly left, and left the rest of us IT folk somewhat clueless about Linux and setting up servers and such. The setup is as follows:

Our local server, which we use for development and as a security tunnel through which we reach our live servers in Germany, is on the first floor of our company. It has Ubuntu and OpenSSH installed. It contains our SVN repository, and our live servers update from this server. It has a dyndns set up, and works perfectly. The updating workflow is as such: Make change, Commit, SSH to local server as root user, SSH to live servers, execute update. This all works real nice through dyndns, and used to work real nice through our local network -> while we were on the first floor (with the server) we had some kind of IP based filtering. Out of 5 WAN's in the company, only ours could SSH to the server. However, we now moved to the second floor and the server acts as if it doesn't know us. I assume the local IP changed when we switched the cables from one part of the switch in the rack to the other part (are different parts of a switch on different IPs? I assume so..), and now we are unable to SSH to it locally (dyndns still works). The people that took over our abandoned office can SSH to it, just like we used to, and yet they shouldn't.

The question is this -> where and how does one set up this local-IP based filtering for SSH connections on a local server? I read several SSH tutorials and strolled through sshd_config filed and such, and could find nothing. If you can help me, please be specific, I am completely clueless about the whole process, so saying something like "generate a public key and upload it to the machine" will just confuse me :)

Thanks a bunch..

Edit:

netstat -plutn | grep sshd

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 758/sshd
tcp6 0 0 :::22 :::* LISTEN 758/sshd

iptables -n -L

Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

SSHD_config

HostbasedAuthentication no

IgnoreUserKnownHosts yes

ListenAddress ::

ListenAddress 0.0.0.0

Match -> not specified, line does not exist

Edit 2: Problem solved.

It was plain old human error. The guy who connected our first floor rack to the second floor didn't do that at all. He actually redirected the ethernet socket to their own switch and told us he did it. Thus, we were online, but through their network. A younger network admin for the building came in today, and when I asked him about it he just sighed in disappointment and connected everything the way it should have been connected in the first place. Now everything is perfectly fine.

share|improve this question
add comment

2 Answers

you shold check what interfaces sshd is listening like

netstat -plutn | grep sshd

and you should check iptables rules for incoming conenctions on 22 port.

also check sshd_config:

HostbasedAuthentication
IgnoreUserKnownHosts
ListenAddress
Match
share|improve this answer
    
Ok, info added into original question? Does this mean anything to you? It means absolutely nothing to me.. –  Swader Apr 7 '11 at 9:43
    
"Out of 5 WAN's in the company, only ours could SSH to the server." WANs or VLANS ? how you connect to server ? servername.dyndns.org or 192.168.0.xxx ? SSHD_CONFIG and iptables looks fine. –  MealstroM Apr 7 '11 at 9:56
    
Wireless lans. From home, we used dyndns to connect. From here (the office) we connected via IP (196.168.3.245). Found the problem, though. Updating main question right now... –  Swader Apr 7 '11 at 10:24
    
@Swader Plz delete yours real external IP or something like that. This can used to compromize yours security. –  MealstroM Apr 7 '11 at 12:29
    
@MealstroM You mean our dyndns? We need the dyndns to be able to work from home. The only interaction possible with our live servers is via the local server, and the only way to connect to that is to know the dnydns address, the admin pass and the root pass. Even then, you need the passphrase to reach the live servers. Isn't this secure enough? How can we improve it further? –  Swader Apr 7 '11 at 21:15
show 2 more comments
up vote 0 down vote accepted

There was no filtering at all. It was human error as specified in the edited content of the question. I guess I'll have to take everything apart one of these days and learn this stuff to spare myself any more timewastage and embarrassment.

Thanks for the effort MealstroM!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.