DenyUsers userid@host issue in sshd_config
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
In order to restrict shared users moving around environments, I implemented DenyUsers userID@host. But this is working only on few hosts. There are some hosts where I implemented the same in sshd_config but not working. Can someone help from where I can troubleshoot the issue?
users configuration sshd
edited Feb 8 at 15:43
Jeff Schaller
31.3k846105
asked Feb 8 at 15:29
user227863
144
 |Â
show 8 more comments
up vote
0
down vote
favorite
In order to restrict shared users moving around environments, I implemented DenyUsers userID@host. But this is working only on few hosts. There are some hosts where I implemented the same in sshd_config but not working. Can someone help from where I can troubleshoot the issue?
users configuration sshd
edited Feb 8 at 15:43
Jeff Schaller
31.3k846105
asked Feb 8 at 15:29
user227863
144
“Not working†means... users can log in to places where you don’t want them to?
– Jeff Schaller
Feb 8 at 15:43
userID is able to ssh from restricted host1 whereas userID should not be able to ssh from the host per sshd_config rule DenyUsers userID@host1
– user227863
Feb 8 at 15:48
2
@k.Cyborg at iptables level you will not get access to information related to user ids
– Patrick Mevzek
Feb 8 at 16:15
1
@user227863 try usinguserid@ip.addressin the DenyHosts rule rather thanuserid@hostname. If there's a DNS problem causing the IP address to fail to be resolved (e.g. your .in-addr.arpa zone isn't correct) then the ssh client's hostname will not be known to the ssh server....so user@hostname will fail to be blocked.
– cas
Feb 9 at 4:21
1
@k.Cyborg iptables is the wrong tool for this. iptables can block entire hosts (actually IP addresses) from connecting to particular ports (e.g. sshd on port 22). It can NOT block specific users from those IP addresses while allowing others - withiptables, blocking is all or nothing. TheDenyUsersconfiguration directive in/etc/ssh/sshd_configdoes that.
– cas
Feb 9 at 4:23
 |Â
show 8 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
In order to restrict shared users moving around environments, I implemented DenyUsers userID@host. But this is working only on few hosts. There are some hosts where I implemented the same in sshd_config but not working. Can someone help from where I can troubleshoot the issue?
users configuration sshd
edited Feb 8 at 15:43
Jeff Schaller
31.3k846105
asked Feb 8 at 15:29
user227863
144
In order to restrict shared users moving around environments, I implemented DenyUsers userID@host. But this is working only on few hosts. There are some hosts where I implemented the same in sshd_config but not working. Can someone help from where I can troubleshoot the issue?
users configuration sshd
edited Feb 8 at 15:43
Jeff Schaller
31.3k846105
asked Feb 8 at 15:29
user227863
144
edited Feb 8 at 15:43
Jeff Schaller
31.3k846105
edited Feb 8 at 15:43
Jeff Schaller
31.3k846105
edited Feb 8 at 15:43
Jeff Schaller
31.3k846105
31.3k846105
asked Feb 8 at 15:29
user227863
144
asked Feb 8 at 15:29
user227863
144
asked Feb 8 at 15:29
user227863
144
144
“Not working†means... users can log in to places where you don’t want them to?
– Jeff Schaller
Feb 8 at 15:43
userID is able to ssh from restricted host1 whereas userID should not be able to ssh from the host per sshd_config rule DenyUsers userID@host1
– user227863
Feb 8 at 15:48
2
@k.Cyborg at iptables level you will not get access to information related to user ids
– Patrick Mevzek
Feb 8 at 16:15
1
@user227863 try usinguserid@ip.addressin the DenyHosts rule rather thanuserid@hostname. If there's a DNS problem causing the IP address to fail to be resolved (e.g. your .in-addr.arpa zone isn't correct) then the ssh client's hostname will not be known to the ssh server....so user@hostname will fail to be blocked.
– cas
Feb 9 at 4:21
1
@k.Cyborg iptables is the wrong tool for this. iptables can block entire hosts (actually IP addresses) from connecting to particular ports (e.g. sshd on port 22). It can NOT block specific users from those IP addresses while allowing others - withiptables, blocking is all or nothing. TheDenyUsersconfiguration directive in/etc/ssh/sshd_configdoes that.
– cas
Feb 9 at 4:23
 |Â
