Both servers are running on RedHat 7.2

This is the output I rcvd from /usr/sbin/sshd -ddd from Host-A

debug1: Seeding random number generator
debug1: sshd version OpenSSH_2.9p2
debug1: private host key: #0 type 0 RSA1
debug3: No RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug3: No RSA1 key file /etc/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
socket: Address family not supported by protocol
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
Cannot bind any address.

Couldn't make out of it too.
It seems like I got the same thing from this other Linux 8 machine over here.

I believe you already had a ssh server running on that port. You'll need to kill it in order to free up the port.

Looking back through this thread, did you ever add this rule to host B's firewall:

-A output -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT

I've been assuming you had tried it, but it does give an error mesage similar to the one you're getting.

On host B, there's no such entry in the iptables:
-A output -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT

That was just my assumption that perhaps that line should be added.
I am not familiar with iptables configuration.
"output" indicates output package according to the man page.

In fact on both servers, there's this entry in iptables:
-A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT

By the /sbin/iptables -L on host-B
target prot opt source destination ports
ACCEPT udp ------ <ip host B> anywhere domain -> any
ACCEPT tcp -y---- anywhere anywhere any -> https
ACCEPT tcp -y---- anywhere anywhere any -> ssh
ACCEPT tcp -y---- anywhere anywhere any -> http
ACCEPT all ------ anywhere anywhere n/a
REJECT tcp -y---- anywhere anywhere any -> 0:1023
REJECT tcp -y---- anywhere anywhere any -> nfs
REJECT udp ------ anywhere anywhere any -> 0:1023
REJECT udp ------ anywhere anywhere any -> nfs
REJECT tcp -y---- anywhere anywhere any -> x11:6009
REJECT tcp -y---- anywhere anywhere any -> xfs
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):

Never tried adding the "output" entry.

Is ssh not multithreaded, is there really a need to kill it and free up the port?

The INPUT rule for ssh seems to accept only SYN packet. nothing else

try changing the ssh rule to

/sbin/iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT -m state --state NEW,RELATED,ESTABLISHED

Dear ppuru

With both iptables only allowing SYN packet:
host_A managed to ssh login to host_B, however not the other way round.
I need to propose to the system administrator to change the iptables with justification.

Please assist & enlighten me.

Can you please post the output of

#/sbin/iptables -nvL

from both the systems

By running /sbin/iptable -nvL
host A:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination


Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination


Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination

By running /sbin/iptables -L:
host B:
ACCEPT udp ------ <ip host B> anywhere domain -> any
ACCEPT tcp -y---- anywhere anywhere any -> https
ACCEPT tcp -y---- anywhere anywhere any -> ssh
ACCEPT tcp -y---- anywhere anywhere any -> http
ACCEPT all ------ anywhere anywhere n/a
REJECT tcp -y---- anywhere anywhere any -> 0:1023
REJECT tcp -y---- anywhere anywhere any -> nfs
REJECT udp ------ anywhere anywhere any -> 0:1023
REJECT udp ------ anywhere anywhere any -> nfs
REJECT tcp -y---- anywhere anywhere any -> x11:6009
REJECT tcp -y---- anywhere anywhere any -> xfs
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):

PS: apologize, not able to run -nvL on host B yet. Would the above be enough?

There are no iptables rules on Host A. And that is the reason why you encountered no problems connecting to Host A's sshd daemon.

Host B on the other hand has firewall rules and is accepting only SYN packets.

Can you throw more light on host B's rule

ACCEPT all ------ anywhere anywhere n/a

Is this the rule for loopback adapter (lo)?

1) Host B has got firewall to accept only SYN packet from port 22.
That explains why host A managed to ssh login to host B successfully?

2) Host A has got nothing.
Wouldn't host B be able to ssh login to host A since host A has got no rules on its firewall?

Msg: Connection time out & secure connection refused
was acquired while attempting to ssh login to host A from host B.

