SSH struggle

Hi,

Running SSH on a Debian Sarge (kernel 2.6.8-2-386).
Port 22 is listening, firewall is open for port 22 on my LAN.

When I SSH from a Windows machine on the LAN using SecureCRT with SSH2, the
RSA key is read/loaded by the client, but I get the flw error message:

SecureCRT has disconnected from the server. Reason: Unable to authenticate
using any of the configured authentication methods.

In /var/log/auth.log there is no trace of any SSH login attempt.
By comparison my "straight" FTP connection from the same client machine are
all successfull, and properly logged.

I'm sure of the settings of the client, as it functions properly on other
servers using ssh2 and password authentication.

So were do I look on the server side ?


Thanks,
Dominique

On Wed, 30 Nov 2005 00:59:12 +0100, Dominique Gibon
<(E-Mail Removed)> wrote:

>Hi,
>
>Running SSH on a Debian Sarge (kernel 2.6.8-2-386).
>Port 22 is listening, firewall is open for port 22 on my LAN.
>
>When I SSH from a Windows machine on the LAN using SecureCRT with SSH2, the
>RSA key is read/loaded by the client, but I get the flw error message:
>
>SecureCRT has disconnected from the server. Reason: Unable to authenticate
>using any of the configured authentication methods.
>
>In /var/log/auth.log there is no trace of any SSH login attempt.
>By comparison my "straight" FTP connection from the same client machine are
>all successfull, and properly logged.
>
>I'm sure of the settings of the client, as it functions properly on other
>servers using ssh2 and password authentication.
>
>So were do I look on the server side ?
>
>
>Thanks,
>Dominique

I dont know debian but does "man sshd_config" help or looking in
/etc/ssh
--

Benway

Dominique Gibon <(E-Mail Removed)> wrote:
> Running SSH on a Debian Sarge (kernel 2.6.8-2-386).
> Port 22 is listening, firewall is open for port 22 on my LAN.

> When I SSH from a Windows machine on the LAN using SecureCRT with SSH2, the
> RSA key is read/loaded by the client, but I get the flw error message:
> SecureCRT has disconnected from the server. Reason: Unable to authenticate
> using any of the configured authentication methods.

What happens when you telnet from this Windows client to the server on
port 22? For example, "telnet debianserver 22".


> In /var/log/auth.log there is no trace of any SSH login attempt.

It sounds like you're not talking to the correct machine, or the
firewall isn't properly open.


> By comparison my "straight" FTP connection from the same client machine are
> all successfull, and properly logged.

OK, so maybe you have the correct machine.


Let us know the result of the "telnet" test suggested above.
Chris

chris-(E-Mail Removed) wrote:


> What happens when you telnet from this Windows client to the server on
> port 22? For example, "telnet debianserver 22".

Server response:

# SSH=2.0-OpenSSH_3.8.1p1. Debian-8.sarge.4

# Protocol mismatch

This does not strike me as strange; with telnet on port 22 ?



/var/log/ auth.log entry: ocalhost sshd[3976]: Bad protocol version
identification '' from ::ffff:192.168.0.2


At least this confirms it is the right server....

Dominique Gibon wrote:


Problem solved, albeit in a strange way.

SecureCRT doesn't seem to do the job, though it works very well to connect
to Unix machines.

Good old simple PuTTY does not have a problem............

> So were do I look on the server side ?

If you can become root on the server, turn off sshd temporarily and then
run sshd in debug mode. This gives you a server that will handle one
connection (with lots of diagnostics) and then exit. [There's probably
a way to make it write all this to a log file.]

Caveat: If you can't walk down the hall to the server, make sure you
have some sort of connection to it open so that you can restart sshd.

chris-(E-Mail Removed) wrote:
> What happens when you telnet from this Windows client to the server on
> port 22? For example, "telnet debianserver 22".

Dominique Gibon <(E-Mail Removed)> wrote:
> Server response:
> # SSH=2.0-OpenSSH_3.8.1p1. Debian-8.sarge.4
> # Protocol mismatch

> This does not strike me as strange; with telnet on port 22 ?

The point of this exercise was to confirm that the Windows PC could
successfully connect to an SSH daemon on your Debian server.

I agree with you that the Protocol Mismatch is to be expected; that's
fine.


> /var/log/ auth.log entry: localhost sshd[3976]: Bad protocol version
> identification '' from ::ffff:192.168.0.2

Good. This shows that the server really is seeing a connection from the
client.

However, this also shows that at least your server is talking IPv6; the
equivalent message on my IPv4-only system is this:

sshd[2686]: Bad protocol version identification '' from 127.0.0.1

Maybe that's the problem - your Windows and Debian systems are talking
IPv6, but SecureCRT doesn't understand IPv6?

Chris

<chris-(E-Mail Removed)> a écrit dans le message de news:
ko2663-(E-Mail Removed)...
>
> Maybe that's the problem - your Windows and Debian systems are talking
> IPv6, but SecureCRT doesn't understand IPv6?
>
You're right, Chris. I have a relatively old version of SecureCRT that does
not speak IPv6.
With PuTTY everything is fine.
Thanks.

> Maybe that's the problem - your Windows and Debian systems are talking
> IPv6, but SecureCRT doesn't understand IPv6?

Dominique Gibon <(E-Mail Removed)> wrote:
> You're right, Chris. I have a relatively old version of SecureCRT that does
> not speak IPv6.

You might want to check the AddressFamily value in your sshd_config file
on your server. The possible values are "any", "inet", or "inet6". The
default is "any", but you may want to try changing yours to "inet" (force
IPv4 only). If it's "inet6" then your ssh daemon has been explicitly set
to talk only IPv6. Obviously this would be a problem since your client
doesn't understand IPv6 ;-)

Chris