Hi guys,

I'm not a linux guru by any means, so please excuse my novice terminology.

Here is a rundown of some servers i have at my disposal:

NEC1 - 10.10.10.100
NEC2 - 10.10.10.101
Dell - 10.10.10.102
DB - 10.10.10.22
FYI, 10.10.10.x is a private network with no DHCP (all IPs are statically assigned).

NEC1, NEC2, and Dell are fresh installs of RedHat EL4 ES Update4. When I installed NEC1, it was sitting on another DHCP-enabled LAN (10.1.127.x). After RH was installed, I was able to SSH, SCP, and ping to and from other servers without any issues. Then I brought NEC1 over to the private LAN (10.10.10.x). I changed my "/etc/sysconfig/network-scripts/ifcfg-eth0" file from:

DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=xx:xx:xx:xx:xx:xx
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes

to

DEVICE=eth0
BOOTPROTO=none
BROADCAST=10.10.10.255
HWADDR=xx:xx:xx:xx:xx:xx
IPADDR=10.10.10.101
NETMASK=255.255.255.0
NETWORK=10.10.10.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes

I used the "/etc/sysconfig/network-scripts/ifcfg-eth0" file from the DB server as a template. The DB server has been up on the network for a while, and I have not had any difficulties with it before. Thus, I assume its good and used its ifc-cfg-eth0 file for a template.

After I changed the ifcfg-eth0 file from NEC1, I did a "service network restart". NEC1 can ping DB, and DB can ping NEC1. NEC1 cannot SSH to DB, but DB can SSH into NEC1. After a long delay, the following is the error msg I get when I try to SSH from NEC1 to DB:

ssh_exchange_identification: read: Connection reset by peer

When I installed RH, I disabled the firewall. I still checked to see if it was up, by running "service iptables status". It returms "Firewall is stopped".

I googled the error msg, but I wasn't able to make much of it. I thought maybe I screwed up something with the networking, so I brought up NEC2. I installed RH on that box, and it never touched the 10.1.127.x network. As soon as the OS was installed, I stuck a static IP on him, but it everything was exactly the same as NEC1.

Then I remembered that I had installed RH EL4 ES Update4 on the Dell server the day before. This server was installed on the DHCP-enabled 10.1.127.x network. Everything has been working normally. I changed him over to the 10.10.10.x network. I had expected it to also have problems SSH'ing to other server, but I was wrong. The Dell server actually worked fine. Apparently, there is something different between Dell and NEC1/NEC2, but I just don't know what it is.

So to summarize, here is what's going on:

1. NEC1, NEC2, and Dell all have a fresh install of RH EL4 ES Update4
2. All three servers have statically assigned IPs on a private network
3. NEC1 and NEC2 have network connectivity, but they cannot SSH to other servers. Dell works fine.

I'm trying to figure out why NEC1/NEC2 cannot SSH out. I'm pretty much stumped. Has anyone ever encountered an issue like this before? Can someone give me some suggestions on how I should proceed here? Thanx fellas

Check the contents and permissions of the .ssh/ directory in your home directory on NEC1 and NEC2 against that on your Dell. If I've read your post correctly then you have already proved that the SSH server is OK, and that the network connectivity between clients and server is fine (with ping tests).

hello hob,

thanx for the suggestions. i just checked the permissions of the .ssh dir between NEC1/NEC2 and Dell, and everything looks pretty much the same.

here is something kind of strange. someone suggested to me that i check "/etc/ssh_config" and only enabled protocol 2. i did this and it did not have any affect on my troubles. afterwards, i reverted my ssh_config file back to default settings.

however, if i go to any server that NEC1/NEC2 could not ssh to (ie - DB) and edit "/etc/sshd_config" to only use protocol 2, then i am able to ssh in from NEC/NEC2. this is really strange to me, becuz i dont understand how this is a server side issue. but... it works, so i am mixed between joy and befuddlement.

basically, here are the steps that i took:

1. in any server that i am failing to ssh into (from NEC1/NEC2), edit "/etc/sshd_config" to only use protocol 2
2. restart sshd

something else that i dont understand... if i leave "/etc/sshd_config" as default on the server side, if i want to force protocol 2 from the client side, i should be able to do so with "ssh -2 10.10.10.22" (ssh to DB). but when i run this command, it still fails (same problem as in the original post). so right now, the only way i know how to get around this issue is to only enable protocol 2 support on the server side. does this sound normal?

No, it sounds like the SSH server is running an old version of SSH. Version 2 of the SSH protocol has been the standard and default with OpenSSH clients and servers for several years now. Version 1 of the SSH protocol had known security weaknesses, and is very much deprecated.

i just verified on all servers mentioned in this thread (NEC1, NEC2, Dell, and DB) are running the same version of OpenSSH. when i run "ssh -V", it returns the following:
"OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003"


my default /etc/ssh/sshd_config file lookse like this:
# $OpenBSD: sshd_config,v 1.69 2004/05/23 23:59:53 dtucker Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#ShowPatchLevel no

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server


so be default, both verion 1 and 2 of the ssh protocol are enabled, correct?

Yes.

If you haven't already, try using the "-vvv" option with the ssh client. This lets you see every stage of the SSH login process, which may make it clear at which point the logins fail.

What was the error you encountered? To check if it remote server accepts it. try this steps
1. do the ssh connection from the client side
2. on the remote ssh server, do tcpdump, check if there are packets traversing on port 22.

oh by the way, flush first the firewall it may have a default firewall. iptables -F to flush.

Have you set a gateway for NEC1 ?

It doesn't look like it going by what you have posted in /etc/sysconfig/networking/devices/ifcg-eth0.

Also have you checked hosts.allow and hosts.deny for the appropiate entries for NEC1

I apologize for (temporarily) highjacking your thread, honesthank, but I just can't reach some information.

Hi sandgroper.

Your link http://203.59.24.225/~steveray/linux/kpppconfig.txt

from your post http://www.linuxquestions.org/questi...16&postcount=9 seems dead. Is your HowTo still available?

I need it for this: http://www.linuxquestions.org/questi...40#post2891540

Hi JZL240I-U
Yes my Howto is still available , that is a fairly old link using a IP address and my ISP have moved/reorganised their servers around.

Try this link.

http://members.iinet.net.au/~stevera...kpppconfig.txt

Thank you for the fast response. Link works and content already printed. Stupid mode sadly not mentioned either, though .

Thanks everybody for your patience during my intrusion.