Secure Shell: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
VisuellWikitext
Keine Bearbeitungszusammenfassung
Zeile 86: Zeile 86:
  Wer einen Windows-Desktop benutzt und über das SSH-Protokoll auf eine Linux-Maschine zugreifen will, kann das Programm nutzen.
  Wer einen Windows-Desktop benutzt und über das SSH-Protokoll auf eine Linux-Maschine zugreifen will, kann das Programm nutzen.


= Benutzeroberflächen =
== Benutzeroberflächen ==
Wem es zu mühsam ist, auf der Kommandozeile die SSH-Verbindung zu einem Server aufzubauen, der sucht vielleicht ein grafisches Programm, um Verbindungsdaten zu verwalten.*  - gibt es sowohl für Linux als auch für Windows.  
Wem es zu mühsam ist, auf der Kommandozeile die SSH-Verbindung zu einem Server aufzubauen, der sucht vielleicht ein grafisches Programm, um Verbindungsdaten zu verwalten.*  - gibt es sowohl für Linux als auch für Windows.  
* Das Programm ist in den offiziellen Paketquellen enthalten.
* Das Programm ist in den offiziellen Paketquellen enthalten.

Version vom 11. Juli 2022, 10:03 Uhr

Was ist die Secure Shell?

  • Es gab einmal eine Zeit, als Computer im Netz über das Telnet-Protokoll zugänglich waren.
  • Da dieses Protokoll keine Verschlüsselung bot, wurde das Mitschneiden von Passwörtern zur trivialen Angelegenheit.
  • Um den Fernzugang zu sichern, schrieb Tatu Ylönen Mitte der 1990er eine Programmsuite – bestehend aus Server, Client und Hilfsprogrammen – die er ssh (secure shell) nannte.
  • Später gründete er die Firma ssh.com und bot die Version 2 der SSH-Suite nur noch kommerziell an.
  • Daraufhin wurde von Entwicklern des Betriebssystems OpenBSD der öffentliche Quellcode der Version 1 geforkt.
  • Sie entwickelten das Programm unter dem Namen "OpenSSH" weiter.
  • Diese OpenSSH-Suite wurde fester Bestandteil quasi aller Linux-Distributionen.
  • Drei wichtige Eigenschaften führten zum Erfolg von ssh :* Authentifizierung der Gegenstelle, kein Ansprechen falscher Ziele
    • Verschlüsselung der Datenübertragung, kein Mithören durch Unbefugte
    • Datenintegrität, keine Manipulation der übertragenen Daten
  • Mehr Details zur verwendeten Verschlüsselung finden sich .
  • Falls man sich auf den eigenen Computer hinter einem DSL-Router per SSH einloggen will, muss man zuvor in diesem eine einrichten, sonst kommt keine Verbindung zustande.


Der SSH-Client

ssh user@sol-1 
user@sol-1's password:
Last login: Sun Feb 12 07:38:50 2006 from client.local
Sun Microsystems Inc.   SunOS 5.9       Generic_112234-03       November 2002
bash-2.05$

Und schon befindet man sich auf einem anderen System, in diesem Fall mit dem Betriebssystem Solaris. 

ssh server 
Password:
Linux vdr 2.4.27-ctvdr-1 #1 Fri Oct 15 18:38:29 UTC 2004 i686 GNU/Linux
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Sun Feb 12 07:38:23 2006 from client.local
user@server:~$

Oder auf einem anderen Linux-System.

  • Wie man sieht, ist die Angabe des Benutzernamens optional, wenn er auf beiden Systemen gleich ist.
  • Man kann auch einfach einen Befehl anhängen, der anstelle der Terminal-Session ausgeführt wird.
  • Nach der Ausführung des Befehls wird die SSH-Session dann automatisch beendet:
ssh server cat /etc/issue 
Password:
Debian GNU/Linux 3.1 \n \l

Oder etwas komplizierter - eine Datensicherung machen ("backup"): 

$ ssh root@server 'cd /etc; tar czvf - network/' | cat > etc_network_backup.tar.gz 
Password:
network/
network/interfaces
network/if-post-down.d/
network/if-pre-up.d/
network/if-up.d/
network/if-down.d/
network/options
network/interfaces.pre-etherconf
network/interfaces.1
network/run

