Announcement

Collapse
No announcement yet.

SSH with Windows 10 Build 1803

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • SSH with Windows 10 Build 1803

    I have updated to Windows 10 Version 1803 today.

    I use SSH to connect to the server, and I have PuTTY installed as the SSH client.
    Right now, I cannot connect to my SVN repository and I cannot connect to the server with PuTTY.

    This is the error that I get from an SVN LOG command:

    Unable to open connection:
    gethostbyname: unknown errorsvn: E170013: Unable to connect to a repository at URL 'svn+ssh://<my server>'
    svn: E210002: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
    svn: E210002: Network connection closed unexpectedly

    I have found reports, for example at the following sites:
    - [url]https://hn.svelte.technology/item/17093645[/url]
    - [url]https://www.bleepingcomputer.com/news/microsoft/windows-10-openssh-client-installed-by-default-in-april-2018-update/[/url]
    that an OpenSSL client is installed by default with Windows 10 Version 1803.

    I am guessing that this is the cause of the error.

    What do I have to do?

    Is it possible to use the OpenSSL client?
    Or should I uninstall it?

    Phil

  • #2
    The failure is "gethostbyname: unknown error". I'd suggest double checking your DNS server configuration.

    Also, a quick google found this: [url]https://sourceforge.net/p/puttysm/support-requests/4/[/url]
    Ignoring the bits at the top (mostly - as I assume you're on fresh PuTTY bits), the stuff down near the bottom is more germane: try putting the PuTTY on the C: drive it is installed elsewhere.

    Comment


    • #3
      Thanks Doug.

      I did actually solve this problem, and it is not related to the OpenSSH client.
      It seems to be related to resolution of the NetBios name, which fails if the name is specified entirely in lower case.
      I capitalized the first letter in the name of the server and now it works.

      What I find plain weird is, that it does not appear to be case sensitive. It only fails if the whole name is lowercase. All other variations seem to work.

      There is some information here:
      [URL="https://techcommunity.microsoft.com/t5/Windows-Insider-Program/Windows-10-RS4-17650-NETBios-Resolution-Issue/td-p/187721"]https://techcommunity.microsoft.com/...ue/td-p/187721[/URL]

      and I personally added a reply to a similar issue here:
      [URL="https://answers.microsoft.com/en-us/windows/forum/windows_10-networking/windows-1001713448-update-windows-application/f81719b1-d497-452f-af51-d188a22fbc43"]https://answers.microsoft.com/en-us/...1-d188a22fbc43[/URL]
      Last edited by DougR; 05-21-2018, 02:50 PM. Reason: Turn html on.

      Comment


      • #4
        I have to wonder if there's a broken DNS cache. Could you run "ipconfig /flushdns" from a command-line on your Windows box and then re-test the "all lowercase" version?

        Comment


        • #5
          It made no difference.

          Here are ping commands with different case, including the ipconfig /flushdns command.

          [code]
          Microsoft Windows [Version 10.0.17134.48]
          (c) 2018 Microsoft Corporation. All rights reserved.

          C:\Windows\System32>cd \

          C:\>ping magrathea
          Ping request could not find host magrathea. Please check the name and try again.

          C:\>ping Magrathea

          Pinging Magrathea [192.168.178.30] with 32 bytes of data:
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64

          Ping statistics for 192.168.178.30:
          Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
          Approximate round trip times in milli-seconds:
          Minimum = 0ms, Maximum = 0ms, Average = 0ms

          C:\>ipconfig /flushdns

          Windows IP Configuration

          Successfully flushed the DNS Resolver Cache.

          C:\>ping magrathea
          Ping request could not find host magrathea. Please check the name and try again.

          C:\>ping Magrathea

          Pinging Magrathea [192.168.178.30] with 32 bytes of data:
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64

          Ping statistics for 192.168.178.30:
          Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
          Approximate round trip times in milli-seconds:
          Minimum = 0ms, Maximum = 0ms, Average = 0ms

          C:\>ping magratheA

          Pinging magratheA [192.168.178.30] with 32 bytes of data:
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64

          Ping statistics for 192.168.178.30:
          Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
          Approximate round trip times in milli-seconds:
          Minimum = 0ms, Maximum = 0ms, Average = 0ms

          C:\>ping MAGRATHEA

          Pinging MAGRATHEA [192.168.178.30] with 32 bytes of data:
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64
          Reply from 192.168.178.30: bytes=32 time<1ms TTL=64

          Ping statistics for 192.168.178.30:
          Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
          Approximate round trip times in milli-seconds:
          Minimum = 0ms, Maximum = 0ms, Average = 0ms

          C:\>
          [/code]

          Comment


          • #6
            Compelling data. Got to say that Microsoft has a big problem here! Thank you for sharing!

            Comment

            Working...
            X