Hi Colin, On Friday 08 August 2008, Colin Watson wrote: > "Connection refused" sounds like the server process simply isn't > listening on that port. Client logs aren't going to tell us much here. > Is there anything useful in the server log? Would it be possible to > stop the server and bring it up in debugging mode (with -ddd) and see > what it says then? Ah, I think I see what has happened here. After I configured my network for both IPv4 and IPv6 (some time last year IIRC), I got the following error from openssh-server on start: Server listening on 0.0.0.0 port 22. Bind to port 22 on :: failed: Address already in use. Because of that I had the following in sshd_config: # FJP: Only bind to '::' to avoid boot error due to IPv4/IPv6 conflict. # '::' and '0.0.0.0' are essentially the same address. ListenAddress :: #ListenAddress 0.0.0.0 With that config both IPv6 _and_ IPv4 happily worked with the testing version even though debug only shows sshd listening on '::'. After uncommenting the 'ListenAddress 0.0.0.0', the scp from VirtualBox again works with unstable openssh-server and on start of openssh-server I now get: Server listening on 0.0.0.0 port 22. Server listening on :: port 22. So, it looks like the new upstream has tightened its separation between IPv4 and IPv6, fixing the reason why I added the workaround but also breaking IPv4 support which previously worked with the workaround in place. It also explains why scp worked from other systems on my network (as those have a good IPv6 address) and why D-I failed (as netcfg only configures IPv4). Conclusion is that this BR can be closed, but I suspect the same issue could trip up others. Maybe worth a mention in README.Debian? Cheers, Frans
Attachment:
signature.asc
Description: This is a digitally signed message part.