ssh Guide

Contents:

1. SSH Guide
   1. Short version
   2. Initial setup
   3. Maintenance
   4. Misc
2. Other nice things
   1. ssh x-forwarding
   2. sshfs
3. 2fa ssh
4. SFTP
   1. Further reading

SSH Guide

Following scenario: You have one PC (let's call it host or server) and another mobile PC (called guest), you want to access your PC from your guest via ssh.

Short version

Server (to be accessed)

1. Install ssh-server: sudo apt-get install openssh-server or sudo pacman -S openssh
2. Check ssh-deamon status: systemctl status sshd

Client (accesser)

1. DEBIAN-base Systems only: Install ssh-client sudo apt-get install openssh-client

---

Initial Setup

First you need ssh-server installed on server via:

# For Debian-based systems
sudo apt-get install openssh-server
# For Arch-based systems
sudo pacman -S openssh

Check status of ssh-daemon with:

sudo service sshd status
# should print something with 'Active: active (running)'

# If you use systemd
systemctl status sshd

# Start service via systemd
systemctrl start sshd

On your guest you should have at least installed a ssh-client using:

sudo apt-get install openssh-client

Preparation guest

On guest you can now connet to server via ssh:

ssh user@earthUrl

, where user is a valid username on server and earthUrl is the public url for your earth PC.

While testing this command you need to type your password and you will get a ssh-terminal to the server PC.

If you follow the guide you should exit this ssh session using CTRL+d or typing exit as command.

Passwordless login

In order to not enter your password all the time, ssh has a public key authentification process. All following steps have to be done on the guest system. First you need to generate a public and private key:

ssh-keygen

Your keys are stored in ~/.ssh/, you were ask to enter a password for your key, it is only needed (for security reasons) if you, e.g. are on a shared PC, but on guest (your own personal PC) no password should be ok.

After you created the key-pairs, you need to add your public key to server:

ssh-copy-id user@earthUrl

If everything was succesfully you are now able to ssh without a password to server, just test it:

ssh user@earthUrl

The file ~/.ssh/authorized_keys should appear on the host system (server) which contains one line per key followed by username@computerName.

Maintenance

Removal and management of ssh keys

Authorised Keys - who can access me

In ~/.ssh/authorized_keys you'll find systems having access (one host each line) to your current machine; maintain those lists (this is the part where the public keys are copied via ssh-copy-id are pasted).

Known hosts - to whom I connected

In ~/.ssh/known_hosts you'll find systems you accesses (one host each line). When connecting via ssh to a known host and the identity changed somehow you might need to remove some entries here (or you were hacked via a MITM and should not continue the connection attempt).

Misc

Fix broken pipe error caused by a time-out of the connection

Set on the connecting machine (client) in /etc/ssh/ssh_config:

Host *
ServerAliveInterval 120

OR (!) on the receiving machine (server):

Host *
ClientAliveInterval 120

Number is the time between keep alive packets are sent.

Other nice things

ssh x-forwarding

ssh x-forwarding allows to forward X11 GUI applications via ssh (but it might be slow)

• edit /etc/ssh/sshd_config and uncomment X11Forwarding yes (possibly you have to change no to yes)
• restart the ssh service: systemctl restart sshd.service
• Now try to start your application: ssh -X <user>@<hostnameOrIP> thunar (or a generic session without the application name)
  • To verify your successful X11 connection run on the remote host xauth list and see if any entry appears
  • If you get a "cannot open display" error but running programs like xclock works try: [export XAUTHORITY=$HOME/.Xauthority] (https://unix.stackexchange.com/a/709789/116710)

sshfs

Install via: sudo apt-get install sshfs

You can mount folders (via fullPath) from server as localFolder (must exist) on guest using:

sshfs user@earthUrl:/fullPath localFolder

2fa ssh

Assumes that you have google authenticator installed on a mobile device

1. Installation:
   1. yay -S libpam-google-authenticator
   2. Optional (to display the QR code) sudo apt-get install libqrencode (or qrencode)
2. Edit sudo nano /etc/pam.d/sshd
   • Add here auth required pam_google_authenticator.so at the top (the order influences the order of password and 2nd factor; here 2nd factor will be asked first)
3. Edit /etc/ssh/sshd_confg
   • Set ChallengeResponseAuthentication yes
4. Reload sshd service (systemctl reload sshd.service)
5. Generate a key: google-authenticator and follow the instructions

Optional: Generate a qrcode (or just type in your secret) manually:

1. Install qrencode
2. qrencode -o- -d 300 -s 10 "otpauth://totp/YOUR_IDENTIFICATION?secret=YOUR_SECRET" | display

Additonal Resources

• https://wiki.archlinux.org/index.php/Google_Authenticator
• qrencode command on SO
• https://github.com/google/google-authenticator-libpam

SFTP

1. Install and setup ssh like shown above

2. Check in your /etc/ssh/sshd_config if this line is present: Subsystem sftp /usr/lib/ssh/sftp-server or Subsystem sftp /usr/lib/openssh/sftp-server

3. If your data should lie in the home directory of the sftp user create the jail directory here (otherwise see here; only share and subfolders will have write access!):

    sudo chown root:root /home/<username>                    # It must be owned by root for chroot to work
    sudo chmod 0755 /home/<username>                         # Give root full access
   

4. Create a subfolder (e.g. share) within the previously created folder and change the permissions to in order to provide write access:

    sudo chown root:sftponly /home/<username>/share
    sudo chmod 0755 /home/<username>/share                   # Or 7777 if all other users should be access this folder (this can cause a security risk) - 7777 instead of 0777 since samba users only have read permissions if the sftp user adds something
    # Seet ACL for new files (otherwise other users might not be able to delete/move new files inside this directory)
    setfacl -R -m g::rwx /<directory>                        # See also: https://unix.stackexchange.com/a/331167/116710
   

   1. If you chose that other users are able to access (see comment in code block above) you might want to add a bind mount to access this folder from outside: sudo mount --bind /home/<username>/share/ /path/where/you/bind/mount/it/to/ (the second path will be your destination where other users could access it (e.g. inside a samba share)

   2. Or permanently in /etc/fstab:

       # Bind mount for SFTP jail to be accessible in smb://share directory
       /home/<username>/share/ /path/where/you/bind/mount/it/to/   none  bind              0        0
      

   3. If you have suggestions regarding best practices or the potential security risks you might want to comment to this Stackexchange post

5. Optional (depends if you use Match User or Match Group later on): create a group: sudo groupadd sftponly

6. Add user (within group sftponly (optional) and no shell login; last path is the path to the desired directory for your sftp data): sudo useradd -g sftponly -s /usr/bin/nologin -d /home/<uname> <uname>

7. Set a strong (!) password to prevent potential "account is locked" error: passwd <uname> (we will disable password logins later)

8. Adapt you /etc/ssh/sshd_config config:

    Match Group sftponly
      ChrootDirectory %h
      ForceCommand internal-sftp
      AllowTcpForwarding no
      X11Forwarding no
      PasswordAuthentication no
   

9. Add the public keys of your peers: Follow steps in Fixing path for authorized_keys (the echo part must be done as root; sudo does not work here; see here why; with "'ssh-rsa username@host'" the content of your public key is meant)

10. Restart the sshd.service: systemctrl restart sshd.service

11. Test your login

---

Alternatively to step 5 you could so something like that:

topDir           permissions: drwxr-x--- user1 group2
└── subDir       permissions: drwxrwsr-x user1 group1 subdir
    ├── file1    permissions: -rw-r--r-- user1 group1 files
    └── file2    ...

All members of group1 should be in group2 but not the opposite.

Further reading

• SFTP_chroot
• SFTP identity file command line
• Convert keys for openssh/putty (PuTTY/WinSCP can convert those files automatically into its own format)
• Permission denied error when writing files
• SFTP cmd line with key