• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Support SSH keys for Migration Manager

breun

Golden Pleskian
For security we disable password authentication for SSH and only allow public key authentication by default. Unfortunately the Plesk Migration Manager only supports password authentication, so every time we want to use PMM we need to temporarily allow password authentication. It would be very nice if PMM offered the option of providing a private key and passphrase as another method of authentication.
 
I agree. How do you disable key authentication and enable root /password authentication?
 
You don't necessarily need to disable public key authentication, but you'll need to enable password authentication. Set 'PassordAuthentication yes' in /etc/ssh/sshd_config and reload the sshd service.
 
Thank you. I thought I had done that, perhaps not correctly. I will give it another try. Doesn't the SSH login banner interfere with the Migration Manager's ability to login?...In other words... I can sign in to SSH as Root, then the banner is displayed. Currently the password is not requested because I am using keys. There is no password request.
 
AFAIK the banner doesn't interfere and you don't need to disable public key authentication to use password authentication. But sure, you can always disable public key authentication as well. Just make sure you know the password to get in without a key. :) You're doing an interactive login, but the migration manager doesn't.
 
Last edited:
Really appreciate your engaging in this!

I cannot figure out how to disable public key authentication, but if I don't have to in order to allow migration manager to be able to login, which I thought I did until now, then I wont worry too much about that. Everything I have read about public key authentication instructs on how to enable it, and how important it for security, etc etc. Nothing on how to go back to simple login/ password authentication :(

I also read somewhere in the parallels forums that the banner would interfere with migration manager logging in. Perhaps that writer was wrong. In any case, if I understand you correctly, I need only set 'PassordAuthentication yes' in /etc/ssh/sshd_config and need not worry about public key authentication still running. Is that correct? I will give it a try now. Thanks so much for helping me with this!
 
Yes, as far as I know that's correct.

But if you really want to disable public key authentication, just set 'PubkeyAuthentication no' in sshd_config and reload the sshd service. Don't forget to leave at least one method of authentication enabled if SSH is your only way into the server.

You can comment out the Banner statement in sshd_config if you want to get rid of that.

By the way, all of these options are documented: man sshd_config
 
Breun, again thanks.

This is not a matter of being unwilling to read the manual but rather a problem of not always understanding what I have read therein. I am fairly new to Linux having come from a Windows IIS background where RDP was the norm. I do, however, know enough to be dangerous. :)

Here is where my confusion lies: As you can see, I believe that I have set Password Authentication correctly. I am sure of the rrot password, haveing set is as a root user by typing passwrd and entering it twice as required. Yet, each time I attempt to use Plesk Migration manager it responds with, "incorrect user name and password" I am therefore at a loss as to what I am doing incorrectly. Thsi is something that I will have to do many times and so I must learn what si wrong.

My sshd.conf

# $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

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

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

# 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
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

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

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

# Authentication:

#LoginGraceTime 2m
PermitRootLogin without-password
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# 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
PasswordAuthentication yes

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

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

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes

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

# Accept locale-related environment variables
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
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
ClientAliveInterval 60
ClientAliveCountMax 240
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
UseDNS no
PermitRootLogin without-password
 
Yeah dont (ever, ever, ever) turn off Key auth. Ever. :p

Your problem is you set:


PermitRootLogin without-password

Which means (man sshd_config for future reference):

If this option is set to without-password, password authentication is disabled for root.

If you want to be able to log into the root account at all, you would set that to "Yes".
 
Many thanks,

I guess that is why I am no longer able to login to my server at all and am therefore hosed:(
 
I would ask, Then I guess that line "PermitRootLogin without-password" should be commented out? I mean its not a matter of changing the setting in that line but rather commenting it out entirely?
 
Commenting out means not setting a value, which means the default is used. So you can either set it 'PermitRootLogin yes' explicitly or comment out that line, same effect.
 
Thank you. I understand. I assume that now that I have changed the setting to, "PermitRootLogin without-password" and have disabled key authentication and logged out of my server, there is no way that I will ever log in again correct? :(
 
I should have added that I do still have access to the server as I had previously installed Plesk on it so I can try to figure out a way to get my data off of it onto a new server without migration manager, I guess I could do backup and then restore onto a new server, so it could be worse. But no ssh access ever again to this server I guess?
 
Last edited by a moderator:
An engineer in the datacenter should be able to login on the machine locally, change the SSH configuration and reload the sshd service for you.

If you have Plesk running (and did not explicitly disable managing the root crontab through Plesk) you have one other option: use the cron scheduling feature in Plesk to execute a command to modify the SSH configuration and restart the SSH daemon.

Pro tip 1: always keep a terminal session open when changing the SSH daemon configuration and test the new configuration using a separate terminal window. In case the new configuration is not to your liking you still have a working terminal session which you can use to fix things.

Pro tip 2: get a server with some kind of serial console access if you can, so SSH is not the only way to a command prompt.
 
Last edited:
Breun,

I wish that Plesk support were as clear and responsive as you are. You have been very, very helpful. The cron option is available but I'm afraid that I woudl not know what to enter in the command box to accomplish that. If you have a PayPal account I would be happy to PM or email you access details and PayPal you some $ to do it for me. I would ask you to just tell me what to put in there but I don't want to take up too much of your time unpaid.

As for data center admin access, this is on an Amazon Ec2 instance so there will be no joy there. :(
 
Last edited by a moderator:
Also, Thank you for your tips...That's just the kind of help I need to be able to help myself in future.

I will learn how to have termnal window access open as well. I have never done that, only SSH.

And, what is a serial console?
 
It's midnight here and I'm about to go to bed. From the top of my head (untested, no warranty, etc.), you'll want to execute the following as root from cron to 1) remove all lines containing PermitRootLogin from sshd_config and 2) restart sshd:

sed -i /PermitRootLogin/d /etc/ssh/sshd_config && service sshd restart
 
I will learn how to have termnal window access open as well. I have never done that, only SSH.

Actually I was talking about SSH. You login via SSH, modify sshd_config and restart sshd. Keep your current SSH window open and try to login via SSH using a second window. If that doesn't work you at least still have that first window with a login session to fix things.

And, what is a serial console?

A way to access a server via a serial cable via another system. Some virtual server providers also provide the virtual equivalent of this idea where you can SSH into some central system and then get access to your server through a physical (or virtual) serial cable to your server. This is also very nice when having to troubleshoot boot problems without having physical access to the server.
 
Back
Top