LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 05-26-2015, 10:10 PM   #1
brukuo
LQ Newbie
 
Registered: Mar 2015
Location: Singapore
Posts: 10

Rep: Reputation: Disabled
SSH login to server always fail upon first attempt


Noticed recently that my first SSH attempt (using putty) to a Red Hat server always fail. Must leave the failed session on, then the second SSH attempt will succeed. If I close the failed ssh session, the second attempt will also fail as well.

This issue only cropped up about two weeks ago and it also happens to other users for this RHEL server only. I am using putty(release 0.64) but other users are connecting to it via command line SSH in their Linux desktop. Not aware of any changes done to this RHEL server recently.

Any suggestions on where should I start looking into?
 
Old 05-27-2015, 02:47 PM   #2
ButterflyMelissa
Senior Member
 
Registered: Nov 2007
Location: Somewhere on my hard drive...
Distribution: Manjaro
Posts: 2,686
Blog Entries: 23

Rep: Reputation: 398Reputation: 398Reputation: 398Reputation: 398
Quote:
Any suggestions on where should I start looking into?
Rootkit on the server? This smells like a fake login screen to capture a password, store it and then hand the control over to the real login screen...
But, that's my paranoia
Thor
 
Old 05-27-2015, 06:14 PM   #3
joe_2000
Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 808

Rep: Reputation: 216Reputation: 216Reputation: 216
Quote:
Originally Posted by brukuo View Post

Any suggestions on where should I start looking into?
I'd check the system logs to see whether both attempts are seen by the ssh server and if any useful information is provided regarding the failed attempt. I am not familiar with how Redhat does it... Debian systems will typically put this into /var/log/auth.log
 
Old 05-27-2015, 06:32 PM   #4
suicidaleggroll
LQ Guru
 
Registered: Nov 2010
Location: Colorado
Distribution: OpenSUSE, CentOS
Posts: 5,260

Rep: Reputation: 1948Reputation: 1948Reputation: 1948Reputation: 1948Reputation: 1948Reputation: 1948Reputation: 1948Reputation: 1948Reputation: 1948Reputation: 1948Reputation: 1948
Quote:
Originally Posted by brukuo View Post
Noticed recently that my first SSH attempt (using putty) to a Red Hat server always fail. Must leave the failed session on, then the second SSH attempt will succeed. If I close the failed ssh session, the second attempt will also fail as well.
I don't follow. What do you mean "leave the failed session on"? If the ssh connection fails, then it never connected, so it's not "on". What kind of messages are you actually seeing?
 
Old 05-27-2015, 09:23 PM   #5
brukuo
LQ Newbie
 
Registered: Mar 2015
Location: Singapore
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by suicidaleggroll View Post
I don't follow. What do you mean "leave the failed session on"? If the ssh connection fails, then it never connected, so it's not "on". What kind of messages are you actually seeing?
I would open a first SSH session (via putty) to connect to the server. Then this first session would just hang there, and later time-out with the error message "Network error. Software caused connection abort". But I would not close this first session which failed, and open a duplicate session to SSH to the server again. The duplicate session would then connect successfully to the server, showing a login prompt. I doubt this issue is caused by Putty, as I could connect via SSH to other servers without any issue.
 
Old 05-28-2015, 03:59 AM   #6
Tim Abracadabra
Member
 
Registered: May 2014
Location: USA, Wherever I may Roam
Distribution: Debian w/Xfce, LFS 7.9, ++
Posts: 117

Rep: Reputation: Disabled
Seems like the Server and network connectivity to it are the common element, as
you mentioned other users on Linux systems are also having errors to this server.

Are these internet and/or wireless connections?
Maybe try enabling keepalives in the PuTTY Connections configuration.

Also, try using the -vvv debug option on the first attempted SSH session and paste the output here(In code tags please).
Maybe that will provide a clue.

Hope that helps,
Tim
 
Old 05-28-2015, 04:27 AM   #7
brukuo
LQ Newbie
 
Registered: Mar 2015
Location: Singapore
Posts: 10

Original Poster
Rep: Reputation: Disabled
Below is the screenshot when I tried to connect via ssh from my client PC to the server:

[2015-05-28 16:23.50] ~
[opsuser.MSS11001290] ➤ ssh -vvv bkuo@192.168.4.67
OpenSSH_6.7p1, OpenSSL 1.0.1g 7 Apr 2014
debug1: Reading configuration data /etc/ssh_config
debug3: macs ok: [hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hm ac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,umac-64-etm@op enssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-e tm@openssh.com,hmac-md5-etm@openssh....tm@openssh.com,hmac-ripemd160 -etm@openssh.com,hmac-sha1-96-etm@op...tm@openssh.com,hmac-r ipemd160@openssh.com]
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.4.67 [192.168.4.67] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7
ssh_exchange_identification: read: Connection reset by peer

──────────────────────────────────────────────────────────────────────────────────────────────────── ───────────────────────────────────────────────────────────────────────────────
[2015-05-28 16:25.18] ~
[opsuser.MSS11001290] ➤

Thank you.
 
Old 05-28-2015, 04:32 AM   #8
brukuo
LQ Newbie
 
Registered: Mar 2015
Location: Singapore
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Tim Abracadabra View Post
Seems like the Server and network connectivity to it are the common element, as
you mentioned other users on Linux systems are also having errors to this server.

Are these internet and/or wireless connections?
Maybe try enabling keepalives in the PuTTY Connections configuration.

Also, try using the -vvv debug option on the first attempted SSH session and paste the output here(In code tags please).
Maybe that will provide a clue.

Hope that helps,
Tim
The connections are via wired lan (no Internet, no wireless), and the clients and the servers are within the Intranet of 192.168.X.Y, where clients are in the 192.168.40 segments and the server is in the 192.168.4 segment. Firewall exist within these two segments but port 22 has already been opened between these two intranet segments. Thanks!
 
Old 05-28-2015, 04:51 AM   #9
brukuo
LQ Newbie
 
Registered: Mar 2015
Location: Singapore
Posts: 10

Original Poster
Rep: Reputation: Disabled
This is using the same client to connect via SSH to another server, and is successful:

