SSH Tipps und Tricks: Difference between revisions

From Lolly's Wiki
Jump to navigationJump to search
m (Text replacement - "[[Kategorie:" to "[[Category:")
Line 1: Line 1:
[[Category:SSH|Tipps]]
[[Category:SSH|Tipps]]
[[Category:Putty|Tipps]]
[[Category:Putty|Tipps]]
=SSH, der Weg zum Ziel=
=SSH, way to the target=
==SSH über ein oder mehrere Hops==
==SSH over one or more 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.
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 <i>ProxyJump</i>s for the way from host_a to host_b.
Wir kommen also nur von GW_2 zu Host_b, also machen wir uns hierfür einen Eintrag in der ~/.ssh/config:
So we only get from jumphost_2 to host_b, so we make an entry in ~/.ssh/config for this:
<pre>
<pre>
Host Host_B
Host host_b
   ProxyJump GW_2
   ProxyJump jumphost_2
</pre>
</pre>
Zu GW_2 kommen wir aber nur über GW_1, also brauchen wir hierfür auch einen Eintrag:
But we can only get to jumphost_2 via jumphost_1, so we need an entry for this as well:
<pre>
<pre>
Host GW_2
Host jumphost_2
   ProxyJump GW_1
   ProxyJump jumphost_1
</pre>
</pre>


Jetzt gibt man auf Host_A einfach <i>ssh Host_B</i> ein und wird über die beiden Gateways GW_1 und GW_2 getunnelt.
Now simply type <i>ssh host_b</i> 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==
==Portforwardings für z.B. NFS macht man jetzt einfach so==
<pre>
<pre>
root@Host_A# share -F nfs -o ro=@127.0.0.1/32 /tmp
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
root@host_a# ssh -R 22049:localhost:2049 user@host_b
user@Host_B$ su -
user@host_b$ su -
root@Host_B# mount -oro nfs://127.0.0.1:22049/tmp /mnt
root@host_b# mount -oro nfs://127.0.0.1:22049/tmp /mnt
</pre>
</pre>
Im Hintergrund werden dann die TunnelVerbindungen aufgebaut und man macht das PortForwarding direkt von Host_A nach Host_B. Sehr schlank und elegant.
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.


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
==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...


==Ausbruch aus dem Paradies==
You need a locally installed [http://www.meadowy.org/~gotoh/projects/connect connect], e.g. under Ubuntu: apt-get install connect-proxy.
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...
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.


Vorraussetzung ist ein lokal installiertes [http://www.meadowy.org/~gotoh/projects/connect connect], z.B. unter Ubuntu: apt-get install connect-proxy.
Then you enter in the ~/.ssh/config:
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:
<pre>
<pre>
Host ssh-via-proxy
Host ssh-via-proxy
   ProxyCommand connect -H proxy-server:3128 ssh-server 443
   ProxyCommand connect -H proxy-server:3128 ssh-server 443
</pre>
</pre>
Schwuppdiwupp ist man mit <i>ssh ssh-server</i> auf dem SSH-Ziel, wo man hinmöchte. Natürlich kann man auf den ssh-server wieder als ProxyCommand eintragen usw. usw.
Schwuppdiwupp is one with <i>ssh ssh-server</i> on the SSH target, where one would like to go. Of course you can enter the ssh-server again as ProxyCommand etc. etc.
 


==Achja... das interne Wiki...==
==Ah yes... the internal wiki...==
Auch nicht schlimm, wenn das nur vom internen Netz erreichbar ist, dann fragen wir einfach via Socks-Proxy an:
Also not bad, if this is only accessible from the internal network, then we just request via socks proxy:
<pre>
<pre>
user@Host_A$ ssh -C -N -T -f -D8080 interner-rechner
user@host_a$ ssh -C -N -T -f -D8080 internal-host
user@Host_A$ chromium-browser --proxy-server="socks5://localhost:8080" https://wiki.intern.firma.de/ &
user@host_a$ chromium-browser --proxy-server="socks5://localhost:8080" https://wiki.internal.office/ &
</pre>
</pre>
Die Optionen sind:
Options are:
<pre>
<pre>
-C      Requests compression <- das ist optional
-C      Requests compression <- das ist optional
Line 55: Line 53:
-D      Local-Remote-Socks5-Proxy Port
-D      Local-Remote-Socks5-Proxy Port
</pre>
</pre>
Oder wieder via ~/.ssh/config:
Or again via ~/.ssh/config:
<pre>
<pre>
Host wiki
Host wiki
Line 63: Line 61:
   PermitLocalCommand yes
   PermitLocalCommand yes
   LocalCommand      chromium-browser --proxy-server="socks5://localhost:8888" https://wiki.intern.firma.de/ &
   LocalCommand      chromium-browser --proxy-server="socks5://localhost:8888" https://wiki.intern.firma.de/ &
   Hostname          interner-rechner
   Hostname          internal-host
</pre>
</pre>
Und dann <i>ssh -N -f wiki</i> (Entsprechungen für -N und -f habe ich noch nicht gefunden).
And then <i>ssh -N -f wiki</i>


=Der Fingerabdruck=
=Der Fingerabdruck=

Revision as of 10:30, 16 March 2023

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.