# SSH Users...

## peehole

Not sure if this is the appropriate forum for this...

I added my underprivlidged user to the sshd group (kuser) but he still cannot login? Also, is it better to have xinetd handle the requests for SSH? 

Thanks

----------

## rac

 *peehole wrote:*   

> Not sure if this is the appropriate forum for this...

 

Looks fine to me.

 *Quote:*   

> I added my underprivlidged user to the sshd group (kuser)

 

This should not be necessary.

 *Quote:*   

> but he still cannot login?

 

Are you sure your user has a login shell?  What is the last field of the /etc/passwd entry for him?

 *Quote:*   

> Also, is it better to have xinetd handle the requests for SSH?

 

I don't think so, and neither does the default Gentoo installation.  By default, sshd runs in standalone mode, and xinetd (or any inetd, for that matter), is not needed at all in many Gentoo installations.  I have yet to install an inetd on any Gentoo machine.

----------

## peehole

Thanks..

User did not have a login shell... 

What would you suggest for security around sshd?

----------

## rac

 *peehole wrote:*   

> What would you suggest for security around sshd?

 

Some or all of the following, depending on your situation: Use an IP filtering firewall to block access to it from hosts you don't need to access it. 

Use tcpwrappers support (/etc/hosts.allow and /etc/hosts.deny) to further restrict access

Do not permit root to log in via ssh

Disable SSH protocol 1

Disable password authentication, allowing only public key authentication

Enable privilege separation

----------

## klieber

 *peehole wrote:*   

> I added my underprivlidged user to the sshd group (kuser) but he still cannot login? Also, is it better to have xinetd handle the requests for SSH?

 

Unless you specifically add:

```
AllowGroups    sshd
```

to your /etc/ssh/sshd_config file, sshd doesn't look at the sshd group memebership since that line isn't in the config file by default.  (at least, not on Gentoo)

--kurt

----------

## kashani

 *peehole wrote:*   

>  is it better to have xinetd handle the requests for SSH? 
> 
> Thanks

 

Actually its a really bad idea. sshd will be started each time a user connects and will generate new keys which will cause a few second delay for the passwd prompt. It may not be as dramatic as it was when I made the mistake of doing the same thing using ssh 1.2.x on a Sparc 2. I believe it was almost a minute before I got a prompt.  :Smile: 

rac's suggestions covered just about all the security features except two.

1. chroot jail for users

This is a big pain in the ass and will take you some time to get things working well for all users. Unless you're at least an intermediate user/admin I'd stay away from this. 

2. scponly shell

This is a special shell for users that only allows them to scp or sftp into their account. There are some problems with this, but it's a nice solution if you don't want users to have login priveleges. You can find it by searching for scponly on freshmeat.net.

kashani

----------

## Xor

hi,

 *Quote:*   

> 2. scponly shell
> 
> This is a special shell for users that only allows them to scp or sftp into their account. There are some problems with this, but it's a nice solution if you don't want users to have login priveleges. You can find it by searching for scponly on freshmeat.net. 

 

cool... do you have first-hand intel about it? Would be nice to have some info (especialy the problems you mentioned)

tnx

xor

----------

## kashani

Installation

      No problems under gentoo. I think by default it adds a line in your /etc/shells file, but you should double check. Then it's just a matter of setting users to use the scponly shell vs /bin/bash or whatever. 

sftp server

      I had problems getting sftp to work for users with the scponly shell. The fix was to create a sym link to the sftp-server in the users path.  Something like

ls -sf /usr/lib/misc/sftp-server /usr/local/bin/sftp-server

security

      There were some security issues discovered last month. Apparently a user can modify their environment variables via their local .ssh folder which would allow the to excute code. The fix is to own their home dir to root and create a sub folder owned by the user for the user's use.

Hope that helps.

kashani

----------

