My use case is I have to access AWS ec2 instances through a jumpbox.
Here is my SSH config.
Host awsjumpbox
User sshuser
HostName jumpboxhostname
IdentityFile /Users/myusername/.ssh/id_rsa
LocalForward 8022 10.0.168.43:22
It works when I do SCP command to copy files to the EC2 instance.
myusername % scp -r -i ~/aws/aws-keypair.pem -P 8022 * ec2-user#localhost:testdir
The authenticity of host '[localhost]:8022 ([::1]:8022)' can't be established.
ECDSA key fingerprint is SHA256:rrwr62yjP2cgUTT9SowdlrIwGi4jMMwt5x4Aj6E4Y3Y.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[localhost]:8022' (ECDSA) to the list of known hosts.
/etc/profile.d/lang.sh: line 19: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
README.md 100% 1064 24.3KB/s 00:00
However, when I executed SSH command. It returns a strange IP address.
myusername % ssh -i ~/aws/aws-keypair.pem -P 8022 ec2-user#localhost
ssh: connect to host 0.0.31.86 port 22: No route to host
What is the cause of this issue? How do I fix it?
Thank you.
Don't use LocalForward and reverse the flow.
Use ProxyCommand or ProxyJump. This will allow SSH to open a session to your bastion server transparently.
E.g. your configuration should be something in the line of
Host 10.0.168.43
User root
ProxyCommand ssh -W %h:%p sshuser#awsjumpbox
...
or
Host 10.0.168.43
User root
ProxyJump sshuser#awsjumpbox
...
I have setup a tunnel through a jump host as such :
ssh -o ProxyCommand='ssh -W %h:%p bastion' -i my-emr.pem -ND 8888 hadoop#ip-my.ec2.internal
bastion is a host I have defined in my ~/.ssh/config
This way I can access ip-my.ec2.internal etc. via a SOCKS5 proxy. I want to test whether this host is accessible via SOCKS5 proxy. Is there a command I can use? I can test if the bastion host is accessible using a command like this :
nc -G 2 -z my-bastion.com 22
Anyway I can extend the above command to test if the end host which is ip-my.ec2.internal?
It looks like all your testing in the nc command is whether port 22 will allow a connection within 2 seconds. That's not the same thing whether you can can make an SSH connection to my-bastion. It doesn't even prove that you can connect to my-bastion at all. It is not uncommon for firewalls to accept connections that they will not pass any data for.
If you want the same level of weak testing you'd do the same thing along the lines of:
ssh bastion nc -G 2 -z ip-my.ec2.internal 8888
There are lots of ways for this to incorrectly return that it is reachable when it isn't, just as there are lots of ways for your other nc command can fail. But it might give you some useful information for managing a UI.
The only way to know that network connection is possible is to attempt the actual network connection you want. As a rule, you should not pre-flight network connections. Just attempt them, and deal with connection errors (which can happen even if your pre-flights pass). If the goal is to avoid long waits, then shorten your timeouts (which will lead to more false-negatives when the network is slow).
I have a complex SSH tunnel problem I'm trying to solve and can't seem to get it quite right.
Simply put:
ME -> Bastion:22 -> Instance:8500
Bastion uses a different username and key than instance. I would like to be able to access port 1234 on instance from localhost:1234
Right now I have the following:
Host bastion
HostName bastion.example.com
ForwardAgent yes
IdentityFile ~/.ssh/id_ecdsa
User spanky
Host internal
ForwardAgent yes
HostName consul.internal
IdentityFile ~/.ssh/aws.pem
ProxyJump bastion
User ec2-user
Port 8500
But I don't think I've got it.
The following two commands work, but I'm trying to distill them into a working config:
ssh -L 2222:10.0.0.42:22 bastion.example.com -N -i ~/.ssh/id_ecdsa
ssh -L 8500:localhost:8500 ec2-user#localhost -N -i ~/.ssh/aws.pem -p 2222
With a current version of ssh, you should be able to use:
ssh -L1234:localhost:1234 -J spanky#bastion.example.com ec2-user#consul.internal
From man ssh:
-J destination
Connect to the target host by first making a ssh
connection to the jump host described by destination 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.
I have a bash script using ssh to remote forward, so that I can login the machine running the script. I use a script because periodically the network needs some sort of auth. If ssh fails, I'll retry. The script is basically this:
while [ 1 ]; do
authentication
ssh -N -v -R 9999:localhost:22 user#$remote_ip
done
The problem is ssh won't exit upon remote forward failure like below:
debug1: Remote: Forwarding listen address "localhost" overridden by server GatewayPorts
debug1: remote forward failure for: listen 9999, connect localhost:22
Warning: remote port forwarding failed for listen port 9999
debug1: All remote forwarding requests processed
The failure is due to this:
debug1: server_input_global_request: tcpip-forward listen localhost port 9999
debug1: Local forwarding listening on 0.0.0.0 port 9999.
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 9999
The previous session doesn't end yet, and the port is in use.
Is there a way to check whether ssh succeeds or not?
And as a programmer, I really can't understand why it's designed this way. What's the rationale behind this design?
You can pass in config parameter ExitOnForwardFailure to tell ssh client to terminate the connection if it cannot set up port forwarding.
ExitOnForwardFailure
Specifies whether ssh(1) should terminate the connection if it cannot set up all requested dynamic, tunnel, local, and remote port forwardings. The argument must be ''yes'' or ''no''. The default is ''no''.
Something like:
ssh -N -v -R 9999:localhost:22 user#$remote_ip -o ExitOnForwardFailure=yes
Your ssh session has a timeout on the server side, so when you try to reconnect, the previous connection is still listening on port 9000.
Use openvpn, instead of this hacky solution.
I have a small local network. Only one of the machines is available to the outside world (this is not easily changeable). I'd like to be able to set it up such that ssh requests that don't come in on the standard port go to another machine. Is this possible? If so, how?
Oh and all of these machines are running either Ubuntu or OS X.
Another way to go would be to use ssh tunneling (which happens on the client side).
You'd do an ssh command like this:
ssh -L 8022:myinsideserver:22 paul#myoutsideserver
That connects you to the machine that's accessible from the outside (myoutsideserver) and creates a tunnel through that ssh connection to port 22 (the standard ssh port) on the server that's only accessible from the inside.
Then you'd do another ssh command like this (leaving the first one still connected):
ssh -p 8022 paul#localhost
That connection to port 8022 on your localhost will then get tunneled through the first ssh connection taking you over myinsideserver.
There may be something you have to do on myoutsideserver to allow forwarding of the ssh port. I'm double-checking that now.
Edit
Hmmm. The ssh manpage says this: **Only the superuser can forward privileged ports. **
That sort of implies to me that the first ssh connection has to be as root. Maybe somebody else can clarify that.
It looks like superuser privileges aren't required as long as the forwarded port (in this case, 8022) isn't a privileged port (like 22). Thanks for the clarification Mike Stone.
#Mark Biek
I was going to say that, but you beat me to it! Anyways, I just wanted to add that there is also the -R option:
ssh -R 8022:myinsideserver:22 paul#myoutsideserver
The difference is what machine you are connecting to/from. My boss showed me this trick not too long ago, and it is definitely really nice to know... we were behind a firewall and needed to give external access to a machine... he got around it by ssh -R to another machine that was accessible... then connections to that machine were forwarded into the machine behind the firewall, so you need to use -R or -L based on which machine you are on and which you are ssh-ing to.
Also, I'm pretty sure you are fine to use a regular user as long as the port you are forwarding (in this case the 8022 port) is not below the restricted range (which I think is 1024, but I could be mistaken), because those are the "reserved" ports. It doesn't matter that you are forwarding it to a "restricted" port because that port is not being opened (the machine is just having traffic sent to it through the tunnel, it has no knowledge of the tunnel), the 8022 port IS being open and so is restricted as such.
EDIT: Just remember, the tunnel is only open so long as the initial ssh remains open, so if it times out or you exit it, the tunnel will be closed.
(In this example, I am assuming port 2222 will go to your internal host. $externalip and $internalip are the ip addresses or hostnames of the visible and internal machine, respectively.)
You have a couple of options, depending on how permanent you want the proxying to be:
Some sort of TCP proxy. On Linux, the basic idea is that before the incoming packet is processed, you want to change its destination—i.e. prerouting destination NAT:
iptables -t nat -A PREROUTING -p tcp -i eth0 -d $externalip --dport 2222 --sport
1024:65535 -j DNAT --to $internalip:22
Using SSH to establish temporary port forwarding. From here, you have two options again:
Transparent proxy, where the client thinks that your visible host (on port 2222) is just a normal SSH server and doesn't realize that it is passing through. While you lose some fine-grained control, you get convenience (especially if you want to use SSH to forward VNC or X11 all the way to the inner host).
From the internal machine: ssh -g -R 2222:localhost:22 $externalip
Then from the outside world: ssh -p 2222 $externalip
Notice that the "internal" and "external" machines do not have to be on the same LAN. You can port forward all the way around the world this way.
Forcing login to the external machine first. This is true "forwarding," not "proxying"; but the basic idea is this: You force people to log in to the external machine (so you control on who can log in and when, and you get logs of the activity), and from there they can SSH through to the inside. It sounds like a chore, but if you set up simple shell scripts on the external machine with the names of your internal hosts, coupled with password-less SSH keypairs then it is very straightforward for a user to log in. So:
On the external machine, you make a simple script, /usr/local/bin/internalhost which simply runs ssh $internalip
From the outside world, users do: ssh $externalip internalhost and once they log in to the first machine, they are immediately forwarded through to the internal one.
Another advantage to this approach is that people don't get key management problems, since running two SSH services on one IP address will make the SSH client angry.
FYI, if you want to SSH to a server and you do not want to worry about keys, do this
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
I have an alias in my shell called "nossh", so I can just do nossh somehost and it will ignore all key errors. Just understand that you are ignoring security information when you do this, so there is a theoretical risk.
Much of this information is from a talk I gave at Barcamp Bangkok all about fancy SSH tricks. You can see my slides, but I recommend the text version as the S5 slides are kind of buggy. Check out the section called "Forward Anything: Simple Port Forwarding" for info. There is also information on creating a SOCKS5 proxy with OpenSSH. Yes, you can do that. OpenSSH is awesome like that.
(Finally, if you are doing a lot of traversing into the internal network, consider setting up a VPN. It sounds scary, but OpenVPN is quite simple and runs on all OSes. I would say it's overkill just for SSH; but once you start port-forwarding through your port-forwards to get VNC, HTTP, or other stuff happening; or if you have lots of internal hosts to worry about, it can be simpler and more maintainable.)
You can use Port Fowarding to do this. Take a look here:
http://portforward.com/help/portforwarding.htm
There are instructions on how to set up your router to port forward request on this page:
http://www.portforward.com/english/routers/port_forwarding/routerindex.htm
In Ubuntu, you can install Firestarter and then use it's Forward Service feature to forward the SSH traffic from a non standard port on your machine with external access to port 22 on the machine inside your network.
On OS X you can edit the /etc/nat/natd.plist file to enable port fowarding.
Without messing around with firewall rules, you can set up a ~/.ssh/config file.
Assume 10.1.1.1 is the 'gateway' system and 10.1.1.2 is the 'client' system.
Host gateway
Hostname 10.1.1.1
LocalForward 8022 10.1.1.2:22
Host client
Hostname localhost
Port 8022
You can open an ssh connection to 'gateway' via:
ssh gateway
In another terminal, open a connection to the client.
ssh client