Linux User not able to login
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
|
show 4 more comments
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
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 setLogLevel
toDebug
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, yourtemipuser
is 9... Can you log in locally (i.e., not over ssh)? BTW, I don't know offhand ifsshd
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 runssh 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
|
show 4 more comments
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
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
linux login putty login-manager
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 setLogLevel
toDebug
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, yourtemipuser
is 9... Can you log in locally (i.e., not over ssh)? BTW, I don't know offhand ifsshd
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 runssh 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
|
show 4 more comments
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 setLogLevel
toDebug
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, yourtemipuser
is 9... Can you log in locally (i.e., not over ssh)? BTW, I don't know offhand ifsshd
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 runssh 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
|
show 4 more comments
6 Answers
6
active
oldest
votes
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.
add a comment |
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.
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
add a comment |
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.
add a comment |
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
add a comment |
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"
New contributor
add a comment |
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
edited Jul 27 '13 at 17:08
bahamat
24.6k15090
24.6k15090
answered Jun 26 '13 at 11:00
mezimezi
6841917
6841917
add a comment |
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Mar 28 '13 at 3:33
answered Mar 23 '13 at 12:19
DitiDiti
1086
1086
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Jun 26 '13 at 7:51
Sassan torabkheslatSassan torabkheslat
1057
1057
add a comment |
add a comment |
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"
New contributor
add a comment |
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"
New contributor
add a comment |
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"
New contributor
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"
New contributor
New contributor
answered 19 mins ago
grajnikanthgrajnikanth
1
1
New contributor
New contributor
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
edited Nov 30 '16 at 11:22
DarkHeart
3,51432340
3,51432340
answered Nov 30 '16 at 11:20
Tarun SharmaTarun Sharma
1
1
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 setLogLevel
toDebug
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 ifsshd
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