My question may sound totally noob… it’s because I am So forget my ignorance please.
I followed the exact steps on the Mailinabox setup video. At the end of the video I have everything in the status check exactly like the author and everything is working. The thing I try to do after that is to upload an html static page using FileZilla to display the name of my humble page. Following instructions on the “web” tab of my box I arrive at step 3. where I am stuck for
“…the protocol is SSH or SFTP, and use the SSH login credentials that you used when you originally created this machine at your cloud host provider. This is not what you use to log in either for email or this control panel. Your SSH credentials probably involves a private key file…”
My cloud host provider is DigitalOcean. My credentials with them is my gmail address and a password. But in FileZilla it never worked, always display error messages concerning authentication refused or connection refused. I know and totally understand here it’s not the place to ask for FileZilla help or tutorial and that’s not my point here. My point is, based on the fact FileZilla needs some specific authentications requiring SSH and based on the fact the Status Check page of my box shows :
“The SSH server on this machine permits password-based login. A more secure way to log in is using a public key. Add your SSH public key to $HOME/.ssh/authorized_keys, check that you can log in without a password, set the option ‘PasswordAuthentication no’ in /etc/ssh/sshd_config, and then restart the openssh via ‘sudo service ssh restart’.”
I am (in my general ignorance) assuming that this “error” in the status page is why I have troubles connecting with FileZilla.
In the video tutorial of Mailinabox the author has the same “error” in the status page at the end of the video and he mention something about dns which should updates by themselves within 30mn and ignore the “error” status. Concerning my box it has been created since more than 2 hours now… so I am afraid something somewhere did not update correctly or I may have missed something. What would I have missed ?? What do you think ?
Hi, you would use a login/password which has nothing to do with DigitalOcean to log into your server via FileZilla. You are likely trying to login with regular FTP, not secure FTP.
In FileZilla, you want to change the Protocol from FTP to SFTP (SSH File Transfer Protocol). Then for logon type, you want to use Key file. For username, this is the user which you SSH into your box, so root or another user if you set a non-root sudo account up.
For the key file, you use your private key from your local box.
The error about password-based login is different. This means in /etc/ssh/sshd_config on your box, you’ve still got PasswordAuthentication yes when it should be PasswordAuthentication no.
In FileZilla I was trying to connect using SFTP but I figured it out that what it required was the root password… DigitalOcean never emailed to me cause I created the droplet using SSH key (tried FileZilla connection using key file but never worked). So at the end I managed to create a new root password with DigitalOcean and using it was able to resolve the FileZilla situation… because I just wanted to upload 1 single page it’s now done and I don’t need to connect again using FileZilla for a long time
Concerning the edition of sshd_config you are totally right, “PasswordAuthentication” was on “yes”, I edited that for “no” and saved my change. Now it doesn’t change anything from my point of view : I was able to ssh without password using public/private key stored in my computer and it’s still the case. My understanding is it will change the way I would connect with FileZilla in the future because using keyfile will be the only option working.
After having saved my change with Nano I restarted the machine “restart now” (because my memory didn’t want to give me back the exact thing to type to restart only SSH") and now when I go into the status check page of my box I have the exact same thing as before, everything in green except 1 thing :
“The SSH server on this machine permits password-based login. A more secure way to log in is using a public key. Add your SSH public key to $HOME/.ssh/authorized_keys, check that you can log in without a password, set the option ‘PasswordAuthentication no’ in /etc/ssh/sshd_config, and then restart the openssh via ‘sudo service ssh restart’.”
As my understanding goes, the “PasswordAuthentication” is already set up as “no” (I went back to sshd_config with Nano to confirm I didn’t messed up something while saving : it is “no” as it should be so it’s correct). My public key is added in my box while creating it following the steps of the video tutorial and my keys are on my computer as well following steps of video tutorial of MIAB. So I should not receive this “error” and should be with a green checkmark isn’t it ?
At this point because everything is working I would probably ignore this “error”, especially when the author has the same thing in his video tutorial and just ignore it “for now” bet never came back into the matter. What do you think ?
Be sure you search through the entire sshd_config file as sometimes you’ll find PasswordAuthentication is present in more than one place. Usually it’s only one place with DO, but something still isn’t correct. Immediately after you verify there is only one, instead of rebooting, try:
sudo service ssh restart
This will force your server to reload the edited sshd_config file and apply those rules to all new connections.
You are correct in your understanding now of FileZilla. Once you prevent PasswordAuthentication you will need to use the Key file method, by directing FileZilla to your key.
So I checked the sshd_config file many times and I have only 1 instance of “PasswordAuthentication” which is at value “no” (before your first answer to the topic it was at “yes” but I changed it following your advice).
Looking into the end of the file, the comment part talks about PAM and authentication. And I have “ChallengeResponseAuthentication” to “no” as it should “normally” be.
But at the end I notice I can still connect with FileZilla using root password. Which should not be possible.
Btw, thanks to remind me the command for “ssh”, I was trying “ssh reboot” loool need more sleep
So now I try to understand why I still have the same “error” message in status check and why I can still login using root and root password from FileZilla when in my “sshd_config” it says “no”. Looking into this config file with my limited understanding I can see under “#Authentication” the following “PermitRootLogin YES”. Is that the cause of the “issue” I am facing ?? I am unsure because when I ssh etc… I still do a root login, it’s just I don’t use the password for that but instead the ssh key so at this point I am wondering if I change that at “NO” would it means then I couldn’t even ssh into the box even with ssh key ?
To force root login with key only, you should change the setting to:
PermitRootLogin without-password
If you’ve definitely updated the sshd_config file correctly I’d think you haven’t restarted the service properly. Just be aware that if you restart the service and you don’t have your key authentication working and you’ve set PemitRootLogin without-password you could lock yourself out. You’d need to use the console with DigitalOcean to get back in.
So I followed your instructions in restarting ssh and also full reboot but still can connect with FileZilla using password. Then I followed your next instruction and edited sshd_config to change “PermitRootLogin” to “without-password”, restarted ssh and full reboot as before just to be sure and now when I want to connect with FileZilla with password it doesn’t work that’s a good start !!
But in the status check page of my box I still have in red the following :
“The SSH server on this machine permits password-based login. A more secure way to log in is using a public key. Add your SSH public key to $HOME/.ssh/authorized_keys, check that you can log in without a password, set the option ‘PasswordAuthentication no’ in /etc/ssh/sshd_config, and then restart the openssh via ‘sudo service ssh restart’.”
Can I safely ignore it now ? Or do I still miss something somewhere ?
ok… so I am not going to ignore it. Thanks a lot for your help v60fan !!
For sure I am out of ideas too (was out well before you ). So if anyone else has ideas regarding the fact in the status check page the 2nd line is still in red when all others are in green, I will appreciate.
hi zero, could you just post the entire content of your “/etc/ssh/sshd_config” for us using http://pastebin.com/ (or something similar). i think it could just be a simple config mistake which prevents your status page from being green.
here is mine if you want to compare it to yours http://pastebin.com/cFhD2Ahd (note: that if you haven’t created another user on your DO droplet you might need to set “PermitRootLogin yes”)
as stated above by v60fan the important setting is "PasswordAuthentication no"
you should definitly not ignore this error because it could enable an attacker to brute-force his way into your box.
Hi Beyondthewall and thanks a lot to take the time to assist me on that, it’s well appreciated !
Here is the pastebin for my sshd_config : http://pastebin.com/Tuj6Pbfc
I compared with yours and as I can tell they are similar, except for my “PermitRootLogin” which is at “without-password” because I had the issue when it was at “yes” and if I remember correctly V60fan told me to try to force it to use the ssh key using “without-password”. I didn’t created an other user on my DO droplet.
If I may have missed something by comparing your pastebin with my config file please forgive me, I just finished a very hard and long work day and … I may be more prone to do dumb mistakes ! So feel free to correct me.
Btw… in all the process trying to troubleshoot this situation at one point I created a new root password for the DO droplet because DO never emailed to me the original root password (expected behaviour when you create your droplet including SSH key in it). I doubt creating a new root password will be the cause of the situation because it was there before but just wanted to let you know in case it may gives you ideas for solutions.
Of course I don’t want to ignore the situation because I totally understand it “open the door” to a brute-force attack… but the fact is if you guys here don’t have the solution… I have no way to figure it out by myself with my more than limited technical knowledge compare to you (But lets say we don’t find a solution… I would just setup a so complicated root password it would take 30000 years to brute force looooool ! )
oh yes i see it. you need to uncomment the line “PasswordAuthentication no” (this means you need to delete the # in front of it)
the hashtag makes it ignore this option and use default values(which in this case means “yes”).
change: #PasswordAuthentication no
to: PasswordAuthentication no
then restart ssh: sudo service ssh restart
and your ssh error should go away.
i also recommend creating a custom user on your droplet and UNsetting the root password. (but thats only my opinion, other people might have a different view)
create user: adduser yourusername
add this user to sudo group (for sudo based root permissions, so you can use your userpassword to get elevated/root permissions) gpasswd -a yourusername sudo
unset root passwd: passwd -d root
… I really never seen that !! omg I’m so bad !! I did it and of course now everything is working perfectly everything in green in the status page !!
That’s one more case where the cause of everything was between my display and my chair !
Concerning creating an other user I understand the reason behind that : we don’t want to use root every day as it has power to do everything, including breaking things. But if we elevate the new user to sudo group will it have the same power of root ??
yes you will be able to get root privileges but you’ll need to enter your password everytime you use sudo.
also with a root pass set its possible to lock yourself out of your box. (in case something goes wrong and no root pass is set you can boot into safemode and have a rootshell)
… but as i said its more a believe thing. much more important than that is having password authentication disabled in ssh
Ok I understand the idea… I’ll see how I feel once I had time to play around with these things again and maybe I’ll set up a new user.
So now we have found the cause at all my troubles, it was a single “#”. Now do I have to classify this post as “Solved” or something similar ?? (It is my first post here).
Care to explain? My only intention was to make others aware of a minor issue in the instructions on some platforms. I don’t know what necropost means or what makes it undesirable. If you refer to posting comments on old (solved) issues, I’d say the platform should either disallow comments once an issue is closed or you should realize that the entire purpose of the forum and the growing knowledge base is for people to search in before the ask new questions. The old post stating the same problem as came up recently states a solution that isn’t relevant to the current issue, but it still comes up when you search for what could be the problem. I placed a link to my other post there to help others experiencing the same issue and also not getting joy from the solution describred there. If that’s not the right thing to do, slay me and I will refrain from posting anything in the future.
Many thanks for this post. I had the same issue with getting the password based ssh warning. My config file was set to PasswordAuthentication no and had gone through the service restarts. The problem was as described in your link, the “50-cloud-init.conf” having PasswordAuthentication set to yes.
So forget my ignorance please.
!!