Bei einer langsamen Verbindung empfiehlt sich zusätzlich die Benutzung der Option -C (großes C), die zusätzlich zur Verschlüsselung eine transparente Kompression der übertragenen Daten aktiviert.

  • Bei einer schnellen Verbindung wird die Kompression aber vermutlich bremsen.
  • Woher weiß man nun aber, dass man tatsächlich mit dem richtigen Rechner verbunden ist, und nicht ein Angreifer die Verbindung umgeleitet hat? Dafür gibt es den Host-Schlüssel, der jeden SSH-Server eindeutig identifiziert.
  • Greift man zum ersten Mal auf einen bestimmten Server zu, kennt man diesen Schlüssel natürlich noch nicht. (Außer man hat ihn sich auf anderen Wegen im Voraus besorgt.)
ssh server 
The authenticity of host 'server (192.168.1.5)' can't be established.
ECDSA key fingerprint is b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server' (ECDSA) to the list of known hosts.
Password:

Wenn gerade in diesem Moment jemand die Verbindung gekapert hat, hat man natürlich Pech, außer man kann den Administrator des Servers nach dem richtigen Fingerprint des Host-Schlüssels fragen.

  • Den ECDSA-Fingerprint eines Servers kann man mit dem Systemprogramm ssh-keygen erfahren:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l

gibt den Fingerprint und einige weitere Informationen aus, zum Beispiel 256 b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1 root@server (ECDSA).

  • Wenn man auf Nummer sicher gehen möchte, lässt man sich vom Administrator des Servers diese Ausgabe mitgeben (evtl.
  • ausdrucken) und kann dann beim ersten Verbindungsversuch überprüfen, ob man sich tatsächlich zum richtigen SSH-Server verbunden hat und nicht zu einem dazwischengeschalteten Angreifer.

Bei allen weiteren Kontakten stellt das ssh-Programm jedoch von nun an über asymmetrische Kryptografie sicher, dass der Server auch über den richtigen öffentlichen Schlüssel verfügt, der zum öffentlichen, in der Datei ~/.ssh/known_hosts abgelegten passt, und verweigert im Zweifelsfall den Verbindungsaufbau.

Sollte sich dieser Schlüssel einmal aus legitimen Gründen geändert haben, bspw.

  • weil das System neu aufgesetzt wurde, muss man den entsprechenden veralteten Schlüssel erst einmal auf dem Client mit dem Befehl
ssh-keygen -R hostname

aus der known_hosts-Datei entfernen.

Sollte die Verbindung nicht mehr reagieren, zum Beispiel wenn der SSH-Server heruntergefahren wurde, lässt sich der ssh-Client mit der Eingabe von "~." (nacheinander) beenden. 

Hinweis
Wer einen Windows-Desktop benutzt und über das SSH-Protokoll auf eine Linux-Maschine zugreifen will, kann das Programm nutzen.

Benutzeroberflächen

Wem es zu mühsam ist, auf der Kommandozeile die SSH-Verbindung zu einem Server aufzubauen, der sucht vielleicht ein grafisches Programm, um Verbindungsdaten zu verwalten.* - gibt es sowohl für Linux als auch für Windows.

  • Das Programm ist in den offiziellen Paketquellen enthalten.
  • PAC Manager - (Perl Auto Connector) nicht in den offiziellen Paketquellen enthalten, aber über SourceForge wird ein Fremdpaket angeboten, das manuell installiert werden kann.
  • Gnome-RDP - mit diesem Programm kann man nicht nur RDP- und -Verbindungen aufbauen, sondern auch SSH-Terminalsitzungen.
  • Leider kann man in der aktuellen Version die Zugangspasswörter nicht speichern lassen und keine Angaben zum verwendeten Port machen.
  • Es funktioniert somit nur mit Servern, die den Standard-SSH-Port 22 nutzen.
  • In den offiziellen Paketquellen enthalten, benötigt aber Mono als Voraussetzung.

.ssh/config

Wenn man sich auf der Konsole mit einem anderen Server verbinden möchte, muss man evtl.

  • zum Beispiel Port und Benutzernamen angeben.
  • Um das Ganze zu vereinfachen, kann man Voreinstellungen für ssh in der config-Datei $HOME/.ssh/config hinterlegen.
  • Hier ein Beispiel:
# ssh (secure shell) configuration file
Host test1
   HostName 123.456.789.0
   Port 980
   User MeinBenutzerName

Host test2
   HostName test.mynet.local
   User test
   CheckHostIP no
   Cipher blowfish

Host foobar
   HostName domain.tld
   Port 55550
   User fanta
   IdentityFile ~/.ssh/private_ssh_key_rsa

ssh MeinBenutzerName@123.456.789.0 -p980 

ssh test1

für einen Verbindungsaufbau.

  • Alle Parameter, die man verwenden kann, findet man unter openbsd.org oder in der von ssh_config.

