[SOLVED] If I echo into /dev/pts/N, in a terminal using SSH, will it

dedec0 · 10-13-2017, 11:09 AM

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.

^,^

dedec0 · 10-13-2017, 11:35 AM

Quote:

Originally Posted by pan64

in that case you may try to check logs to find the reason (on both client/server side).

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)

Turbocapitalist · 10-13-2017, 11:46 AM

Quote:

Originally Posted by dedec0

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)

(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:

Code:

ssh -J me@remote.server.is dedec0@other.comp

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

Code:

ssh -o ProxyCommand='ssh -W %h:%p remote.server.is' other.comp

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

dedec0 · 10-13-2017, 12:30 PM

Quote:

Originally Posted by Turbocapitalist

(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:

Code:

ssh -J me@remote.server.is dedec0@other.comp

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

Code:

ssh -o ProxyCommand='ssh -W %h:%p remote.server.is' other.comp

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

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:

Code:

$ ssh me@remove.server.is # at local machine
$ ssh private.machine # at Internet accessible machine, same user+pw
$ command1 # private network machine
[... output ...]
$ command2 # private network machine
[... output ...]
$ command3 # private network machine
[... output ...]
$ command4 # private network machine
[... output ...]
$ ^D # out of private.machine
$ ^D # out of remove.server.is
$ ^D # close my local terminal window

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.

Turbocapitalist · 10-13-2017, 12:54 PM

Quote:

Originally Posted by dedec0

Do you still think I should ProxyJump to them?

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?

Code:

Host private1 private1.machine
        User me
        Hostname private1.machine
        ProxyJump me@remove.server.is:22

Host private2 private1.machine
        User me
        Hostname private2.machine
        ProxyJump me@remove.server.is:22

Host *
        ServerAliveInterval 31

If it complains then use ProxyCommand:

Code:

Host private1 private1.machine
        User me
        Hostname private1.machine
        ProxyCommand ssh -W %h:%p remove.server.is

Host private2 private1.machine
        User me
        Hostname private2.machine
        ProxyCommand ssh -W %h:%p remove.server.is

Host *
        ServerAliveInterval 31

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.