What are the configeration need to done to enable sftp connection to Windows m/c

When I try

$sftp -v <username>@[IP]
Connecting to <ip>...
debug1: SSH args "ssh -oProtocol = 2 -s -oForwardAgent = no -oForwardX11 = no -l <username> -v <ip> sftp"
SSH Version Sun_SSH_1.0.1, protocol versions 1.5/2.0.
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: getuid ### geteuid ### anon 1
debug1: connect: Connection timed out
debug1: Trying again...
Why this message is comming...

please suggest...

Which version of Solaris are you running? Can you check if the system is hardened and the service in the /etc/inetd.conf and /etc/services file is commented ? Under / , is there the .rhosts file there?

Thanks for reply

Previously the connection was going now only the problem came.

Yes etc/inetd.conf file is commented.
and /etc/services ssh is not commented

There was no .rhosts file under root.

what was the significance of Rhosts Authentication ?

please bare with me am new to UNIX

first, uncomment the entry in inetd.conf file and see. We'll check on the error which you've pointed to.. keep updating

Check the /etc/sshd.conf for any rhost auth settings (if any)?

/etc/ssh/ssh_config file was fully commented

can you please tell me the use of Rhosts Authentication disabled

how its affected on the s/m

When the sftp was working same lines are comming as follows

$sftp -v <username>@[IP]
Connecting to <ip>...
debug1: SSH args "ssh -oProtocol = 2 -s -oForwardAgent = no -oForwardX11 = no -l <username> -v <ip> sftp"
SSH Version Sun_SSH_1.0.1, protocol versions 1.5/2.0.
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: getuid ### geteuid ### anon 1
debug1: connect: Connection established.

So come to the point first, does your ssh/sftp working now? Is it resolved?

Your keys might not have been generated/planted in either hosts.
Normally each user wishing to use SSH with RSA or DSA authentication runs
this (ssh-keygen -t rsa ) once to create the authentication key in $HOME/.ssh/identity, $HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa. Additionally, the system administrator may use this to generate host keys, as seen in /etc/rc.

ssh was working fine

but to this sftp to <ip> only not working now.

whether Wndows machine any changes need to done at other end

keys are placed thats why previouly we are able to connect.

IS it a problem with connectivity right now....

where the messages tell any thing with respect to connectivity...

whats your infra like? any firewall between your subnets? or are they sitting on the same segment? What are you using for SSH on the windows side? SSH.COM? F-Secure? OpenSSH? How did you install the public key? Was it in the correct format? Different products require the public key to be in different formats and different locations. If you need to convert the public key format, there is a '-e' option on ssh-keygen which will convert from OpenSSH format to SECSH format

My assumption now is that the ping to your gateway at the least is working. And you can at least ping the ip of your Windows machine from your solaris box...

lot of firewal 2 our side 2 client side

we dont have access to their machine

Is there any way to trace the connection going through differnt servers/subnet while attempting sftp....

you mean traceroute?
anyway, go thru this article first:

Meanwhile I will see if I can figure out what can be done to resolve this

For your reading and verification
Setting up a SFTP Server on Windows

How we can trace the path for sftp connection using traceroute command???

The Solaris "traceroute" command lets you trace the route your packets are taking to get from your current workstation to a remote workstation you're trying to reach.
For instance, suppose you're on the Internet and you're not getting an HTTP response from a remote server named zdtips.com. You try to "ping" the
remote site like this:

ping www.abc.com

but get no answer. Is the remote server down, or is there a broken link between you and the remote site? Issue the following command to see where
the problem lies:

traceroute www.abc.com

The traceroute command works its way through the network, and tells you the path it's taking to get to the destination site as it goes along. Watch for
the point traceroute fails to learn more about the network segment that has failed. Of course you can also try this on working connections to learn more about how your Internet packets get from one site to another.