Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I've been trying to figure this out for a few days and I'm stumped. I have two linux servers that run SSH as a service. One server is RHEL 4 and one is CentOS 4, so they should be pretty identical. Both have all updates applied via up2date. The problem that I'm having is that all clients can connect to the RHEL 4 server via SSH, but only a handful are able to connect to the CentOS 4 server.
When I attempt to connect with a client that fails to connect to CentOS, but can connect to RHEL, here is what I see on the client machine:
$ ssh -vvv xxx.xxx.xxx.xxx
OpenSSH_3.8.1p1 Debian-8.sarge.6, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to centos [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
*** at this point it freezes and does nothing
On the CentOS SSH server, I see the following entries in /var/log/secure:
May 18 11:22:41 centos sshd: debug3: fd 4 is not O_NONBLOCK
May 18 11:22:41 centos sshd: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7
May 18 11:22:41 centos sshd: debug1: Forked child 4896.
May 18 11:22:41 centos sshd: debug3: send_rexec_state: entering fd = 7 config len 502
May 18 11:22:41 centos sshd: debug3: ssh_msg_send: type 0
May 18 11:22:41 centos sshd: debug3: send_rexec_state: done
May 18 11:22:41 centos sshd: debug1: inetd sockets after dupping: 3, 3
May 18 11:22:41 centos sshd: Connection from ::ffff:xxx.xxx.xxx.xxx port 56266
May 18 11:22:41 centos sshd: Did not receive identification string from ::ffff:xxx.xxx.xxx.xxx
It seems like the client isn't sending an identification string, but if that is the case why doesn't the other SSH server complain? I'm at a loss. Any insight would be greatly appreciated.
Here is the sshd_config file just in case, but the RHEL 4 server that everyone is able to connec to uses the same config...
Subsystem sftp /usr/libexec/openssh/sftp-server
DenyUsers oracle nobody games mysql operator adm apache root mail
Not sure, but possible cause may be old entry of CentOS server in client's .ssh directory structure. Rename .ssh directory on client system. They try to connect to CentOS server again. It should recreate .ssh directory structure.
Also try to regenerate public key on CentOS server again.
Tell us if problem resolves or not. If not, post log messages if there is any change.
Still get the same error on both sides. I am thinking the line to think about is this one...
Did not receive identification string from ::ffff:xxx.xxx.xxx.xxx
So to me it seems like the machines are able to connect, it is just that the client isn't passing a version string or something similar. But why does this client connect to other SSH services without a problem...
If it helps...
Clients that CAN connect:
OS X 10.4.9 - OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006
RHEL 4 - OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
Cygwin - OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005
Red Hat 9 - OpenSSH_4.2p1, OpenSSL 0.9.7a Feb 19 2003
Clients that CANNOT connect:
Debian - OpenSSH_3.8.1p1 Debian-8.sarge.6, OpenSSL 0.9.7e 25 Oct 2004
Fedora 6 - OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
Red Hat 9 - OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
Red Hat 9 - OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
Thanks for the help so far, I'm hoping that someone will have bumped into this problem before and know what the heck is going on.
Well crap. Still having the same problem and the output looks the same from the client machine. The server logs have changed to reflect ipv6 being disabled. Here is a new snippet from /var/log/secure:
May 24 15:43:09 centos sshd: debug3: fd 4 is not O_NONBLOCK
May 24 15:43:09 centos sshd: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7
May 24 15:43:09 centos sshd: debug1: Forked child 4868.
May 24 15:43:09 centos sshd: debug3: send_rexec_state: entering fd = 7 config len 502
May 24 15:43:09 centos sshd: debug3: ssh_msg_send: type 0
May 24 15:43:09 centos sshd: debug3: send_rexec_state: done
May 24 15:43:09 centos sshd: debug1: inetd sockets after dupping: 3, 3
May 24 15:43:09 centos sshd: Connection from xxx.xxx.xxx.xxx port 40178
May 24 15:43:09 centos sshd: Did not receive identification string from xxx.xxx.xxx.xxx
And just in case it matters, I disabled ipv6 by adding the followings lines to /etc/modprobe.conf
it seems that the client has a problem with not finding any of the three possible identity files (identity, id_rsa, id_dsa). Do you have at least one of those in your ~/.ssh directory? (Not that it should matter if you want to do password auth only)
What does /etc/ssh/ssh_config (not sshd_config) look like on your client?
Thanks for the response Rupert. Here is my /etc/ssh/ssh_config:
$ cat /etc/ssh/ssh_config
# $OpenBSD: ssh_config,v 1.19 2003/08/13 08:46:31 markus Exp $
# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for various options
# Host *
# ForwardAgent no
# ForwardX11 no
# ForwardX11Trusted yes
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# EscapeChar ~
The ~/.ssh directory on the client that cannot connect didn't have id_rsa or id_dsa previously. In fact I had let the directory recreate itself earlier my removing it as suggested by an earlier poster. But, just to see what would happen, I copied my keys over from a machine that uses key authentication and IS able to connect to the funky ssh server. So, here is what the ~/.ssh directory looks like now for the client that can still not connect:
$ ls -alh .ssh
drwx------ 2 joe joe 4.0K May 30 04:49 .
drwxr-x--x 22 joe joe 4.0K May 24 12:40 ..
-rw------- 1 joe joe 1.5K Feb 28 12:24 authorized_keys
-rw------- 1 joe joe 668 May 30 04:49 id_dsa
-rw-r--r-- 1 joe joe 597 May 30 04:49 id_dsa.pub
-rw------- 1 joe joe 883 May 30 04:49 id_rsa
-rw-r--r-- 1 joe joe 217 May 30 04:49 id_rsa.pub
-rw------- 1 joe joe 479 May 17 05:31 known_hosts
The verbose output from trying to connect on the client side changed a little bit. Here is the new output when the keys are present:
Hmm, this is strange.
Can't really help you much, other than suggesting to
1. Setup to use only Protocol 2, not both 1 and 2. Just for the sake of limiting possible causes. (Do you actually still need ssh1? I haven't had that activated in years)
2. Copy settings in /etc/ssh/ssh_config from one of the working clients.
Sorry, but can't do much more than wish you good luck...
Did anyone ever have a solution to this? I know this thread was from sometime ago but I am having a similar problem with a couple of Xen VMs that I am running. I have a small cluster that has the Xen hypervisor running on Scientific Linux 5 on the worker nodes. I can ssh from the VMs to the external network and I can ssh from the both the host and the head node to the VMs. But for some reason when I try to ssh between the VMs (which are running on the same host) I am encountering the same problem as was described above in this thread.
[root@gxn-vwn2 ~]# ssh -v 192.168.17.100
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.17.100 [192.168.17.100] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
And then it just hangs here...
If anyone has any insight it would be appreciated. Thanks.
I was never able to figure out what was going on. I ended up installing White Box Linux on the problem machine and everything works fine now. Same SSH config and all. I know that doesn't help you too much, but if you do solve the problem I would be very interested to hear what the solution is.