I see. So some care must be taken when more options are present in ~/.ssh/config - which was not my case, but I am sure that others that read this thread will use the
note you wrote on #15.

^,^

I am pretty sure the problem is at my ISP because the behaviour did not happen with only one server. Any ssh session had it, and I confirmed there was no limit imposed in one server I eventually use.

On the other hand, I do not know which log file I should check, nor if I have access to the needed logs in a server (no root access) or any second level remote machine.

/var/log/auth* are not accessible in the machines where I do not have root access.

The network I access in the server I talked about in this thread is:

- local machine do 'ssh me@remote.server.is' to access a private network

- from remote.server.is command line, do 'ssh other.comp' ("other.comp" cannot be accessed directly)

For the broken connections, would I want to check the logs for remove.server.is? For other.comp machine? For both?

Or just my local logs are enough to point the problem cause? (but, as I said above, I do not know which files to check and what is expected to be found)

(I'll hop over the log question.)

Going through a jump host aka bastion should be done using either the ProxyJump directive if you are using a new SSH client or ProxyCommand if you are using an old one. Otherwise if you connect with an SSH client to the bastion and then another SSH client to the inner host, you are trusting the bastion with all the secrets you might type into the inner host. By using ProxyJump or ProxyCommand you instead have an encrypted connection all the way through to your destination.

So for a new SSH client, ProxyJump can be put into ~/.ssh/config or else a -J used as a runtime option:

Or for an old SSH client, the ProxyCommand directive can go into ~/.ssh/config or used with -o as a runtime option.

If you're stuck with an old SSH client, then I'd put everything into ~/.ssh/config.

Re: (...) Do you still think I should ProxyJump to them?
 

No big problem with the logs, someone will eventually say something.

You pointed and described a situation that I am not sure it is what I have.

The "second level" machine I described is accessed with the same account and password I use to access the first server (among other things like files, programs, ...). I had (and have) no worry in showing everything I do on the second machine for the first one. They are basically the same, except that the Internet accessible server is a FreeBSD that should not be used for many tasks beside accessing the private network. My terminal usually get these commands:

Further, there are several private.machine's, sometimes I change which one I use. There are eventual access problems in them.

Do you still think I should ProxyJump to them? I would (at least, I imagine) need to configure several DNS names for those remote machines I cannot access from my home or from eventual accesses around the Internet.

Yes, or else ProxyCommand. Then you can just connect to the shortcut and it will automatically pass through the bastion host. ssh private1

Can you use the -J option with your SSH client or does it complain?

If it complains then use ProxyCommand:

You can use keys for any of them, too, by adding IdentityFile in the right places. No changes are needed to the machine in the middle, even if it is still running FreeBSD. ;)

DNS entries are not needed you can go by IP address, too. Either way it is the bastion host / jump host access to names that counts. You can make shortcuts in your ~/.ssh/config file however.