Your best friend for file transfer.

Fetch application logoFetch

FTP client username being seen as anonymous on FTP server (2 posts)

  • Started 6 months ago by MB
  • Latest reply 6 months ago from Jim Matthews
  • MB Member

    Hello Jim,

    Maybe you have an easy answer.
    When I try to connect to an external FTP from within my business, my router is configured for a IP4 Static IP that we use. If I try to connect, I get the dreaded "ssh_exchange_identification: read: Connection reset by peer"
    So I did a SSH check and I get:
    Michael iMac~ orthowest$ ssh -v orthowest@claimsplus.softcare.com
    OpenSSH_5.2p1, OpenSSL 0.9.8y 5 Feb 2013
    debug1: Reading configuration data /etc/ssh_config
    debug1: Connecting to claimsplus.softcare.com [160.109.234.136] port 22.
    debug1: Connection established.
    debug1: identity file /Users/orthowest/.ssh/identity type -1
    debug1: identity file /Users/orthowest/.ssh/id_rsa type -1
    debug1: identity file /Users/orthowest/.ssh/id_dsa type -1
    ssh_exchange_identification: read: Connection reset by peer

    The server end is seeing this:
    2017-05-05 14:22:49 75.118.42.162 - - [44837]user - - 331 - - - 22
    2017-05-05 14:22:49 75.118.42.162 - - [44837]user anonymous - 331 - - - 22
    2017-05-05 14:22:49 75.118.42.162 - - [44837]pass ****** - 530 - - - 22

    For some reason, my username is lost in the transmission and changed to "anonymous"

    If I change my router to use Dynamic IP and not my Static IP, the connection is made, no problems:
    Michael-iMac:~ orthowest$ ssh -v orthowest@claimsplus.softcare.com
    OpenSSH_5.2p1, OpenSSL 0.9.8y 5 Feb 2013
    debug1: Reading configuration data /etc/ssh_config
    debug1: Connecting to claimsplus.softcare.com [160.109.234.136] port 22.
    debug1: Connection established.
    debug1: identity file /Users/orthowest/.ssh/identity type -1
    debug1: identity file /Users/orthowest/.ssh/id_rsa type -1
    debug1: identity file /Users/orthowest/.ssh/id_dsa type -1
    debug1: Remote protocol version 2.0, remote software version 1.82_sshlib Globalscape
    debug1: no match: 1.82_sshlib Globalscape
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_5.2
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: server->client aes256-ctr hmac-sha1 none
    debug1: kex: client->server aes256-ctr hmac-sha1 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug1: Host 'claimsplus.softcare.com' is known and matches the RSA host key.
    debug1: Found key in /Users/orthowest/.ssh/known_hosts:1
    debug1: ssh_rsa_verify: signature correct
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    EFT Server 7.1.2.4 Welcome to ClaimsPlus.softcare.comdebug1: Authentications that can continue: password,keyboard-interactive
    debug1: Next authentication method: keyboard-interactive
    Enter password:

    Or if I try to connect from anywhere other than my business internet connection. Everything works.
    Obviously, I turned of all the firewall rules, etc.

    Have you seen this? Where my username is lost in the connection and changed to "anonymous" if I use
    a static IP?

    Regards
    Mike

    Posted 6 months ago #

  • Jim Matthews Administrator

    Hi,

    I think the bit about anonymous in the server logs is a red herring. That server log is for an FTP connection (port 21), but the "ssh_exchange_identification" error is coming from an SSH connection (port 22). I would check the sshd (SSH Daemon, or server) logs on the server.

    Here is a link to another time this ssh error was reported:

    https://fetchsoftworks.com/fetch/messageboard/ssh-exhange-identification-read-connection-reset-by-peer

    This quote might be relevant:

    "I had this problem and it turned out to be that sshd (?) was doing a reverse lookup on my client IP and DNS was not working at the time. The key to finding this was that /var/log/messages on the server was reporting issues with hosts.allow."

    Thanks,

    Jim Matthews
    Fetch Softworks

    Posted 6 months ago #

Reply

  • Or nickname, if you prefer.
  • This will be kept confidential.
  • This is to ensure that you’re a person, not a spambot.