1

We are unable to ssh or scp to a particular host, SSH Connection hangs for a while and then gets disconnected and we get this error "Lost connection"
All the hosts are CentOS 6.7

Openssh version openssh-5.3p1-112.el6_7

Openssh client: version: openssh-clients-5.3p1-112

[root@Host5 ~]# ssh 10.10.10.10 -p 22022   
CentOS release 6.6 (Final)  
########################  
 Authorized Use Only    
########################  

The host is in the same network, I have searched a lot for this, I think there is something very small or big issue. which i am unable to solve. is there any setting in config file which is missed by me.

Output for reference

[root@GACRMDATA5 ~]# grep '^[^#]' /etc/ssh/sshd_config   Port 22022   Protocol 2   SyslogFacility AUTH   SyslogFacility AUTHPRIV   PermitRootLogin yes   AllowTcpForwarding no   RSAAuthentication yes   PubkeyAuthentication yes   AuthorizedKeysFile      .ssh/authorized_keys   PermitEmptyPasswords no   PasswordAuthentication yes   ChallengeResponseAuthentication no   GSSAPIAuthentication yes   GSSAPICleanupCredentials yes   UsePAM yes   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   X11Forwarding yes   AllowUsers root   UseDNS no   ClientAliveInterval 60   ClientAliveCountMax 5   Subsystem       sftp    /usr/libexec/openssh/sftp-server   PermitEmptyPasswords no   Banner /etc/issue   IgnoreRhosts no   HostbasedAuthentication no   LoginGraceTime 1m   MaxStartups 5  

@tachomi, below is the ssh and scp command used:

ssh -p 22022 user@ip  
scp -P 22022 /home/user/file user@ip:/home/user/  

@Jakuje bashrc output :

# User specific aliases and functions  

alias rm='rm -i'   alias cp='cp -i'   alias mv='mv -i'  

# Source global definitions   if [ -f /etc/bashrc ]; then  
        . /etc/bashrc   fi
  • Please check iptables rules on the host you're trying to connect to - sudo iptables -L should show you all of them. If you don't know what they mean, don't heistate to attach them. If it isn't against your security sense, you can disable iptables for a moment, check if you can connect, and turn iptables back again. As of now, we don't have enough information to know what's your problem. – TNW Jan 22 '16 at 14:24
  • 1
    On the problem server, kill sshd. restart it by /usr/sbin/ssd -ddd in debug mode, which allows you one single login session. Go to your ssh client and launch ssh with ssh -vvv server_name and compare the debug dumps each one will generate. It might tell you why it is aborting connection. Short of seeing something meaningful on these output dumps, I'd also suggest checking iptables or any other server based firewall you are running. – MelBurslan Jan 22 '16 at 14:37
  • Make a telnet 10.10.10.10 22022, which will tell you if you can make a tcp connection to that host:port. – joepd Jan 22 '16 at 14:41
  • 1
    I have check iptables is not running, I don't have telnet to run on the server. – Mongrel Jan 22 '16 at 15:16
  • 1
    @Roaima output "/bin/bash" for the user from which we are accessing (`/etc/passwd, last field) – Mongrel Jan 22 '16 at 15:21
0

Based on the output i.e. "Authorized Use Only" you do seem to connect. (I assume that is coming from the server.)

You could check the sshd server log messages. You appear to have shown the server side sshd configuration, so it looks like you can login there via some other mechanism. The suggestion of running the sshd server in debug mode (perhaps also on a different port) also seems like a good idea.

You could try ssh with the -v for verbose flag. Also try running a command directly from ssh to avoid starting a login shell on the server e.g. run something like "ssh servername hostname".

  • Robb W & MelBurslan -v flag was very helpful. thanks for the solution. – Mongrel Jan 27 '16 at 15:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.