Ssh

AUTHOR | HACKBUGZ

StackExchange | HACKBUGZ
TIKTOK | HACKBUGZ

Links

sshfs(1) - Linux man page
wiki.ubuntuusers.de FUSE/SSHFS
wiki.ubuntuusers.de FUSE  

SSH Key Management
Authorized_keys file in SSH
How to restrict a user to one folder and not allow them to move out his folder - Unix & Linux Stack Exchange
Restrict SSH User Access to Certain Directory Using Chrooted Jail
Debian/Ubuntu Linux: Restrict an SSH user session to a specific directory by setting chrooted jail - nixCraft
SSHFS - ArchWiki

security - How to create a restricted SSH user for port forwarding? - Ask Ubuntu
Aus dem Alltag eines Sysadmin: Reverse-SSH-Tunnel und Autossh
What Is Reverse SSH Tunneling? (and How to Use It)
ssh tunneling - SSH: tunnel without shell on ssh server - Unix & Linux Stack Exchange
linux - ssh tunneling only access - Server Fault
How to Setup Reverse SSH Tunnel on Raspberry Pi behind a 3G USB stick modem - IT-REACT
Create a reverse SSH tunnel for remote access to a restricted Linux machine - DEV Community
https://unix.stackexchange.com/questions/55106/disable-user-shell-for-security-reasons
SSH tunnelling for fun and profit: Autossh
ssh-keygen(1) - Linux manual page
linux - ssh_exchange_identification: Connection closed by remote host (not using hosts.deny) - Unix & Linux Stack Exchange

Miklos Szeredi | github
Evolution of FUSE and OverlayFS | Miklos Szeredi

explainshell
Screen
nohup
linuxcommand ssh1
open ip

SSHFS und FUSE sind zwei verschiedene Dinge, die jedoch eng miteinander verwandt sind.

FUSE (Filesystem in Userspace) ist ein Framework für das Betriebssystem Linux, das es ermöglicht, Dateisysteme in Benutzermodus-Programmen zu implementieren, anstatt diese im Kernelmodus implementieren zu müssen. Durch die Verwendung von FUSE können Benutzermodus-Programme wie SSHFS auf einfache Weise ein Dateisystem erstellen, das wie ein herkömmliches Dateisystem gemountet werden kann.

SSHFS (SSH Filesystem) ist eine Erweiterung des FUSE-Frameworks, mit der man ein Dateisystem über SSH mounten kann. Das bedeutet, dass man über eine sichere Verbindung (SSH) auf Dateien und Verzeichnisse auf einem entfernten System zugreifen kann, als wären sie auf dem eigenen Computer vorhanden.

Zusammenfassend kann man sagen, dass FUSE ein Framework ist, das es ermöglicht, Dateisysteme in Benutzermodus-Programmen zu implementieren, während SSHFS eine Anwendung ist, die FUSE verwendet, um ein Dateisystem über SSH zu mounten.

SFTP und SSHFS sind ähnliche Technologien, die beide eine sichere Möglichkeit bieten, auf entfernte Dateien und Verzeichnisse zuzugreifen. Beide basieren auf dem SSH-Protokoll, das eine sichere Verschlüsselung der Datenübertragung ermöglicht. Der Hauptunterschied zwischen SFTP und SSHFS liegt jedoch in der Art und Weise, wie sie die Remote-Dateisysteme bereitstellen.

SFTP (Secure File Transfer Protocol) ist ein Dateiübertragungsprotokoll, das auf dem SSH-Protokoll basiert und es ermöglicht, Dateien zwischen lokalen und entfernten Systemen zu übertragen. SFTP bietet jedoch keine Möglichkeit, ein entferntes Dateisystem zu mounten. Stattdessen bietet SFTP einen Dateizugriff über eine sichere Verbindung, ähnlich wie beim FTP-Protokoll.

SSHFS (SSH Filesystem) hingegen ist ein FUSE (Filesystem in Userspace)-basiertes Dateisystem, das es ermöglicht, ein entferntes Dateisystem als lokales Dateisystem zu mounten. SSHFS verwendet das SSH-Protokoll, um eine sichere Verbindung zu einem entfernten System herzustellen und ein entferntes Dateisystem als lokales Dateisystem zu mounten. Dadurch können Sie auf entfernte Dateien und Verzeichnisse zugreifen, als wären sie auf Ihrem lokalen Computer vorhanden.

