putty to client CentOS 4 server auth error after username

[Rob Hausler]

When I try to log into a clients CentOS4 server via putty from remote I get asked for username, I type root and hit enter and then I get "No supported authentication methods left to try!" and my connection is lost.

However if I run putty from a PC on the clients lan it works fine.

any thoughts? same putty edition same settings - it used to work a few mnths back

[Gfuss]

Rob,
It sounds like a network setting change (e.g. firewall). If it worked before, and you haven't changed anything on the putty computer, they may have either changed the 'main' firewall or altered the iptables on the CentOS machine to only accept SSH/Telnet from local connections.

I'd try to sniff some packets (e.g. WireShark) to see what the actual packets are doing just before the error message.

-Gfuss

[Steven Schweda]

I'm not a user, but from what I read, "PuTTY
is a free implementation of Telnet and SSH
for Win32 and Unix platforms, [...]". Are
you using it as a Telnet client or as an SSH
client? The "No supported authentication
methods" message sounds like SSH.

> [...] if I run putty from a PC on the
> clients lan [...]

On what do you run it when you're "from
remote"?

> [...] same putty edition same settings
> [...]

What's the same as what, where?

Does using putty's "-v" option tell you
anything interesting?

[Jimmy Vance]

When I see this it's usually the ssh protocol setting in putty being set to 1 when it needs to be set to protocol version 2

[Rob Hausler]

Ok some answers to the questions.

Yes I am using Putty to ssh not telent
I can connect on the lan using a XP pro workstation using the same version of putty (have tried version 0.58 & 0.60)

I try from remote again using XP Pro workstation and Putty 0.58 & 0.60

I even tried this morning to remove openssh-server and reinstall using yum to do both.

One I checked the IPTAbles and listed below.

:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d xxx.0.0.xxx -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

I will make a note that I cannot ssh from the server to an external location.. i type,,
ssh address
i get a blank line and nothing.. till I quit ssh.

Hope this might enlighten some.

[Gfuss]

I can see the line for SSH in the iptables.
Being green to iptables, it doesn't appear to be blocking SSH

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j

Append the rule (-A - as order doesn't matter), the rule is for NEW connections via tcp with a destination of 22 (ssh). It ends with -j, however, and I'm wondering if it should be -j ACCEPT to jump to ACCEPT.

While this doesn't help much, I still think it is a firewall issue especially since you are unable to connect from the server to another location via SSH.

[Gfuss]

Rob,
I just realized the SSH line does end with -j ACCEPT, however, I didn't have it in my clipboard. Disregard my posting above about adding ACCEPT.

[Matti_Kurkela]

If the error message is "No supported authentication methods left to try", then that means SSH's authentication method negotiation has successfully started. It proves that a network connection is already established, so the firewall is not an issue.

Maybe the password authentication (for root at least) has been disabled for users coming from any place other than the client's LAN?

If the server is accessible over the Internet, there are various worms and other malware attempting to guess weak root passwords.

The current recommended practice for SSH is to *not* allow direct root logins over the Internet, and consider using SSH public key authentication whenever possible.

If your client has a requirement to keep a log of people using root-level access, direct root login is a *bad* thing: it does not create a record of *who* used the root-level access, just that someone did. This is an instant security audit failure in most security-sensitive environments.

MK

[Rob Hausler]

Ok so if this is the case - how do we get around the problem?

I thought that if a user in passwd had /bin/bash on the end of their record they had access to ssh?

Or am I missing something?

or is there a better way of doing this?
All howto's seem to relate to internal only examples..

[Matti_Kurkela]

To debug this problem, you must have access to the server, or get help from someone who has.

Examine the configuration file /etc/ssh/sshd_config on the server. Refer to "man sshd_config" for details.

If the "PermitRootLogin" option is set to any value other than "yes", you are not going to get in using password authentication with the username "root". (There are four possible settings, not just "yes" or "no".)

If the sshd_config file contains any AllowUsers/DenyUsers/AllowGroups/DenyGroups keywords, only the allowed users can log in using SSH.

If the "PasswordAuthentication" is set to "no", SSH will require the use of stronger authentication methods from all users. The error message suggests this might be the cause.

If, as you say, you could login to the server as root while not on the client's LAN a few months ago, the server's security was in a very poor state back then. Maybe someone has since then clued up and made the server more secure.

MK

[Rob Hausler]

here is my sshd_config

# $OpenBSD: sshd_config,v 1.69 2004/05/23 23:59:53 dtucker Exp $

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

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

# 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
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

#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 yes
#PermitEmptyPasswords no
PasswordAuthentication yes

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

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

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes

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

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server

[Jimmy Vance]

To get the exact error your reporting, I had to go into the putty options for SSH and de-select an option.

Click the + next to SSH in the catagory menu to expand the ssh options. Under Auth make sure that the check box is selected for

Attemp "keyboard-interactive" auth (SSH-2)

When I de-selected this option I got the error your reporting

[Rob Hausler]

We arent running any gui..

Found the fault.. we were actually supplied with an incorrect IP address for the site - wo i dont know who's site we were trying to get into. sorry..


I replaced the config and it works fine. inbound..


However outbound is a different story. i cannot ssh out to other sites. I might start a new thread for that one.

[Rob Hausler]

I went back to square one on site yesterday..and found we had been given the wrong IP supplied from client.