Linux User not able to login












5















I am trying to create new users using useradd command using root credentials it is getting created properly but when I log in with the newly created user with its credentials using a PuTTY Console, I am able to enter the username but when I give the password, it hangs there for a long time until the PuTTY window session timeout happens and the window is closed. However when I use root credentials, it quickly enters the session.



I tried checking the AllowUsers under file /etc/ssh/sshd_config but I didn't find any matching entry, so, I manually tried adding AllowUsers temipuser where temipuser is the username I created. Post making this change from another PuTTY Console I again tried entering this username but it is again the same. I am totally clueless why is this happening.



Another thing is, if I add any user, say just temipuser, to the AllowUsers entry in the sshd_config file, will the root user still have access or will it not get access? I don't want to screw the things here. I understand AllowUsers lets only the specified users and denies others.










share|improve this question




















  • 1





    /var/log/auth.log should use some useful information. Can you add anything you find to your question?

    – Flup
    Mar 14 '13 at 13:21











  • Agreed. Also adjust /etc/ssh/sshd_config to set LogLevel to Debug while you try logging in to get as much information as possible.

    – Shadur
    Mar 14 '13 at 14:16











  • Some Unix stuff chokes on usernames longer than 8 characters, your temipuser is 9... Can you log in locally (i.e., not over ssh)? BTW, I don't know offhand if sshd reads its configuration each time, you might have to restart it (or force it to reread configuration) after changes.

    – vonbrand
    Mar 14 '13 at 17:44











  • Are you able to ssh locally? I.e. what happens if you log in as root and then run ssh temipuser@localhost and enter the user's password when prompted?

    – depquid
    Mar 16 '13 at 20:12











  • When i run ssh temipuser@<ip_of_server>, the same happens, it accepts username but hangs when i give password.

    – Ankit Vashistha
    Mar 17 '13 at 8:07


















5















I am trying to create new users using useradd command using root credentials it is getting created properly but when I log in with the newly created user with its credentials using a PuTTY Console, I am able to enter the username but when I give the password, it hangs there for a long time until the PuTTY window session timeout happens and the window is closed. However when I use root credentials, it quickly enters the session.



I tried checking the AllowUsers under file /etc/ssh/sshd_config but I didn't find any matching entry, so, I manually tried adding AllowUsers temipuser where temipuser is the username I created. Post making this change from another PuTTY Console I again tried entering this username but it is again the same. I am totally clueless why is this happening.



Another thing is, if I add any user, say just temipuser, to the AllowUsers entry in the sshd_config file, will the root user still have access or will it not get access? I don't want to screw the things here. I understand AllowUsers lets only the specified users and denies others.










share|improve this question




















  • 1





    /var/log/auth.log should use some useful information. Can you add anything you find to your question?

    – Flup
    Mar 14 '13 at 13:21











  • Agreed. Also adjust /etc/ssh/sshd_config to set LogLevel to Debug while you try logging in to get as much information as possible.

    – Shadur
    Mar 14 '13 at 14:16











  • Some Unix stuff chokes on usernames longer than 8 characters, your temipuser is 9... Can you log in locally (i.e., not over ssh)? BTW, I don't know offhand if sshd reads its configuration each time, you might have to restart it (or force it to reread configuration) after changes.

    – vonbrand
    Mar 14 '13 at 17:44











  • Are you able to ssh locally? I.e. what happens if you log in as root and then run ssh temipuser@localhost and enter the user's password when prompted?

    – depquid
    Mar 16 '13 at 20:12











  • When i run ssh temipuser@<ip_of_server>, the same happens, it accepts username but hangs when i give password.

    – Ankit Vashistha
    Mar 17 '13 at 8:07
















5












5








5








I am trying to create new users using useradd command using root credentials it is getting created properly but when I log in with the newly created user with its credentials using a PuTTY Console, I am able to enter the username but when I give the password, it hangs there for a long time until the PuTTY window session timeout happens and the window is closed. However when I use root credentials, it quickly enters the session.



