The first thing I'd look for on the XP box is the Windws firewall - it might be set to squash all those incoming packets, so you receive the request alright, but the XP doesn't get the reply back because of its own too tight firewall. What is your friend using on his XP box, putty, the cygwin ssh, or what?

Just so I understand - your friend's external Linux box can connect, but neither his XP machine nor your other remote host where you tried the initial connections from can connect, right?

That makes me think that the problem isn't on your side anymore.

mlp

Here's what I've tried lately.

I've tried ssh acces from three different XP machines (didn't work) that, as far as I know, do not use software firewalls. I also tried from two different Linux machines and that did work. One of these tests was by a colleague with a dual boot XP / linux box, for him Linux worked, XP didn't. I also tried from different platforms (W2K, older mandrake linux pc and Unix) on a Unix university network and none worked.

Can it be due to sshd settings on my linux box or an incompatability of the version of ssh run on the remote XP boxes and mine?

If it helps, here's my sshd_config file:

# Package generated configuration file
# See the sshd(8) manpage for defails

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# ...but breaks Pam auth via kbdint, so we have to turn it off
# Use PAM authentication via keyboard-interactive so PAM modules can
# properly interface with the user (off due to PrivSep)
PAMAuthenticationViaKbdInt no
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

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

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no

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


# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
#PrintLastLog no
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net
#ReverseMappingCheck yes

Subsystem sftp /usr/lib/sftp-server

Make sure that ssh2 is selected in puTTY on the XP boxes or connection will be refused since you specified Protocol 2 only. BTW, props for not using SSH 1

The ssh2 options were activated.... are there other settings that are critical, like the public key stuff?
I've so far just used defaults, but that always worked fine for me, until I became system administrator of my own machine....

Off the top of my head, these are good ones to have:

Port 22
Protocol 2
SyslogFacility AUTHPRIV
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
PasswordAuthentication yes
PermitEmptyPasswords no
X11Forwarding yes
MaxStartups 10
Banner /etc/ssh/ssh_banner
VerifyReverseMapping yes

Setting PermitRootLogin to no forces you to login as regular user and su - to get root. This keeps people from hacking root by simply trying passwords. Even if they guess it, they won't log in and won't know they got the right password.

The Banner /etc/ssh/ssh_banner setting displays the /etc/ssh/ssh_banner file when logging in. Mine contains a warning:
"This system is for use only by authorized XYZ Company IS employees!
By completing the log in process, you agree to the following terms:
You are an IS Dept. employee of XYZ Company authorized to use this system.
All actions may be logged, monitored and reported.
Your IP & MAC addresses have been logged.
Have a nice day!"

MaxStartups keeps a limit on how many sshd processes are spawned.

VerifyReverseMapping is a good thing.

X11Forwarding yes allows you to start an X app and see it on your desktop. IE: I ssh to a box across the country, run redhat-config-users and see the GUI on my desktop.

Thanks for the tips and settings! I've changed what you've posted, unfortunately the problem persists. Is it maybe related to a package version of sshd? Are there other packages out there?

If you have run up2date, you should have the latest... You can always search at rpmfind.net

Have you tried compiling a version from source? I've often found that a lot of the packages that ship with distros are fubared. Try compiling it, and see what happens. That fixed a lot of problems I was having with packages.

here's an update on the status of my problem, so far not resolved, allthought I'm getting a lot familiar with linux through your different suggestions!

what works:
ftp, telnet, ssh from different remote linux boxes
ftp, telnet, ssh from local Windows boxes

what doesn't work:
ftp, telnet, ssh from different remote Windows boxes and a remote unix network box.

I've tried:
-done the same tests with and without my router --> same results;
-recompiling the latest ssh package --> same results;
-different settings in the sshd_config file --> same results;
-different settings on the Windows remote ssh clients --> same results.

If you guys have other suggestions they are very welcome. Could this be related to the Linux Debian 3.0 distribution, I could try RedHat 9.0 for example?

thanks
Ferry

Well at that point, I wonder if it couldn't be a problem with your ISP ?? He could block popular ports to reduce trafic specialy if you have a "no server" agreement with him...

I've checked with my ISP and they do not block any ports. ssh works from a remote linux box, using the same default port as a remote windows box for which ssh does not work...

The problem turned out to be the NIC driver, using a different one solved the problem.

Thanks again for your help.