Skip to content

This document is a WORK IN PROGRESS.
This is just a quick personal cheat sheet: treat its contents with caution!

SSH

SSH is a cryptographic network protocol for operating network services securely over an unsecured network.

In addition to remote terminal access provided by the main ssh binary, the ssh suite of programs has grown to include other tools such as scp (Secure Copy Program) and sftp (Secure File Transfer Protocol).

Reference(s)

Table of content

Install

Install openssh:

# emerge -a net-misc/openssh

# pacman -S openssh

For Artix users

  • If using openrc: 
    # pacman -S cronie openssh-openrc
  • If using runit: 
    # pacman -S cronie openssh-runit
  • If using s6: 
    # pacman -S cronie openssh-s6

# apt install openssh openssh-server

# yum install openssh

# dnf install openssh

If you also want to host an SSH server (sshd, SSH daemon), then add it to your init system and start it:

# rc-update add sshd default
# /etc/init.d/sshd start

Depending on your runit implementation, either run: 

# ln -s /etc/runit/sv/sshd /service
or run: 
# ln -s /etc/runit/sv/sshd /var/service
or run: 
# ln -s /etc/runit/sv/sshd /run/runit/service
In any case, finally run: 
# sv up sshd


# service sshd start
# chkconfig sshd on

# systemctl enable sshd
# systemctl start sshd

Config

  • Create an ssh key pair: 
    $ ssh-keygen -o -t rsa -b 4096 -C "user@mail.com" -f "/home/user/.ssh/ssh_key_name"

When creating the key pair, if asked to enter a passphrase: no passphrase might be just fine (e.g. for git use). In this case you can instead use this command: 

$ ssh-keygen -o -t rsa -b 4096 -C "user@mail.com" -f "/home/user/.ssh/ssh_key_name" -N ""

  • Add ssh key pair: 

    $ eval `ssh-agent -s`
$ ssh-add ~/.ssh/ssh_key_name

  • Check ssh key pair: 

    $ ssh-keygen -l -f ~/.ssh/id_rsa.pub

TODO: motd: https://www.kali-linux.fr/astuces/comment-securiser-son-serveur-ssh

Use

Prerequisite(s)

Make sure sshd is running on the remote computer, e.g. on SystemD based distro: 