show 8 more comments
“Not working†means... users can log in to places where you don’t want them to?
– Jeff Schaller
Feb 8 at 15:43
userID is able to ssh from restricted host1 whereas userID should not be able to ssh from the host per sshd_config rule DenyUsers userID@host1
– user227863
Feb 8 at 15:48
2
@k.Cyborg at iptables level you will not get access to information related to user ids
– Patrick Mevzek
Feb 8 at 16:15
1
@user227863 try usinguserid@ip.addressin the DenyHosts rule rather thanuserid@hostname. If there's a DNS problem causing the IP address to fail to be resolved (e.g. your .in-addr.arpa zone isn't correct) then the ssh client's hostname will not be known to the ssh server....so user@hostname will fail to be blocked.
– cas
Feb 9 at 4:21
1
@k.Cyborg iptables is the wrong tool for this. iptables can block entire hosts (actually IP addresses) from connecting to particular ports (e.g. sshd on port 22). It can NOT block specific users from those IP addresses while allowing others - withiptables, blocking is all or nothing. TheDenyUsersconfiguration directive in/etc/ssh/sshd_configdoes that.
– cas
Feb 9 at 4:23
“Not working†means... users can log in to places where you don’t want them to?
– Jeff Schaller
Feb 8 at 15:43
“Not working†means... users can log in to places where you don’t want them to?
– Jeff Schaller
Feb 8 at 15:43
userID is able to ssh from restricted host1 whereas userID should not be able to ssh from the host per sshd_config rule DenyUsers userID@host1
– user227863
Feb 8 at 15:48
userID is able to ssh from restricted host1 whereas userID should not be able to ssh from the host per sshd_config rule DenyUsers userID@host1
– user227863
Feb 8 at 15:48
2
2
@k.Cyborg at iptables level you will not get access to information related to user ids
– Patrick Mevzek
Feb 8 at 16:15
@k.Cyborg at iptables level you will not get access to information related to user ids
– Patrick Mevzek
Feb 8 at 16:15
1
1
@user227863 try using
userid@ip.address in the DenyHosts rule rather than userid@hostname. If there's a DNS problem causing the IP address to fail to be resolved (e.g. your .in-addr.arpa zone isn't correct) then the ssh client's hostname will not be known to the ssh server....so user@hostname will fail to be blocked.– cas
Feb 9 at 4:21
@user227863 try using
userid@ip.address in the DenyHosts rule rather than userid@hostname. If there's a DNS problem causing the IP address to fail to be resolved (e.g. your .in-addr.arpa zone isn't correct) then the ssh client's hostname will not be known to the ssh server....so user@hostname will fail to be blocked.– cas
Feb 9 at 4:21
1
1
@k.Cyborg iptables is the wrong tool for this. iptables can block entire hosts (actually IP addresses) from connecting to particular ports (e.g. sshd on port 22). It can NOT block specific users from those IP addresses while allowing others - with
iptables, blocking is all or nothing. The DenyUsers configuration directive in /etc/ssh/sshd_config does that.– cas
Feb 9 at 4:23
@k.Cyborg iptables is the wrong tool for this. iptables can block entire hosts (actually IP addresses) from connecting to particular ports (e.g. sshd on port 22). It can NOT block specific users from those IP addresses while allowing others - with
iptables, blocking is all or nothing. The DenyUsers configuration directive in /etc/ssh/sshd_config does that.– cas
Feb 9 at 4:23
 |Â
show 8 more comments
1 Answer
1
active
oldest
votes
up vote
1
down vote
ok. I finally checked secure logs and it turns out to be DNS name resolving issue. I quickly used the protocol DenyUsers userID@IPAddress as per @cas solution and it worked.
answered Feb 10 at 10:27
user227863
144
you should accept your own answer to mark the question as resolved.
– cas
Feb 15 at 1:23
Apologies. Not aware of this. Will ensure I donot add my comments as answer @cas.
– user227863
Feb 15 at 11:47
That's not what I was saying. It's a good answer, it solved your problem, you should accept it. It's perfectly OK on SE sites to accept your own answer.
– cas
Feb 15 at 12:27
oh sorry misread it :) @cas
– user227863
Feb 15 at 12:30
No problem. It didn't occur to me that my comment might have been misread as sarcastic. Really, there was and is no sarcasm intended. And it's good to have Questions resolved with an accepted Answer.
– cas
Feb 15 at 12:33
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
ok. I finally checked secure logs and it turns out to be DNS name resolving issue. I quickly used the protocol DenyUsers userID@IPAddress as per @cas solution and it worked.
answered Feb 10 at 10:27
user227863
144
you should accept your own answer to mark the question as resolved.
– cas
Feb 15 at 1:23
Apologies. Not aware of this. Will ensure I donot add my comments as answer @cas.
– user227863
Feb 15 at 11:47
That's not what I was saying. It's a good answer, it solved your problem, you should accept it. It's perfectly OK on SE sites to accept your own answer.
– cas
Feb 15 at 12:27
oh sorry misread it :) @cas
– user227863
Feb 15 at 12:30
No problem. It didn't occur to me that my comment might have been misread as sarcastic. Really, there was and is no sarcasm intended. And it's good to have Questions resolved with an accepted Answer.
– cas
Feb 15 at 12:33
add a comment |Â
up vote
1
down vote
ok. I finally checked secure logs and it turns out to be DNS name resolving issue. I quickly used the protocol DenyUsers userID@IPAddress as per @cas solution and it worked.
answered Feb 10 at 10:27
user227863
144
you should accept your own answer to mark the question as resolved.
– cas
Feb 15 at 1:23
Apologies. Not aware of this. Will ensure I donot add my comments as answer @cas.
– user227863
Feb 15 at 11:47
That's not what I was saying. It's a good answer, it solved your problem, you should accept it. It's perfectly OK on SE sites to accept your own answer.
– cas
Feb 15 at 12:27
oh sorry misread it :) @cas
– user227863
Feb 15 at 12:30
No problem. It didn't occur to me that my comment might have been misread as sarcastic. Really, there was and is no sarcasm intended. And it's good to have Questions resolved with an accepted Answer.
– cas
Feb 15 at 12:33
add a comment |Â
up vote
1
down vote
up vote
1
down vote
ok. I finally checked secure logs and it turns out to be DNS name resolving issue. I quickly used the protocol DenyUsers userID@IPAddress as per @cas solution and it worked.
answered Feb 10 at 10:27
user227863
144
ok. I finally checked secure logs and it turns out to be DNS name resolving issue. I quickly used the protocol DenyUsers userID@IPAddress as per @cas solution and it worked.
answered Feb 10 at 10:27
user227863
144
answered Feb 10 at 10:27
user227863
144
answered Feb 10 at 10:27
user227863
144
answered Feb 10 at 10:27
user227863
144
144
you should accept your own answer to mark the question as resolved.
– cas
Feb 15 at 1:23
Apologies. Not aware of this. Will ensure I donot add my comments as answer @cas.
– user227863
Feb 15 at 11:47
That's not what I was saying. It's a good answer, it solved your problem, you should accept it. It's perfectly OK on SE sites to accept your own answer.
– cas
Feb 15 at 12:27
oh sorry misread it :) @cas
– user227863
Feb 15 at 12:30
No problem. It didn't occur to me that my comment might have been misread as sarcastic. Really, there was and is no sarcasm intended. And it's good to have Questions resolved with an accepted Answer.
– cas
Feb 15 at 12:33
add a comment |Â
you should accept your own answer to mark the question as resolved.
– cas
Feb 15 at 1:23
Apologies. Not aware of this. Will ensure I donot add my comments as answer @cas.
– user227863
Feb 15 at 11:47
That's not what I was saying. It's a good answer, it solved your problem, you should accept it. It's perfectly OK on SE sites to accept your own answer.
– cas
Feb 15 at 12:27
oh sorry misread it :) @cas
– user227863
Feb 15 at 12:30
No problem. It didn't occur to me that my comment might have been misread as sarcastic. Really, there was and is no sarcasm intended. And it's good to have Questions resolved with an accepted Answer.
– cas
Feb 15 at 12:33
you should accept your own answer to mark the question as resolved.
– cas
Feb 15 at 1:23
you should accept your own answer to mark the question as resolved.
– cas
Feb 15 at 1:23
Apologies. Not aware of this. Will ensure I donot add my comments as answer @cas.
– user227863
Feb 15 at 11:47
Apologies. Not aware of this. Will ensure I donot add my comments as answer @cas.
– user227863
Feb 15 at 11:47
That's not what I was saying. It's a good answer, it solved your problem, you should accept it. It's perfectly OK on SE sites to accept your own answer.
– cas
Feb 15 at 12:27
That's not what I was saying. It's a good answer, it solved your problem, you should accept it. It's perfectly OK on SE sites to accept your own answer.
– cas
Feb 15 at 12:27
oh sorry misread it :) @cas
– user227863
Feb 15 at 12:30
oh sorry misread it :) @cas
– user227863
Feb 15 at 12:30
No problem. It didn't occur to me that my comment might have been misread as sarcastic. Really, there was and is no sarcasm intended. And it's good to have Questions resolved with an accepted Answer.
– cas
Feb 15 at 12:33
No problem. It didn't occur to me that my comment might have been misread as sarcastic. Really, there was and is no sarcasm intended. And it's good to have Questions resolved with an accepted Answer.
– cas
Feb 15 at 12:33
add a comment |Â
Â
draft saved
draft discarded
Â
draft saved
draft discarded
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f422834%2fdenyusers-useridhost-issue-in-sshd-config%23new-answer', 'question_page');
);
Post as a guest
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
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
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
“Not working†means... users can log in to places where you don’t want them to?
– Jeff Schaller
Feb 8 at 15:43
userID is able to ssh from restricted host1 whereas userID should not be able to ssh from the host per sshd_config rule DenyUsers userID@host1
– user227863
Feb 8 at 15:48
2
@k.Cyborg at iptables level you will not get access to information related to user ids
– Patrick Mevzek
Feb 8 at 16:15
1
@user227863 try using
userid@ip.addressin the DenyHosts rule rather thanuserid@hostname. If there's a DNS problem causing the IP address to fail to be resolved (e.g. your .in-addr.arpa zone isn't correct) then the ssh client's hostname will not be known to the ssh server....so user@hostname will fail to be blocked.– cas
Feb 9 at 4:21
1
@k.Cyborg iptables is the wrong tool for this. iptables can block entire hosts (actually IP addresses) from connecting to particular ports (e.g. sshd on port 22). It can NOT block specific users from those IP addresses while allowing others - with
iptables, blocking is all or nothing. TheDenyUsersconfiguration directive in/etc/ssh/sshd_configdoes that.– cas
Feb 9 at 4:23