Talk:OpenSSH/Cookbook/Proxies and Jump Hosts

About (Reverted edits by 84.171.50.240 . . . (put a missing "ssh" command), the original syntax "ssh -tt ... ssh -tt ..." was correct.  Now if chaining to a third host were part of the example, a third instance of ssh would be needed, but then that would also need the hostname. Larsnooden (discuss • contribs) 06:54, 8 October 2014 (UTC)

Did you try this? When I omit "ssh" I get: me@local:~$ ssh -tt -p 1234 root@foo.bar.de -tt root@192.168.5.55 bash: root@192.168.5.55: command not found Connection to foo.bar.de closed. me@local:~$ It works well with: ssh -tt -p 1234 root@foo.bar.de -tt ssh root@192.168.5.55

--84.171.50.240 (discuss) 07:27, 8 October 2014 (UTC)

The second -tt comes after the second instance of ssh, it is there to force pseudo-tty allocation which is often needed when chaining, but there might be occasions where it can be safely omitted. me@local:~$ ssh -tt -p 1234 root@foo.bar.de ssh -tt root@192.168.5.55 The second ssh is running on the remote machine. They are being nested. Larsnooden (discuss • contribs) 07:32, 8 October 2014 (UTC)

Sorry, I overlooked the first ssh command --84.171.50.240 (discuss) 07:40, 8 October 2014 (UTC)

185.17.206.59 chaining with keys
185.17.206.59, putting in stanzas for each step in a chain of hosts isn't really an arbitrary number or order any more. It's just using a different labeling system than the previous subsection. Or am I missing the idea?

Either way, I found a mistake I wrote in the previous section regarding keys.

Here are the proposed changes from 185.17.206.59‎: Another possibility to use keys for host1 and host2 is to specify the details of the target host using separate stanzas in :

Example: using  to differentiate between ssh from the local LAN and ssh from remote; call   from local LAN and   from remote.

Larsnooden (discuss • contribs) 09:24, 17 May 2016 (UTC)

Old SSH recipes
How about moving them to dedicated linked pages? It seems to me that they are more a source of confusion and verbosity, rather than useful information (I should think most SSH users keep it reasonably up to date to avoid security holes, or just let their OS update it). --46.141.101.118 (discuss) 13:22, 17 December 2019 (UTC)


 * that's probably a good idea. The question will be how to fit it in within the structure of a book.  There are still quite a few distros that have old versions of OpenSSH still, notably RHEL and CentOS.  Larsnooden (discuss • contribs) 13:57, 17 December 2019 (UTC)
 * ✅ They're not moved out to their own pages quite yet, but I've separated them and marked them more clearly as deprecated. We'll need the old instructions around for a few more years because of relics like RHEL6 and 7 and CentOS 6 and 7. Larsnooden (discuss • contribs) 15:39, 29 May 2020 (UTC)
 * RHEL7 a relic??? Sure, not the latest, but the end-of-support date is 2024! I get your point, though. Regardless, some of us need to support systems that have uptimes exceeding 10 years. This webbook is a handy resource for us poor souls. Might I also suggest the inclusion of the bash /dev/tcp redirect trick for systems that are too old for even netcat? Jlaidman (discuss • contribs) 23:32, 6 October 2020 (UTC)
 * Thanks for the feedback. It is appreciated.  I'll look into that redirection method and revisit the netcat method below.  Which systems would predate netcat? Larsnooden (discuss • contribs) 02:32, 7 October 2020 (UTC)

netcat allows change of username
The outdated netcat method does not allow a change of username.

I don't think this is true. In fact some of the examples that use the netcat method specify different users:

''If the user accounts names are different on the two machines, that works, too. Here, 'user2' is the account on the second machine which is the final target. The user 'fred' is the account on the intermediary or jump host.''

Jlaidman (discuss • contribs) 23:22, 6 October 2020 (UTC)