[durenthal]

Hi.
I'm getting "Access Denied" when I try to login via SSH to my SuSe box. The service is running, but I'm being denied access. I've tried with multiple accounts, all with valid passwords. In (much) earlier versions of SuSe, I never had this problem, so I'm guessing there's a security setting somewhere I need to change... but I can't find it. Please help

[dylunio]

how are you trying to login?

ssh user@12.34.45.1

(replace user with a username, and 12.34.45.1 with the ip or hostname of the machine)

It should then prompt you for a password for the user, which you should enter.

Edit: you may also look into tcp wrappers

[anomie]

First of all, did you open up port 22?

Second, on the tcp wrappers note, you may have to explicitly provide an entry in /etc/hosts.allow.

An entry like

sshd : 192.168.1.201 : ALLOW

where 192.168.1.201 is the IP (or portion of IP, e.g. 192.168.1) you want to allow access.

[durenthal]

Originally Posted by anomie

First of all, did you open up port 22?

Of course. Had it not been open I wouldn't have been prompted for a uid and pwd.

[durenthal]

Originally Posted by dylunio

how are you trying to login?

ssh user@12.34.45.1

(replace user with a username, and 12.34.45.1 with the ip or hostname of the machine)

It should then prompt you for a password for the user, which you should enter.

I'm using putty from a windows box to ssh in. I get a valid ssh connection. The linux server prompts me for a uid and password. Both are correct. The linux server returns ACCESS DENIED.

It appears to be a permissions issue rather than a service issue.

[anomie]

Or perhaps a tcp wrappers issue, as we have both mentioned already. You might like to try it out.

[durenthal]

Adding an explicit entry for sshd in /etc/hosts.allow made no difference. Still get the same "Access denied" response after each login attempt.

[anomie]

I am beginning to suspect the putty client may be the problem. If there is an option in putty, make sure it is set to use ssh protocol 2.

It would be helpful if there was a Unix / Linux box you had access to so that you could try the plain CLI that was suggested, thus at least eliminating a screwy client software as the problem.

[durenthal]

No sooner said than done. I have multiple linux servers and only have this problem one the one server. I tried it from another linux box and it worked just fine, suggesting that the problem is indeed putty. Putty is configured for v2 as preferred. Setting it to v2 only fixes the issue.

Thx.

[SillyChild]

I got the same problem after having a clean SuSE 9.1 install. It will authenticate successfully, but then kick me out I'm trying to ssh from another linux box.

Here is an example:

prompt:> ssh sillychild@***.***.***.***
Keyboard-interactive:
Password:
Keyboard-interactive:
Authentication successful.
prompt:> (back to the promt of client machine)

It says authentication successful, but then kicks me out. Any idea what is going wrong?

Just for your reference, here is sshd_config file:

#       $OpenBSD: sshd_config,v 1.68 2003/12/29 16:39:50 millert Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey for protocol version 1
HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
#GSSAPIEnableMITMAttack no

# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication' and 'PermitEmptyPasswords'
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
UseLogin yes
#UsePrivilegeSeparation yes
PermitUserEnvironment yes
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem       sftp    /usr/lib/ssh/sftp-server

Thanks.