OpenSSH client

Configuration

If you have a file containing known_hosts using RSA or ECDSA host key algorithm and the server now supports ed25519 for example, you will get a warning that the host key has changed and will be unable to connect.

  • This means you will have to verify the new host key.

The following configurations expect a recent OpenSSH client, as updating OpenSSH on the client side is generally not an issue.

Modern

This configuration is less compatible and you may not be able to connect to some servers which use insecure, deprecated algorithms.

  • Nevertheless, modern servers will work just fine.

File: ~/.ssh/config 

# Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to.

HashKnownHosts yes 

# Host keys the client accepts - order here is honored by OpenSSH

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Intermediate (connects to older servers)

This configuration can connect to older OpenSSH servers which run old or intermediate configurations.

File: ~/.ssh/config 

# Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to.

HashKnownHosts yes 

# Host keys the client accepts - order here is honored by OpenSSH

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256

Key generation

Large key sizes are used as SSH keys are not renewed very often (see also Security/Key_Management).

Note:
DSA and RSA 1024 bit (or lower) keys are considered weak and should be replaced as soon as possible.

Don't hesitate to create multiple different keys for different usages.

  • In particular, never mix your personal and Mozilla keys.
# RSA keys are favored over ECDSA keys when backward compatibility is required,
# thus, newly generated keys are always either ED25519 or RSA (NOT ECDSA or DSA).

$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz" 

# ED25519 keys are favored over RSA keys when backward compatibility is not required.
# This is only compatible with OpenSSH 6.5+ and fixed-size (256 bytes).

$ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"

You may then want to add the new key to your SSH agent or your configuration file (or both). 

# Add key to ssh-agent

$ ssh-add ~/.ssh/id_..._mozilla... # <= replace by your key's path 

# Add configuration to ~/.ssh/config

host *.mozilla.com IdentityFile ~/.ssh/id_...mozilla... # <= replace by your key's path

Protection of user keys

  • Protected by strong passphrase.
  • Never copied to another system than your own workstation/personal physical disks/tokens.
  • Use SSH forwarding or SSH tunneling if you need to jump between hosts. DO NOT maintain unnecessary agent forwarding when unused.

Protection of machine keys

When SSH keys are necessary for automation between systems, it is reasonable to use passphrase-less keys. * The recommended settings are identical to the user keys.

  • The keys must be accessible only by the admin user (root) and/or the system user requiring access.
  • Usage of machine keys should be registered in an inventory (a wiki page, ldap, an inventory database), to allow for rapid auditing of key usage across an infrastructure.
  • The machine keys should be unique per usage.
  • Each new usage (different service, different script called, etc.) should use a new, different key.
  • Only used when strictly necessary.
  • Restrict privileges of the account (i.e.
  • no root or "sudoer" machine account).
  • Using a ForceCommand returning only the needed results, or only allowing the machine to perform SSH-related tasks such as tunneling is prefered.
  • Disable sftp if not needed as it exposes more surface and different logging mechanisms than SSH (and thus scp) itself.
Note:
You may want to use the group "users" instead of "sftpusers" in the example below as this may already exist and include all regular users by default. 
    # groupadd sftpusers
    # usermod -a -g sftpusers <userthat_needs_ftp>
    # chgrp sftpusers /usr/lib/ssh/sftp-server
    # chmod 0750 /usr/lib/ssh/sftp-server

Multi-factor bypass setup for machine keys

Machine keys do not play well with multi-factor authentication as there is no human interaction. * All logins from machine accounts should be protected by an additional authentication layer (VPN, another machine, etc.).

  • All logins from machine accounts are only allowed within the private IP-space, and if possible, only the relevant machine source IPs should be accessible.

File: /etc/ssh/sshd_config (OpenSSH 6.3+)

Match User machine_user Address 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12 

   PubkeyAuthentication yes
   KbdInteractiveAuthentication no
   AuthenticationMethods publickey

File: /etc/ssh/sshd_config (OpenSSH 5.3+ w/ RedHat/CentOS patch)

Match User machine_user Address 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12 

   RequiredAuthentications2 publickey

Auditing your existing SSH keys

Existing keys are generally stored in ~/.ssh/ (Linux/OSX) or %APPDATA% (Windows).

  • Look for id_{rsa,ed25519,ecdsa,dsa}, identity, IdentityFile, *.pem, and other identity files.

Display SSH keys information

# You may run this for any key file that you have.

$ ssh-keygen -lf id_rsa 2048 bc:4f:46:2b:3d:f1:e2:0f:ac:40:99:49:ed:c9:81:a2 Mozilla key for xyz (RSA) ^^ ^^^^^^^^^ ^^^^ ^^^ |__ Size |__ Fingerprint |__ Comment |__ Type

