I have a machine behind a firewall which is accessible from my server via a reverse SSH tunnel.
I would now like to prevent everyone from logging in to the machine IF they came from the ssh tunnel connection. Is this possible?
You can use the match directive in sshd_config to not provide a shell for connections coming from a specific ip address
Match Address 10.1.1.1/32
ForceCommand /bin/false
Related
i made some tests with verbose argument while initializing ssh tunnels,
with a GOOD a WRONG destination address,
but i didn't see a difference between good and bad ssh tunnel initialization.
when i launch my ssh tunnel with a reachable ip address, like that :
ssh -L 3338:<reachable-ip-adress>:4000 my-user#bastion1.amfinesoft.net
verbose mode returns to me :
debug1: Requesting forwarding of local forward LOCALHOST:3338 -> ip-adress:4000
AND when i launch my ssh tunnel with a UNREACHABLE ip address, like that :
ssh -L 3339:<unreachable-ip-adress>:4001 my-user#bastion1.amfinesoft.net
verbose mode returns to me the same output !
debug1: Requesting forwarding of local forward LOCALHOST:3339 -> ip-adress:4001
In the first test, i know my ssh tunnel is correctly intialized, but not the second test.
So, my question is : how to check, on my bastion1 machine, or on my localhost machine that desired ssh tunnel has beenn correctly initialized ?
The tunnel was setup correctly in both cases, as the tunnel exists only between your local system and the system you ssh to (bastion1).
Setting up a tunnel will not check, if packets can actually be forwarded, as ssh has no knowledge on the protocol inside the tunnel and how forwarding works. Only once you send a packet through the tunnel and the sshd on bastion1.amfinesoft.net will try to forward it to the unreachable IP-Address, you will be able to see, whether or not your target address is reachable.
So to check if your tunnel is working, you need to check whether the target system can be reached, using the protocol you are tunnelling.
I want to make a local port that serve a python http.server accessible to the internet without messing around with port-forwarding on my home router, tunnelling it on a digital ocean vps.
My local port is 8080, the port on the remote vps 4444, just for example
ssh -i .ssh/mykey -R 4444:localhost:8080 root#myvpsip
But still http://myvpsip:4444 is not accessible
ufw is disabled on the vps..What am I missing?
For the forwarded port to listen on any address (and not just localhost) you need to prepend an additional : to the forward specification.
ssh -i .ssh/mykey -R :4444:localhost:8080 root#myvpsip
Additionally, you must have GatewayPorts yes or GatewayPorts clientspecified on the server-side sshd configuration.
I am trying to access my Linux machine from anywhere in the world. I have tried originally port forwarding and then ssh'ing in; however, I believe my school's WiFi won't allow port forwarding (every time I ran it, it would tell me connection refused). I have setup an account with ngrok and I can remotely SSH in, but now I am wondering if it is possible to RDP. I tried connecting via the Microsoft Remote Desktop app on Mac, but it instantly crashes. I have also looked at trying to connect with localhost, but it's not working. So far, I have tried (with xxxx being the port):
ssh -L xxxx:localhost:xxxx 0.tcp.ngrok.io
and
ssh -L xxxx:localhost:xxxx <user>#0.tcp.ngrok.io
but my computer won't allow it and after about 2 or 3 times, it warns me of a possible DNS Spoofing. Is there anyway that I can run a remote desktop of my linux machine that I have ssh tunneled to (from my mac) on ngrok? Thank you!
First you'll need to sign up with ngrok if you haven't already and you'll be given an authtoken. You'll need to install this by running
./ngrok authtoken <insert your token here>
This will save your token to a file located ../username/.ngrok/ngrok.yml
Then you'll need to ask ngrok to create a TCP tunnel from their servers to your local machine's Remote Desktop port which should be 3389 by default
ngrok tcp 3389
Give it 30 seconds or so then jump to http://localhost:4040/status to see what the tcp address ngrok has allocated you. It should look something like tcp://1.tcp.ngrok.io:158764
Now you should be able to remote into your machine using address 1.tcp.ngrok.io:158764
I am using agent forwarding, it works fine. But the ssh client is sharing all registered (ssh-add) keys with the remote server. I have personal keys that I don't want to share with the remote server. Is there a way to restrict with keys are being forwarded?
I have multiple github accounts and aws accounts. I don't want to share all the ssh-keys.
Looks like it is possible with OpenSSH 6.7 - it supports unix socket forwarding. We could start secondary ssh-agent with specific keys and forward it's socket to remote host. Unfortunately this version is not available for my server/client systems at the time of writing.
I have found another possible solution, using socat and standard SSH TCP forwarding.
Idea
On local host we run secondary ssh-agent with only keys we want to see on remote host.
On local host we set up forwarding of TCP connections on some port (portXXX) to secondary ssh-agent's socket.
On remote host we set up forwarding from some socket to some TCP port (portYYY).
Then we establish ssh connection with port forwarding from remote's portYYY to local portXXX.
Requests to ssh agent go like this:
local ssh-agent (secondary)
^
|
v
/tmp/ssh-.../agent.ZZZZZ - agent's socket
^
| (socat local)
v
localhost:portXXX
^
| (ssh port forwarding)
v
remote's localhost:portYYY
^
| (socat remote)
v
$HOME/tmp/agent.socket
^
| (requests for auth via agent)
v
SSH_AUTH_SOCK=$HOME/tmp/agent.socket
^
| (uses SSH_AUTH_SOCK variable to find agent socket)
v
ssh
Drawbacks
It is not completely secure, because ssh-agent becomes partially available through TCP: users of remote host can connect to your local agent on 127.0.0.1:portYYY, and other users of your local host can connect on 127.0.0.1:portXXX. But they will see only limited set of keys you manually added to this agent. And, as AllenLuce mentioned, they can't grab it, they only could use it for authentication while agent is running.
socat must be installed on remote host. But looks like it is possible to simply upload precompiled binary (I tested it on FreeBSD and it works).
No automation: keys must be added manually via ssh-add, forwarding requires 2 extra processes (socat) to be run, multiple ssh connections must be managed manually.
So, this answer is probably just a proof of concept and not a production solution.
Let's see how it can be done.
Instruction
Client side (where ssh-agent is running)
Run new ssh-agent. It will be used for keys you want to see on remote host only.
$ ssh-agent # below is ssh-agent output, DO NOT ACTUALLY RUN THESE COMMANDS BELOW
SSH_AUTH_SOCK=/tmp/ssh-qVnT0UsgV6yO/agent.22982; export SSH_AUTH_SOCK;
SSH_AGENT_PID=22983; export SSH_AGENT_PID;
It prints some variables. Do not set them: you will loose your main ssh agent. Set another variable with suggested value of SSH_AUTH_SOCK:
SSH_AUTH_SECONDARY_SOCK=/tmp/ssh-qVnT0UsgV6yO/agent.22982
Then establish forwarding from some TCP port to our ssh-agent socket locally:
PORT=9898
socat TCP4-LISTEN:$PORT,bind=127.0.0.1,fork UNIX-CONNECT:$SSH_AUTH_SECONDARY_SOCK &
socat will run in background. Do not forget to kill it when you're done.
Add some keys using ssh-add, but run it with modified enviromnent variable SSH_AUTH_SOCK:
SSH_AUTH_SOCK=$SSH_AUTH_SECONDARY_SOCK ssh-add
Server side (remote host)
Connect to remote host with port forwarding. Your main (not secondary) ssh agent will be used for auth on hostA (but will not be available from it, as we do not forward it).
home-host$ PORT=9898 # same port as above
home-host$ ssh -R $PORT:localhost:$PORT userA#hostA
On remote host establish forwarding from ssh-agent socket to same TCP port as on your home host:
remote-host$ PORT=9898 # same port as on home host
remote-host$ mkdir -p $HOME/tmp
remote-host$ SOCKET=$HOME/tmp/ssh-agent.socket
remote-host$ socat UNIX-LISTEN:$SOCKET,fork TCP4:localhost:$PORT &
socat will run in background. Do not forget to kill it when you're done. It does not automatically exit when you close ssh connection.
Connection
On remote host set enviromnent variable for ssh to know where agent socket (from previous step) is. It can be done in same ssh session or in parallel one.
remote-host$ export SSH_AUTH_SOCK=$HOME/tmp/ssh-agent.socket
Now it is possible to use secondary agent's keys on remote host:
remote-host$ ssh userB#hostB # uses secondary ssh agent
Welcome to hostB!
The keys themselves are not shared by forwarding your agent. What's forwarded is the ability to contact the ssh-agent on your local host. Remote systems send challenge requests through the forwarding tunnel. They do not request the keys themselves.
See http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fwd for a graphical explanation.
Server A with memcached, Server B needs to use memcached. If I leave memcached open to all ips (default), Server B can:
telnet server.a.etc 11211
and get in. If I ping server B, I get an ip, 153.353.234.23 (example), and I put that in my memcached options
OPTIONS="-l 153.353.234.23"
restart and now server b can't connect over telnet any longer. I assume this is because perhaps it is using a different ip address for this connection? Some other error? Either way, I'd like to be able to see the ip of server B when it connects.
I enabled memcached logging
-vvv >var/log/memcached.log 2>&1
and I see logs getting generated, but not the ip addresses of connecting machines.
with memcached -l you are instructing the memcached server to bind on a specific IP address of the server. This is useful if you want memcached to accept data on a specific IP or network interface on your server node.
You can leave the default to make memcached bind on any IP address of the server (0.0.0.0 on IPv4).
I don't think memcached has a command switch to login the source IP.
You can use the command
netstat -natp | grep 11211 | grep ESTABLISHED
on a linux system to get the established connections to memcached and the IPs of the clients.
You can:
telnet telnetmyip.com
also
ssh telnetmyip.com
also
curl telnetmyip.com