I tried checking the AllowUsers under file /etc/ssh/sshd_config but I didn't find any matching entry, so, I manually tried adding AllowUsers temipuser where temipuser is the username I created. Post making this change from another PuTTY Console I again tried entering this username but it is again the same. I am totally clueless why is this happening.



Another thing is, if I add any user, say just temipuser, to the AllowUsers entry in the sshd_config file, will the root user still have access or will it not get access? I don't want to screw the things here. I understand AllowUsers lets only the specified users and denies others.










share|improve this question
















I am trying to create new users using useradd command using root credentials it is getting created properly but when I log in with the newly created user with its credentials using a PuTTY Console, I am able to enter the username but when I give the password, it hangs there for a long time until the PuTTY window session timeout happens and the window is closed. However when I use root credentials, it quickly enters the session.



I tried checking the AllowUsers under file /etc/ssh/sshd_config but I didn't find any matching entry, so, I manually tried adding AllowUsers temipuser where temipuser is the username I created. Post making this change from another PuTTY Console I again tried entering this username but it is again the same. I am totally clueless why is this happening.



Another thing is, if I add any user, say just temipuser, to the AllowUsers entry in the sshd_config file, will the root user still have access or will it not get access? I don't want to screw the things here. I understand AllowUsers lets only the specified users and denies others.







linux login putty login-manager






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 14 '13 at 22:43









Kazark

5952829




5952829










asked Mar 14 '13 at 12:57









Ankit VashisthaAnkit Vashistha

84182030




84182030








  • 1





    /var/log/auth.log should use some useful information. Can you add anything you find to your question?

    – Flup
    Mar 14 '13 at 13:21











  • Agreed. Also adjust /etc/ssh/sshd_config to set LogLevel to Debug while you try logging in to get as much information as possible.

    – Shadur
    Mar 14 '13 at 14:16











  • Some Unix stuff chokes on usernames longer than 8 characters, your temipuser is 9... Can you log in locally (i.e., not over ssh)? BTW, I don't know offhand if sshd reads its configuration each time, you might have to restart it (or force it to reread configuration) after changes.

    – vonbrand
    Mar 14 '13 at 17:44











  • Are you able to ssh locally? I.e. what happens if you log in as root and then run ssh temipuser@localhost and enter the user's password when prompted?

    – depquid
    Mar 16 '13 at 20:12











  • When i run ssh temipuser@<ip_of_server>, the same happens, it accepts username but hangs when i give password.

    – Ankit Vashistha
    Mar 17 '13 at 8:07
















  • 1





    /var/log/auth.log should use some useful information. Can you add anything you find to your question?

    – Flup
    Mar 14 '13 at 13:21











  • Agreed. Also adjust /etc/ssh/sshd_config to set LogLevel to Debug while you try logging in to get as much information as possible.

    – Shadur
    Mar 14 '13 at 14:16











  • Some Unix stuff chokes on usernames longer than 8 characters, your temipuser is 9... Can you log in locally (i.e., not over ssh)? BTW, I don't know offhand if sshd reads its configuration each time, you might have to restart it (or force it to reread configuration) after changes.

    – vonbrand
    Mar 14 '13 at 17:44











  • Are you able to ssh locally? I.e. what happens if you log in as root and then run ssh temipuser@localhost and enter the user's password when prompted?

    – depquid
    Mar 16 '13 at 20:12











  • When i run ssh temipuser@<ip_of_server>, the same happens, it accepts username but hangs when i give password.

    – Ankit Vashistha
    Mar 17 '13 at 8:07










1




1





/var/log/auth.log should use some useful information. Can you add anything you find to your question?

– Flup
Mar 14 '13 at 13:21





/var/log/auth.log should use some useful information. Can you add anything you find to your question?

– Flup
Mar 14 '13 at 13:21













Agreed. Also adjust /etc/ssh/sshd_config to set LogLevel to Debug while you try logging in to get as much information as possible.

– Shadur
Mar 14 '13 at 14:16





Agreed. Also adjust /etc/ssh/sshd_config to set LogLevel to Debug while you try logging in to get as much information as possible.

