LinuxQuestions.org - unable to ssh remote server (firewall turn off)

- Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)

- - unable to ssh remote server (firewall turn off) (https://www.linuxquestions.org/questions/linux-server-73/unable-to-ssh-remote-server-firewall-turn-off-888563/)

unable to ssh remote server (firewall turn off)

i m unable to ssh my one centos 5.6 remote server from my one server

plz check below output

Code:

ssh -v root@sxyz.abc.com

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Applying options for *

debug1: Connecting to xxx.abc.com [xx.xx.xx.xx] 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

debug1: loaded 3 keys

i even turn off all firewall rules on both server

i can able to ssh from my home or any other pc to remote pc so i don't think there is any problem in target pc

Normally, after "loaded 3 keys", you should have something like :

Code:

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3

debug1: match: OpenSSH_4.3 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

[...]

i.e., it is the beginning of the dialog between the local machine and the remote machine.

In order to have more information, you could, for example, increase the level of verbosity in for remote ssh daemon.

Another solution for having more information, but this time on the client side, is to catch all systems calls launched during the execution of the ssh command :

Code:

strace ssh -v remoteuser@remotehost &>/tmp/ssh.out

If, after this command, your terminal gets unusable (it often happens after this kind os test), it' not a problem. Type blindly the reset command :

Code:

reset

File /tmp/ssh.out could give you some hints about the problem.

On my system, thanks to strace, I see what happens after the "debug1: loaded 3 keys" message :
- loading of local file /etc/passwd
- reading of the line of root in the local file /etc/passwd
- reading of the SSHD banner sent by the remote machine ; here : SSH-2.0-OpenSSH_4.3
- ...

Code:

ssh -vvvvvvv root@1.1.1.1

post that output.

Is the ssh server daemon running on the target computer?

Quote:

Originally Posted by szboardstretcher (Post 4397169)

Code:

ssh -vvvvvvv root@1.1.1.1

post that output.

Code:

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Applying options for *

debug2: ssh_connect: needpriv 0

debug1: Connecting to abc.xyz.com [xx.xx.xx.xxx] port 22.

debug1: Connection established.

debug1: permanently_set_uid: 0/0

debug1: identity file /root/.ssh/identity type -1

debug3: Not a RSA1 key file /root/.ssh/id_rsa.

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

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

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 /root/.ssh/id_rsa type 1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: loaded 3 keys

Quote:

Originally Posted by frankbell (Post 4397506)

Is the ssh server daemon running on the target computer?

yes it's running. i m able to connect from other pc

Quote:

Originally Posted by szboardstretcher (Post 4397169)

Code:

ssh -vvvvvvv root@1.1.1.1

post that output.

There are only 3 debug levels, anything above the third v will get ignored.

ankitsagwekar

It looks like an issue with the root rsa key in the client PC. try to log in with a different user to your client PC and then ssh root@abc.xyz.com

ankitsagwekar, this is slightly off topic of the question you are asking, you might want to have a look at this thread: http://www.linuxquestions.org/questi...erences-45261/ At the bottom, in post 7, there are several links and tips on how to properly secure your SSH server once you have it running.

Quote:

Originally Posted by manyrootsofallevil (Post 4397678)

i try from different user still same result

Quote:

Originally Posted by Noway2 (Post 4397789)

i don't want to secure my server. my problem is i m not able to ssh to remote server from one specific client ssh from rest of the pc is working fine

The debug messages below

Quote:

Originally Posted by ankitsagwekar (Post 4397628)

Code:

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

[...]

debug3: key_read: missing whitespace

debug2: key_type_from_name: unknown key type '-----END'

debug3: key_read: missing keytype

debug1: identity file /root/.ssh/id_rsa type 1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: loaded 3 keys

are exactly identical to the messages one can get when successfully connecting to a CentOS server from a user root having a /root/.ssh/id_rsa file (generated with ssh-keygen). So, at least on the client side, these debug messages give no additional hints.

If the problem is on the local machine, strace may give some hints.
If the problem is between the local machine and the distant machine, tcpdump on either side may give some hints.

Hi Ankit, I'll suggest to check /etc/hosts.deny and /etc/hosts.allow from remote server and also check you /var/log/secure.