Wenn es darum geht, auf entfernte Dateien und Verzeichnisse zuzugreifen, ist SSHFS in der Regel die bessere Option, da es die Möglichkeit bietet, ein entferntes Dateisystem als lokales Dateisystem zu mounten, was die Arbeit mit entfernten Dateien und Verzeichnissen erleichtert. SFTP ist jedoch eine gute Option, wenn Sie nur Dateien übertragen müssen, ohne das gesamte Dateisystem mounten zu müssen.

SSH|SCP|SFTP FUSE, SSHFS

Mit dem SSH-Clients SSHSSH|SCP|SFTP kann man sich über ein Terminal auf entfernte Rechner anmelden.
Die Kommunikation und die Authentifizierung findet dabei verschlüsselt statt.
SSH kann dabei interaktiv oder nicht interaktiv genutzt werden

RANKING DER REMOTE CLIENTS|TOOLS NACH SICHERHEIT

# SSH
# SCP
# SFTP
# RLOGIN
# TELNET
# FTP

SSH STATUS

$ systemctl status ssh 

$ whoami
$ who
$ w

$ ps
$ ps aux
$ ps aux | grep ssh 
$ ps aux | grep sshd 

$ lsof -i -n | egrep 'ssh' 
$ lsof -i -n | egrep 'sshd' 

$ ss 
$ ss -l
$ ss | grep tcp
$ ss | grep -i ssh
$ ss -u -a

$ last -a | grep -i still

apk*error
$ service ssh status 
$ netstat -tanup | grep ssh 
$ netstat -tnpa | grep 'ESTABLISHED.*sshd
$ netstat -an | grep 8090/port
$ firewall-cmd --list-all-zones 

SSH tools

ssh-keygen
$ ssh-keyscan ip > known_hosts
$ ssh-keyscan -f txtwithhosts

ssh-keyscan

ssh-copy-id

ssh-add
$ ssh-add -l 
$ ssh-add KEY 

ssh-agent
$ pgrep ssh-agent 
$ ps aux | grep ssh-agent

SSH|SSHFS|FUSE CONFIG FILES

$ cat /etc/ssh/sshd_config
$ cat /etc/ssh/ssh_config
$ /etc/fuse.conf
$ /etc/modules

IN LAB
AllowHosts
AllowUsers
AllowGroups
ChRootGroups(Syntax: AllowGroups)
ChRootUsers(Syntax: AllowUsers)

Create SSH Key

$ ssh-keygen -t ed25519 -b 4096

Copy SSH Key

$ ssh-copy-id  -i KEY user@IP
$ ssh-copy-id  -i ~/.ssh/KEY user@IP

copy key while login with key
$ ssh-copy-id -i KEYTOCOPY -f -o 'IdentityFile KEYTOLOGIN' -p 5000 USER@IP

Login with SSH Key

$ ssh -i ~/.ssh/KEY user@IP -p 5001

Login SSH Password automation

install sshpass 
#!/bin/bash 
read -s -p "Enter your password: " password 
echo 
sshpass -p "$password" ssh username@remote_server

ssh config files & folders

/etc/ssh/ssh_config
/etc/ssh/sshd_config
~/.ssh
~/.ssh/authorized_keys 
~/.ssh/known_hosts

ssh sshd_config file

$ nano /etc/ssh/sshd_config
 Port 5000
 PubkeyAuthentication yes
 PasswordAuthentication no
 PermitEmptyPasswords no
 X11Forwarding no
 Banner /path/ (Message before login)
 ListenAddress (Strict/Diff Networks)
 MaxSessions 
MaxSessions parameter

ssh motd file

$ nano /etc/motd (Message after Login)

ssh known_hosts file

$ nano ~/.ssh/known_hosts 

ssh authorized_keys file

$ nano ~/.ssh/authorized_keys 

How to manually copy SSH public keys to server:
On the local machine
$ cat ~/.ssh/id_rsa.pub
copy
ssh-rsa .STRING. USER@IP

On the remote server paste the line to:
~/.ssh/authorized_keys

SSHFS FUSE

$ sshfs user@host:/dir /dir -o IdentityFile=~/.ssh/KEY

$ sshfs user@host:/dir /dir -o IdentityFile=~/.ssh/KEY -o idmap=user -o uid=$(id -u) -o gid=$(id -g)

$ sshfs user@host:/dir /dir -C -p 5001

SSHFS FUSE | USER MAPPING