SSH agent forwarding

ATTENTION
SSH Agent forwarding exposes your authentication to the server you're connecting to.
  • By default, an attacker with control of the server (i.e.
  • root access) can communicate with your agent and use your key to authenticate to other servers without any notification (i.e.
  • impersonate you).For this reason, one must be careful when using SSH agent forwarding.
  • Defaulting to always forwarding the agent is strongly discouraged.Note also that while the attacker can use your key as long as the agent is running and forwarded, he cannot steal/download the key for offline/later use.

SSH forwarding allows you to jump between hosts while keeping your private key on your local computer.

  • This is accomplished by telling SSH to forward the authentication requests back to the ssh-agent of your local computer.
  • SSH forwarding works between as many hosts as needed, each host forwarding new authentication request to the previous host, until the ssh-agent that holds the private key is reached.

"Ssh forwarding.png"

On each host, two environment variables are declared for the user enabling ssh-agent: * $SSH_AUTH_SOCK declares the location of the unix socket that can be used to forward an authentication request back to the previous host.(ex: /tmp/ssh-NjPxtt8779/agent.8779).

  • Only present if using SSH agent forwarding.
  • $SSH_CONNECTION shows the source IP and port of the previous host, as well as the local IP and port. (ex: 10.22.248.74 44727 10.8.75.110 22).

To use ssh-agent, add the flag -A to your ssh commands:

$ ssh -A user@ssh.mozilla.com

You can set the following configuration parameter in your local ssh configuration at ~/.ssh/config.

Host ssh.mozilla.com 

   ForwardAgent yes

Hardening the Agent forwarder

It is possible to require confirmation every time the agent is used (i.e.

  • when you connect to a server through the SSH agent) by using the -c flag:
# First, remove the key from the agent if it's already loaded:

$ ssh-add -d ~/.ssh/id_ed25519 

# And re-add it with the -c flag:

$ ssh-add -c ~/.ssh/id_ed25519

It is also possible to lock the key in the agent after a configurable amount of time, this can be done either for all keys when starting the agent, or per key when adding the keys to the agent with the -t flag: 

# Keep all keys decrypted/useable in memory for 30 minutes (1800 seconds)

$ ssh-agent -t 1800 

# First, remove the key from the agent if it's already loaded:

$ ssh-add -d ~/.ssh/id_ed25519 

# Re-add it, with the -t flag to keep this specific key decrypted/useable in memory for 30 minutes (1800 seconds)

$ ssh-add -t 1800 ~/.ssh/id_ed25519

For MacOSX in particular it's possible to save the passphrase in the Keychain. If you do so it is strongly recommended to also change the keychain setting to lock itself when the computer is locked, and/or to timeout and lock the keychain. These settings are not controlled by OpenSSH. 

# MacOSX only - save the passphrase in the Keychain

$ ssh-add -K ~/.ssh/id_ed25519

Note:
There are also some third-party patches for various OpenSSH clients that will notify you visually when the agent is being used.
These are not officially supported and may require you to recompile OpenSSH.

* OpenSSH Linux

Recommended, safer alternatives to SSH agent forwarding

OpenSSH >=7.3

OpenSSH 7.3 onwards allow users to jump through several hosts in a rather automated fashion. It has full support for scp and sftp commands as well as regular ssh.

For example to reach a host behind a bastion/jumphost: 

# Single jump
$ ssh -J ssh.mozilla.com myhost.private.scl3.mozilla.com

# Jump through 2 hops
$ ssh -J ssh.mozilla.com,ec2-instance.aws.net 10.0.0.3

# Copy data from a host
$ scp -oProxyJump=ssh.mozilla.com myhost.private.scl3.mozilla.com:/home/kang/testfile ./

You can also add these lines to your ~/.ssh/config 

Host *.mozilla.com !ssh.mozilla.com
ProxyJump ssh.mozilla.com

Older versions of OpenSSH

It is possible to directly forward ports for single jumps instead of forwarding the agent. This has the advantage of never exposing your agent to the servers you're connecting to.

For example, you can add these lines to your ~/.ssh/config 

Host *.mozilla.com !ssh.mozilla.com
ProxyCommand ssh ssh.mozilla.com -W %h:%p

This will automatically forward the SSH connection over ssh.mozilla.com when you connect to a mozilla.com SSH server.

Abgerufen von „https://wiki.foxtom.de/index.php?title=Secure_Shell&oldid=40536“