• GoDaddy Community
  • VPS & Dedicated Servers
  • VPS & Dedicated Servers

    cancel
    Showing results for 
    Show  only  | Search instead for 
    Did you mean: 
    Go to solution
    New

    SSH accepting connection, then dropping connection?

    We're running a Premium Managed VPS Linux server for several development sites.

     

    It's WHM / Cpanel setup, version 86.0.18, CentOS 6.10

     

    Issues arose yesterday, continuing today. Any SFTP or SSH connection successfully connects, then drops. I've spent a day googling and trying options, to no avail.

     

    Godaddy's support chat keeps dumping me back to the start, so that's no help. 

    Here's the ssh -v output, see if this makes sense to anyone, I'm stumped:

    josephwilson@Joes-iMac ~ % ssh -v mfop@198.12.154.108
    OpenSSH_8.1p1, LibreSSL 2.7.3
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: /etc/ssh/ssh_config line 47: Applying options for *
    debug1: Connecting to 198.12.154.108 [198.12.154.108] port 22.
    debug1: Connection established.
    debug1: identity file /Users/josephwilson/.ssh/id_rsa type 0
    debug1: identity file /Users/josephwilson/.ssh/id_rsa-cert type -1
    debug1: identity file /Users/josephwilson/.ssh/id_dsa type -1
    debug1: identity file /Users/josephwilson/.ssh/id_dsa-cert type -1
    debug1: identity file /Users/josephwilson/.ssh/id_ecdsa type -1
    debug1: identity file /Users/josephwilson/.ssh/id_ecdsa-cert type -1
    debug1: identity file /Users/josephwilson/.ssh/id_ed25519 type -1
    debug1: identity file /Users/josephwilson/.ssh/id_ed25519-cert type -1
    debug1: identity file /Users/josephwilson/.ssh/id_xmss type -1
    debug1: identity file /Users/josephwilson/.ssh/id_xmss-cert type -1
    debug1: Local version string SSH-2.0-OpenSSH_8.1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
    debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000002
    debug1: Authenticating to 198.12.154.108:22 as 'mfop'
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
    debug1: kex: host key algorithm: ssh-rsa
    debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
    debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
    debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
    debug1: Host '198.12.154.108' is known and matches the RSA host key.
    debug1: Found key in /Users/josephwilson/.ssh/known_hosts:2
    debug1: rekey out after 4294967296 blocks
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: rekey in after 4294967296 blocks
    debug1: Will attempt key: /Users/josephwilson/.ssh/id_dsa 
    debug1: Will attempt key: /Users/josephwilson/.ssh/id_ecdsa 
    debug1: Will attempt key: /Users/josephwilson/.ssh/id_ed25519 
    debug1: Will attempt key: /Users/josephwilson/.ssh/id_xmss 
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
    debug1: Next authentication method: publickey
    debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
    debug1: Trying private key: /Users/josephwilson/.ssh/id_dsa
    debug1: Trying private key: /Users/josephwilson/.ssh/id_ecdsa
    debug1: Trying private key: /Users/josephwilson/.ssh/id_ed25519
    debug1: Trying private key: /Users/josephwilson/.ssh/id_xmss
    debug1: Next authentication method: password
    
    mfop@198.12.154.108's password: 
    debug1: Authentication succeeded (password).
    Authenticated to 198.12.154.108 ([198.12.154.108]:22).
    
    debug1: channel 0: new [client-session]
    debug1: Requesting no-more-sessions@openssh.com
    debug1: Entering interactive session.
    debug1: pledge: network
    debug1: Sending environment.
    debug1: Sending env LANG = en_US.UTF-8
    Last login: Fri Apr 24 19:50:49 2020 from 68.33.46.6
    debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
    debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
    debug1: channel 0: free: client-session, nchannels 1
    Connection to 198.12.154.108 closed.
    Transferred: sent 2952, received 2704 bytes, in 0.2 seconds
    Bytes per second: sent 14681.4, received 13448.0
    debug1: Exit status 0
    josephwilson@Joes-iMac ~ % 

     

    All users's SFTP, SSH access on this server is affected by this, even root user. 

    I *can* access WHM / Cpanel through the UIs, and all user's credentials work there as well.

     

    Odd things:

    - I have a separate client's WHM / Cpanel server that is now exhibiting the exact same problem.

    - There is no connection between these servers, other than being godaddy managed Linux servers.

    - Discovered FTP works with current credentials, but not SFTP.

    - only updates I see have been run were EasyApache auto-updates to PHP 7.2.30, etc.

     

    Anyone else seeing this? Solve this?

    1 ACCEPTED SOLUTION

    I spoke with managed support and they were able to help me out.  An update caused a conflict with openssh versions.  These commands resolved the issue, I ran them from the terminal in WHM.

     

    rpm -qa openssh*
    rpm -e --nodeps openssh-server-5.3p1-269.el6.x86_64
    rpm -e --nodeps openssh-5.3p1-269.el6.x86_64
    rpm -e --nodeps openssh-clients-5.3p1-269.el6.x86_64
    yum -y update openssh

     

    You may want to do more research before running these commands.  Thanks

    View solution in original post

    13 REPLIES 13

    We are experiencing the same issue, affecting all our servers.  Any ideas?

    No more ideas, maybe a firewall or other protective update. I'm happy we aren't alone on this at least.

    I think I got the same, SFTP & SSH stopped working yesterday (4/24), 

    After posted mine, see yours.  Have you been able to fix it ?

     

    my post : https://ca.godaddy.com/community/VPS-Dedicated-Servers/All-sudden-SFTP-stopped-working-on-Friday/td-...

    I spoke with managed support and they were able to help me out.  An update caused a conflict with openssh versions.  These commands resolved the issue, I ran them from the terminal in WHM.

     

    rpm -qa openssh*
    rpm -e --nodeps openssh-server-5.3p1-269.el6.x86_64
    rpm -e --nodeps openssh-5.3p1-269.el6.x86_64
    rpm -e --nodeps openssh-clients-5.3p1-269.el6.x86_64
    yum -y update openssh

     

    You may want to do more research before running these commands.  Thanks

    View solution in original post

    Interesting, I thought the OpenSSL was involved, glad you got a workable solution, I’ll try it out and report back.

    Definitely appreciate your posting this, it appears to be working as intended after the re-update of OpenSSL.

     

    Glad you got a support tech who was able to help, through my 2 calls and 2 chats, I was repeatedly told "no updates were run, you should google for a fix, not our problem" 

     

    That's honestly the first time I've ever had an issue with godaddy support.

     

    Thank you again!

    A quick followup on this for anyone else running into this.

     

    When you run:

    rpm -qa openssh*

    You may need to remove (rpm -e --nodeps <filename>) all the returned entries, then for each:

     

    yum install openssh
    yum install openssh-client
    yum install openssh-server
    
    YOU MUST REBOOT THE SERVER for the changed code to be in effect.

     

    Thanks this fixed my issue. I wasn't able to ssh out of my server so my rsync backups have been failing for a couple of weeks. Godaddy needs to test out their updates. Just last month a update broke a daily php script I have to update our database. Had to roll it back.

    It worked on 3 of our 5 WHM GoDaddy VPS with no problem, but on the last two I ran into some "duplicate packages":

    [root@star ~]# rpm -qa openssh*
    openssh-5.3p1-124.el6.x86_64
    openssh-clients-5.3p1-124.el6.x86_64
    openssh-server-5.3p1-124.el6_10.x86_64
    openssh-server-5.3p1-124.el6.x86_64
    openssh-clients-5.3p1-124.el6_10.x86_64
    openssh-5.3p1-124.el6_10.x86_64
    [root@star ~]# rpm -e --nodeps openssh-server-5.3p1-269.el6.x86_64
    error: package openssh-server-5.3p1-269.el6.x86_64 is not installed
    [root@star ~]# rpm -e --nodeps openssh-5.3p1-269.el6.x86_64
    error: package openssh-5.3p1-269.el6.x86_64 is not installed
    [root@star ~]# rpm -e --nodeps openssh-clients-5.3p1-269.el6.x86_64
    error: package openssh-clients-5.3p1-269.el6.x86_64 is not installed
    [root@star ~]# yum -y update openssh
    Loaded plugins: fastestmirror, universal-hooks
    Setting up Update Process
    Loading mirror speeds from cached hostfile
    * EA4: 204.10.37.146
    * cpanel-addons-production-feed: 204.10.37.146
    * cpanel-plugins: 204.10.37.146
    * base: centos-distro.cavecreek.net
    * extras: mirror.lax.genesisadaptive.com
    * updates: mirror.lax.genesisadaptive.com
    Resolving Dependencies
    --> Running transaction check
    ---> Package openssh.x86_64 0:5.3p1-124.el6 will be updated
    --> Processing Dependency: openssh = 5.3p1-124.el6 for package: openssh-server-5.3p1-124.el6.x86_64
    --> Processing Dependency: openssh = 5.3p1-124.el6 for package: openssh-clients-5.3p1-124.el6.x86_64
    ---> Package openssh.x86_64 0:5.3p1-124.el6_10 will be an update
    --> Finished Dependency Resolution
    Error: Package: openssh-server-5.3p1-124.el6.x86_64 (installed)
    Requires: openssh = 5.3p1-124.el6
    Removing: openssh-5.3p1-124.el6.x86_64 (installed)
    openssh = 5.3p1-124.el6
    Updated By: openssh-5.3p1-124.el6_10.x86_64 (updates)
    openssh = 5.3p1-124.el6_10
    Available: openssh-5.3p1-123.el6_9.x86_64 (base)
    openssh = 5.3p1-123.el6_9
    Error: Package: openssh-clients-5.3p1-124.el6.x86_64 (installed)
    Requires: openssh = 5.3p1-124.el6
    Removing: openssh-5.3p1-124.el6.x86_64 (installed)
    openssh = 5.3p1-124.el6
    Updated By: openssh-5.3p1-124.el6_10.x86_64 (updates)
    openssh = 5.3p1-124.el6_10
    Available: openssh-5.3p1-123.el6_9.x86_64 (base)
    openssh = 5.3p1-123.el6_9
    You could try using --skip-broken to work around the problem
    ** Found 3 pre-existing rpmdb problem(s), 'yum check' output follows:
    openssh-5.3p1-124.el6_10.x86_64 is a duplicate with openssh-5.3p1-124.el6.x86_64
    openssh-clients-5.3p1-124.el6_10.x86_64 is a duplicate with openssh-clients-5.3p1-124.el6.x86_64
    openssh-server-5.3p1-124.el6_10.x86_64 is a duplicate with openssh-server-5.3p1-124.el6.x86_64

    I had a similar issue on one of mine. I ran the rpm -e --nodeps commands against the el6_10 versions before running the yum -y update openssh command. Yum then properly updated 124.el6 to 124.el6_10 without leaving the conflicting version behind.

     

    ...ymmv

    Many thanks to @eyedoctors. Saved me a lot of stress. Solving problems like this without email support (thus forced to use chat and phone) can be painful. Thanks for taking one for the team.

    OMG I have been dealing with this exact issue for 3 days with no luck and found this and it worked!!!!!

     

    Thanks

    I am a total beginner with this sort of stuff, and suddenly encountering SSH issues like the ones described above as of sometime during the last three months (after quite a few years with no issues at all, and without having made any changes to the server myself). I'm more than a little irritated this is the case.

    The message when I access Terminal about all the damage I could do by fumbling around has me pretty freaked out. Can someone recommend a high-quality, easy-as-heck tutorial that walks me through what to do while trying to update OpenSSH, so that I don't mess up a server that is for the most part otherwise working fine? Ideally, the tutorial will assume I know nothing, which isn't far from the truth.