SSH – Misconfigured SSHD with Only Website mPanel Access

centos7linuxssh

EDIT 2 :

Due to the influence of a virus, a late-night session,
and very rusty knowledge of SSH, I made a silly mistake:
deleted the server's private keys from /etc/ssh/,
because I thought they didn't belong there.

The articles and documentation that I had recently read
were either too simplistic or too complex,
and I couldn't quickly discover the info that I needed,
so before turning off for the night I asked the question below.

Now that I've sorted it out, you can just skip to my answer.

I'm leaving the question here because the comments would not make sense without it.

===============================

Original question:

A remote server will not accept any kind of ssh connection.
The only access I have now is via the hosting provider's website.
The reason is that sshd keys are misconfigured.
(Due to silly mistakes; it was working fine for years, and I screwed it up yesterday.)

Although it has "Password Authentication yes", it no longer asks, and simply closes the connection.

Instructions for setting up SSH keys assume you have password access from a local terminal to send new keys to the server, but I don't have that.

With only mPanel web access, what is the easiest way to get sshd to accept passwords again?

Alternatively, is there a way to set up keys on the server and on the client without having to transfer files?
I doubt it, as the mpanel has no copy/paste, so I would have to type public keys by hand (doesn't seem practical).

Hope I can do it just by editing sshd config and/or hiding some files.

It's Centos7 with SSH 6.6 (compatible with SSH 9 on Manjaro at home).

Earlier, when key authentication failed, it asked for a password,
but I hadn't used the pw for so long I couldn't find it for a while,
and continued trying with changed key configurations (changing files via sftp in Filezilla).
After a few more botched login attempts it stopped asking for a password, and the filezilla connection broke too.
(Hadn't read the ssh docs for years, and forgot some important points.)

I wonder if a flag has been set somewhere, and sshd won't ask for a password until the flag is cleared…?

EDIT:

connection is closed immediately after 'KEXINIT sent'.
this is because the local and remote keys don't match.

debug1: SSH2_MSG_KEXINIT sent  
Connection closed by ... (the server)

The puzzle is "why does it not ask for a password?".
But i don't even care why, i just want to reset that sshd daemon,
and don't know enough atm to be confident about how.
I guess I'll restart that service soon; maybe change some config.
Am reading redhat EL7 docs, but it will take a while … 😉

fail2ban is not installed. I did not try any pw at all with ssh, as it stopped asking before i found the pw; I haved used the pw in mpanel, it's correct.
What I'm hoping for is general info about how to safely and easily clear sshd, rather than diagnose what's gone wrong.
Will need to set it up to accept pw so I can then configure it with new keys. Am now searching for info on sshd server setup (most info is about client setup).

Best Answer

Martin's comment pointed me in the right direction.
The short answer to the question was:
on the server, in /etc/ssh/ delete what's left of the keys, then restart the sshd service.
This causes the sshd service to create new host key-pairs.

The server uses one of its host key-pairs to set up an encrypted channel
to negotiate with the client; without this it cannot ask for a password,
as the password must not be transferred unencrypted.
I had deleted the private keys, and a public key alone cannot do it.

Below is more of the kind of information I needed,
which at the time I couldn't find all of in the documentation.
(It's there, but mixed in with a lot of other details.)

Simple configuration for public key authentication

File layout:

client                          server

/etc/ssh/                       /etc/ssh/
  ssh_config                      sshd_config
                 |<---pubkey---   'ssh_host' key pair
                 |
/<user>/.ssh/    |              /<user>/.ssh/
  known_hosts  <-|
  'id' key pair    ---pubkey-->    authorized_keys

The files 'known_hosts' and 'authorized_keys'
each contain a list of public keys, one key per line.

/<user>/ can be /root/, as well as any /home/<username>/.
root works the same way as the others.

Sequence of events (simplified) :

  1. server setup

    'ssh_host' key-pairs are created when sshd first starts
    if they go missing, sshd creates replacements whenever it re-starts

  2. client setup

    user creates 'id' key-pair by running ssh-keygen
    user sends public key to server by running ssh-copy-id
    (password authentication must be enabled for ssh-copy-id to work)

  3. connection

    server sends 'ssh_host' public key to client
    client checks that it's in known_hosts
    [on first connection to a new server, or to a server whose keys have changed,
    the client asks the user if it's OK to add the server's key to known_hosts.
    it's not OK if you're not expecting it]

    client sends user's 'id' public key to server
    server checks that it's in the user's authorized_keys
    [if it's not, the client's user cannot log into the server]

Note

A key can "cross over" between users:
e.g., put a client user's key in server root's authorized_keys
and that user can log into the server as root, if PermitRootLogin is not 'no'.

This is how I make it possible to connect as root with Filezilla.
In KDE on Manjaro it's not possible to run X-windows apps as root,
so Fz needs to run as me, but log into the server as root;
it does not have access to root's id key, so has to use mine.
[On the server, PermitRootLogin is off most of the time, and I turn it on
only briefly, when Filezilla is the best tool for doing some reconfiguration.]

Related Topic