$ sshfs Benutzername@irgendEinRechner:/pfad_auf_dem_server/ ~/fusessh -o idmap=user -o uid=$(id -u) -o gid=$(id -g) 
$ sshfs user@host:/dir /dir -o IdentityFile=~/.ssh/KEY -o idmap=user -o uid=$(id -u) -o gid=$(id -g) -o nonempty -p 5001 

SSHFS FUSE | SYMLINKS

$ sshfs -o follow_symlinks

$ sshfs Benutzername@irgendEinRechner:/pfad_auf_dem_server/ ~/fusessh -o follow_symlinks 

SSHFS FUSE | FUSERMOUNT

$ fusermount -u /dir 

SSHFS FUSE | Denied root access to user mounted FUSE file system

This is by design in fuse as a security measure. 
Pass the -o allow_root or -o allow_other option when mounting the filesystem with sshfs.
https://serverfault.com

SSHFS TIMEOUT

1) In der Datei .ssh/config folgende Zeile hinzufügen (liegt im Homeverzeichnis des Anwenders, bzw. wenn man Automount beim Systemstart macht, ist die Datei /root/.ssh/config zu ändern):

 $ sshfs -o ServerAliveInterval=15
 $ sshfs-o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3  
 SSHFS mount that survives disconnect| keep connection alive
The options ServerAliveInterval=5,ServerAliveCountMax=3 say that ssh checks every 5 seconds to see whether the remote server is still responding. 
If it does not receive a response after 3 of these checks, then it disconnects automatically. 
Thus any process waiting on this mount should hang about 15 seconds max.
The options ConnectTimeout=3,ConnectionAttempts=1 are necessary because otherwise ssh will wait a very long time when attempting to reestablish connections, 
which again causes other processes to hang if they try to access the mount during this time.

SSHFS SYSTEMSTART | /etc/fstab

$ sshfs#Benutzername@irgendEinRechner:/pfad_auf_dem_server/ ~/fusessh fuse uid=1003,gid=100,umask=0,allow_other,_netdev 0 0

$ sshfs#user@server:/remote/folder /local/mount/dir fuse IdentityFile=sshkeyfile,Port=XXX,allow_other,_netdev,ServerAliveInterval=45,ServerAliveCountMax=2,reconnect,noatime,auto 0 0 

$ sshfs#user@server:/remote/folder /local/mount/dir fuse IdentityFile=sshkeyfile,Port=XXX,uid=1000,gid=1000,allow_other,_netdev,ServerAliveInterval=45,ServerAliveCountMax=2,reconnect,noatime,auto 0 0 

$ sshfs#user@server:/remote/folder /local/mount/dir fuse delay_connect,IdentityFile=sshkeyfile,Port=XXX,uid=1000,gid=1000,allow_other,_netdev,ServerAliveInterval=45,ServerAliveCountMax=2,reconnect,noatime,auto 0 0 

SSHFS SHOW MOUNTS/CHECK MOUNTED | /etc/mtab

$ mount
$ cat /proc/mounts
$ cat /etc/mtab
$ cat /etc/mtab | grep fuse
$ cat /etc/mtab | grep ssh
$ findmnt
$ findmnt | grep fuse
$ findmnt | grep ssh
$ df -h
$ lsblk -f

SSH Port-Tunneling

Local Forwarding

$ ssh -i ~/.ssh/KEY -L 80:IP:80 user@IP -p 2000 

Reverse SSH Tunnel

Check for:
1. ServerAliveInterval(sshd_config)
2. autossh

ssh -R 5001:localhost:22 -fN IP

AutoSSH SSH Tunnel

$ autossh -NT -o "ExitOnForwardFailure=yes" -R 5001:localhost:6001 -l USER IP -p 7001 -i /home/USER/.ssh/KEY

$ autossh -N -f -i /home/<user>/.ssh/id_rsa -R 22222:localhost:22 <user>@<remote_host>
-N: tell ssh to not execute any command, since we only use it for tunneling.
-f: tell autossh to fall into background on start.
-i: tell ssh to use the proper identity.
-R 22222:localhost:22: 
reverse tunnel remote host's 22222 port to localhost's 22 port. 
So that we can use ssh -p 22222 localhost on remote host to ssh into local machine.

nano /etc/systemd/system/sshtunnel.service 

sshtunnel.service

[Unit]
Description=AutoSSH tunnel service
#After=network.target
After=network-online.target ssh.service
[Service]
User=USER
Environment="AUTOSSH_GATETIME=0"
RestartSec=30
Restart=always
ExecStart=/usr/bin/autossh -NT -o "ExitOnForwardFailure=yes" -R 5001:localhost:6000 -l USER IP -p 6001 -i /home/USER/.ssh/KEY
ExecStop=pkill -s KILL autossh
TimeoutStopSec=10
[Install]
WantedBy=multi-user.target

systemctl status sshtunnel.service
systemctl daemon-reload
systemctl restart sshtunnel.service

When using ssh multiplexing, killing the ssh process is often undesirable 
(it kills all open connections with that host), 
and you cannot easily access the escape because "escape not available to multiplexed sessions". 
The right way is then to run the analogue of the forwarding command that you want to cancel, 
but adding -O cancel. For instance:

ssh -O cancel -L 5002:192.168.0.10:5002 192.168.178.100

This will disable this port forwarding without terminating the session. Again, this will only   
work if ssh multiplexing is in use for the connection to 192.168.178.100

$ ssh -luser 192.xx.xxx.xx

ssh commands

$ ssh user@192.168.188.2 '[command]'
$ ssh user@192.168.188.2 'ls -la /home/user'
$ put

ssh execute command

$ ssh user@ip 'ls -la'

ssh execute script

$ ssh user@ip < script.sh
$ ssh user@ip "bash -s" < script.sh

secure file transfer

SCP file

$ pscp

# scp [source][destination]
# destination ip:/path/

$ scp /test user@192.168.188.2:/home/user/test
$ scp *.txt user@192.168.188.2:/home/user/txt

$ scp user@192.168.188.2:/home/user/txt.txt .

How to copy files from one machine to another using ssh

SCP folder

