I have two users who are members of group ssh. In my sshd_config file there is a line like this:
----------------------
AllowGroups ssh
----------------------

user1 can connect to machine:

#:/etc$ ssh levent@server
luser1@server's password:
Linux server 2.4.17 #8 SMP Tue Jan 15 19:28:26 EET 2002 i686 unknown

Most of the programs included with the Debian GNU/Linux system are
freely redistributable; the exact distribution terms for each program
are described in the individual files in /usr/share/doc/*/copyright

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

user1@intrasrv:~$

user2 just can't!:

#:/etc$ ssh user2@server
user2@server's password:
Permission denied, please try again.
user2@server's password:
Permission denied, please try again.
user2@server's password:
Permission denied (publickey,password).

I have no rule defined in hosts.allow and hosts.deny yet.

Does anybody know why this happens?

I'm not familiar with the AllowGroups.

However you need to check the basics:

Is user2's home directory and .ssh subdirectory writable by ONLY user2 as it needs to be? (Make sure you check parents of the the home directory - write for all on the parent equates to write for all on the subdirectory.)

Does user2 have a password set in /etc/passwd?
(You don't have to give the password on ssh login with .shosts or authorized_keys but it still has to exist.)

ssh will always fail if the setup is not deemed secure due to open permissions or lack of a password. The reasoning being that using "secure" shell implies you want to be able to trust the connection you're making. If its wide open anyone can change it without you knowing.

>>Is user2's home directory and .ssh subdirectory writable by ONLY user2 as it >>needs to be? (Make sure you check parents of the the home directory - write
>>for all on the parent equates to write for all on the subdirectory.)

I didn't understand this.

>Does user2 have a password set in /etc/passwd?
>(You don't have to give the password on ssh login with .shosts or >authorized_keys but it still has to exist.)

Yes user has password.


Actually no other user is allowed accept user1 which is me!

No other user?

In what you wrote originally you show a "ssh levent@server" and later a "ssh user2@server".

The first one means login to "server" as the user, "levent".

The second one means login to "server" as the user, "user2".

That is to say "levent" and "user2" are separate users. If they are not then your ssh commands would not work as typed simply because the user you are specifying does not exist.

If I have a host named "localmach" and another host named "remotemach". I can have one user on localmach named "localuser". I can ALSO have a user named "localuser"on remotemach. I can also have another user named remoteuser on remotemach that doesn't exist on localmach.

On localmach logged in as localuser I can type:
ssh localuser@remotemach - To become user localuser on the host remotemach
ssh remoteuser@remotemach - To become user remoteuser on the host remotemach.

In fact I could also do the above if I'm the root user on localmach.

By default this would establish a connection but prompt me for a password. The .shosts or authorized_keys can be setup to avoid requiring a password because you tell it to trust certain connections from localmach.

Not sure what you didn't understand about my first comment. Directories and files have permissions (a/k/a mode) on them. If you do:
ls -l

You see a display of files that starts with their permissions. Each character in the first column has a meaning as for example:
drwxrwxrwx

The "d" tellls you it is a directory (not really a permission but rather an identifier). The first rwx tells you the user (the one that owns the file) has r(ead) w(rite) e(x)ecute permissions on the file. The second rwx tells you the group has those same permissions and the last rwx tells you everyone else has them.

Compare this to:
lrwxr-x-r--

The "l" tells you it is a symbolic link. The first rwx tells you same as above. The r-x after that tells you the group only has r(ead) and e(x)ecute permissions but not w(rite) permissions. The r-- at the end tells you that everyone else has ONLY r(ead) permissions.

If you don't understand the above you need to have a look at the following:
man ls (look at the "-l" flag for all the info it gives).
man chmod - Tells you about setting permissions for a file
man chown - Tells you about setting ownership for a file
man chgrp - Tells you about setting group memebership for a file

P.S. To others reading the thread: I know permissions on the slink don't really determine permission to the underlying file. Just using it for illustration purposes.

Sorry i replaced levent with user1 but forgot a replacement My account ( levent ) logs in but all the others cannot log in.

"no other users" and "all others" is somewhat confusing. What "others" are there if there are no other users?

Rather than just giving the command you typed specify differences where they exist such as:

"Logged in as user1 on host1 I did ssh user1@host2"

-OR-

"Logged in as user1 on host1 I did ssh user2@host2"

-OR-

"Logged in as user1 on host1 I did ssh user2@host1"

Using that same syntax just express what did work and what didn't like:

"Logged in as user1 on host1 I was able to successfully do ssh user1@host2 but logged in as user2 on host1 I couldn't get ssh user1@host2 to work."

Right now what you last said makes it sound like:

"Logged in as unknown user on unknown host I was able to successfully login as some user @ some host which may or may not be the same host and user. Despite having no other users I couldn't login from one of those non-existent users the same way."

I'm sure that's not what you intended but that's how its coming through.