Linuxhotel Wiki

Wie ging das nochmal?

Benutzer-Werkzeuge

Webseiten-Werkzeuge


lpi1:ssh

Dies ist eine alte Version des Dokuments!


Todo: anpassen des Unit-Files bei systemd 1)

ssh

Einsatzzwecke von ssh

  • Fernadministration
  • Dateien übers Netz kopieren
  • Tunnel bauen

Vorteile von ssh

  • Sicherheit durch Public-Private Key Verschlüsselung
  • Mehrere Benutzer können einen Account gemeinsam Nutzen
  • Single Sign On möglich

Grundfunktionen

Einloggen auf <Rechner> mit <Benutzer>: 2)

ssh <Benutzer>@<Rechner>

hängende ssh-Verbindung beenden:

~.

ssh-Verbindung pausieren:

~Strg+z

Dateien auf andere Rechner kopieren: 3)

scp <Datei> <Benutzer>@<Rechner>:/<Verzeichnis>

Dateien auf andere Rechner ohne lange Pfadangaben ins $HOME-Verzeichnis von <Benutzer> kopieren:

scp <Datei> <Benutzer>@<Rechner>:<Verzeichnis>

Fingerprint Hostkey überprüfen:

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

Server Keys neu erzeugen

Debian

rm /etc/ssh/ssh_host_*key*
dpkg-reconfigure openssh-server

Public-Private-Key Authentifizierung

Als Nutzer Schlüsselpaar erzeugen:

ssh-keygen -t rsa -b 4096 -C "Kommentar"

Public-Key auf anderen Rechner übertragen:

ssh-copy-id  -i .ssh/id_rsa.pub nutzer05@notebook06

oder alternativ:

cat .ssh/id_rsa.pub | ssh nutzer05@notebook06 "cat >> .ssh/authorized_keys"
ssh nutzer05@notebook06 "chmod 400 .ssh/authorized_keys"

Serverseitig Passwortauthentifizierung abschalten

/etc/ssh/sshd_config:

  UsePAM no
  PasswordAuthentication no

Nutzer Zugriff beschränken

mit authorized_keys command

Problem: die Datei ~/.ssh/authorized_keys gehört dem Nutzer, den man einschränken möchte.

~/.ssh/authorized_keys
command="/bin/cat /var/log/messages",no-agent-forwanding,no-X11-forwarding,no-port-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHBqUtiLsRTLKquoVXKwhrPRD92CzaN9EOkVEfWoHfdC nutzer26@notebook26

mit Match

/etc/ssh/sshd_config
Match User nutzer12
  ForceCommand /usr/local/bin/cat_messages
/usr/local/bin/cat_messages
#!/bin/sh
/bin/cat /var/log/messages

ssh-agent

Schlüssel dem ssh-agent hinzufügen:

ssh-add .ssh/id_dsa

4)

Agent-Forwarding nutzen

ssh -A nutzer17@notebook17
ssh nutzer07@notebook07

SSH über mehrere Hops

+--------+                  +------------+                +------------+
| ssh    |                  | Hop Server |                | server     |
| client |                  | notebook01 |                | notebook02 |
|        | ================ssh========tunnel============> |            |
+--------+                  +------------+                +------------+

Client

centos 7:

~/.ssh/config
Host notebook02
  Hostname notebook02.linuxhotel.de
  ProxyCommand ssh notebook01.linuxhotel.de -W %h:%p

Bei älteren SSH-Versionen muss zusätzlich netcat bzw. nc installiert sein: ~/.ssh/config : ( debian 6.0, centos 6 )

Host notebook02
  Hostname notebook02.linuxhotel.de
  ProxyCommand ssh -q notebook01.linuxhotel.de nc %h %p

Hop Server

optional, damit sich der Benutzer nicht auf dem Hop-Server einloggen kann

/etc/ssh/sshd_config :

Match User nutzer02
  ForceCommand nc notebook02 22

testen

ssh notebook02

