Unable to SSH with putty for newly created user. Ubuntu 13.10

January 25, 2016 9.8k views
Linux Basics
tech454934
By:
tech454934

I need to give a new user access to make changes to files in a folder under /var/www
I created the user sudo adduser newuser I then tried to add the user to the www-data group so that they can modify the files owned by www-data.

The user was not able to ssh in at all. So I deleted the user sudo deluser --remove-home newuser and recreated it again but this time did not add it to the group, but this had no effect, i was still unable to ssh with the new user.

I am able to ssh onto the box with another user I created ages ago and probaly set up a public private key however the folders this article Initial Servire setup talks about a .ssh directory which my current user (that can ssh in) does not have.

Is there an easyer way to give a temporary user access to just 1 directory under /var/www and if not, how can I go about finding if I have a public key under my existing user that I need to copy to the new user?

Many Thanks
Marc

Log In to Comment
2 Answers
gparent January 25, 2016

If you have a public key set up for a user, it will be in that user's ~/.ssh/authorized_keys file. Try looking again? What command are you using to verify this?

Reply
  • tech454934 January 26, 2016

    I am unable to see any .ssh folder in my home directory when login in as myself or as the root user. That is whyI was wondering if it could be set up differently.

    I would have followed a guide similar to this and was thinking maybe Ubuntu 13.10 would possibly do things differently?

    What is weird is I have no .ssh directory, but can ssh onto the box with this user, but when I create another user it is denied access. Is there maybe some other setting that is required possibly?

    Initial Server Setup with Ubuntu 14.04
    by Justin Ellingwood
    When you start a new server, there are a few steps that you should take every time to add some basic security and set a solid foundation. In this guide, we'll walk you through the basic steps necessary to hit the ground running with Ubuntu 14.04.
    • BeanJr January 27, 2016

      hey,

      Just wanted to answer your question here.

      If a .ssh directory DOES NOT exist in your $HOME (variable for where the user's home is - do echo "$HOME" and you'll see what I mean) then enter the following commands:

      mkdir .ssh
      chmod 700 .ssh
      cd .ssh
      [name of preferred editor here - can be vi, vim, nano] authorized_keys

      paste your public key into this file

      then type:
      chmod 640 authorized_keys

      NOTE: When doing the steps for another users besides the root/yourself, remember to go back out to the user's $HOME and type:
      chown user:group .ssh -R

      replace "user" and "group" with the person's username. This way THAT user can read and write to their .ssh directory and any files contained within it. If you don't chown that user's SSH directory their access would be denied because putty can't read the public key for that user since root (or some other user) owns that file instead of them.

      • kelbs January 27, 2018

        I wasn't able to ssh into my droplet as a newly created user UNTIL I followed the steps BeanJr laid out here. That was the missing piece from DigitalOcean's guide (https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04)

        Thanks BeanJr!

        • BeanJr January 27, 2018

          No problem! Wow, a whole year has gone by since I posted that aha

        • gparent February 14, 2018

          To clarify, the "missing" steps that BeanJr posted are what you can read in "Step Four".

          • kelbs February 20, 2018

            Show me where in that guide it tells you

            "When doing the steps for another users besides the root/yourself, remember to go back out to the user's $HOME and type:
            chown user:group .ssh -R

            replace "user" and "group" with the person's username. This way THAT user can read and write to their .ssh directory and any files contained within it. If you don't chown that user's SSH directory their access would be denied because putty can't read the public key for that user since root (or some other user) owns that file instead of them."

            This is the part that wasn't working for me. After following the guide, I was able to SSH with root login, but not with the user I created. Not until I used the chown command from BeanJr and then it worked...

          • gparent February 20, 2018

            Hello,

            That would be Step four, Option 2: Manually Install the Key.

            "On the server, as the root user, enter the following command to temporarily switch to the new user (substitute your own user name):"

            have a good day,

          • kelbs February 20, 2018

            Ahh ok thanks. I probably missed that step where you temporarily switch from root user to other user

    • gparent January 27, 2016

      No, unless you're using some weird config, there's definitely a .ssh directory with a authorized_keys file in there, assuming that you're using SSH keypair authentication. If you use password authentication, it's possible there is none. If you don't see the directory, it's possible you're not verifying using the right commands.

      • tech454934 January 27, 2016

        I have no .ssh in my home directory at all so assume then .ssh is not being used. The problem I have is when using putty or WinSCP I am unable to login with the newuser I just created! I type sudo adduser newuser follow the prompts and the user is created. I can see the users home dir under /home/newuser the same as with my other user (that can login using Putty and WinScp) However when I try login with newuser it says authenticating, but always says access denied.

        I am trying to figure out what else I need to do to allow the newuser to connect via port 22. I don't want to give the user root privileges (which my other user has) just to FTP some files onto my server. But if I have no .ssh file in my users home directory, could there be something else I am missing?

        I have found a .ssh in the directory /root/ but nowhere else on the server.

        Thanks for your patience...

        • gparent January 28, 2016

          If you want to log in using public key authentication as a given user, you will need to go in that user's home directory and create the .ssh directory, as well as the authorized_keys file as explained very precisely by BeanJr.

          This is how you are able to log in as root right now. As you found out, there really is a .ssh directory, we're not joking.

          "But if I have no .ssh file in my users home directory, could there be something else I am missing?"

          No. You won't be able to log in via public key authentication if that's the case.

          • tech454934 February 1, 2016

            Thanks for all the input.
            The issue was not that the user did not have an .ssh directory, as my user that can ssh onto the box does not have a .ssh directory ether. From what I understand now after a lot of time with the support guys is you don't need a .ssh public key if you are doing password auth, which my system is doing. The issue was on creating a new user and password the user was unable to ssh onto the box even when the correct password was provided, so creating a .ssh for the user that was unable to login would not have been of any help.

            The issue in the end was the way the box was set up, it had an allow users section in the sshdconfig file that only allows ssh via named users, if the user is not on the list, it will not allow it to ssh on to the box at all regardless.
            This file can be found here:
            /etc/ssh/sshd            config

            Thanks Again for all the input.

            Regards
            Marc

          • gparent February 1, 2016

            Actually, we mentioned it several times that the .ssh directory was for public key authentication and not password authentication. Were you using a default configuration, creating the .ssh directory and placing the public key in authorized_keys would have let your newly created user log in without problem. To be perfectly clear, this is what was meant by "assuming that you're using SSH keypair authentication" and "If you want to log in using public key authentication".

            The real issue was that nowhere in this entire thread was it mentioned that we were working with a modified sshd_config, hence the confusion you inadvertently created.

            Normally that additional line in sshd_config isn't there ("No, unless you're using some weird config...") and the instructions given work perfectly as-is, so you can refer to them the next time you have a log in issue. Note that you can use AllowGroups to make things easier than AllowUsers

            When you know the config is non-default, verify your authentication logs and the cause will be made obvious there. They are usually found in /var/log/auth.log. This is always a good reflex to have when you aren't sure what you broke.

