Find the answer to your Linux question:
Results 1 to 8 of 8
Hello, recently i've had troubles connecting via SSH to of my servers, the error output is very weird, [root@server1 ~]# ssh server2.name.com Rejected Connection to server2.name.com closed. I can connect ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Sep 2007
    Posts
    24

    SSH connection problem, Rejected


    Hello, recently i've had troubles connecting via SSH to of my servers, the error output is very weird,

    [root@server1 ~]# ssh server2.name.com
    Rejected
    Connection to server2.name.com closed.

    I can connect server1 to others of my servers and can't to others ones and i receive the same error, there are not wrappers on them, the ping is great between them, and i cant do a scp o sftp neither,however i can successfully telnet the port 22 of the target host;

    [root@server1 tmp]# telnet server2 22
    Trying xx.xx.xx.xx....
    Connected to server2.com (xx.xx.xx.xx).
    Escape character is '^]'.
    SSH-1.99-OpenSSH_3.6.1p2

    The sshd_config is for default there are not configs on it.

    Any clue will be very very helpfully , and sorry for the continous problems

    Best Regards!

  2. #2
    Linux Guru smolloy's Avatar
    Join Date
    Apr 2005
    Location
    CA, but from N.Ireland
    Posts
    2,414
    You say there are not wrappers on the server, so does that mean that this definitely isn't related to /etc/hosts.deny or /etc/hosts.allow?

    Are you using a key (and are you sure you're using the right one?)?
    Registered Linux user #388328 || Registered LFS user #15880
    AMD 64 X2 4600+ :: 2X1GB DDR2 800 :: GeForce 9400 GT 512MB :: ASUS M2N32 Deluxe :: 4X250GB SATAII
    Need instant help? Try us on IRC -- #linuxforums on freenode

  3. #3
    Just Joined!
    Join Date
    Sep 2007
    Posts
    24
    Hello smolloy thankls for your quickly answer, exactly,not wrappers on the server means the /etc/hosts.allow/deny are empty

    Im not specifing any key at the moment to do the connection, anyway i entered into the known_hosts file of the conflict server and i erased the server1 key .

    But i think the problem could be a key problem because to any server i can connect they request me to do a new key.

    Hope helps for the solution!.

    Regards!

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru anomie's Avatar
    Join Date
    Mar 2005
    Location
    Texas
    Posts
    1,692
    Short answer is: could be a number of things based on the limited info provided so far. The tcp port is obviously open to you, per your telnet test. It sounds like tcp_wrappers is also not the problem, as you say there are no rules.

    ssh -vvv user@hosts

    If you post the results of that, we may be able to isolate what is happening.

    -------------

    One a whole separate tangent, you should consider disabling SSH protocol 1 on that sshd server. There are known exploits.

  6. #5
    Just Joined!
    Join Date
    Sep 2007
    Posts
    24
    Hello anomie, thanks for your help like always; here are the output of the command;

    [root@stinger ~]# ssh -vvv root@server2.com
    OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to stats.server2.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
    debug3: Not a RSA1 key file /root/.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 /root/.ssh/id_dsa type 2
    debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p2
    debug1: match: OpenSSH_3.6.1p2 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_3.9p1
    debug2: fd 3 setting O_NONBLOCK
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    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: 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: 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(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug2: dh_gen_key: priv key bits set: 137/256
    debug2: bits set: 532/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 15
    debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 15
    debug1: Host 'server2.com' is known and matches the RSA host key.
    debug1: Found key in /root/.ssh/known_hosts:15
    debug2: bits set: 511/1024
    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
    debug2: key: /root/.ssh/identity ((nil))
    debug2: key: /root/.ssh/id_rsa ((nil))
    debug2: key: /root/.ssh/id_dsa (0x8e0711
    debug1: Authentications that can continue: publickey,password,keyboard-interactive
    debug3: start over, passed a different list publickey,password,keyboard-interactive
    debug3: preferred gssapi-with-mic,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: /root/.ssh/identity
    debug3: no such identity: /root/.ssh/identity
    debug1: Trying private key: /root/.ssh/id_rsa
    debug3: no such identity: /root/.ssh/id_rsa
    debug1: Offering public key: /root/.ssh/id_dsa
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Remote: Forced command: /root/scripts/validate-rsync
    debug1: Server accepts key: pkalg ssh-dss blen 433
    debug2: input_userauth_pk_ok: fp ca:9d:17:7e:72:f7:51:04:14:32:b9:ed:4e:11:06:30
    debug3: sign_and_send_pubkey
    debug1: read PEM private key done: type DSA
    debug1: Remote: Forced command: /root/scripts/validate-rsync
    debug1: Authentication succeeded (publickey).
    debug1: channel 0: new [client-session]
    debug3: ssh_session2_open: channel_new: 0
    debug2: channel 0: send open
    debug1: Entering interactive session.
    debug2: callback start
    debug2: client_session2_setup: id 0
    debug2: channel 0: request pty-req confirm 0
    debug3: tty_make_modes: ospeed 38400
    debug3: tty_make_modes: ispeed 38400
    debug3: tty_make_modes: 1 3
    debug3: tty_make_modes: 2 28
    debug3: tty_make_modes: 3 127
    debug3: tty_make_modes: 4 21
    debug3: tty_make_modes: 5 4
    debug3: tty_make_modes: 6 0
    debug3: tty_make_modes: 7 0
    debug3: tty_make_modes: 8 17
    debug3: tty_make_modes: 9 19
    debug3: tty_make_modes: 10 26
    debug3: tty_make_modes: 12 18
    debug3: tty_make_modes: 13 23
    debug3: tty_make_modes: 14 22
    debug3: tty_make_modes: 18 15
    debug3: tty_make_modes: 30 0
    debug3: tty_make_modes: 31 0
    debug3: tty_make_modes: 32 0
    debug3: tty_make_modes: 33 0
    debug3: tty_make_modes: 34 0
    debug3: tty_make_modes: 35 0
    debug3: tty_make_modes: 36 1
    debug3: tty_make_modes: 37 0
    debug3: tty_make_modes: 38 1
    debug3: tty_make_modes: 39 0
    debug3: tty_make_modes: 40 0
    debug3: tty_make_modes: 41 0
    debug3: tty_make_modes: 50 1
    debug3: tty_make_modes: 51 1
    debug3: tty_make_modes: 52 0
    debug3: tty_make_modes: 53 1
    debug3: tty_make_modes: 54 1
    debug3: tty_make_modes: 55 1
    debug3: tty_make_modes: 56 0
    debug3: tty_make_modes: 57 0
    debug3: tty_make_modes: 58 0
    debug3: tty_make_modes: 59 1
    debug3: tty_make_modes: 60 1
    debug3: tty_make_modes: 61 1
    debug3: tty_make_modes: 62 0
    debug3: tty_make_modes: 70 1
    debug3: tty_make_modes: 71 0
    debug3: tty_make_modes: 72 1
    debug3: tty_make_modes: 73 0
    debug3: tty_make_modes: 74 0
    debug3: tty_make_modes: 75 0
    debug3: tty_make_modes: 90 1
    debug3: tty_make_modes: 91 1
    debug3: tty_make_modes: 92 0
    debug3: tty_make_modes: 93 0
    debug2: channel 0: request shell confirm 0
    debug2: fd 3 setting TCP_NODELAY
    debug2: callback done
    debug2: channel 0: open confirm rwindow 0 rmax 32768
    debug2: channel 0: rcvd adjust 131072
    Rejected
    debug2: channel 0: rcvd eof
    debug2: channel 0: output open -> drain
    debug2: channel 0: obuf empty
    debug2: channel 0: close_write
    debug2: channel 0: output drain -> closed
    debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
    debug2: channel 0: rcvd close
    debug2: channel 0: close_read
    debug2: channel 0: input open -> closed
    debug3: channel 0: will not send data after close
    debug2: channel 0: almost dead
    debug2: channel 0: gc: notify user
    debug2: channel 0: gc: user detached
    debug2: channel 0: send close
    debug2: channel 0: is dead
    debug2: channel 0: garbage collecting
    debug1: channel 0: free: client-session, nchannels 1
    debug3: channel 0: status: The following connections are open:
    #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

    debug3: channel 0: close_fds r -1 w -1 e 6 c -1
    Connection to server2.com closed.
    debug1: Transferred: stdin 0, stdout 0, stderr 40 bytes in 0.0 seconds
    debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 1008.7
    debug1: Exit status 0

  7. #6
    Linux Guru anomie's Avatar
    Join Date
    Mar 2005
    Location
    Texas
    Posts
    1,692
    While I'm looking through this could you explain what /root/scripts/validate-rsync is? I'm trying to figure out how it fits in. (Is it run automatically via root's .profile/.bash_profile or something?)

  8. #7
    Linux Guru anomie's Avatar
    Join Date
    Mar 2005
    Location
    Texas
    Posts
    1,692
    Aha, one more thing. Can you get console access to server2 and see if PermitRootLogin is set to anything in particular (e.g. forced-commands-only) in /etc/ssh/sshd_config?

  9. #8
    Just Joined!
    Join Date
    Sep 2007
    Posts
    24
    Hello anomei, sorry for the delay of the answer, your help was very very helpfully!

    Yes the problem was in this scripts, was a script the rsync directly in a ssh connection like it shows here;

    https://people.chem.umass.edu/wiki/i...utomated_Login

    Is solved thanks again for your cooperation! (y)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •