0

After a change of Internet provider, hence of modem/router and IP address, I cannot log in from home to a server via ssh as I used to do with the previous provider. The change of circumstances is at the client/host/home side.
If I ask ssh what happened with ssh -YC guest@server.com -v, the result is:

OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server.com [aaa.bbb.ccc.ddd] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
ssh_exchange_identification: read: Connection reset by peer

What are the steps to restore the previous safe situation?

The client/localhost is a desktop system running on Ubuntu 16, although this is reproducible with other Ubuntu releases. The server is the login node of a computer cluster at the workplace; this runs on Debian Buster. The new provider is reputable and is not blacklisted. The factors that ostensibly changed between before and afterwards are those linked to the new service: hardware-wise the router, software-wise the IP address.

6
  • I don't think there is sufficient information to tell for sure, but I'd guess that the modem is accepting the ssh connection rather than forwarding to the server inside. This assums that the server is behind the new modem on the new ISP. Please provide more details about which system is where relative to the new modem. Jun 25 '20 at 22:29
  • @crimson-egret I have added some info. If this is not what you meant, please elaborate on the information needed. That will be interesting at any rate. Jun 26 '20 at 7:44
  • Is the server behind the new hardware/ISP, or the client? Jun 26 '20 at 14:52
  • The client: I work from home and have just changed my provider, who has provided a new modem. Good point, it was obvious for me and I have edited the post accordingly. Jun 26 '20 at 15:04
  • Ok, then next most likely place to look is at the server config. It could be that the server is whitelisting only certain IPs, either in the sshd_config or in some firewall before ssh gets the connection. Can you simply nc SERVER-IP 22 and get a connection using netcat? Jun 26 '20 at 15:15
0

If you interact with a real ssh server, when you run nc SERVERIP 22 you must receive after a few seconds 2/3 of the welcome message of SSH like one of these examples:

SSH-2.0-OpenSSH_5.3
SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u1 
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3

Usually, when you run ssh -v you must have somewhere two lines:

debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u1

My perception is that you have a firewall that blocks the ssh connection, so it can be:

  • on your side (router)
  • on your ISP
  • on the destination server (can be either a firewall or /etc/hosts.deny or /etc/hosts.allow)

You must test:

  • a ssh connection on port 22 from your current location to some other location (ask a friend):

    IF this ssh session is working, that means the problem is not on your side

  • a ssh connection to your server, port 22, but from another location

    IF this connection is not working, you can think you have a IP filtering on the server side

2
  • Q1. Are the free and trustworthy services that one can connect to with SSH as a test? For example, there is example.com for pinging. Anything similar that applies to SSH testing? Say there is no friend with a ssh? Jun 28 '20 at 11:15
  • Q2. When you say "test" do you mean making a nc call or log in on the server? From my report up above it looks like we get Connection established Jun 28 '20 at 11:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.