ssh is smarter than I am
 

First please excuse my long-windedness. I have been working on this for a couple of days now. Feal free to skip to the end unless you want all the gory details of how I got there.

Well I thought I had it working. :(

In a previous thread I was working on getting dns working on my linux firewall. I am building it from the ground up. It is based on Debian Lenny's base install no gui. Not in service yet.

I know that part of the problem is that I don't enter the command correctly all the time and so dns can't return any data. I am not sure that, even though I have set the name servers in dhclient.conf, they are being used until I do a restart on bind and dhcp. At this point local names will resolv on the server but not on a client.

My setup

Big-bad-www > Existing-Linux-firewall -> local-network -> plastic-box-router -> New-Linux-firewall < hub > client

What I want is for local names to resolve without having to enter the domain name when I do something like "$ ssh -l user-name some-host". I understand that for ssh to resolve in some cases I need to populate the /etc/hosts file with data. I already have the data set up in dns for my local network, and it dose work with the description above when I use the dig, nslookup or host commands. But it does not resolve for ssh or vncviwer.

This project is both for practical use and a learning experience. Eventually this server will replace my current firewall.

So my questions to start with are; ( disreguard I seam to have this part fixed)

Without the hosts file populated on the clients should I still get local name resolution for ssh and vncviewer from the server via dns?

How do I get the client machine to resolve local names from the data on the server? I have edited /etc/hosts on the client to contain the server name and ip.

So far google and the man pages have not yielded a solution for me.

Thanks for what guidance you can give me.
***********************************

More info.

I have been looking at this for a couple of days now. I have to the best of my ability locked the linux firewall/dns down. It is possible that something in that proccess is what is causing the problem, yet befor I setup bind9 I was able to ssh into the server. This leads me to believe that it is a name resolution issue.

Second, I did update the firewall/dns server since I installed bind9 but I think the ssh issue accured befor that update.

I am certain that it is not a "too many connection at one time issue" because there are only 2 machines on the network I have setup for testing the setup before I put it into production.

I opened a hole thorugh the plastic-box router to the firewll/dns server and tried to ssh into it form my laptop, which I could do before, and I got the same error.
I have not changed anything on the client machine since the Debian Lenny RC1 install except to add a line in /etc/hosts " 192.168.x.x some-local.network server-name", and a line in /etc/hoss.conf "order host,bind".

At the moment the network is not up so I can't give the exact error when I try to ssh into the client from the server.

I suspect that it is an issue with the host.allow or host.deny file on the server. There again the server is not up so I can't give you the exact file. But I do have a line ALL:ALL:deny in the allow file but it is after an entry that is suppose to allow connections form the local network by name. As I remember something like ALL: .some-local.network . My understanding is that reading the files stops on the first match, with the allow file read first. So it seams that somehow my entry above is not working corectly. I did have the ALL:PARINOID line active in the deny file but have disabled it.
**********************************************

So ok I have booted both systems now. I just ran '$ ssh -vl user 192.168.x.x' and this is what it returned.

Typing this in by hand made me realize that these files don't exist on the client machine nor do they exist on the server. Some how trying to redirect the output with > some-file does not work for me with ssh. So I have to enter it by hand.

Something I forgot to mention before is that I have zeroed out the known_hosts files on both machines. So that is not the issue like I have read that some people have had.

Running another command I came across has revealed that the sshd on the server seams to not be able to bind to any address.

I ran the same command on the client and it returned the same thing.

I ran # ssh 192.168.x.x from the server and it connected right up and asked for aproval of the fingerprint of the client.

I ran, again on the server, # ssh -vl user host.some-local.network it returned
On the client side it allways returns ssh_exchange_identification: Connection closed by remote host wether I use just the ip or include user names and host names.

In /var/log/auth there are several entries about the host name not matching the ip. In the example above the name and ip are correct for what is in the dns data base. The ip's are assigned by dhcp and static so that the same mac address always gets the same ip. Have tried some changes to /etc/security/host_access.

Hear is the error in /var/log/auth.log
I am not sure why I am getting this error. The only thing I can figure is that the user account I am using to login with only exists on the server. I have to use this account or root to login to the server because it is locked down pretty hard and will not accept any other users to login.

Still none of this explains why I can't access the client from the server when using names. I have not connected my laptop back up to the testing network to see if I can log into the client from it which would indicate that it is a server specific problem. Guess I will try that.

Well that was little help. I was able to ssh into the client machine form my laptop, but only with the ip and not the fqdn. I got the same error when I tried to login to the server. Guess I go read some more posts on google.
********************************

Looking back through the log I am keeping as I setup the new firewall/dns I see an entry about editing /etc/pam.d/login to make selinux control logins. Could that be the issue.

Well I have looked at the pam setup for sshd and I don't see a reason that it should be causing the problem I am having. It is not calling anything that should be causing this problem.

I have changed some things and now the error that is reported by.. I think I will do a restart. No change. grrrr

So ok the exact entry in auth.log is:
The first entry is from trying to connect with "$ ssh -vl smoke 192.168.7.1" (smoke is a general user account on the firewall box, it does not exist on the client) both the host name and address are correct per the dhcp lease assigned to the client machine

The second entry in from trying to connect with "$ ssh -v 192.168.7.1". It still pulled the correct name and ip yet I was still denied access.

Line 13 in the hosts.allow file reads "ALL: LOCAL" The next line reads "ALL: .Torah-disciple.local". There are no other uncommented lines in the file. I had a line that read "ALL:ALL:deny" but I commented it out just in case.

There is an entry in syslog that matches up time wise with the second attempt that says not sure that means anything but there it is.

I have tried adding a line in sshd.conf to specifically allow the user "smoke" and did a ssh restart and there is no change.

Any ideas where to look?

Nearly all of these issues are because your DNS is broken. Most of the errors indicate that your reverse DNS does not match your forward DNS (i.e. the PTR records do not agree with the A records).

I see that, as previously, you're trying to mask out or leave out information that you don't think is important. I thought you would have learned from earlier that this information usually is important, since I wasn't able to figure out half of your problems until you posted the full information instead of just what you thought was relevant.

As to why you cannot use shorthostname from your client, it's because you don't have a "search" or "domain" statement in your /etc/resolv.conf that refers to your local domain (on the client).

Also, you cannot start two copies of sshd with the same config file--they will try to bind to the same ports. You have to stop the normal sshd service if you want to run a copy in non-forking mode for debugging purposes.

Thanks chort

This is what I initially thought the problem was but then rejected it. I have not changed them since they were setup before. Hear are the PTR records
Hear are the A records
I see the incorrect ip for distraction. Don't know how I could have missed it. Correcting it allows me to ssh into the server from the client.

My resolv.conf is automatically generated on the client machines so anything I put in them gets over written on reboot. Some how I have managed to get the setup correct so that the auto-gen-version contains a "search" and "domain" statement. Not sure how I did that, guess I will have to wait until I start to configure the rest of the clients when the system goes live.

Thanks for that. I did not realize that I was trying to run two copies. I only came across the command in a post somewhere and tried it hoping that it would help me figure out what was going on.

FYI; Names would not have worked from my laptop because the static ip and associated name is for the wireless and I was connected by cat5 so the lappy had a dynamic ip at the time.

Once again Thanks for the help. All is happy now, until I break something again.

Thanks

Just an FYI. If you have an entry sshd_config "AllowUsers rebees@ahost", it means to allow the local user "rebees" from remote host "ahost". On the remote host, you may be logged in as a different user.

Also look at the handy "getent" command. You can enter "getent hosts <ahostname>". It will use gethostbyname() and return local hosts and hosts on the internet. It is a quick and easy way to check if things like nsswitch.conf and resolv.conf are configured correctly, even in a setup where you don't have your own dns server.