SSH, der Weg zum Ziel

SSH über ein oder mehrere Hops

Um die SSH-Verbindung von Host_A zu Host_B machen zu können muß man sich über zwei Rechner dorthin tunneln (GW_1 und GW_2). Wenn man sich immer erst einloggt und dann weiter einloggt ist es manchmal sehr schwierig die Portforwardings mitzuschleifen, oder den Socks5-Proxy. Einfacher ist es, wenn man sich ProxyCommands für den Weg von Host_a zu Host_b definiert. Wir kommen also nur von GW_2 zu Host_b, also machen wir uns hierfür einen Eintrag in der ~/.ssh/config:

Host Host_B
   ProxyJump GW_2

Zu GW_2 kommen wir aber nur über GW_1, also brauchen wir hierfür auch einen Eintrag:

Host GW_2
   ProxyJump GW_1

Jetzt gibt man auf Host_A einfach ssh Host_B ein und wird über die beiden Gateways GW_1 und GW_2 getunnelt.

Portforwardings für z.B. NFS macht man jetzt einfach so

root@Host_A# share -F nfs -o ro=@127.0.0.1/32 /tmp
root@Host_A# ssh -R 22049:localhost:2049 user@Host_B
user@Host_B$ su -
root@Host_B# mount -oro nfs://127.0.0.1:22049/tmp /mnt

Im Hintergrund werden dann die TunnelVerbindungen aufgebaut und man macht das PortForwarding direkt von Host_A nach Host_B. Sehr schlank und elegant.

PS: Das /dev/tcp/%h/%p ist ein BASH-Builtin wobei %h und %p von der SSH durch Host (%h) und Port (%p) ausgefüllt werden

Ausbruch aus dem Paradies

Problem: Die Umgebung in der man sich aufhält ist leider so unglücklich mit Firewalls verbaut, daß man nicht arbeiten kann. Man muß aber per SSH raus, um woanders kurz etwas zu schauen, oder zu holen. Nunja, es gibt immer einen Weg...

Vorraussetzung ist ein lokal installiertes connect, z.B. unter Ubuntu: apt-get install connect-proxy. Weiterhin braucht man einen SSH-Server, wo ein sshd auf dem Port 443 lauscht, denn die meisten Proxies wollen einen nur auf known Ports durchlassen.

Dann trägt man in der ~/.ssh/config ein:

Host ssh-via-proxy
  ProxyCommand connect -H proxy-server:3128 ssh-server 443

Schwuppdiwupp ist man mit ssh ssh-server auf dem SSH-Ziel, wo man hinmöchte. Natürlich kann man auf den ssh-server wieder als ProxyCommand eintragen usw. usw.

Achja... das interne Wiki...

Auch nicht schlimm, wenn das nur vom internen Netz erreichbar ist, dann fragen wir einfach via Socks-Proxy an:

user@Host_A$ ssh -C -N -T -f -D8080 interner-rechner
user@Host_A$ chromium-browser --proxy-server="socks5://localhost:8080" https://wiki.intern.firma.de/ &

Die Optionen sind:

-C      Requests compression <- das ist optional
-N      Do not execute a remote command.
-T      Disable pseudo-tty allocation.
-f      Requests ssh to go to background just before command execution.
-D      Local-Remote-Socks5-Proxy Port

Oder wieder via ~/.ssh/config:

Host wiki
  Compression        yes
  DynamicForward     8888
  RequestTTY         no
  PermitLocalCommand yes
  LocalCommand       chromium-browser --proxy-server="socks5://localhost:8888" https://wiki.intern.firma.de/ &
  Hostname           interner-rechner

Und dann ssh -N -f wiki (Entsprechungen für -N und -f habe ich noch nicht gefunden).

Der Fingerabdruck

Für die Verifikation ist es oft leichter mit kürzeren Zahlenketten. Daher ist der Fingerabdruck praktisch, um Keys einfacher zu vergleichen:

$ ssh-keygen -lf ~/.ssh/id_dsa.pub
1024 98:c5:76:...:08:fa:ba  lollypop@lollybook (DSA)

Nutzer einschränken

# SSH is only allowed for users in the group ssh except syslog
AllowGroups ssh
DenyUsers syslog

PuTTY Portable

pageant zusammen mit putty starten

In die Datei ..\PortableApps\PuTTYPortable\App\AppInfo\Launcher\PuTTYPortable.ini muß folgendes unter [Launch] stehen:

[Launch]
ProgramExecutable=putty\pageant.exe
CommandLineArguments='%PAL:DataDir%\settings\mykeys.ppk -c %PAL:AppDir%\putty\putty.exe'
DirectoryMoveOK=yes
SupportsUNC=yes

Zu PortableApps siehe auch:

ppk -> pem

$ nawk '/---- BEGIN SSH2 PUBLIC KEY ----/{printf "ssh-rsa "; getline; comment=$2; gsub(/"/,"",comment); getline line; while(line !~ /^---- END/){printf line; getline line;} printf " %s\n",comment;}' pubkey.ppk

Probleme mit älteren Gegenstellen

Unable to negotiate with <IP> port 22: no matching host key type found. Their offer: ssh-dss

$ ssh -oHostKeyAlgorithms=+ssh-dss <IP>

ssh_dispatch_run_fatal: Connection to <IP> port 22: DH GEX group out of range

$ ssh -oKexAlgorithms=diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 <IP>

SFTP chroot

# mkdir --parents --mode=0755 /sftp_chroot/etc

/etc/fstab

...
/etc/passwd /sftp_chroot/etc/passwd none ro,bind 0 0
/etc/group  /sftp_chroot/etc/group  none ro,bind 0 0

/etc/ssh/sshd_config

...

AllowGroups ssh-user

Subsystem sftp internal-sftp
Match group sftp
  AllowGroups sftp
  X11Forwarding no
  AllowTcpForwarding no
  AllowAgentForwarding no
  PermitTunnel no
  ForceCommand internal-sftp
  PasswordAuthentication yes
  ChrootDirectory /sftp_chroot/
  AuthorizedKeysFile	/sftp_chroot/%h/.ssh/authorized_keys

Create SFTP user

Now you can put authorized keys into the files /home/sftp/.authorized_keys/username And create the sftp users like this:

# USER=myuser
# mkdir   --parents     --mode=0755 /home/sftp/${USER}
# useradd --create-home --home-dir  /home/sftp/${USER}/home ${USER}

Two factor authentication

Google Authenticator

As the Google Authenticator is a tool which is available on several SmartPhone OS I took this one for the OTP authentication.

All steps have to be done on the destination host.

Install libpam-google-authenticator

$ sudo apt-get install libpam-google-authenticator

Add settings to the /etc/pam.d/sshd

Put this line at the top of your /etc/pam.d/sshd!

auth [success=done new_authtok_reqd=done default=die] pam_google_authenticator.so nullok

See the man page pam.d(5) or read here... The meaning of the parameters:

success=done : If pam_google_authenticator returns successful (code was correct) all authentication is done.
new_authtok_reqd=done : New authentication token is required set to done. Done is like ok, <man page>except that the stack also terminates and control is immediately returned to the application.</man page>
default=die : If pam_google_authenticator failed no other authentications will be tried
nullok : Allow user to access auth mechanism even if the password is empty

Add settings to the /etc/ssh/sshd_config

This lines have to be in the /etc/ssh/sshd_config:

UsePAM yes
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive:pam

Without the setting in /etc/pam.d/sshd the "PasswordAuthentication no" will not be sufficient and still ask for a password because /etc/pam.d/sshd enables password authentication.

SSH Tipps und Tricks

Contents