Post by Maurice BateyYou seem to missing/ignoring my questions in other replies, the ones
ending in ?.
Not deliberately, I can assure you!
Will comb through and check. Watch this space... 8-))
Tell you what, Instead of that, go through this and see what needs
improvement and lets you run a check front to back.
-------- standard debug ssh/sshd problem steps follows: ------------
Version
0.0
The following is mainly for Mandriva, maybe Suse, maybe Redhat/Fedora and
your install is not using SELinux/ACL's.
I assume you have:
o installed ALL system updates and have rebooted.
o installed the sshd daemon/service package. (OpenSSH Server).
o enabled it to run on boot.
o started sshd on the server.
In this document, "server" is where you are trying to ssh into and
"client" is where you ssh from.
Client is where ssh it trying to connect to sshd on the server.
All ssh test shots will be to a user account on the server, not root.
Where you see bittwister, or ~/, you should be in/using your user account.
Some commands need root privileges to run. To create a root terminal,
Click up a terminal,
su - root or for the k/ubuntu crowd it would be
sudo -i
Anytime I am working a problem, I will open another root terminal and do a
tail -f /var/log/messages
on each system I am working with.
I suggest you do the same.
PS: To abort tail -f command, do a Control c
To close a terminal/ssh session exit
sshd has to running and/or enabled to run on the server.
pgrep -lf sshd <===== Should return the pid and program name
3866 /usr/sbin/sshd <============ see, sshd is running, pid=3866
It might not be running if sshd is to run when needed. :(
Do check the permissions on it
ls -al /usr/sbin/sshd
-rwxr-xr-x 1 root root 379292 2008-05-06 14:53 /usr/sbin/sshd
chkconfig --list | grep sshd <====== on some systems
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off <= which run level starts on boot
sshd-xinetd: off <=== on indicates to start when needed
NOTE: Do not have both set on.
Current run level found with
/sbin/runlevel
N 3 <==== indicates my system is set at 3 and 3:on indicates
sshd will be started on boot.
If not running, you might be able to start it with
service sshd start
or maybe
/etc/init.d/sshd start
First prove you can connect to it by ip address when you are on the server
ssh bittwister@$(hostname -i)
If there is nothing in /etc/hosts.allow and /etc/hosts.deny
I expect that to work.
If fails, make sure your user account's .ssh directory has the correct
permissions by doing:
cd ~/.ssh
chmod 700 .
chmod 600 *
cd
ssh bittwister@$(hostname -i)
If no message showed up in /var/log/messages and there is nothing in
/etc/hosts.allow and /etc/hosts.deny I have no idea what to check next.
man hosts.allow to understand lines not starting with #
Next, run some test to prove network resolution is working.
Test by node name with
ssh bittwister@$(hostname --alias) then by fully qualified domain name
ssh bittwister@$(hostname --fqdn)
Failure on those, will be a /etc/hosts or network problem.
If so, only use the server's ip address from your client until
you get the network problem solved.
Once that works, verify the hostname ip matches what the client sees.
hostname -i on the server
host servers_hostname_here on the client.
If the hostname -i returns 127.0.0.1 on the server,
you need to use the ip address of the server's nic that
is connected to the client.
ifconfig to find the address. Snippet follows
eth1 Link encap:Ethernet HWaddr 00:16:17:57:66:54
inet addr:192.168.1.131 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::216:17ff:fe57:6654/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
the inet addr: field is ip4 ip address
the inet6: field is the ip6 ip address.
Verify the ip address test on server with
ssh ***@servers_ip_here
Once those run, only the firewall and /etc/hosts.allow and hosts.deny
contents would block incoming ssh attempts on the server.
You open the Mandriva firewall with
shorewall clear
Before doing that, get the server ip address for the nic connected to
the client.
ifconfig should give you a list of running nics.
hostname -i on the server.
assuming server is not blocking pings, verify connection with
ping -c1 servers_ip_here on the client, if works then
***@servers_ip_here on the client.
if fails, hit up arrow
and open the firewall on the server with
shorewall clear
hit a carriage return on the client to run the ssh client to server
test shot again.
No matter what, quickly enable the firewall, with
service shorewall restart
or shorewall restart
on the server.
If no messages in /var/log/messages on the server and hosts.allow and
hosts.deny are empty. I do not know what the problem is.
If all the above seems to be true, you will need to dump your settings
so we can see them. Run the commands on server and client.
Cut the command and results and paste them in your reply.
hostname
hostname -fqdn
hostname -i
cat /etc/hosts
grep -v \# /etc/hosts.allow
grep -v \# /etc/hosts.deny
ifconfig
If you see repeatable error messages in the tail -f terminals
every time you do the ssh command, we need to see those also.
Would not hurt to provide results from doing something like
ssh -v ***@servers_ip_here
or ssh -vv ***@servers_ip_here
or ssh -vvv ***@servers_ip_here
which will give increasing debug information with each v.
Take a look at each and decide which one might help us.
PS:
If you run with /etc/hosts.allow and hosts.deny, I found
it helpful for /etc/hosts.deny to contain
ALL: ALL:\
spawn ( \
/bin/echo -e "\n\
TCP Wrappers\: Connection Refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
\n\
User\: %u\n\
Host\: %c\n\
Date\: $(date)\n\
" | /bin/mail -s \"$(uname -n)\" root ) & : DENY
#*********************** end host.deny ********************************
That will send an email to root any time something gets through hosts.allow
without being allowed.
Example email follows:.
TCP Wrappers: Connection Refused
By: wm81.home.test
Process: sshd (pid 11046)
User: unknown
Host: localhost.localdomain
Date: Sun Aug 17 20:50:41 CDT 2008
I have postfix installed, so I modified aliases to send any mail
to root to me.
tail -11 /etc/postfix/aliases | head -5
# Person who should get root's mail. This alias
# must exist.
# CHANGE THIS LINE to an account of a HUMAN
root: bittwister
And executed:
postalias aliases
Once postfix is restarted, all mail to root (security alerts, cron job
failures, audit failures,...) automagically shows up in my email box.