tech454934 February 1, 2016

The issue in the end was the way the box was set up, it had an allow users section in the sshdconfig file that only allows ssh via named users, if the user is not on the list, it will not allow it to ssh on to the box at all regardless.
This file can be found here:
/etc/ssh/sshdconfig

I think this may be the way Digital Ocean configures the Ubuntu OS when setting up a new droplet. I did not know this file even existed and have never modified it previously, all I did was create one user when I setup the droplet and have ssh'ed onto the box with it ever since.

So if you are able to ssh onto your droplet but have no .ssh directory in that user's home directory and newly created users are denied access to the droplet, see if you don't have an allow users section in your sshdconfig file!

Reply
  • gparent February 2, 2016

    This won't be an issue with the default images as they do not contain an AllowUsers directive. I went ahead and tested every single one of them. It would be safer to verify logs if you get an issue like the above.

    If you follow a tutorial like this one and forget what commands you set later on, the logs will always contain the root cause of the problem.

    How To Tune your SSH Daemon Configuration on a Linux VPS
    by Justin Ellingwood
    SSH is the standard way to connect to remote Linux systems. You probably know the basics of how to use it, but the daemon also has many options that can give you more flexibility in user authentication and control. In this guide, we'll explore some of these options in order to give you a more secure and more flexible SSH experience.
Have another answer? Share your knowledge.

Related Questions