[opsuser.MSS11001290] ssh -vvv bkuo@192.168.4.85
OpenSSH_6.7p1, OpenSSL 1.0.1g 7 Apr 2014
debug1: Reading configuration data /etc/ssh_config
debug3: macs ok: [hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-ripemd160@openssh.com]
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.4.85 [192.168.4.85] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mobaxterm/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa...01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,arcfour,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,arcfour,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-ripemd160@openssh.com
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-ripemd160@openssh.com
debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none
debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none
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-sha256,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com
debug2: mac_setup: setup hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1578/3072
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 84:b4:53:6a:42:0c:e8:c4:cc:66:63:7e:22:ba:0c:7f
debug3: load_hostkeys: loading entries for host "192.168.4.85" from file "/home/mobaxterm/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/mobaxterm/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.4.85' is known and matches the RSA host key.
debug1: Found key in /home/mobaxterm/.ssh/known_hosts:1
debug2: bits set: 1516/3072
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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/mobaxterm/.ssh/id_rsa (0x0),
debug2: key: /home/mobaxterm/.ssh/id_dsa (0x0),
debug2: key: /home/mobaxterm/.ssh/id_ecdsa (0x0),
debug2: key: /home/mobaxterm/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred hostbased,publickey,password,keyboard-interactive
debug3: authmethod_lookup publickey
debug3: remaining preferred: password,keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/mobaxterm/.ssh/id_rsa
debug3: no such identity: /home/mobaxterm/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/mobaxterm/.ssh/id_dsa
debug3: no such identity: /home/mobaxterm/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/mobaxterm/.ssh/id_ecdsa
debug3: no such identity: /home/mobaxterm/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/mobaxterm/.ssh/id_ed25519
debug3: no such identity: /home/mobaxterm/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
debug2: we sent a password packet, wait for reply
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (password).
Authenticated to 192.168.4.85 ([192.168.4.85]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /bin/xauth list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: X11 forwarding request accepted on channel 0
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Thu May 28 01:25:35 2015 from 192.168.4.1
bkuo@helios:~>

Thank you.
 
Old 05-28-2015, 11:28 PM   #10
RMLinux
Member
 
Registered: Jul 2006
Posts: 260

Rep: Reputation: 37
http://superuser.com/questions/29482...nnection-abort

try also connection "0".
 
Old 06-01-2015, 09:34 PM   #11
brukuo
LQ Newbie
 
Registered: Mar 2015
Location: Singapore
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by RMLinux View Post
Thank you for your suggestion but I am having issue getting the first connection (via ssh) to the server. The connection does not drop after connected to the server. I could only connect to the server on the second attempt, but must leave the first failed session on.
 
Old 06-02-2015, 01:46 PM   #12
Sefyir
Member
 
Registered: Mar 2015
Distribution: Linux Mint
Posts: 394

Rep: Reputation: 161Reputation: 161
I'm not sure why the first wouldn't work but the second would but the delay sounds like a DNS lookup timeout.
If you have a tight firewall (just port 22 for ssh) it may not allow a DNS check on another port (I don't remember which)
If you put this in the sshd_config it may fix the problem (it's supposedly fairly useless anyways)
Code:
UseDNS no

Last edited by Sefyir; 06-02-2015 at 01:49 PM.
 
Old 06-02-2015, 08:49 PM   #13
brukuo
LQ Newbie
 
Registered: Mar 2015
Location: Singapore
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Sefyir View Post
I'm not sure why the first wouldn't work but the second would but the delay sounds like a DNS lookup timeout.
If you have a tight firewall (just port 22 for ssh) it may not allow a DNS check on another port (I don't remember which)
If you put this in the sshd_config it may fix the problem (it's supposedly fairly useless anyways)
Code:
UseDNS no
The "UseDNS" has already been configured to 'No' in the <sshd_config> file.

See below for the server's <sshd_config> file content:
# $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $

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

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

# 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
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# 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 1024

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

# Authentication:

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

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedKeysCommand none
#AuthorizedKeysCommandRunAs nobody

# 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 no
#PermitEmptyPasswords no

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

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
#GSSAPIEnableMITMAttack no


# 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 and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

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

# no default banner path
#Banner none

# override default of no subsystems
Subsystem sftp /usr/lib64/ssh/sftp-server

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server
#
#
# 13 Sept 2013, modified by D.I.
UseDNS no

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

Below is the server's <ssh_config> file content:
# $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker 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 some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
# ForwardAgent no
# ForwardX11 no

# If you do not trust your remote host (or its administrator), you
# should not forward X11 connections to your local X11-display for
# security reasons: Someone stealing the authentification data on the
# remote side (the "spoofed" X-server by the remote sshd) can read your
# keystrokes as you type, just like any other X11 client could do.
# Set this to "no" here for global effect or in your own ~/.ssh/config
# file if you want to have the remote X11 authentification data to
# expire after two minutes after remote login.
ForwardX11Trusted yes

# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS 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
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com

# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
# GSSAPIEnableMITMAttack no

# This enables sending locale enviroment variables LC_* LANG, see ssh_config(5).
SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
SendEnv LC_IDENTIFICATION LC_ALL
-------------------------------------------------------------------------------------------

Thanks
 
Old 06-08-2015, 12:12 AM   #14
brukuo
LQ Newbie
 
Registered: Mar 2015
Location: Singapore
Posts: 10

Original Poster
Rep: Reputation: Disabled
When I perform SSH from another server in the same network segment (192.168.4.Y) into this host, there is no issue logging in.
 
Old 06-08-2015, 11:16 AM   #15
Tim Abracadabra
Member
 
Registered: May 2014
Location: USA, Wherever I may Roam
Distribution: Debian w/Xfce, LFS 7.9, ++
Posts: 117

Rep: Reputation: Disabled
Looking at this we see a couple of things.

Code:
Failed session attempt (post 7)
debug1: Local version string SSH-2.0-OpenSSH_6.7
ssh_exchange_identification: read: Connection reset by peer
Code:
Successful SSH session to a different server (post 9)
debug1: Local version string SSH-2.0-OpenSSH_6.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
Normally the remote server sends its SSH protocol and software version to the client
and they agree on a compatibile mode. See this OPENSSH FAQ for details.

On the failing session the client never recieves this version information.
Instead the client gets the "Connection reset by peer" which means the remote server
(or some intermediary device) sent you a RST packet, which then dropped the connection.

Why? Some Ideas:
Your SSH Host server aborted the connection while negotiating the protocol version.
As this was all of a sudden, maybe there was a software or configuration change.
Talk to the Admin and check out the server logs as previously mentioned by Joe 2000.
You mention in post #8 that the clients are in the 192.168.40 segments and the server is
in the 192.168.4 segment and a Firewall exists within these two segments.
If that means a Firewall is in between the clients and the server then it is possible that
the version response back is being blocked and the firewall may also send the RST packet
to drop the connection.

So I'd say we really need to see what the server is telling us during the failed connnection attempt.
Does it not like something and is dropping the connection?
Does the server actually try to continue building the SSH session but
the version packets do not get to your client (Firewall,??)?
Is the server missing something it expects from the client before it will
send the version packets so then it times out the connection and sends the RST?
(Configuration or version incompatability/bug)
Your last post (#14) indicates SSH works OK from another server on the same
network segment so maybe this issue is related to the firewall between the segments.

It would be really nice to see what the server logs are saying !!
Solving is more fun than guessing

BTW - The OS, version of the server and your client might be nice

Tim

Last edited by Tim Abracadabra; 06-08-2015 at 12:15 PM. Reason: Typo, clarification
 
  


Reply

Tags
ssh access


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Connections to Debian server fail on first attempt Neki Linux - Networking 3 07-26-2012 11:03 AM
Installation of SSH client and server fail dorlack Linux - Newbie 2 08-02-2011 11:36 AM
[Ubuntu]No Remote Response from SSH Login Attempt debsys07 Linux - Networking 1 12-29-2010 08:37 PM
SSH time out on login attempt from remote box: command needed to check port 22 bweaver Linux - Security 3 12-01-2010 04:57 PM
illegal ssh login attempt killing me ridwan77 Linux - Security 9 05-30-2006 04:27 AM


All times are GMT -5. The time now is 10:06 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration