Wenn die Verbindung abgebrochen ist und die SSH-Sitzung nicht von selber abgebrochen ist, kann man die SSH-Session mit ~. beenden.

OpenSSH verwendet für die SSH-Keys das openssh-Format (alles in einer Zeile), Putty das ssh2-Format (mehrere Zeilen). Putty-Keys kann mit puttygen in das openssh-kompatible Format exportieren, aber bis man dem User erklärt hat wie das funktioniert, kann man häufig schneller selber umwandeln:

ssh-keygen -i -f user-putty-key.pub > user-openssh-key.pub

for h in server1 server2 server3; do echo -n "$h: " ; ssh -o BatchMode=yes $h hostname ; done
server1: server1
server2: Permission denied (publickey,keyboard-interactive).
server3: server3

Dieser alte Cisco-Switch ist nicht mehr kompatibel zu den modernen (sicherern) default-Einstellungen von SSH. Zum Glück kann man sich noch "freikaufen" …

Host ganzalterciscoswitch
   user myuser
   hostname ganzalterciscoswitch.example.com
   # Unable to negotiate with 192.168.1.1 port 22: no matching cipher found.
   # Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
   Ciphers +aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
   # no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
   KexAlgorithms +diffie-hellman-group1-sha1 

Wenn man den Zielserver nicht direkt erreichen kann, sondern sich erst mal über einen Bastion-Host/SSH-Proxy einloggen muss:

ssh -J bnutzer@bastion.example.com:22 s2benutzer@192.168.5.11

bnutzer: der Login-User auf dem Bastion-Host

s1benutzer: der Login-User auf meinem Zielserver

192.168.5.11: mein Zielserver (vom Bastion-Host aus gesehen, darf natürlich auch ein Name sein, sofern der Bastion-Host sowas auflöst)

und wenn man das häufiger machen muss, trägt man sich folgendes in die $HOME/.ssh/config ein:

Host internal-server1.example.com server1
        hostname 192.168.5.11
        User s1bnutzer
        ProxyJump bnutzer@bastion.example.com:22

dann reicht ein ssh server1 um zum Zielsystem zu kommen

für Spezialfälle (oder ältere SSH-Versionen) kann man auf dem SSH-Proxy-Server auch einen extra Befehl aufrufen, z.B. netcat …

Host internal-server2.example.com server2
        User s2bnutzer
        ProxyCommand ssh bnutzer@bastion.example.com 'nc 192.168.5.12 22'

Beispiel: auf dem XYWebserver läuft ein Dienst, den man erstmal testen möchte und der deshalb nur auf localhost Port 8080 lauscht. Wenn man sich das nicht nur mit lynx ansehen will und keine Accessdinge mit dem Server anstellen will oder darf, kann man sich auch mit einem SSH-Tunnel behelfen …

$HOME/.ssh/config:

host xywebserver
        localforward 8888 localhost:8080

bei ssh -v xywebserver gibt es im Output eine sehr klare Meldung, was da passiert:

...
debug1: Local connections to LOCALHOST:8888 forwarded to remote address localhost:8080
...

damit kann man dann unter http://localhost:8888 mit dem Webbrowser auf dem eigenen Rechner ansehen, was der Server eigentlich nur für sich selber unter Port 8080 auspuckt.

(natürlich auch möglich: localforward 8080 localhost:8080, habe hier nur zur Veranschaulichung absichtlich einen anderen Port verwendet)

für einmalige Aktionen geht das natürlich auch mit ein paar Optionen auf der Kommandozeile:

ssh -v -L 8888:localhost:8080 loginuser@xywebserver

unter Windows kann man plink verwenden (ist bei Putty dabei):

Prinzip:

plink.exe -ssh -l loginuser -pw password -L localhost_listener:remote-host:remote-port ssh-server

manchmal erreicht man das Ziel nicht direkt …

# .ssh/config
host tun0
        hostname bekannterserver
        user hella
        localforward 22220 gateway.athome.example.com:22

host home hometun tun1
        hostname localhost
        port 22220
        user hella
        localforward 22221 192.168.0.5:22
        UserKnownHostsFile /home/heb/.ssh/known_hosts_tun1

host tun2 homeserver
        hostname localhost
        port 22221
        user hella
        UserKnownHostsFile /home/heb/.ssh/known_hosts_tun2

um verbindung zum homeserver aufzunehmen, braucht man 3 Shells, 3 XTerms, Screen-Sessions oder Konsolenfenster:

Shell 1:

ssh tun0

Shell 2:

ssh tun1

Shell 3:

ssh tun2

Wenn man beim Start der bash sicherstellen möchte, dass da auf jeden Fall eine bash-Shell mit ssh-agent und geladenem key läuft …

Dies ist eine Notlösung, wenn z.B. in einer Windows-Umgebung im Terminalserver¹⁾ leider der putty nur ohne pageant ²⁾ läuft. Sobald man die eingesperrte aber dann doch heimelige Linux-Umgebung betritt, gibt es dann auch wieder einen richtigen ssh-agent fürs Wohlbefinden und die Usability … und SSH-Verbindungen wie gewohnt sind ohne Hindernisse möglich (wenn auf allen Zielmaschinen die ssh-keys ausgerollt sind).

Hinweise:

• wenn der SSH-Key mit Passwort geschützt ist, wird natürlich nach diesem Passwort gefragt
• wenn irgendwie möglich, ist ein zentraler SSH-Agent auf dem Desktop vermutlich immer besser
• noch schönere ein-eindeutige und zufällige SSH-Agent-Socket-Namen bekommt man mit SOCKET=$( mktemp -u sshagent_XXXXXXXXXXX -p $AUTHDIR );

# am Ende der $HOME/.bashrc 
SSHKEY=$HOME/.ssh/id_rsa
 
# nur wenn die Shell interaktiv ist (also *nicht* bei scp, sftp, rsync, "nur ein Kommando per ssh abgesetzt")
if tty -s ; then
  # nur wenn es den SSHKEY auch gibt
  if [ -r $SSHKEY ]; then
    # nur wenn kein SSH_AGENT erreichbar ist
    if [[ ! $SSH_AUTH_SOCK ]]; then
      # ein garantiert nur von mir (und root) lesbares Verzeichnis
      # fuer den ssh-agent-socket
      AUTHDIR=$HOME/tmp/.ssh_auth_$UID
      mkdir -p $AUTHDIR
      chmod 700 $AUTHDIR
      SOCKET=$AUTHDIR/sshagentsocket.$$
      #SOCKET=$( mktemp -u sshagent_XXXXXXXXXXX -p $AUTHDIR  );
      ssh-agent -a $SOCKET
      export SSH_AUTH_SOCK=$AUTHDIR/sshagentsocket.$$
      ssh-add $SSHKEY
    fi
  fi
fi

• siehe auch:
  • TAR
  • kubectl via SSH Tunnel
• https://www.exoscale.com/syslog/advanced-ssh-6-things/
• Johannes Franken: OpenSSH Grundlagen, OpenSSH Tunnel