Sicherheitseinschränkung bei Agent-Forwarding

Mit eingeschaltetem Agent-Forwarding sollte man nur vertrauenswürdige Server besuchen. root-Benutzer auf dem Server können während die Verbindung besteht den ssh-Agent „mitbenutzen“. Dazu sucht root nach

  • Prozess-Nummern ( -t ),
  • die dem verbundenen Benutzer gehören ( -u ),
  • die eine IP-Verbindung geöffnent haben ( -i ),
  • deren Namen mit der Zeichenkette sshd beginnt ( -c )
PIDS="$(lsof -a -i -c sshd -u nutzer05 -t)"

Weiter sucht er nach dazu passenden Socket-Dateien ( /tmp/ssh-*/agent.$pid ), und speichert die letzte ( tail -n 1 ) in der Variablen SSH_AUTH_SOCK

export SSH_AUTH_SOCK=$(for pid in $PIDS; do ls /tmp/ssh-*/agent.$pid; done 2>/dev/null | tail -n 1)

Auch ein ssh-agent auf dem client-Rechner kann ähnlich mitgenutzt werden:

export SSH_AGENT_PID=$(pgrep -u nutzer05 -x 'ssh-agent')
SSH_AUTH_SOCK=$(lsof -a -U -p $SSH_AGENT_PID -F n | tail -n 1)
export SSH_AUTH_SOCK=${SSH_AUTH_SOCK#n}
ssh nutzer07@notebook07

Fehlersuche

ssh -v nutzer06@notebook06
ssh -vv nutzer06@notebook06

SSH Tunnel

TCP Tunnel

Allgemein:

ssh -L <lokaler Port>:<Zielrechner>:<Zielport> <Benutzer>@<ssh-Server>

Spezialfall X-Weiterleitung:

ssh -X <Benutzer>@<Rechner>

Dazu muß in der Datei /etc/ssh/sshd_config folgender Eintrag vorhanden sein:

X11Forwarding yes

Tunnel Rückwärts:

ssh -R <Port auf ssh-Server>:<Zielrechner>:<Zielport> <Benutzer>@<ssh-Server>

Dazu muß in der Datei /etc/ssh/sshd_config folgender Eintrag vorhanden sein:

GatewayPorts yes

Tunnel nachträglich anlegen:

~C
help
-L <lokaler Port>:<Zielrechner>:<Zielport>

IP Tunnel / VPN

noch nicht getestet

Client

ssh -f -w 0:1 192.168.1.15 true
ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
route add 10.0.99.0/24 10.1.1.2

Server

/etc/ssh/sshd_config :

PermitTunnel yes
ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
route add 10.0.50.0/24 10.1.1.1

Links

1)
als Default werden alle Prozesse einer proc group bei restart oder stop gekillt. Das ist nicht das, was man bei ssh o.ä. will. Unit-File nach /etc/systemd/system kopieren und KillMode=process rein und das Verhalten ist wie früher. Bei vielen Distris ist das Standard-Unit-File mit KillMode=control-group. D.h. man müsste immer und überall bei jeder ssh-Installation diese Änderung machen, wenn man nicht irgendwann ein doofes Problem haben will
2)
Wenn auf dem entfernten Rechner Befehle ausgeführt werden sollen (z.B. Updates einspielen), die nicht unterbrochen werden sollen (z.B. von einem Netzwerkproblem), dann ist screen auf dem entfernten Rechner sehr nützlich
3)
manchmal ist hier auch dateien_kopieren_mit_sudo_tar_und_ssh nützlich, besonders wenn sowohl die Quell-Datei als auch das Ziel auf entfernten Rechnern liegen
4)
Bei openSuSE 11.0 wird der ssh-agent bei der Anmeldung nur gestartet, wenn das Verzeichnis ~/.ssh existiert:
mkdir -m 700 ~/.ssh
lpi1/ssh.1453386097.txt.gz · Zuletzt geändert: 2016/04/28 15:02 (Externe Bearbeitung)