SSH, way to the target

SSH over one or more hops

To make the SSH connection from host_a to host_b you have to tunnel through two hosts (jumphost_1 and jumphost_2). If you always log in first and then continue logging in, it is sometimes very difficult to loop through the port forwardings or the Socks5 proxy. It is easier to define ProxyJumps for the way from host_a to host_b. So we only get from jumphost_2 to host_b, so we make an entry in ~/.ssh/config for this:

Host host_b
   ProxyJump jumphost_2

But we can only get to jumphost_2 via jumphost_1, so we need an entry for this as well:

Host jumphost_2
   ProxyJump jumphost_1

Now simply type ssh host_b on host_a and you will be tunneled through the two gateways jumphost_1 and jumphost_2.

Portforwardings for example for NFS are now easy like this

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

In the background the tunnel connections are established and the port forwarding is done directly from host_a to host_b. Very slim and elegant.

Breakout from paradise

Problem: The environment you are in is unfortunately so unfortunate with firewalls that you can not work. But you have to SSH out to look somewhere else or to get something. Well, there is always a way...

You need a locally installed connect, e.g. under Ubuntu: apt-get install connect-proxy. Furthermore you need a SSH server, where a sshd is listening on port 443, because most proxies only want to let you through on known ports.

Then you enter in the ~/.ssh/config:

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

Schwuppdiwupp is one with ssh ssh-server on the SSH target, where one would like to go. Of course you can enter the ssh-server again as ProxyCommand etc. etc.

Ah yes... the internal wiki...

Also not bad, if this is only accessible from the internal network, then we just request via socks proxy:

user@host_a$ ssh -C -N -T -f -D8080 internal-host
user@host_a$ chromium-browser --proxy-server="socks5://localhost:8080" https://wiki.internal.office/ &

Options are:

-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

Or again 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           internal-host

And then ssh -N -f wiki

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