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?

Host */*
  ProxyCommand ssh $(dirname %h) -W $(basename %h):%p

Host host1/host2/host3
  IdentityFile /home/me/.ssh/host3
  IdentitiesOnly yes

Host host1/host2
  IdentityFile /home/me/.ssh/host2
  IdentitiesOnly yes

Host host1
  IdentityFile /home/me/.ssh/host1
  IdentitiesOnly yes

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 ~/.ssh/config:

Host host1/host2
        IdentityFile ~/.ssh/host1_rsa

Host */* 
        ProxyCommand ssh %r@$(dirname %h) -W $(basename %h):%p

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

Host jumphost
        HostName my.jumphost.com   # internet reachable hostname or IP address
        User jumphostuser
        Port 2200   # outside reachable port, NATed to jumphost
        IdentityFile ~/.ssh/jumphost_rsa

Host lanhost
        HostName lanhost   # must resolve in the local network, also if called from remote
        User lanhostuser
        Port 22
        IdentityFile ~/.ssh/lanhost_rsa

Host lanhost/remote
        IdentityFile ~/.ssh/lanhost_rsa   # same as in "Host LANhost"

Host */remote
        ProxyCommand ssh -W $(dirname %h):22 jumphost

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)

Done 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)