sftp/ftp failure from LINUX to Windows

[skt_skt]

Red Hat Enterprise Linux AS release 4 (Nahant Update 6)
source is a LINUX one and target is window machine and the public key from LINUX user is provided to import the key to get trutsed.

Not sure why it is failing. Any one has any suggetions??

$sftp -vvv -oIdentityFile=/home/applmgr/.ssh/id_rsa_weichert -oUser=test_ftp 12.166.37.243
Connecting to 12.166.37.243...
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 12.166.37.243 [12.166.37.243] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /home/applmgr/.ssh/id_rsa_weichert.
debug2: key_type_from_name: unknown key type '----'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Comment:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '----'
debug3: key_read: missing keytype
debug1: identity file /home/applmgr/.ssh/id_rsa_weichert type -1
ssh_exchange_identification: Connection closed by remote host
Couldn't read packet: Connection reset by peer
$


#telnet 12.166.37.243 22
Trying 12.166.37.243...
Connected to 12.166.37.243 (12.166.37.243).
Escape character is '^]'.
Connection closed by foreign host.

#telnet 65.246.198.243 22
Trying 65.246.198.243...
Connected to 65.246.198.243 (65.246.198.243).
Escape character is '^]'.
Connection closed by foreign host.

#telnet 12.166.37.243 21
Trying 12.166.37.243...
Connected to 12.166.37.243 (12.166.37.243).
Escape character is '^]'.
Connection closed by foreign host.

#telnet 65.246.198.243 21
Trying 65.246.198.243...
Connected to 65.246.198.243 (65.246.198.243).
Escape character is '^]'.
Connection closed by foreign host.

#nmap -v 12.166.37.243 -p 21

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2009-06-16 21:12 EDT
Initiating SYN Stealth Scan against 12.166.37.243 [1 port] at 21:12
Discovered open port 21/tcp on 12.166.37.243
The SYN Stealth Scan took 0.10s to scan 1 total ports.
Host 12.166.37.243 appears to be up ... good.
Interesting ports on 12.166.37.243:
PORT STATE SERVICE
21/tcp open ftp

Nmap run completed -- 1 IP address (1 host up) scanned in 0.692 seconds

#nmap -v 12.166.37.243 -p 22

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2009-06-16 21:12 EDT
Initiating SYN Stealth Scan against 12.166.37.243 [1 port] at 21:12
Discovered open port 22/tcp on 12.166.37.243
The SYN Stealth Scan took 0.09s to scan 1 total ports.
Host 12.166.37.243 appears to be up ... good.
Interesting ports on 12.166.37.243:
PORT STATE SERVICE
22/tcp open ssh

Nmap run completed -- 1 IP address (1 host up) scanned in 0.515 seconds

#nmap -v 65.246.198.243 -p 21

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2009-06-16 21:12 EDT
Initiating SYN Stealth Scan against 65.246.198.243 [1 port] at 21:12
Discovered open port 21/tcp on 65.246.198.243
The SYN Stealth Scan took 0.07s to scan 1 total ports.
Host 65.246.198.243 appears to be up ... good.
Interesting ports on 65.246.198.243:
PORT STATE SERVICE
21/tcp open ftp

Nmap run completed -- 1 IP address (1 host up) scanned in 0.349 seconds

#nmap -v 65.246.198.243 -p 22

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2009-06-16 21:13 EDT
Initiating SYN Stealth Scan against 65.246.198.243 [1 port] at 21:13
Discovered open port 22/tcp on 65.246.198.243
The SYN Stealth Scan took 0.07s to scan 1 total ports.
Host 65.246.198.243 appears to be up ... good.
Interesting ports on 65.246.198.243:
PORT STATE SERVICE
22/tcp open ssh

Nmap run completed -- 1 IP address (1 host up) scanned in 0.354 seconds

#

[Ivan Ferreira]

As you should know, there are some non printable characters that are different on Unix and Windows, specially the LF|CR/LF for a file.

Maybe, you key file is encoded with Windows charset, and that is why you get:

debug2: key_type_from_name: unknown key type '----'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Comment:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '----'
debug3: key_read: missing keytype

You can use cat -e to check if you see a ^M at the end of each line.

[Steven E. Protter]

Shalom,

Services on the windows boxes APPEAR to be working.

Have you checked the event logs on Windows, and/or restarted the services.

sEP

[Steven Schweda]

> source is a LINUX one and target is window
> machine

Source? Target? Is the Linux system the
client? Is the Windows system the server?

> and the public key from LINUX user is
> provided to import the key to get trutsed.

Where was the key created? Where was it
imported? How?

> debug3: Not a RSA1 key file /home/applmgr/.ssh/id_rsa_weichert.
> debug2: key_type_from_name: unknown key type '----'
> debug3: key_read: missing keytype

Looks as if the key file format could be bad.
There are two popular SSH key file formats
(OpenSSH, SSH2), and if you have the wrong
one, then you'll need to convert it before
you can use it.

If I could see any of the key files, I might
be able to say more. You could try
generating test key files on each system to
see if they have the same format or not.

[Steven Schweda]

> OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003

> ---- BEGIN SSH2 PUBLIC KEY ----
> [...] converted from OpenSSH [...]

If you're using OpenSSH on the HP-UX system,
then conversion to SSH2 format may not have
been the best thing to do.

[Steven Schweda]

> If you're using OpenSSH on the HP-UX system,

Or the Linux system. (Whatever.)

[Ivan Ferreira]

Use cat -e

[Steven Schweda]

Also, we just needed to see the key file
format, not all the key data. You might wish
to throw that key away, and get a new one.

[Steven Schweda]

> Created the key in opensshformat. [...]

> debug3: Not a RSA1 key file /home/applmgr/.ssh/id_rsa_weichert.openssh.

Sounds bad to me.

[skt_skt]

"debug1: Connecting to 12.166.37.243 [12.166.37.243] port 22.
debug1: Connection established.
"

does the above message enoughg to say the connection was reaching till the windows server. Unfortnatly the windows remote team does not see any hit from my source server in the log.

[Steven Schweda]

> does the above message enoughg to say the
> connection was reaching till the windows
> server.

For some values of "reaching", yes.

> Unfortnatly the windows remote team does
> not see any hit from my source server in
> the log.

I don't know what the server on Windows will
log. If the client can't find a valid key to
send, ...

> debug3: Not a RSA1 key file /home/applmgr/.ssh/id_rsa_weichert.openssh.

... then it may not do anything worth
logging.

You might try setting up some keys on the
Linux system itself, and getting that to
work, so that you can see what happens in a
working situation. It's often helpful to be
able to compare a working situation with a
non-working situation.

[skt_skt]

We figured the windows machine is not able to handle the NAT. So we put a static transalation on the external gateway so that the original IP of the source would be preserved while communicating. Now it is able to connect with password and that is a good sign. I would tune the password less connection later and let u know result