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 [email protected] -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.

Improve this question
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.
    – crimson-egret
    Commented Jun 25, 2020 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.
    – XavierStuvw
    Commented Jun 26, 2020 at 7:44
  • Is the server behind the new hardware/ISP, or the client?
    – crimson-egret
    Commented Jun 26, 2020 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.
    – XavierStuvw
    Commented Jun 26, 2020 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?
    – crimson-egret
    Commented Jun 26, 2020 at 15:15

1 Answer 1

Reset to default
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

Improve this answer
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?
    – XavierStuvw
    Commented Jun 28, 2020 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
    – XavierStuvw
    Commented Jun 28, 2020 at 11:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .