How do I SSH to machine A via B in one command?

Using ProxyCommand in your SSH config.

Create an SSH configuration file in your home directory (unless you want to make this system-wide), ~/.ssh/config:

Host unibroker          # Machine B definition (the broker)
Hostname 12.34.45.56    # Change this IP address to the address of the broker
User myusername         # Change this default user accordingly 
                        # (`user@unibroker` can overwrite it)

Host internalmachine    # Machine A definition (the target host)
ProxyCommand ssh -q unibroker nc hostname.or.IP.address.internal.machine 22

Now you can reach Machine A directly using

ssh user@internalmachine

Also note that now you have a single SSH host target name for it, you can use this in other applications as well. E.g.:

  • SCP to copy files.

    scp somefile user@internalmachine:~/
    
  • In your GUI applications:

    use sftp://user@internalmachine/ as the location to browse on the machine.

    KDE-based (Dolphin): use fish://user@internalmachine/

Notes

Change hostname.or.IP.address.internal.machine and the port (22) to the machine you like to reach as if you would from the unibroker machine.

Depending on netcat versions on the unibroker host, the -q0 option must be omitted. Regarding authentication; you're basically setting up two SSH connections from your workstation. This means both the unibroker host and the internalmachine host are verified/authenticated against one after another (for both keypair/password and host key verification).

Explanation

This approach of the use of ProxyCommand and 'netcat' is just one way to do it. I like this, because my SSH client talks directly to the target machine so that I can verify the host key from my client and I can use my public key authentication without using another key on the broker.

Each Host defines the start of a new host section. Hostname is the target hostname or IP address of that host. User is what you would provide as the user part in ssh user@hostname.

ProxyCommand will be used as the pipe to the target machine. By using SSH to the first machine and directly setting up a simple 'netcat' (nc) to the target from there, this is basically just a plaintext forward to the internal machine from the broker between those. The -q options are to silence any output (just a personal preference).

Make sure you have netcat installed on the broker (usually available by default on Ubuntu) - either netcat-openbsd Install netcat-openbsd or netcat-traditional Install netcat-traditional.

Note that you're still using SSH with encryption twice here. While the netcat channel is plaintext, your SSH client on your PC will set up another encrypted channel with the final target machine.


You could use the -J command line option:

ssh -J user@machineB user@machineA

From man ssh:

-J [user@]host[:port]
     Connect to the target host by first making a ssh connection to
     the jump host and then establishing a TCP forwarding to the
     ultimate destination from there.  Multiple jump hops may be
     specified separated by comma characters.  This is a shortcut to
     specify a ProxyJump configuration directive.

It was introduced in OpenSSH version 7.3 (released in August 2016). It is available in Ubuntu 16.10 and later.


Hop in one go

An obvious alternative to the ProxyCommand approach I provided in my other answer would be 'hopping' directly to the target machine:

ssh -t user@machineB ssh user@machineA

Note the -t on the first ssh command. Without it, it will fail:

Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Permission denied, please try again.
[...]

It will force a real TTY to be allocated

Downside of this is that now all configuration, verification and authentication takes place at Machine B, which I really don't like in my situation for security reasons. I like my keypair on my own PC and authenticate and verify the final target machine from my own PC. Additionally, you can only use the interactive shell for SSH, so this won't deal with other tools like SCP or using your GUI file manager.

For all the aforementioned reasons I strongly recommend the ProxyCommand approach, but for a quick connect this works fine.