– Shadur
Mar 14 '13 at 14:16













Some Unix stuff chokes on usernames longer than 8 characters, your temipuser is 9... Can you log in locally (i.e., not over ssh)? BTW, I don't know offhand if sshd reads its configuration each time, you might have to restart it (or force it to reread configuration) after changes.

– vonbrand
Mar 14 '13 at 17:44





Some Unix stuff chokes on usernames longer than 8 characters, your temipuser is 9... Can you log in locally (i.e., not over ssh)? BTW, I don't know offhand if sshd reads its configuration each time, you might have to restart it (or force it to reread configuration) after changes.

– vonbrand
Mar 14 '13 at 17:44













Are you able to ssh locally? I.e. what happens if you log in as root and then run ssh temipuser@localhost and enter the user's password when prompted?

– depquid
Mar 16 '13 at 20:12





Are you able to ssh locally? I.e. what happens if you log in as root and then run ssh temipuser@localhost and enter the user's password when prompted?

– depquid
Mar 16 '13 at 20:12













When i run ssh temipuser@<ip_of_server>, the same happens, it accepts username but hangs when i give password.

– Ankit Vashistha
Mar 17 '13 at 8:07







When i run ssh temipuser@<ip_of_server>, the same happens, it accepts username but hangs when i give password.

– Ankit Vashistha
Mar 17 '13 at 8:07












6 Answers
6






active

oldest

votes


















2














look for any relevant entries under /var/log/secure or /var/log/auth.log. Also, make sure that you don't have custom rules added under /etc/security/access.conf which might access to the server for that user.



Those logs will contain information about failed logins and may indicate clearly what went wrong.



The /etc/security/access.conf file specifies (user/group, host), (user/group, network/netmask) or (user/group, tty) combinations for which a login will be either accepted or refused.






