How do I SSH to machine A via B in one command?
up vote
79
down vote
favorite
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:
Log in to a different university machine, say machine B
(This machine B is accessible via SSH from my home computer.)
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
add a comment |
up vote
79
down vote
favorite
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:
Log in to a different university machine, say machine B
(This machine B is accessible via SSH from my home computer.)
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
add a comment |
up vote
79
down vote
favorite
up vote
79
down vote
favorite
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:
Log in to a different university machine, say machine B
(This machine B is accessible via SSH from my home computer.)
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
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:
Log in to a different university machine, say machine B
(This machine B is accessible via SSH from my home computer.)
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
networking ssh remote-access tunnel
edited Jun 22 '13 at 15:57
gertvdijk
49.9k18141235
49.9k18141235
asked Jun 22 '13 at 15:03
nikosdi
5171710
5171710
add a comment |
add a comment |
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 or 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.
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
add a comment |
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.
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
add a comment |
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.
3
+1 because this works even if you need to specify key file for machineA
– Grief
Feb 21 at 10:36
add a comment |
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.
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 theB
machine, either.
– danemacmillan
Jul 13 '16 at 21:47
add a comment |
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.
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
add a comment |
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!
add a comment |
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.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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 or 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.
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
add a comment |
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 or 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.
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
add a comment |
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 or 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.
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 or 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.
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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
3
+1 because this works even if you need to specify key file for machineA
– Grief
Feb 21 at 10:36
add a comment |
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.
3
+1 because this works even if you need to specify key file for machineA
– Grief
Feb 21 at 10:36
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
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 theB
machine, either.
– danemacmillan
Jul 13 '16 at 21:47
add a comment |
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.
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 theB
machine, either.
– danemacmillan
Jul 13 '16 at 21:47
add a comment |
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.
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.
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 theB
machine, either.
– danemacmillan
Jul 13 '16 at 21:47
add a comment |
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 theB
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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!
add a comment |
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!
add a comment |
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!
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!
answered Dec 13 at 14:39
Z-Y00
211
211
add a comment |
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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