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











up vote
79
down vote

favorite
41












I want to access a computer, say machine A which is based in my university's network. However, this computer is only accessible via the internal network of the university, so I can not use SSH to this computer from home directly.



Here's what I do now:





  1. Log in to a different university machine, say machine B



    (This machine B is accessible via SSH from my home computer.)



  2. Use SSH on B to connect to A.



Is there a way to do that faster? Using only one ssh command.










share|improve this question




























    up vote
    79
    down vote

    favorite
    41












    I want to access a computer, say machine A which is based in my university's network. However, this computer is only accessible via the internal network of the university, so I can not use SSH to this computer from home directly.



    Here's what I do now:





    1. Log in to a different university machine, say machine B



      (This machine B is accessible via SSH from my home computer.)



    2. Use SSH on B to connect to A.



    Is there a way to do that faster? Using only one ssh command.










    share|improve this question


























      up vote
      79
      down vote

      favorite
      41









      up vote
      79
      down vote

      favorite
      41






      41





      I want to access a computer, say machine A which is based in my university's network. However, this computer is only accessible via the internal network of the university, so I can not use SSH to this computer from home directly.



      Here's what I do now:





      1. Log in to a different university machine, say machine B



        (This machine B is accessible via SSH from my home computer.)



      2. Use SSH on B to connect to A.



      Is there a way to do that faster? Using only one ssh command.










      share|improve this question















      I want to access a computer, say machine A which is based in my university's network. However, this computer is only accessible via the internal network of the university, so I can not use SSH to this computer from home directly.



      Here's what I do now:





      1. Log in to a different university machine, say machine B



        (This machine B is accessible via SSH from my home computer.)



      2. Use SSH on B to connect to A.



      Is there a way to do that faster? Using only one ssh command.







      networking ssh remote-access tunnel






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jun 22 '13 at 15:57









      gertvdijk

      49.9k18141235




      49.9k18141235










      asked Jun 22 '13 at 15:03









      nikosdi

      5171710




      5171710






















          7 Answers
          7






          active

          oldest

          votes

















          up vote
          84
          down vote



          accepted










          Yes, 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 -q0 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.






          share|improve this answer



















          • 4




            I had to remove the -q0 option as it wasn't supported by the machine I was using. Other than that, it all worked. This is a FANTASTIC tip. Thank you so much. :)
            – Gerry
            Dec 3 '13 at 2:43












          • I ran into a problem, your answer works fine for me from the terminal, but i am unable to do it using the gui sftp, it says : unhandled error message, timed out while logging in.
            – Vikash B
            Oct 22 '15 at 18:52










          • @VikashB Well, it really should work. Consider creating a NEW question to handle your specific situation.
            – gertvdijk
            Oct 22 '15 at 19:32










          • I did here is the question: askubuntu.com/questions/688567/…
            – Vikash B
            Oct 23 '15 at 10:03






          • 1




            To complement the wise word of @gertvdijk, there is a great wikibook on the topic of ssh proxies and jump hosts that can serve as an invaluable reference.
            – Travis Clarke
            Nov 22 '17 at 8:48




















          up vote
          38
          down vote













          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.






          share|improve this answer























          • Why not have one answer with both the 'One Off' and Permanent solutions?
            – demure
            Jun 22 '13 at 16:08






          • 3




            @demure That's how StackExchange sites work... See: What is the official etiquette on answering a question twice? says "It's better to post two different answers, than to put them into one answer.". And I don't consider this to be the same solution. Permanent/temporarily is not what makes this approach differently, in my opinion.
            – gertvdijk
            Jun 22 '13 at 16:10












          • Other guides say to use, in addition, the -A switch, but indicate that this has security implications. Do you know what it means to forward, or not, the authentication agent connection?
            – Diagon
            Oct 16 at 15:09


















          up vote
          17
          down vote













          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.






          share|improve this answer



















          • 3




            +1 because this works even if you need to specify key file for machineA
            – Grief
            Feb 21 at 10:36


















          up vote
          14
          down vote













          Try using



          Host <visible hostname alias>
          Controlmaster auto
          User <user>
          hostname <visible hostname>
          port <port>
          IdentityFile ~/.ssh/<id file>

          Host <private LAN hostname alias>
          ProxyCommand ssh -q -W <private LAN hostname>:<private LAN port> <visible hostname alias>


          in your ~/.ssh/config and do it all in one shot with keys only residing on your computer.






          share|improve this answer























          • Terribly formatted by default:
            – SSH Help
            Jul 29 '14 at 13:50










          • This is more clean than introducing netcat into the mix. Also, the private SSH key does not need to exist on the B machine, either.
            – danemacmillan
            Jul 13 '16 at 21:47


















          up vote
          1
          down vote













          ProxyCommand is a clean solution for a case when you allow shell access in both the systems. We wanted to give remote users access to an internal machine (A) through a broker (B), but without allowing the user a shell access to B for improved security. This worked:



          Replace the login shell



          Replace the login shell (use chsh) for extuser on the broker with the following script (stored in a file):



          #!/bin/sh   # this is essential to avoid Exec format error
          ssh internaluser@A


          Provided no password login has been set up in extuser@B for the remote user and in internaluser@A for extuser@B, then executing the following command will directly take the remote user to A



          ssh extuser@B


          Tip: Create the necessary no password login authorized_keys setup in extuser@B before changing to the custom login shell. After the change, since this account is inaccessible to anybody through a shell, only a sudoer@B can make changes to the file authorized_keys by editing it directly.



          sudo vi ~extuser/.ssh/authorized_keys
          sudo touch ~extuser/.hushlogin


          The last line is to supress the login banner display from B, so the remote user has a transparent access to A.






          share|improve this answer























          • Very interesting approach. However, the main downsides of this are: 1) Use is limited to standard SSH usage (no SFTP/SCP support). 2) A user can't select another target host other than the single one (because hardcoded in login shell) 3) Host key validation can't be done from workstation to the final target host (since the use of the broker SSH binary). 4) Private keys for users to access the final target host are residing on the broker rather than with the user. This allows for impersonation of the user by an admin (which isn't possible normally).
            – gertvdijk
            Aug 5 '16 at 13:01










          • All points true, thanks for elaborating. However, the primary purpose is to provide a trusted user ssh access to A without login to B. Since only admin can add the public key of the trusted user on B (through sudo, without login), this already implies that the user has (admin) access to the private key of extuser@B (not of the trusted user outside), and has set it up, at the first place!
            – Sunthar
            Sep 29 '16 at 20:55


















          up vote
          1
          down vote













          You mean you need several jumpers:)



          Recently,I met this problem with jumper1 jumper2 and my final machine,as for my sol



          local script:



          #!/bin/bash
          sshpass -p jumper1Passwd ssh -t jumper1@jumper1IP ./Y00.sh


          then on the 1st jumper (which is my router), I placed a script named Y00.sh:



          ssh -tt jumper2@jumper2 -i ~/.ssh/id_rsa sshpass -p finalPassWord ssh -tt final@final


          You can replace these with your IP and passwords, good luck!






          share|improve this answer




























            up vote
            0
            down vote













            This is a very helpful suggestion. After messing about for hours, I found this note, & confirmed this works exactly as documented. To connect thru MachineA to MachineB, from remote machineC:



            eg: [xuser@machineC ~] ssh -t MachineA ssh MachineB



            The "-t" is critical, ssh fails if it is not present.
            You will get prompted twice, first for password on MachineA, then second time for
            MachineB. Also, note that this assumes you have user "xuser" defined on all
            three machines. If not, just use the ssh syntax: "yuser@MachineA ...". Also note that
            you can use dotted quad raw IP#s, if you want to. This is useful if you are linking
            thru a private local net which is using IPs not exposed to the world - ie. not in
            your local host file, or any DNS. To get a file from MachineB, to remote machineC,
            you can scp from MachineB to MachineA, then from MachineA to remote machineC. (Eg. the
            remote machineC can ping MachineA, but not MachineB.) Caveat: I tested with Fedora and WindowsXP, MachineA is an XP-box running ICS (Internet Connection Sharing), while MachineB and remote machineC are Fedora-Linux boxes. This suggestion solved a key problem for me - ie. restricted, monitored remote access to my remote site lan.
            Note also, when you "logout" from MachineB, you should see two "Connection to xxx.xxx.xxx.xxx closed." messages.






            share|improve this answer





















            • If you set up and configure public key authentication, then you don't need to worry about entering in your passwords. But -t is still required.
              – Felipe Alvarez
              Feb 19 '15 at 12:45










            • @FelipeAlvarez You still have to worry about entering the second password if you don't trust machine B to have passwordless login to A!
              – Michael
              Apr 23 '17 at 21:59











            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "89"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f311447%2fhow-do-i-ssh-to-machine-a-via-b-in-one-command%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            7 Answers
            7






            active

            oldest

            votes








            7 Answers
            7






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            84
            down vote



            accepted










            Yes, 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 -q0 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.






            share|improve this answer



















            • 4




              I had to remove the -q0 option as it wasn't supported by the machine I was using. Other than that, it all worked. This is a FANTASTIC tip. Thank you so much. :)
              – Gerry
              Dec 3 '13 at 2:43












            • I ran into a problem, your answer works fine for me from the terminal, but i am unable to do it using the gui sftp, it says : unhandled error message, timed out while logging in.
              – Vikash B
              Oct 22 '15 at 18:52










            • @VikashB Well, it really should work. Consider creating a NEW question to handle your specific situation.
              – gertvdijk
              Oct 22 '15 at 19:32










            • I did here is the question: askubuntu.com/questions/688567/…
              – Vikash B
              Oct 23 '15 at 10:03






            • 1




              To complement the wise word of @gertvdijk, there is a great wikibook on the topic of ssh proxies and jump hosts that can serve as an invaluable reference.
              – Travis Clarke
              Nov 22 '17 at 8:48

















            up vote
            84
            down vote



            accepted










            Yes, 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 -q0 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.






            share|improve this answer



















            • 4




              I had to remove the -q0 option as it wasn't supported by the machine I was using. Other than that, it all worked. This is a FANTASTIC tip. Thank you so much. :)
              – Gerry
              Dec 3 '13 at 2:43












            • I ran into a problem, your answer works fine for me from the terminal, but i am unable to do it using the gui sftp, it says : unhandled error message, timed out while logging in.
              – Vikash B
              Oct 22 '15 at 18:52










            • @VikashB Well, it really should work. Consider creating a NEW question to handle your specific situation.
              – gertvdijk
              Oct 22 '15 at 19:32










            • I did here is the question: askubuntu.com/questions/688567/…
              – Vikash B
              Oct 23 '15 at 10:03






            • 1




              To complement the wise word of @gertvdijk, there is a great wikibook on the topic of ssh proxies and jump hosts that can serve as an invaluable reference.
              – Travis Clarke
              Nov 22 '17 at 8:48















            up vote
            84
            down vote



            accepted







            up vote
            84
            down vote



            accepted






            Yes, 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 -q0 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.






            share|improve this answer














            Yes, 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 -q0 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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 11 '17 at 19:03









            Community

            1




            1










            answered Jun 22 '13 at 15:24









            gertvdijk

            49.9k18141235




            49.9k18141235








            • 4




              I had to remove the -q0 option as it wasn't supported by the machine I was using. Other than that, it all worked. This is a FANTASTIC tip. Thank you so much. :)
              – Gerry
              Dec 3 '13 at 2:43












            • I ran into a problem, your answer works fine for me from the terminal, but i am unable to do it using the gui sftp, it says : unhandled error message, timed out while logging in.
              – Vikash B
              Oct 22 '15 at 18:52










            • @VikashB Well, it really should work. Consider creating a NEW question to handle your specific situation.
              – gertvdijk
              Oct 22 '15 at 19:32










            • I did here is the question: askubuntu.com/questions/688567/…
              – Vikash B
              Oct 23 '15 at 10:03






            • 1




              To complement the wise word of @gertvdijk, there is a great wikibook on the topic of ssh proxies and jump hosts that can serve as an invaluable reference.
              – Travis Clarke
              Nov 22 '17 at 8:48
















            • 4




              I had to remove the -q0 option as it wasn't supported by the machine I was using. Other than that, it all worked. This is a FANTASTIC tip. Thank you so much. :)
              – Gerry
              Dec 3 '13 at 2:43












            • I ran into a problem, your answer works fine for me from the terminal, but i am unable to do it using the gui sftp, it says : unhandled error message, timed out while logging in.
              – Vikash B
              Oct 22 '15 at 18:52










            • @VikashB Well, it really should work. Consider creating a NEW question to handle your specific situation.
              – gertvdijk
              Oct 22 '15 at 19:32










            • I did here is the question: askubuntu.com/questions/688567/…
              – Vikash B
              Oct 23 '15 at 10:03






            • 1




              To complement the wise word of @gertvdijk, there is a great wikibook on the topic of ssh proxies and jump hosts that can serve as an invaluable reference.
              – Travis Clarke
              Nov 22 '17 at 8:48










            4




            4




            I had to remove the -q0 option as it wasn't supported by the machine I was using. Other than that, it all worked. This is a FANTASTIC tip. Thank you so much. :)
            – Gerry
            Dec 3 '13 at 2:43






            I had to remove the -q0 option as it wasn't supported by the machine I was using. Other than that, it all worked. This is a FANTASTIC tip. Thank you so much. :)
            – Gerry
            Dec 3 '13 at 2:43














            I ran into a problem, your answer works fine for me from the terminal, but i am unable to do it using the gui sftp, it says : unhandled error message, timed out while logging in.
            – Vikash B
            Oct 22 '15 at 18:52




            I ran into a problem, your answer works fine for me from the terminal, but i am unable to do it using the gui sftp, it says : unhandled error message, timed out while logging in.
            – Vikash B
            Oct 22 '15 at 18:52












            @VikashB Well, it really should work. Consider creating a NEW question to handle your specific situation.
            – gertvdijk
            Oct 22 '15 at 19:32




            @VikashB Well, it really should work. Consider creating a NEW question to handle your specific situation.
            – gertvdijk
            Oct 22 '15 at 19:32












            I did here is the question: askubuntu.com/questions/688567/…
            – Vikash B
            Oct 23 '15 at 10:03




            I did here is the question: askubuntu.com/questions/688567/…
            – Vikash B
            Oct 23 '15 at 10:03




            1




            1




            To complement the wise word of @gertvdijk, there is a great wikibook on the topic of ssh proxies and jump hosts that can serve as an invaluable reference.
            – Travis Clarke
            Nov 22 '17 at 8:48






            To complement the wise word of @gertvdijk, there is a great wikibook on the topic of ssh proxies and jump hosts that can serve as an invaluable reference.
            – Travis Clarke
            Nov 22 '17 at 8:48














            up vote
            38
            down vote













            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.






            share|improve this answer























            • Why not have one answer with both the 'One Off' and Permanent solutions?
              – demure
              Jun 22 '13 at 16:08






            • 3




              @demure That's how StackExchange sites work... See: What is the official etiquette on answering a question twice? says "It's better to post two different answers, than to put them into one answer.". And I don't consider this to be the same solution. Permanent/temporarily is not what makes this approach differently, in my opinion.
              – gertvdijk
              Jun 22 '13 at 16:10












            • Other guides say to use, in addition, the -A switch, but indicate that this has security implications. Do you know what it means to forward, or not, the authentication agent connection?
              – Diagon
              Oct 16 at 15:09















            up vote
            38
            down vote













            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.






            share|improve this answer























            • Why not have one answer with both the 'One Off' and Permanent solutions?
              – demure
              Jun 22 '13 at 16:08






            • 3




              @demure That's how StackExchange sites work... See: What is the official etiquette on answering a question twice? says "It's better to post two different answers, than to put them into one answer.". And I don't consider this to be the same solution. Permanent/temporarily is not what makes this approach differently, in my opinion.
              – gertvdijk
              Jun 22 '13 at 16:10












            • Other guides say to use, in addition, the -A switch, but indicate that this has security implications. Do you know what it means to forward, or not, the authentication agent connection?
              – Diagon
              Oct 16 at 15:09













            up vote
            38
            down vote










            up vote
            38
            down vote









            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.






            share|improve this answer














            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 13 '17 at 12:25









            Community

            1




            1










            answered Jun 22 '13 at 15:47









            gertvdijk

            49.9k18141235




            49.9k18141235












            • Why not have one answer with both the 'One Off' and Permanent solutions?
              – demure
              Jun 22 '13 at 16:08






            • 3




              @demure That's how StackExchange sites work... See: What is the official etiquette on answering a question twice? says "It's better to post two different answers, than to put them into one answer.". And I don't consider this to be the same solution. Permanent/temporarily is not what makes this approach differently, in my opinion.
              – gertvdijk
              Jun 22 '13 at 16:10












            • Other guides say to use, in addition, the -A switch, but indicate that this has security implications. Do you know what it means to forward, or not, the authentication agent connection?
              – Diagon
              Oct 16 at 15:09


















            • Why not have one answer with both the 'One Off' and Permanent solutions?
              – demure
              Jun 22 '13 at 16:08






            • 3




              @demure That's how StackExchange sites work... See: What is the official etiquette on answering a question twice? says "It's better to post two different answers, than to put them into one answer.". And I don't consider this to be the same solution. Permanent/temporarily is not what makes this approach differently, in my opinion.
              – gertvdijk
              Jun 22 '13 at 16:10












            • Other guides say to use, in addition, the -A switch, but indicate that this has security implications. Do you know what it means to forward, or not, the authentication agent connection?
              – Diagon
              Oct 16 at 15:09
















            Why not have one answer with both the 'One Off' and Permanent solutions?
            – demure
            Jun 22 '13 at 16:08




            Why not have one answer with both the 'One Off' and Permanent solutions?
            – demure
            Jun 22 '13 at 16:08




            3




            3




            @demure That's how StackExchange sites work... See: What is the official etiquette on answering a question twice? says "It's better to post two different answers, than to put them into one answer.". And I don't consider this to be the same solution. Permanent/temporarily is not what makes this approach differently, in my opinion.
            – gertvdijk
            Jun 22 '13 at 16:10






            @demure That's how StackExchange sites work... See: What is the official etiquette on answering a question twice? says "It's better to post two different answers, than to put them into one answer.". And I don't consider this to be the same solution. Permanent/temporarily is not what makes this approach differently, in my opinion.
            – gertvdijk
            Jun 22 '13 at 16:10














            Other guides say to use, in addition, the -A switch, but indicate that this has security implications. Do you know what it means to forward, or not, the authentication agent connection?
            – Diagon
            Oct 16 at 15:09




            Other guides say to use, in addition, the -A switch, but indicate that this has security implications. Do you know what it means to forward, or not, the authentication agent connection?
            – Diagon
            Oct 16 at 15:09










            up vote
            17
            down vote













            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.






            share|improve this answer



















            • 3




              +1 because this works even if you need to specify key file for machineA
              – Grief
              Feb 21 at 10:36















            up vote
            17
            down vote













            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.






            share|improve this answer



















            • 3




              +1 because this works even if you need to specify key file for machineA
              – Grief
              Feb 21 at 10:36













            up vote
            17
            down vote










            up vote
            17
            down vote









            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.






            share|improve this answer














            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 17 at 16:16









            muru

            135k20291493




            135k20291493










            answered Jan 16 at 16:19









            Erik Sjölund

            501412




            501412








            • 3




              +1 because this works even if you need to specify key file for machineA
              – Grief
              Feb 21 at 10:36














            • 3




              +1 because this works even if you need to specify key file for machineA
              – Grief
              Feb 21 at 10:36








            3




            3




            +1 because this works even if you need to specify key file for machineA
            – Grief
            Feb 21 at 10:36




            +1 because this works even if you need to specify key file for machineA
            – Grief
            Feb 21 at 10:36










            up vote
            14
            down vote













            Try using



            Host <visible hostname alias>
            Controlmaster auto
            User <user>
            hostname <visible hostname>
            port <port>
            IdentityFile ~/.ssh/<id file>

            Host <private LAN hostname alias>
            ProxyCommand ssh -q -W <private LAN hostname>:<private LAN port> <visible hostname alias>


            in your ~/.ssh/config and do it all in one shot with keys only residing on your computer.






            share|improve this answer























            • Terribly formatted by default:
              – SSH Help
              Jul 29 '14 at 13:50










            • This is more clean than introducing netcat into the mix. Also, the private SSH key does not need to exist on the B machine, either.
              – danemacmillan
              Jul 13 '16 at 21:47















            up vote
            14
            down vote













            Try using



            Host <visible hostname alias>
            Controlmaster auto
            User <user>
            hostname <visible hostname>
            port <port>
            IdentityFile ~/.ssh/<id file>

            Host <private LAN hostname alias>
            ProxyCommand ssh -q -W <private LAN hostname>:<private LAN port> <visible hostname alias>


            in your ~/.ssh/config and do it all in one shot with keys only residing on your computer.






            share|improve this answer























            • Terribly formatted by default:
              – SSH Help
              Jul 29 '14 at 13:50










            • This is more clean than introducing netcat into the mix. Also, the private SSH key does not need to exist on the B machine, either.
              – danemacmillan
              Jul 13 '16 at 21:47













            up vote
            14
            down vote










            up vote
            14
            down vote









            Try using



            Host <visible hostname alias>
            Controlmaster auto
            User <user>
            hostname <visible hostname>
            port <port>
            IdentityFile ~/.ssh/<id file>

            Host <private LAN hostname alias>
            ProxyCommand ssh -q -W <private LAN hostname>:<private LAN port> <visible hostname alias>


            in your ~/.ssh/config and do it all in one shot with keys only residing on your computer.






            share|improve this answer














            Try using



            Host <visible hostname alias>
            Controlmaster auto
            User <user>
            hostname <visible hostname>
            port <port>
            IdentityFile ~/.ssh/<id file>

            Host <private LAN hostname alias>
            ProxyCommand ssh -q -W <private LAN hostname>:<private LAN port> <visible hostname alias>


            in your ~/.ssh/config and do it all in one shot with keys only residing on your computer.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jul 29 '14 at 14:35









            ElefantPhace

            2,42931024




            2,42931024










            answered Jul 29 '14 at 13:49









            SSH Help

            14113




            14113












            • Terribly formatted by default:
              – SSH Help
              Jul 29 '14 at 13:50










            • This is more clean than introducing netcat into the mix. Also, the private SSH key does not need to exist on the B machine, either.
              – danemacmillan
              Jul 13 '16 at 21:47


















            • Terribly formatted by default:
              – SSH Help
              Jul 29 '14 at 13:50










            • This is more clean than introducing netcat into the mix. Also, the private SSH key does not need to exist on the B machine, either.
              – danemacmillan
              Jul 13 '16 at 21:47
















            Terribly formatted by default:
            – SSH Help
            Jul 29 '14 at 13:50




            Terribly formatted by default:
            – SSH Help
            Jul 29 '14 at 13:50












            This is more clean than introducing netcat into the mix. Also, the private SSH key does not need to exist on the B machine, either.
            – danemacmillan
            Jul 13 '16 at 21:47




            This is more clean than introducing netcat into the mix. Also, the private SSH key does not need to exist on the B machine, either.
            – danemacmillan
            Jul 13 '16 at 21:47










            up vote
            1
            down vote













            ProxyCommand is a clean solution for a case when you allow shell access in both the systems. We wanted to give remote users access to an internal machine (A) through a broker (B), but without allowing the user a shell access to B for improved security. This worked:



            Replace the login shell



            Replace the login shell (use chsh) for extuser on the broker with the following script (stored in a file):



            #!/bin/sh   # this is essential to avoid Exec format error
            ssh internaluser@A


            Provided no password login has been set up in extuser@B for the remote user and in internaluser@A for extuser@B, then executing the following command will directly take the remote user to A



            ssh extuser@B


            Tip: Create the necessary no password login authorized_keys setup in extuser@B before changing to the custom login shell. After the change, since this account is inaccessible to anybody through a shell, only a sudoer@B can make changes to the file authorized_keys by editing it directly.



            sudo vi ~extuser/.ssh/authorized_keys
            sudo touch ~extuser/.hushlogin


            The last line is to supress the login banner display from B, so the remote user has a transparent access to A.






            share|improve this answer























            • Very interesting approach. However, the main downsides of this are: 1) Use is limited to standard SSH usage (no SFTP/SCP support). 2) A user can't select another target host other than the single one (because hardcoded in login shell) 3) Host key validation can't be done from workstation to the final target host (since the use of the broker SSH binary). 4) Private keys for users to access the final target host are residing on the broker rather than with the user. This allows for impersonation of the user by an admin (which isn't possible normally).
              – gertvdijk
              Aug 5 '16 at 13:01










            • All points true, thanks for elaborating. However, the primary purpose is to provide a trusted user ssh access to A without login to B. Since only admin can add the public key of the trusted user on B (through sudo, without login), this already implies that the user has (admin) access to the private key of extuser@B (not of the trusted user outside), and has set it up, at the first place!
              – Sunthar
              Sep 29 '16 at 20:55















            up vote
            1
            down vote













            ProxyCommand is a clean solution for a case when you allow shell access in both the systems. We wanted to give remote users access to an internal machine (A) through a broker (B), but without allowing the user a shell access to B for improved security. This worked:



            Replace the login shell



            Replace the login shell (use chsh) for extuser on the broker with the following script (stored in a file):



            #!/bin/sh   # this is essential to avoid Exec format error
            ssh internaluser@A


            Provided no password login has been set up in extuser@B for the remote user and in internaluser@A for extuser@B, then executing the following command will directly take the remote user to A



            ssh extuser@B


            Tip: Create the necessary no password login authorized_keys setup in extuser@B before changing to the custom login shell. After the change, since this account is inaccessible to anybody through a shell, only a sudoer@B can make changes to the file authorized_keys by editing it directly.



            sudo vi ~extuser/.ssh/authorized_keys
            sudo touch ~extuser/.hushlogin


            The last line is to supress the login banner display from B, so the remote user has a transparent access to A.






            share|improve this answer























            • Very interesting approach. However, the main downsides of this are: 1) Use is limited to standard SSH usage (no SFTP/SCP support). 2) A user can't select another target host other than the single one (because hardcoded in login shell) 3) Host key validation can't be done from workstation to the final target host (since the use of the broker SSH binary). 4) Private keys for users to access the final target host are residing on the broker rather than with the user. This allows for impersonation of the user by an admin (which isn't possible normally).
              – gertvdijk
              Aug 5 '16 at 13:01










            • All points true, thanks for elaborating. However, the primary purpose is to provide a trusted user ssh access to A without login to B. Since only admin can add the public key of the trusted user on B (through sudo, without login), this already implies that the user has (admin) access to the private key of extuser@B (not of the trusted user outside), and has set it up, at the first place!
              – Sunthar
              Sep 29 '16 at 20:55













            up vote
            1
            down vote










            up vote
            1
            down vote









            ProxyCommand is a clean solution for a case when you allow shell access in both the systems. We wanted to give remote users access to an internal machine (A) through a broker (B), but without allowing the user a shell access to B for improved security. This worked:



            Replace the login shell



            Replace the login shell (use chsh) for extuser on the broker with the following script (stored in a file):



            #!/bin/sh   # this is essential to avoid Exec format error
            ssh internaluser@A


            Provided no password login has been set up in extuser@B for the remote user and in internaluser@A for extuser@B, then executing the following command will directly take the remote user to A



            ssh extuser@B


            Tip: Create the necessary no password login authorized_keys setup in extuser@B before changing to the custom login shell. After the change, since this account is inaccessible to anybody through a shell, only a sudoer@B can make changes to the file authorized_keys by editing it directly.



            sudo vi ~extuser/.ssh/authorized_keys
            sudo touch ~extuser/.hushlogin


            The last line is to supress the login banner display from B, so the remote user has a transparent access to A.






            share|improve this answer














            ProxyCommand is a clean solution for a case when you allow shell access in both the systems. We wanted to give remote users access to an internal machine (A) through a broker (B), but without allowing the user a shell access to B for improved security. This worked:



            Replace the login shell



            Replace the login shell (use chsh) for extuser on the broker with the following script (stored in a file):



            #!/bin/sh   # this is essential to avoid Exec format error
            ssh internaluser@A


            Provided no password login has been set up in extuser@B for the remote user and in internaluser@A for extuser@B, then executing the following command will directly take the remote user to A



            ssh extuser@B


            Tip: Create the necessary no password login authorized_keys setup in extuser@B before changing to the custom login shell. After the change, since this account is inaccessible to anybody through a shell, only a sudoer@B can make changes to the file authorized_keys by editing it directly.



            sudo vi ~extuser/.ssh/authorized_keys
            sudo touch ~extuser/.hushlogin


            The last line is to supress the login banner display from B, so the remote user has a transparent access to A.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Sep 29 '16 at 20:41

























            answered Jun 8 '16 at 18:27









            Sunthar

            112




            112












            • Very interesting approach. However, the main downsides of this are: 1) Use is limited to standard SSH usage (no SFTP/SCP support). 2) A user can't select another target host other than the single one (because hardcoded in login shell) 3) Host key validation can't be done from workstation to the final target host (since the use of the broker SSH binary). 4) Private keys for users to access the final target host are residing on the broker rather than with the user. This allows for impersonation of the user by an admin (which isn't possible normally).
              – gertvdijk
              Aug 5 '16 at 13:01










            • All points true, thanks for elaborating. However, the primary purpose is to provide a trusted user ssh access to A without login to B. Since only admin can add the public key of the trusted user on B (through sudo, without login), this already implies that the user has (admin) access to the private key of extuser@B (not of the trusted user outside), and has set it up, at the first place!
              – Sunthar
              Sep 29 '16 at 20:55


















            • Very interesting approach. However, the main downsides of this are: 1) Use is limited to standard SSH usage (no SFTP/SCP support). 2) A user can't select another target host other than the single one (because hardcoded in login shell) 3) Host key validation can't be done from workstation to the final target host (since the use of the broker SSH binary). 4) Private keys for users to access the final target host are residing on the broker rather than with the user. This allows for impersonation of the user by an admin (which isn't possible normally).
              – gertvdijk
              Aug 5 '16 at 13:01










            • All points true, thanks for elaborating. However, the primary purpose is to provide a trusted user ssh access to A without login to B. Since only admin can add the public key of the trusted user on B (through sudo, without login), this already implies that the user has (admin) access to the private key of extuser@B (not of the trusted user outside), and has set it up, at the first place!
              – Sunthar
              Sep 29 '16 at 20:55
















            Very interesting approach. However, the main downsides of this are: 1) Use is limited to standard SSH usage (no SFTP/SCP support). 2) A user can't select another target host other than the single one (because hardcoded in login shell) 3) Host key validation can't be done from workstation to the final target host (since the use of the broker SSH binary). 4) Private keys for users to access the final target host are residing on the broker rather than with the user. This allows for impersonation of the user by an admin (which isn't possible normally).
            – gertvdijk
            Aug 5 '16 at 13:01




            Very interesting approach. However, the main downsides of this are: 1) Use is limited to standard SSH usage (no SFTP/SCP support). 2) A user can't select another target host other than the single one (because hardcoded in login shell) 3) Host key validation can't be done from workstation to the final target host (since the use of the broker SSH binary). 4) Private keys for users to access the final target host are residing on the broker rather than with the user. This allows for impersonation of the user by an admin (which isn't possible normally).
            – gertvdijk
            Aug 5 '16 at 13:01












            All points true, thanks for elaborating. However, the primary purpose is to provide a trusted user ssh access to A without login to B. Since only admin can add the public key of the trusted user on B (through sudo, without login), this already implies that the user has (admin) access to the private key of extuser@B (not of the trusted user outside), and has set it up, at the first place!
            – Sunthar
            Sep 29 '16 at 20:55




            All points true, thanks for elaborating. However, the primary purpose is to provide a trusted user ssh access to A without login to B. Since only admin can add the public key of the trusted user on B (through sudo, without login), this already implies that the user has (admin) access to the private key of extuser@B (not of the trusted user outside), and has set it up, at the first place!
            – Sunthar
            Sep 29 '16 at 20:55










            up vote
            1
            down vote













            You mean you need several jumpers:)



            Recently,I met this problem with jumper1 jumper2 and my final machine,as for my sol



            local script:



            #!/bin/bash
            sshpass -p jumper1Passwd ssh -t jumper1@jumper1IP ./Y00.sh


            then on the 1st jumper (which is my router), I placed a script named Y00.sh:



            ssh -tt jumper2@jumper2 -i ~/.ssh/id_rsa sshpass -p finalPassWord ssh -tt final@final


            You can replace these with your IP and passwords, good luck!






            share|improve this answer

























              up vote
              1
              down vote













              You mean you need several jumpers:)



              Recently,I met this problem with jumper1 jumper2 and my final machine,as for my sol



              local script:



              #!/bin/bash
              sshpass -p jumper1Passwd ssh -t jumper1@jumper1IP ./Y00.sh


              then on the 1st jumper (which is my router), I placed a script named Y00.sh:



              ssh -tt jumper2@jumper2 -i ~/.ssh/id_rsa sshpass -p finalPassWord ssh -tt final@final


              You can replace these with your IP and passwords, good luck!






              share|improve this answer























                up vote
                1
                down vote










                up vote
                1
                down vote









                You mean you need several jumpers:)



                Recently,I met this problem with jumper1 jumper2 and my final machine,as for my sol



                local script:



                #!/bin/bash
                sshpass -p jumper1Passwd ssh -t jumper1@jumper1IP ./Y00.sh


                then on the 1st jumper (which is my router), I placed a script named Y00.sh:



                ssh -tt jumper2@jumper2 -i ~/.ssh/id_rsa sshpass -p finalPassWord ssh -tt final@final


                You can replace these with your IP and passwords, good luck!






                share|improve this answer












                You mean you need several jumpers:)



                Recently,I met this problem with jumper1 jumper2 and my final machine,as for my sol



                local script:



                #!/bin/bash
                sshpass -p jumper1Passwd ssh -t jumper1@jumper1IP ./Y00.sh


                then on the 1st jumper (which is my router), I placed a script named Y00.sh:



                ssh -tt jumper2@jumper2 -i ~/.ssh/id_rsa sshpass -p finalPassWord ssh -tt final@final


                You can replace these with your IP and passwords, good luck!







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Dec 13 at 14:39









                Z-Y00

                211




                211






















                    up vote
                    0
                    down vote













                    This is a very helpful suggestion. After messing about for hours, I found this note, & confirmed this works exactly as documented. To connect thru MachineA to MachineB, from remote machineC:



                    eg: [xuser@machineC ~] ssh -t MachineA ssh MachineB



                    The "-t" is critical, ssh fails if it is not present.
                    You will get prompted twice, first for password on MachineA, then second time for
                    MachineB. Also, note that this assumes you have user "xuser" defined on all
                    three machines. If not, just use the ssh syntax: "yuser@MachineA ...". Also note that
                    you can use dotted quad raw IP#s, if you want to. This is useful if you are linking
                    thru a private local net which is using IPs not exposed to the world - ie. not in
                    your local host file, or any DNS. To get a file from MachineB, to remote machineC,
                    you can scp from MachineB to MachineA, then from MachineA to remote machineC. (Eg. the
                    remote machineC can ping MachineA, but not MachineB.) Caveat: I tested with Fedora and WindowsXP, MachineA is an XP-box running ICS (Internet Connection Sharing), while MachineB and remote machineC are Fedora-Linux boxes. This suggestion solved a key problem for me - ie. restricted, monitored remote access to my remote site lan.
                    Note also, when you "logout" from MachineB, you should see two "Connection to xxx.xxx.xxx.xxx closed." messages.






                    share|improve this answer





















                    • If you set up and configure public key authentication, then you don't need to worry about entering in your passwords. But -t is still required.
                      – Felipe Alvarez
                      Feb 19 '15 at 12:45










                    • @FelipeAlvarez You still have to worry about entering the second password if you don't trust machine B to have passwordless login to A!
                      – Michael
                      Apr 23 '17 at 21:59















                    up vote
                    0
                    down vote













                    This is a very helpful suggestion. After messing about for hours, I found this note, & confirmed this works exactly as documented. To connect thru MachineA to MachineB, from remote machineC:



                    eg: [xuser@machineC ~] ssh -t MachineA ssh MachineB



                    The "-t" is critical, ssh fails if it is not present.
                    You will get prompted twice, first for password on MachineA, then second time for
                    MachineB. Also, note that this assumes you have user "xuser" defined on all
                    three machines. If not, just use the ssh syntax: "yuser@MachineA ...". Also note that
                    you can use dotted quad raw IP#s, if you want to. This is useful if you are linking
                    thru a private local net which is using IPs not exposed to the world - ie. not in
                    your local host file, or any DNS. To get a file from MachineB, to remote machineC,
                    you can scp from MachineB to MachineA, then from MachineA to remote machineC. (Eg. the
                    remote machineC can ping MachineA, but not MachineB.) Caveat: I tested with Fedora and WindowsXP, MachineA is an XP-box running ICS (Internet Connection Sharing), while MachineB and remote machineC are Fedora-Linux boxes. This suggestion solved a key problem for me - ie. restricted, monitored remote access to my remote site lan.
                    Note also, when you "logout" from MachineB, you should see two "Connection to xxx.xxx.xxx.xxx closed." messages.






                    share|improve this answer





















                    • If you set up and configure public key authentication, then you don't need to worry about entering in your passwords. But -t is still required.
                      – Felipe Alvarez
                      Feb 19 '15 at 12:45










                    • @FelipeAlvarez You still have to worry about entering the second password if you don't trust machine B to have passwordless login to A!
                      – Michael
                      Apr 23 '17 at 21:59













                    up vote
                    0
                    down vote










                    up vote
                    0
                    down vote









                    This is a very helpful suggestion. After messing about for hours, I found this note, & confirmed this works exactly as documented. To connect thru MachineA to MachineB, from remote machineC:



                    eg: [xuser@machineC ~] ssh -t MachineA ssh MachineB



                    The "-t" is critical, ssh fails if it is not present.
                    You will get prompted twice, first for password on MachineA, then second time for
                    MachineB. Also, note that this assumes you have user "xuser" defined on all
                    three machines. If not, just use the ssh syntax: "yuser@MachineA ...". Also note that
                    you can use dotted quad raw IP#s, if you want to. This is useful if you are linking
                    thru a private local net which is using IPs not exposed to the world - ie. not in
                    your local host file, or any DNS. To get a file from MachineB, to remote machineC,
                    you can scp from MachineB to MachineA, then from MachineA to remote machineC. (Eg. the
                    remote machineC can ping MachineA, but not MachineB.) Caveat: I tested with Fedora and WindowsXP, MachineA is an XP-box running ICS (Internet Connection Sharing), while MachineB and remote machineC are Fedora-Linux boxes. This suggestion solved a key problem for me - ie. restricted, monitored remote access to my remote site lan.
                    Note also, when you "logout" from MachineB, you should see two "Connection to xxx.xxx.xxx.xxx closed." messages.






                    share|improve this answer












                    This is a very helpful suggestion. After messing about for hours, I found this note, & confirmed this works exactly as documented. To connect thru MachineA to MachineB, from remote machineC:



                    eg: [xuser@machineC ~] ssh -t MachineA ssh MachineB



                    The "-t" is critical, ssh fails if it is not present.
                    You will get prompted twice, first for password on MachineA, then second time for
                    MachineB. Also, note that this assumes you have user "xuser" defined on all
                    three machines. If not, just use the ssh syntax: "yuser@MachineA ...". Also note that
                    you can use dotted quad raw IP#s, if you want to. This is useful if you are linking
                    thru a private local net which is using IPs not exposed to the world - ie. not in
                    your local host file, or any DNS. To get a file from MachineB, to remote machineC,
                    you can scp from MachineB to MachineA, then from MachineA to remote machineC. (Eg. the
                    remote machineC can ping MachineA, but not MachineB.) Caveat: I tested with Fedora and WindowsXP, MachineA is an XP-box running ICS (Internet Connection Sharing), while MachineB and remote machineC are Fedora-Linux boxes. This suggestion solved a key problem for me - ie. restricted, monitored remote access to my remote site lan.
                    Note also, when you "logout" from MachineB, you should see two "Connection to xxx.xxx.xxx.xxx closed." messages.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Apr 16 '14 at 22:34









                    Mcl

                    11




                    11












                    • If you set up and configure public key authentication, then you don't need to worry about entering in your passwords. But -t is still required.
                      – Felipe Alvarez
                      Feb 19 '15 at 12:45










                    • @FelipeAlvarez You still have to worry about entering the second password if you don't trust machine B to have passwordless login to A!
                      – Michael
                      Apr 23 '17 at 21:59


















                    • If you set up and configure public key authentication, then you don't need to worry about entering in your passwords. But -t is still required.
                      – Felipe Alvarez
                      Feb 19 '15 at 12:45










                    • @FelipeAlvarez You still have to worry about entering the second password if you don't trust machine B to have passwordless login to A!
                      – Michael
                      Apr 23 '17 at 21:59
















                    If you set up and configure public key authentication, then you don't need to worry about entering in your passwords. But -t is still required.
                    – Felipe Alvarez
                    Feb 19 '15 at 12:45




                    If you set up and configure public key authentication, then you don't need to worry about entering in your passwords. But -t is still required.
                    – Felipe Alvarez
                    Feb 19 '15 at 12:45












                    @FelipeAlvarez You still have to worry about entering the second password if you don't trust machine B to have passwordless login to A!
                    – Michael
                    Apr 23 '17 at 21:59




                    @FelipeAlvarez You still have to worry about entering the second password if you don't trust machine B to have passwordless login to A!
                    – Michael
                    Apr 23 '17 at 21:59


















                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Ask Ubuntu!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f311447%2fhow-do-i-ssh-to-machine-a-via-b-in-one-command%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    How did Captain America manage to do this?

                    迪纳利

                    南乌拉尔铁路局