*` je nach verwendetem Verfahren. Beispiel RSA: in der Datei `id_rsa` steht der (verschlüsselte) private Key. In der Datei `id_rsa.pub` steht der öffentliche Teil des Schlüssels, der verteilt werden darf/muss.
Der Typ [ed25519](https://en.wikipedia.org/wiki/EdDSA "https://en.wikipedia.org/wiki/EdDSA") ist zum heutigen Stand (05.03.2021) die beste Wahl. Allerdings wird er noch [nicht überall unterstützt](https://ianix.com/pub/ed25519-deployment.html "https://ianix.com/pub/ed25519-deployment.html"). In diesem Fall empfiehlt es sich (zusätzlich) einen RSA-Key mit 4096 bit zu erstellen.
ecdsa sollte nicht verwendet werden, da möglicherweise eine Hintertür für die [US-Regierung](http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html "http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html") eingebaut ist. RSA1 und [DSA](https://stackoverflow.com/questions/2821736/whats-the-difference-between-id-rsa-pub-and-id-dsa-pub/27855045#27855045 "https://stackoverflow.com/questions/2821736/whats-the-difference-between-id-rsa-pub-and-id-dsa-pub/27855045#27855045") sollten auch nicht mehr verwendet werden.
Unter Windows gibts mit `puttygen.exe` ein grafisches Pendant dazu. Hier lassen sich die erzeugten Keys auch ins Unix-Format konvertieren.
## Passphrase des SSH-Keys nachträglich ändern
```
ssh-keygen -p -f ~/.ssh/id_rsa
```
## SSH-Key in den SSH-Agenten laden
Der SSH-Agent muss gestartet sein, bei Fedora Core passiert dies automatisch beim Starten der X-Oberfläche.
Dies lädt defaultmäßig alle id\_\*-Files in ~/.ssh in den Agent. Der Agent dient der Bequemlichkeit, d.h. man lädt einmal seinen Key und von nun an kümmert sich der Agent um alle anfragenden Programme, wie z.B. ssh oder scp. Für Windows gibts im Putty-Paket ein Programm namens `pagent.exe`, welches den gleichen Zweck erfüllt.
[Hier](https://wiki.magenbrot.net/linux/kryptographie/ssh/mit_der_ssh-passphrase_an_kde_oder_gnome_anmelden "linux:kryptographie:ssh:mit_der_ssh-passphrase_an_kde_oder_gnome_anmelden") ist eine Anleitung, wie man seinen ssh-Key für die Anmeldung an KDE/Gnome verwenden und ihn gleich in den Agent laden kann.
## SSH-Pubkey verteilen
Um nun den SSH-Key für die Authentifizierung an anderen Servern verwenden zu können muss er noch dort abgelegt werden. Dazu bringt openssh ein schönes Tool mit:
```
ssh-copy-id [user@]machine
```
```
yum -y install pam_ssh
```
```
cd /etc/pam.d
cp system-auth system-auth-ssh
```
```
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_ssh.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_ssh.so
```
```
#%PAM-1.0
auth include system-auth-ssh
account required pam_nologin.so
account include system-auth-ssh
password include system-auth-ssh
session include system-auth-ssh
session required pam_loginuid.so
session optional pam_selinux.so
session optional pam_console.so
```
```
#%PAM-1.0
auth required pam_env.so
auth include system-auth-ssh
account required pam_nologin.so
account include system-auth-ssh
password include system-auth-ssh
session optional pam_keyinit.so force revoke
session include system-auth-ssh
session required pam_loginuid.so
session optional pam_console.so
```
```
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
1a:d4:e6:4f:1a:4f:61:ef:bc:b8:37:a3:22:d9:70:40.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:898
RSA host key for meinserver has changed and you have requested strict checking.
Host key verification failed.
```
- ```
#!/bin/bash
# 2010 Oliver Voelker
#
# delete the given line number from ~/.ssh/known_hosts
#
if [ ${1} -gt 0 ]; then
echo "Deleting line ${1} from ~/.ssh/known_hosts"
sed -i "${1}d" ~/.ssh/known_hosts
else
echo "Clear from ~/.ssh/known_hosts"
echo "Usage: ${0} "
fi
exit 0
```
```
perl
-ni
-e ‘
print if ($. != 898);’
~/.ssh
/known_hosts
```
```
vi +898d +x ~/.ssh/known_hosts
```
```
# chroot for group 'sftponly' and individual users
Match Group sftponly
ChrootDirectory %h
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
ForceCommand internal-sftp
AllowTcpForwarding no
PermitTunnel no
X11Forwarding no
```
```
useradd -g www-data -G sftponly -m -s /bin/false testuser
(optional:) passwd testuser
(oder per Pubkey:) vi /etc/ssh/authorized_keys/testuser
chown root:root /home/testuser
mkdir /home/testuser/exchange
chown -R testuser /home/testuser/exchange
```
```
ssh -N -D1080 username@remotehost.de
```
##### SSH Tunnel unter Windows (mit Putty)
Putty starten und ganz normal unter Hostname den Server eintragen über den getunnelt werden soll. Dann in den Optionen unter Tunnels unter forwarded Ports z.B. Port 1080 eintragen und den Button „Dynamic“ aktivieren.
[](https://wiki.magenbrot.net/uploads/images/gallery/2021-04/putty-socks.jpg)
##### Anwendungen auf das Socks-Protokoll umstellen
Manche Anwendungen wie z.B. Firefox oder manche Chat-Programme wie ICQ unterstützen das SOCKS-Protokoll von sich aus. Hierzu muss in den Optionen als Socks-Hosts der „localhost“ mit Port 1080 und SOCKS-Version 5 eingetragen werden.
##### Anwendung ohne SOCKS-Unterstützung
Jedoch unterstützen nicht alle Anwendungen das SOCKS-Protokoll. Für dieses Problem gibts jedoch sogenannte Socks-Clients wie z.B. \[[http://www.freecap.ru/eng/\]](http://www.freecap.ru/eng/%5D "http://www.freecap.ru/eng/]")
# SSH-Clientkonfiguration Multiplexing
Hier meine Clientkonfiguration. Das Snippet kann entweder global in /etc/ssh/ssh\_config oder im Home ~/.ssh/config hinterlegt werden. Diese Einstellungen sorgen dafür, dass die Verbindung länger bestehen bleibt (Keepalive) und eine SSH-Verbindung mehrfach benutzt werden kann. Weitere Logins auf dem Zielsystem sind damit deutlich schneller.
```
Host *
ForwardAgent no
ForwardX11 no
ForwardX11Trusted no
StrictHostKeyChecking ask
TCPKeepAlive=yes
ServerAliveInterval=15
ServerAliveCountMax=6
Compression=yes
ControlMaster auto
ControlPath /tmp/%r@%h:%p
ControlPersist yes
```
# SSH-Forwarding über SUDO behalten
Aus Sicherheitsgründen werden beim Wechsel per Sudo auf einen anderen Benutzer die Umgebungsvariablen (Environment) gelöscht. Allerdings kann es nützlich sein, die Variable SSH\_AUTH\_SOCK zu behalten, damit das SSH-Forwarding weiter funktioniert.
Im SSH-Client muss natürlich das Agentforwarding aktiviert sein (global in /etc/ssh/ssh\_config oder in ~/.ssh/config):
```
Host *
ForwardAgent Yes
```
```
Defaults env_reset
Defaults env_keep+=SSH_AUTH_SOCK
```
```
user@server:/$ ssh-add -l
4096 34:5b:42:b6:6f:f7:28:3e:54:e9:76:14:43:a2:04:c5 user@server (RSA)
user@server:~$ sudo su
root@server:/# ssh-add -l
4096 34:5b:42:b6:6f:f7:28:3e:54:e9:76:14:43:a2:04:c5 user@server (RSA)
```
```
user@server:~$ ssh-add -l
4096 34:5b:42:b6:6f:f7:28:3e:54:e9:76:14:43:a2:04:c5 user@server (RSA)
user@server:~$ sudo -i
root@server:~# ssh-add -l
4096 34:5b:42:b6:6f:f7:28:3e:54:e9:76:14:43:a2:04:c5 user@server (RSA)
```
```
# ssh-keygen -i -f ~/.ssh/id_dsa_1024_a.pub > ~/.ssh/id_dsa_1024_a_openssh.pub
```
```
# ssh-keygen -e -f ~/.ssh/id_dsa.pub > ~/.ssh/id_dsa_ssh2.pub
```
# SSH-Tunnel
Durch SSH-Tunnel ist es möglich, Systeme zu erreichen, die z.B. in einem privaten Netz hinter einer Firewall liegen. Ein typisches Szenario sieht z.B. so aus:
**Arbeitsplatz Zuhause 192.168.10.1** → via NAT-Router ins internet –> firewall@work firewall.beispiel.de –> **Arbeitsplatz in privatem Netz 192.168.1.100**
Mit folgendem Befehl kann man den lokalen Port 5900 (für VNC) an die IP 192.168.1.100 Port 5900 auf oder im internen LAN hinter dem Host firewall.beispiel.de leiten. Dadurch wird der Port auf 127.0.0.1:5900 gebunden. Der Parameter -N verhindert das Einloggen auf dem Zielsystem, wenn nur der Tunnel benötigt wird:
```
ssh -N -L 5900:192.168.1.100:5900 root@firewall.beispiel.de
```
```
ssh -N -L :5900:192.168.1.100:5900 root@firewall.beispiel.de
```