share|improve this answer

































    1














    Next to adding the user on the Linux machine, you'll have to generate a key (protocol type 2, preferably RSA) for that user as well. You can find instructions for that using Putty's key generator here.



    Select all of the text in the ‘Public key for pasting into authorized_keys file’ box in putty's key generator, paste it into a text editor and save it under the name authorized_keys.



    In the home directory of the new user on the Linux machine, create a .ssh directory if it doesn't exist. This directory should be owned by the user, and only that user should have access to it (chmod 700 .ssh) Copy the authorized_keys file to this directory. You should change the permissions of that file with chmod 0600, and change ownership to the user.



    Now the user should be able to log in.






    share|improve this answer
























    • You do not need a key in order to login via SSH. Password login is enabled by default and if the OP had disabled it, he/she would probably remember

      – Stefano Sanfilippo
      May 8 '13 at 23:14



















    0














    To me, your problem could be be related to a permission issue, since SSH asks you for a login (so it is not a port problem), and a password (so PasswordAuthentication is set to yes, which is the default anyway).



    Indeed, the way sshd works by default is that it attempts reading public SSH keys before asking for a password, and if your ~/.ssh/authorized_keys has the wrong permissions, well, the manual says that sshd will not allow you to login (see below).



    With no other information about your sshd configuration (is AuthorizedKeysFile still commented; do you actually use SSH keys; etc.), my guess was made by reading the sshd manual:




     ~/.ssh/authorized_keys
    Lists the public keys (DSA/ECDSA/RSA) that can be used for logging in as this user.
    The format of this file is described above. The content of the file is not highly
    sensitive, but the recommended permissions are read/write for the user, and not
    accessible by others.

    If this file, the ~/.ssh directory, or the user's home directory are writable by
    other users, then the file could be modified or replaced by unauthorized users. In
    this case, sshd will not allow it to be used unless the StrictModes option has been
    set to “no”.



    So. Can you ls -l ~/.ssh/autorized_keys and double-check that only the user can read that file?



    To make sure nobody but the user can read this directory, use this: chmod -v a-w,u+w ~/.ssh/authorized_keys. Option -v is for chmod to inform you of the changes it made (if any), a-w,u+w is to remove the write permissions for all, and then give the user write permissions back.






    share|improve this answer

































      0














      Did you test adduser temipuser instead of useradd temipuser ???



      linux manual for sshd_conf said:



      AllowUsers



          This keyword can be followed by a list of user name patterns, separated by 
      spaces. If specified, login is allowed only for user names that match one of the
      patterns. Only user names are valid; a numerical user ID is not recognized. **By
      default, login is allowed for all users.** If the pattern takes the form USER@HOST
      then USER and HOST are separately checked, restricting logins to particular users
      from particular hosts. The allow/deny directives are processed in the following
      order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.


      So you don't have to add AllowUsers and if you add this option I don't think it prevent from remote root login if you enabled PermitRootLogin






      share|improve this answer































        0














        Check the /etc/ssh/sshd_config file. Check if the "PasswordAuthentication" line is set to "no". Change this to "yes" and save the file. You have to do this as sudo. Once file is saved restart using command "sudo service ssh restart"






        share|improve this answer








        New contributor




        grajnikanth is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.




























          -1














          Remove any failures login counts , reset with below command:



          pam_tally2 --reset -u username


          use this command to null the entries



          cp /dev/null /var/log/lastlog





          share|improve this answer

























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f67921%2flinux-user-not-able-to-login%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            6 Answers
            6






            active

            oldest

            votes








            6 Answers
            6






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            2














            look for any relevant entries under /var/log/secure or /var/log/auth.log. Also, make sure that you don't have custom rules added under /etc/security/access.conf which might access to the server for that user.



            Those logs will contain information about failed logins and may indicate clearly what went wrong.



            The /etc/security/access.conf file specifies (user/group, host), (user/group, network/netmask) or (user/group, tty) combinations for which a login will be either accepted or refused.






            share|improve this answer






























              2














              look for any relevant entries under /var/log/secure or /var/log/auth.log. Also, make sure that you don't have custom rules added under /etc/security/access.conf which might access to the server for that user.



              Those logs will contain information about failed logins and may indicate clearly what went wrong.



              The /etc/security/access.conf file specifies (user/group, host), (user/group, network/netmask) or (user/group, tty) combinations for which a login will be either accepted or refused.






              share|improve this answer




























                2












                2








                2







                look for any relevant entries under /var/log/secure or /var/log/auth.log. Also, make sure that you don't have custom rules added under /etc/security/access.conf which might access to the server for that user.



                Those logs will contain information about failed logins and may indicate clearly what went wrong.



                The /etc/security/access.conf file specifies (user/group, host), (user/group, network/netmask) or (user/group, tty) combinations for which a login will be either accepted or refused.






                share|improve this answer















                look for any relevant entries under /var/log/secure or /var/log/auth.log. Also, make sure that you don't have custom rules added under /etc/security/access.conf which might access to the server for that user.



                Those logs will contain information about failed logins and may indicate clearly what went wrong.



                The /etc/security/access.conf file specifies (user/group, host), (user/group, network/netmask) or (user/group, tty) combinations for which a login will be either accepted or refused.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Jul 27 '13 at 17:08









                bahamat

                24.6k15090




                24.6k15090










                answered Jun 26 '13 at 11:00









                mezimezi

                6841917




                6841917

























                    1














                    Next to adding the user on the Linux machine, you'll have to generate a key (protocol type 2, preferably RSA) for that user as well. You can find instructions for that using Putty's key generator here.



                    Select all of the text in the ‘Public key for pasting into authorized_keys file’ box in putty's key generator, paste it into a text editor and save it under the name authorized_keys.



                    In the home directory of the new user on the Linux machine, create a .ssh directory if it doesn't exist. This directory should be owned by the user, and only that user should have access to it (chmod 700 .ssh) Copy the authorized_keys file to this directory. You should change the permissions of that file with chmod 0600, and change ownership to the user.



                    Now the user should be able to log in.






                    share|improve this answer
























                    • You do not need a key in order to login via SSH. Password login is enabled by default and if the OP had disabled it, he/she would probably remember

                      – Stefano Sanfilippo
                      May 8 '13 at 23:14
















                    1














                    Next to adding the user on the Linux machine, you'll have to generate a key (protocol type 2, preferably RSA) for that user as well. You can find instructions for that using Putty's key generator here.



                    Select all of the text in the ‘Public key for pasting into authorized_keys file’ box in putty's key generator, paste it into a text editor and save it under the name authorized_keys.



                    In the home directory of the new user on the Linux machine, create a .ssh directory if it doesn't exist. This directory should be owned by the user, and only that user should have access to it (chmod 700 .ssh) Copy the authorized_keys file to this directory. You should change the permissions of that file with chmod 0600, and change ownership to the user.



                    Now the user should be able to log in.






                    share|improve this answer
























                    • You do not need a key in order to login via SSH. Password login is enabled by default and if the OP had disabled it, he/she would probably remember

                      – Stefano Sanfilippo
                      May 8 '13 at 23:14














                    1












                    1








                    1







                    Next to adding the user on the Linux machine, you'll have to generate a key (protocol type 2, preferably RSA) for that user as well. You can find instructions for that using Putty's key generator here.



                    Select all of the text in the ‘Public key for pasting into authorized_keys file’ box in putty's key generator, paste it into a text editor and save it under the name authorized_keys.



                    In the home directory of the new user on the Linux machine, create a .ssh directory if it doesn't exist. This directory should be owned by the user, and only that user should have access to it (chmod 700 .ssh) Copy the authorized_keys file to this directory. You should change the permissions of that file with chmod 0600, and change ownership to the user.



                    Now the user should be able to log in.






                    share|improve this answer













                    Next to adding the user on the Linux machine, you'll have to generate a key (protocol type 2, preferably RSA) for that user as well. You can find instructions for that using Putty's key generator here.



                    Select all of the text in the ‘Public key for pasting into authorized_keys file’ box in putty's key generator, paste it into a text editor and save it under the name authorized_keys.



                    In the home directory of the new user on the Linux machine, create a .ssh directory if it doesn't exist. This directory should be owned by the user, and only that user should have access to it (chmod 700 .ssh) Copy the authorized_keys file to this directory. You should change the permissions of that file with chmod 0600, and change ownership to the user.



                    Now the user should be able to log in.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Mar 23 '13 at 9:45









                    Roland SmithRoland Smith

                    1514




                    1514













                    • You do not need a key in order to login via SSH. Password login is enabled by default and if the OP had disabled it, he/she would probably remember

                      – Stefano Sanfilippo
                      May 8 '13 at 23:14



















                    • You do not need a key in order to login via SSH. Password login is enabled by default and if the OP had disabled it, he/she would probably remember

                      – Stefano Sanfilippo
                      May 8 '13 at 23:14

















                    You do not need a key in order to login via SSH. Password login is enabled by default and if the OP had disabled it, he/she would probably remember

                    – Stefano Sanfilippo
                    May 8 '13 at 23:14





                    You do not need a key in order to login via SSH. Password login is enabled by default and if the OP had disabled it, he/she would probably remember

                    – Stefano Sanfilippo
                    May 8 '13 at 23:14











                    0














                    To me, your problem could be be related to a permission issue, since SSH asks you for a login (so it is not a port problem), and a password (so PasswordAuthentication is set to yes, which is the default anyway).



                    Indeed, the way sshd works by default is that it attempts reading public SSH keys before asking for a password, and if your ~/.ssh/authorized_keys has the wrong permissions, well, the manual says that sshd will not allow you to login (see below).



                    With no other information about your sshd configuration (is AuthorizedKeysFile still commented; do you actually use SSH keys; etc.), my guess was made by reading the sshd manual:




                     ~/.ssh/authorized_keys
                    Lists the public keys (DSA/ECDSA/RSA) that can be used for logging in as this user.
                    The format of this file is described above. The content of the file is not highly
                    sensitive, but the recommended permissions are read/write for the user, and not
                    accessible by others.

                    If this file, the ~/.ssh directory, or the user's home directory are writable by
                    other users, then the file could be modified or replaced by unauthorized users. In
                    this case, sshd will not allow it to be used unless the StrictModes option has been
                    set to “no”.



                    So. Can you ls -l ~/.ssh/autorized_keys and double-check that only the user can read that file?



                    To make sure nobody but the user can read this directory, use this: chmod -v a-w,u+w ~/.ssh/authorized_keys. Option -v is for chmod to inform you of the changes it made (if any), a-w,u+w is to remove the write permissions for all, and then give the user write permissions back.






                    share|improve this answer






























                      0














                      To me, your problem could be be related to a permission issue, since SSH asks you for a login (so it is not a port problem), and a password (so PasswordAuthentication is set to yes, which is the default anyway).



                      Indeed, the way sshd works by default is that it attempts reading public SSH keys before asking for a password, and if your ~/.ssh/authorized_keys has the wrong permissions, well, the manual says that sshd will not allow you to login (see below).



                      With no other information about your sshd configuration (is AuthorizedKeysFile still commented; do you actually use SSH keys; etc.), my guess was made by reading the sshd manual:




                       ~/.ssh/authorized_keys
                      Lists the public keys (DSA/ECDSA/RSA) that can be used for logging in as this user.
                      The format of this file is described above. The content of the file is not highly
                      sensitive, but the recommended permissions are read/write for the user, and not
                      accessible by others.

                      If this file, the ~/.ssh directory, or the user's home directory are writable by
                      other users, then the file could be modified or replaced by unauthorized users. In
                      this case, sshd will not allow it to be used unless the StrictModes option has been
                      set to “no”.



                      So. Can you ls -l ~/.ssh/autorized_keys and double-check that only the user can read that file?



                      To make sure nobody but the user can read this directory, use this: chmod -v a-w,u+w ~/.ssh/authorized_keys. Option -v is for chmod to inform you of the changes it made (if any), a-w,u+w is to remove the write permissions for all, and then give the user write permissions back.






                      share|improve this answer




























                        0












                        0








                        0







                        To me, your problem could be be related to a permission issue, since SSH asks you for a login (so it is not a port problem), and a password (so PasswordAuthentication is set to yes, which is the default anyway).



                        Indeed, the way sshd works by default is that it attempts reading public SSH keys before asking for a password, and if your ~/.ssh/authorized_keys has the wrong permissions, well, the manual says that sshd will not allow you to login (see below).



                        With no other information about your sshd configuration (is AuthorizedKeysFile still commented; do you actually use SSH keys; etc.), my guess was made by reading the sshd manual:




                         ~/.ssh/authorized_keys
                        Lists the public keys (DSA/ECDSA/RSA) that can be used for logging in as this user.
                        The format of this file is described above. The content of the file is not highly
                        sensitive, but the recommended permissions are read/write for the user, and not
                        accessible by others.

                        If this file, the ~/.ssh directory, or the user's home directory are writable by
                        other users, then the file could be modified or replaced by unauthorized users. In
                        this case, sshd will not allow it to be used unless the StrictModes option has been
                        set to “no”.



                        So. Can you ls -l ~/.ssh/autorized_keys and double-check that only the user can read that file?



                        To make sure nobody but the user can read this directory, use this: chmod -v a-w,u+w ~/.ssh/authorized_keys. Option -v is for chmod to inform you of the changes it made (if any), a-w,u+w is to remove the write permissions for all, and then give the user write permissions back.






                        share|improve this answer















                        To me, your problem could be be related to a permission issue, since SSH asks you for a login (so it is not a port problem), and a password (so PasswordAuthentication is set to yes, which is the default anyway).



                        Indeed, the way sshd works by default is that it attempts reading public SSH keys before asking for a password, and if your ~/.ssh/authorized_keys has the wrong permissions, well, the manual says that sshd will not allow you to login (see below).



                        With no other information about your sshd configuration (is AuthorizedKeysFile still commented; do you actually use SSH keys; etc.), my guess was made by reading the sshd manual:




                         ~/.ssh/authorized_keys
                        Lists the public keys (DSA/ECDSA/RSA) that can be used for logging in as this user.
                        The format of this file is described above. The content of the file is not highly
                        sensitive, but the recommended permissions are read/write for the user, and not
                        accessible by others.

                        If this file, the ~/.ssh directory, or the user's home directory are writable by
                        other users, then the file could be modified or replaced by unauthorized users. In
                        this case, sshd will not allow it to be used unless the StrictModes option has been
                        set to “no”.



                        So. Can you ls -l ~/.ssh/autorized_keys and double-check that only the user can read that file?



                        To make sure nobody but the user can read this directory, use this: chmod -v a-w,u+w ~/.ssh/authorized_keys. Option -v is for chmod to inform you of the changes it made (if any), a-w,u+w is to remove the write permissions for all, and then give the user write permissions back.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Mar 28 '13 at 3:33

























                        answered Mar 23 '13 at 12:19









                        DitiDiti

                        1086




                        1086























                            0














                            Did you test adduser temipuser instead of useradd temipuser ???



                            linux manual for sshd_conf said:



                            AllowUsers



                                This keyword can be followed by a list of user name patterns, separated by 
                            spaces. If specified, login is allowed only for user names that match one of the
                            patterns. Only user names are valid; a numerical user ID is not recognized. **By
                            default, login is allowed for all users.** If the pattern takes the form USER@HOST
                            then USER and HOST are separately checked, restricting logins to particular users
                            from particular hosts. The allow/deny directives are processed in the following
                            order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.


                            So you don't have to add AllowUsers and if you add this option I don't think it prevent from remote root login if you enabled PermitRootLogin






                            share|improve this answer




























                              0














                              Did you test adduser temipuser instead of useradd temipuser ???



                              linux manual for sshd_conf said:



                              AllowUsers



                                  This keyword can be followed by a list of user name patterns, separated by 
                              spaces. If specified, login is allowed only for user names that match one of the
                              patterns. Only user names are valid; a numerical user ID is not recognized. **By
                              default, login is allowed for all users.** If the pattern takes the form USER@HOST
                              then USER and HOST are separately checked, restricting logins to particular users
                              from particular hosts. The allow/deny directives are processed in the following
                              order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.


                              So you don't have to add AllowUsers and if you add this option I don't think it prevent from remote root login if you enabled PermitRootLogin






                              share|improve this answer


























                                0












                                0








                                0







                                Did you test adduser temipuser instead of useradd temipuser ???



                                linux manual for sshd_conf said:



                                AllowUsers



                                    This keyword can be followed by a list of user name patterns, separated by 
                                spaces. If specified, login is allowed only for user names that match one of the
                                patterns. Only user names are valid; a numerical user ID is not recognized. **By
                                default, login is allowed for all users.** If the pattern takes the form USER@HOST
                                then USER and HOST are separately checked, restricting logins to particular users
                                from particular hosts. The allow/deny directives are processed in the following
                                order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.


                                So you don't have to add AllowUsers and if you add this option I don't think it prevent from remote root login if you enabled PermitRootLogin






                                share|improve this answer













                                Did you test adduser temipuser instead of useradd temipuser ???



                                linux manual for sshd_conf said:



                                AllowUsers



                                    This keyword can be followed by a list of user name patterns, separated by 
                                spaces. If specified, login is allowed only for user names that match one of the
                                patterns. Only user names are valid; a numerical user ID is not recognized. **By
                                default, login is allowed for all users.** If the pattern takes the form USER@HOST
                                then USER and HOST are separately checked, restricting logins to particular users
                                from particular hosts. The allow/deny directives are processed in the following
                                order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.


                                So you don't have to add AllowUsers and if you add this option I don't think it prevent from remote root login if you enabled PermitRootLogin







                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                answered Jun 26 '13 at 7:51









                                Sassan torabkheslatSassan torabkheslat

                                1057




                                1057























                                    0














                                    Check the /etc/ssh/sshd_config file. Check if the "PasswordAuthentication" line is set to "no". Change this to "yes" and save the file. You have to do this as sudo. Once file is saved restart using command "sudo service ssh restart"






                                    share|improve this answer








                                    New contributor




                                    grajnikanth is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                    Check out our Code of Conduct.

























                                      0














                                      Check the /etc/ssh/sshd_config file. Check if the "PasswordAuthentication" line is set to "no". Change this to "yes" and save the file. You have to do this as sudo. Once file is saved restart using command "sudo service ssh restart"






                                      share|improve this answer








                                      New contributor




                                      grajnikanth is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.























                                        0












                                        0








                                        0







                                        Check the /etc/ssh/sshd_config file. Check if the "PasswordAuthentication" line is set to "no". Change this to "yes" and save the file. You have to do this as sudo. Once file is saved restart using command "sudo service ssh restart"






                                        share|improve this answer








                                        New contributor




                                        grajnikanth is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                        Check out our Code of Conduct.










                                        Check the /etc/ssh/sshd_config file. Check if the "PasswordAuthentication" line is set to "no". Change this to "yes" and save the file. You have to do this as sudo. Once file is saved restart using command "sudo service ssh restart"







                                        share|improve this answer








                                        New contributor




                                        grajnikanth is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                        Check out our Code of Conduct.









                                        share|improve this answer



                                        share|improve this answer






                                        New contributor




                                        grajnikanth is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                        Check out our Code of Conduct.









                                        answered 19 mins ago









                                        grajnikanthgrajnikanth

                                        1




                                        1




                                        New contributor




                                        grajnikanth is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                        Check out our Code of Conduct.





                                        New contributor





                                        grajnikanth is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                        Check out our Code of Conduct.






                                        grajnikanth is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                        Check out our Code of Conduct.























                                            -1














                                            Remove any failures login counts , reset with below command:



                                            pam_tally2 --reset -u username


                                            use this command to null the entries



                                            cp /dev/null /var/log/lastlog





                                            share|improve this answer






























                                              -1














                                              Remove any failures login counts , reset with below command:



                                              pam_tally2 --reset -u username


                                              use this command to null the entries



                                              cp /dev/null /var/log/lastlog





                                              share|improve this answer




























                                                -1












                                                -1








                                                -1







                                                Remove any failures login counts , reset with below command:



                                                pam_tally2 --reset -u username


                                                use this command to null the entries



                                                cp /dev/null /var/log/lastlog





                                                share|improve this answer















                                                Remove any failures login counts , reset with below command:



                                                pam_tally2 --reset -u username


                                                use this command to null the entries



                                                cp /dev/null /var/log/lastlog






                                                share|improve this answer














                                                share|improve this answer



                                                share|improve this answer








                                                edited Nov 30 '16 at 11:22









                                                DarkHeart

                                                3,51432340




                                                3,51432340










                                                answered Nov 30 '16 at 11:20









                                                Tarun SharmaTarun Sharma

                                                1




                                                1






























                                                    draft saved

                                                    draft discarded




















































                                                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                                                    • Please be sure to answer the question. Provide details and share your research!

                                                    But avoid



                                                    • Asking for help, clarification, or responding to other answers.

                                                    • Making statements based on opinion; back them up with references or personal experience.


                                                    To learn more, see our tips on writing great answers.




                                                    draft saved


                                                    draft discarded














                                                    StackExchange.ready(
                                                    function () {
                                                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f67921%2flinux-user-not-able-to-login%23new-answer', 'question_page');
                                                    }
                                                    );

                                                    Post as a guest















                                                    Required, but never shown





















































                                                    Required, but never shown














                                                    Required, but never shown












                                                    Required, but never shown







                                                    Required, but never shown

































                                                    Required, but never shown














                                                    Required, but never shown












                                                    Required, but never shown







                                                    Required, but never shown







                                                    Popular posts from this blog

                                                    CARDNET

                                                    Boot-repair Failure: Unable to locate package grub-common:i386

                                                    濃尾地震