remote-pc $ systemctl status sshd
If sshd is not active and running, then start the sshd service, e.g. on SystemD based distro: 
remote-pc $ sudo systemctl enable sshd
remote-pc $ sudo systemctl start sshd

  • Basic, password based, ssh connection (e.g. to remote user with 123.1.2.3 IP address): 

    $ ssh remoteuser@123.1.2.3

  • RSA (key pair) based ssh connection:

    • Copy and authorize the public key to the remote user (e.g. with 123.1.2.3 IP address): 

      $ ssh-copy-id -i /home/user/.ssh/ssh_key_name.pub remoteuser@123.1.2.3

      If you have to manually copy the public key, see https://web.archive.org/web/20220223140333/https://linuxhandbook.com/add-ssh-public-key-to-server/

    • Then configure ssh to use your ssh_key_name, e.g. with 123.1.2.3: 

      $ vi $HOME/.ssh/config
    > ...
  + >
  + > Host 123.1.2.3
  + >   IdentityFile ~/.ssh/ssh_key_name
  + >
    > ...

    • Finally, you should be able to connect to 123.1.2.3 without being asked for a password: 

      $ ssh remoteuser@123.1.2.3

    • If you still have to enter a password, make sure the target sshd server is well configured, e.g. check the /etc/ssh/sshd_config file and make sure the following options are configured appropriately:

      • PubkeyAuthentication should not be set to no (default is yes)
      • ChallengeResponseAuthentication should be set to no
      • AuthorizedKeysFile should be set to .ssh/authorized_keys
      • if StrictModes is set to yes (which is a sane default), then please make sure that the target $HOME/.ssh folder has the following permissions: drwx------ (if not, run $ chmod 700 $HOME/.ssh), and please make sure that the target $HOME/.ssh/authorized_keys file has the following permissions: -rw------- (if not, run $ chmod 600 $HOME/.ssh/authorized_keys)

  • Test ssh key: 

    $ ssh -T remoteuser@192.168.1.10

  • Copy a file trough ssh on a specific port (e.g. port 2222): 

    $ scp -P 2222 remoteuser@192.168.1.10:/home/remoteuser/plop.file /home/localuser/test.file

  • Copy a directory trough ssh: 

    $ scp -r remoteuser@192.168.1.10:/home/username/folder /home/localuser/folder

  • Avoid ssh freeze after inactivity (see https://serverfault.com/questions/575112/why-do-my-ssh-sessions-freeze-after-some-time): 

    $ vi ~/.ssh/config
    > ...
    > Host *
    >     ...
  + >     ServerAliveInterval 60
    > ...

  • Allow SSH agent forwarding in order to use your private and local SSH key remotely without worrying about leaving confidential data on the server you’re working with. See https://web.archive.org/web/20221214073944/https://www.howtogeek.com/devops/what-is-ssh-agent-forwarding-and-how-do-you-use-it/ : 

    $ vi $HOME/.ssh/config
  > ...
  > Host *
  >   ...
  >   ForwardAgent yes
  > ...

ssh-agent

Reference(s)

TODO

ssh tunneling

Reference(s)

Local forwarding

Reference(s)

  • Forward remote port 42001, of 10.10.0.1, on your local port 10042: 

    $ ssh -L 10042:127.0.0.1:42001 user_name@10.10.0.1

  • Forward remote port 42001, of 10.10.0.1, on your local port 10042, through multiple intermediate machines (multiple "hops"): 

    $ ssh -J gate1_user_name@gate1_ip_address,gate2_user_name@gate2_ip_address -L 10042:127.0.0.1:42001 user_name@10.10.0.1

  • Forward remote ports 42001 and 42002 (of 10.10.0.1) on your local ports 10042 and 20042, through multiple intermediate machines (multiple "hops"): 

    $ ssh -J gate1_user_name@gate1_ip_address,gate2_user_name@gate2_ip_address -L 10042:127.0.0.1:42001 -L 20042:127.0.0.1:42002 user_name@10.10.0.1

  • Forward remote ports 42001 and 42002 (of 192.168.0.1, seen by 10.10.0.1 on another network interface) on your local ports 10042 and 20042, through multiple intermediate machines (multiple "hops"): 

    $ ssh -J gate1_user_name@gate1_ip_address,gate2_user_name@gate2_ip_address -L 10042:192.168.0.1:42001 user_name@10.10.0.1

  • Forward remote port 42001, of 10.10.0.1, on your local port 10042 (without allowing to execute remote command -N, and allowing to bind your local port 10042 to any available interface - not just localhost the loopback interface): 

    $ ssh -L 10042:127.0.0.1:42001 -N -o GatewayPorts=yes user_name@10.10.0.1

Remote forwarding

Reference(s)
  • TODO 
    $ ssh -R ...

Dynamic forwarding

Reference(s)
  • TODO 
    $ ssh -D ...

Security considerations

  • Use SSH key pairs whenever possible to authenticate.

  • Set up a fail2ban (or similar alternative) service.

  • Set up a firewall service, excluding all unused open ports.

  • Lock SSH access for the root user.

  • Optionally don't use port 22 for SSH.

  • When using rsync through SSH, consider using restricted rsync.

Troubleshooting

OpenSSH RSA SHA-1 signatures

When connecting to a SSH server, you might get a similar error: 

Unable to negotiate with 123.1.2.3 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

As of version 8.8, OpenSSH disables RSA signatures using the SHA-1 hash algorithm by default. This change affects both the client and server components.

After upgrading to this version, you may have trouble connecting to older SSH servers that do not support the newer RSA/SHA-256/SHA-512 signatures. Support for these signatures was added in OpenSSH 7.2.

As well, you may have trouble using older SSH clients to connect to a server running OpenSSH 8.8 or higher. Some older clients do not automatically utilize the newer hashes. For example, PuTTY before version 0.75 is affected.

To resolve these problems, you can upgrade your SSH client/server wherever possible. If this is not feasible, support for the SHA-1 hashes may be re-enabled using the following config options: 

HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

Or using the ssh command with the following options: 

$ ssh -oHostKeyAlgorithms=+ssh-rsa -oPubkeyAcceptedAlgorithms=+ssh-rsa username@123.1.2.3

See https://www.gentoo.org/support/news-items/2021-10-08-openssh-rsa-sha1.html.

Misc

  • Play tron with ssh 
    $ ssh sshtron.zachlatta.com

If this cheat sheet has been useful to you, then please consider leaving a star here.