$ scp -r /dir user@192.168.188.2:/home/user/dir 
$ scp -r /dir/* user@192.168.188.2:/home/user/dir 
$ scp -r user@192.168.188.2:/home/user/dir /home/dir
$ scp -r user@192.168.188.2:/home/user/dir .

ssh Jumphost

1. ssh jumphost

PC->Junphost->IntServer
PC->Firewall->IntServer
ssh -J user@ip user@ip

ssh Multi-hop Tunnel

ssh -L8080:localhost:8080 user@host1
SSH Tunnel with -t and -v (verbose)

ssh X11 Forwarding

$ ssh -X user@ip
firefox & 

ssh config file

1. ssh config file in .ssh/config

Host *

       User user

Host linuxhost

       HostName 192.168.188.2
       User user
       Port 2000
       IdentityFile ~/.ssh/mykey

ssh config file in /etc/ssh/ssh_config

debug modus
$ ssh debianvm -v

ssh VNC|DISPLAY

ssh user @<ipadresse> "DISPLAY =:0 nohup firefox"
ssh -i KEY -p XXXX user@x.x.x.x "DIS1PLAY =:0 nohup firefox"
ssh -i KEY -p XXXX -X user@x.x.x.x
ssh -i KEY -L 5901:127.0.0.1:5901 -C -N -l -p XXXX user@x.x.x.x
ssh -i KEY -p XXXX -L 5901:127.0.0.1:5901 -C -N -l user x.x.x.x

socks proxy with google-authenticator!?

# in SSHD FILE
$ AuthenticationMethods publickey,keyboard-interactive
$ nano /etc/pam.d/sshd 	

# google auth
$auth required pam_google_authenticator.so 
$auth required pam_google_authenticator.so nullok

ssh socks reverse

Das ClientAlive-Mechanismus in SSH dient dazu, festzustellen, ob der Client noch verbunden ist, auch wenn keine Aktivität (Datenübertragung) stattfindet. Es unterscheidet sich von der Shell-Variable TMOUT, die Nutzer nach einer bestimmten Inaktivität abmeldet.

   ClientAliveInterval und ClientAliveCountMax: Konfigurieren, wie oft der Server überprüft, ob der Client noch da ist.
   TCP Keepalive: Allgemeiner Mechanismus, um zu erkennen, ob Verbindungen tot sind und sie am Leben zu halten, besonders bei NAT-Routern.
   Inaktivität in der Shell (z.B. keine Eingaben) beeinflusst nicht die automatische Antwort des Clients auf Alive-Nachrichten.
   2023: Neue Optionen ChannelTimeout und UnusedConnectionTimeout in sshd_config eingeführt, um ungenutzte Verbindungen zu beenden.

Tabelle Option Beschreibung ClientAliveInterval Intervall, in dem der Server Alive-Nachrichten sendet. ClientAliveCountMax Anzahl der fehlenden Antworten, bevor die Verbindung als tot betrachtet wird. ServerAliveInterval Intervall, in dem der Client Alive-Nachrichten sendet. ServerAliveCountMax Anzahl der fehlenden Antworten, bevor der Client die Verbindung trennt. TCP Keepalive Verhindert, dass Router NAT-Verbindungen als inaktiv betrachten. TMOUT Shell-Variable, die inaktive Nutzer abmeldet. ChannelTimeout (ab 2023) Timeout für inaktive SSH-Kanäle. UnusedConnectionTimeout Timeout für ungenutzte SSH-Verbindungen.

ClientAliveInterval und ClientAliveCountMax

   Zweck: Dient dazu, festzustellen, ob der Client noch aktiv ist. Der Server sendet Alive-Nachrichten, und wenn der Client nicht antwortet, wird die Verbindung getrennt.
   Vorteil: Nützlich, um Verbindungsprobleme festzustellen, z.B. bei einem plötzlich abgestürzten Client oder einer unterbrochenen Netzwerkverbindung.
   Anwendung: Gut, wenn du sicherstellen willst, dass Verbindungen aktiv bleiben und nicht durch Netzwerkprobleme oder Client-Abstürze blockiert werden.

ChannelTimeout und UnusedConnectionTimeout (ab 2023)

   Zweck: Diese Optionen zielen darauf ab, ungenutzte oder inaktive SSH-Kanäle bzw. Verbindungen zu beenden. Sie berücksichtigen, ob tatsächlich Aktivitäten über die Kanäle stattfinden.
   Vorteil: Effizienter, um Verbindungen zu schließen, die zwar noch offen sind, aber keine Daten mehr übertragen. Diese Optionen sind gezielter auf Inaktivität in Bezug auf tatsächliche Nutzung.
   Anwendung: Nützlich, wenn du Verbindungen beenden willst, die einfach offen bleiben, aber nicht aktiv genutzt werden, z.B. bei Portweiterleitungen, die nicht mehr verwendet werden.

Alles zusammen verwenden?

   Sinnvoll?: Ja, wenn du sowohl sicherstellen möchtest, dass Verbindungen aktiv sind (ClientAliveInterval/CountMax), als auch inaktive Kanäle oder Verbindungen schließt (ChannelTimeout/UnusedConnectionTimeout).
   Anwendung: Wenn du eine robustere Kontrolle über die SSH-Verbindung wünschst, kannst du beide Mechanismen kombinieren, um einerseits abgebrochene Verbindungen zu erkennen und andererseits ungenutzte Verbindungen zu schließen.

Fazit:

   Nur ClientAliveInterval/CountMax: Wenn du nur sicherstellen willst, dass abgebrochene Verbindungen erkannt werden.
   Nur ChannelTimeout/UnusedConnectionTimeout: Wenn du hauptsächlich ungenutzte Verbindungen automatisch beenden willst.
   Beide zusammen: Optimale Kontrolle über die Verbindungsstabilität und das automatische Schließen inaktiver Verbindungen.

s geht um die Konfiguration von SSH-Verbindungen, insbesondere um das ClientAlive-Mechanismus, der dafür sorgt, dass SSH-Verbindungen nicht unbegrenzt offen bleiben, wenn sie nicht aktiv sind. Zusätzlich wird erklärt, wie man TCPKeepAlive und systemweite TCP-Einstellungen anpasst. Wenn keine Anpassung möglich ist, wird empfohlen, den SSH-Prozess manuell zu beenden.

   ClientAliveInterval und ClientAliveCountMax: Server sendet Alive-Nachrichten, um festzustellen, ob der Client noch reagiert.
   TCPKeepAlive: Systemweite TCP-Einstellung, die Verbindungen auf lebendig prüft.
   Manuelles Beenden: Auf dem Client SSH beenden, um Portweiterleitungen zu unterbrechen.
   Script: Ein Beispielskript zum Beenden der SSH-Verbindung und Einrichten eines neuen Tunnels.

Tabelle Option Beschreibung ClientAliveInterval Intervall, in dem der Server Alive-Nachrichten sendet (Standard: 0 = deaktiviert). ClientAliveCountMax Anzahl der ausstehenden Nachrichten, bevor die Verbindung getrennt wird. TCPKeepAlive Allgemeine TCP-Einstellung, um zu überprüfen, ob eine Verbindung noch aktiv ist. ServerAliveInterval Ähnlich wie ClientAlive, aber für den Client, um Verbindungsabbrüche zu erkennen. SSH-Skript Skript, um SSH-Tunnel manuell zu beenden und neu zu starten.