3) Both servers has got this entry when I look in /etc/sysconfig/iptables:
A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT
Does it mean that both servers accept SYN packet from port 22?

4) If that entry from host B does mean loopback adapter for loopback testing, will it affect the ssh authentication in anyways?

Please enlighten me on this, apologize if I am being too inquisitive.

You will have to do away with the SYN flag.

The rule

ACCEPT tcp -y---- anywhere anywhere any -> ssh

will accept only the first packet and drop the rest ( someone correct me if I am wrong ).
So, even though the sshd daemon responds, the rest of the packets from the client will be dropped by your firewall rules.

Start

#/usr/sbin/tcpdump port 22

on a different terminal window on Host B and try connecting to ssh from host A.

You can use tcpwrappers to ensure that only host A can connect to host B and vice versa... that is, if that is your plan.

B will accept only SYN packets so it will drop the other packets.

please run

#iptables -nvL

to clarify this. If it a rule for the loopback adapter, it indeed won't affect connections originating outside your box.

While attempting to ssh login to host A from host B:

OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: getuid 97 geteuid 0 anon 1
debug1: Connecting to host_A [ip_address] port 22.
debug1: connect: Connection timed out
debug1: Trying again...
debug1: Connecting to host_A [ip_address] port 22.
debug1: connect: Connection timed out
debug1: Trying again...
debug1: Connecting to host_A [ip_address] port 22.

I think I have a problem getting host A's sshd daemon to response?

Will get the iptables -nvL once I manage to talk to administrator. Thank You

can you

#service sshd status

OR

#ps -C sshd

on Host A to ensure sshd is indeed running ...

Confirmed sshd is running ..with a PID

EDIT
from var/log/messages on host A
Jun 21 12:25:37 host A sshd: sshd -TERM succeeded
Jun 21 12:29:34 host A sshd: Starting sshd:
Jun 21 12:29:35 host A sshd: succeeded
Jun 21 12:29:35 host A sshd:
Jun 21 12:29:35 host A rc: Starting sshd: succeeded
Jun 22 08:56:17 host A sshd: sshd -TERM succeeded
Jun 22 09:00:16 host A sshd: Starting sshd:
Jun 22 09:00:16 host A sshd: succeeded
Jun 22 09:00:16 host A sshd:
Jun 22 09:00:16 host A rc: Starting sshd: succeeded

Hi capt_caveman & all:

Need your advice on SSH. I have 2 Linux boxes here, A is with OpenSSH-4.0p1; B is with OpenSSH-3.6.1p2. I am trying to setup a passwordless ssh login between these 2. These are the steps:
- ssh-keygen -t dsa on both servers
- exchanging id_dsa.pub; appending the key to authorized_keys2 of the other server.

I managed to ssh login without being prompted for password from A to B;
however it keeps prompting me for password if I were to do it from B to A.

Attached are the printout of attempt to ssh login from B to A:
From ServerB
sh-2.05b$ ssh -vvv <serverA> date
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to <serverA> [10.10.10.5] port 22.
debug1: Connection established.
debug1: identity file /usr/user/.ssh/identity type -1
debug1: identity file /usr/user/.ssh/id_rsa type -1
debug3: Not a RSA1 key file /usr/user/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /usr/user/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.0
debug1: match: OpenSSH_4.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 133/256
debug2: bits set: 1010/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /usr/cosmos/COS_4.2/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /usr/cosmos/COS_4.2/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host '<serverA>' is known and matches the RSA host key.
debug1: Found key in /usr/user/.ssh/known_hosts:1
debug2: bits set: 1044/2048
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /usr/user/.ssh/identity
debug3: no such identity: /usr/user/.ssh/identity
debug1: Trying private key: /usr/user/.ssh/id_rsa
debug3: no such identity: /usr/user/.ssh/id_rsa
debug1: Offering public key: /usr/user/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
user@serverA's password:

Any ideas what gone wrong?
Any advices would be greatly appreciated.