SSH

De WikiMar
(S'ha redirigit des de: Ssh)
Dreceres ràpides: navegació, cerca

SSH Scripts per mantenir tunnels

SSH Scripts


Engega el ssh:

/etc/init.d/sshd restart

Tornar a demanar IP:

/net.eth0 restart

Sessió:

 /xdm restart


Connexió rebent les finestres a la màquina local:

ssh -X usuari@maquina

En cas que no hi sigui cal tenir fer

emerge xauth

En cas de problemes

ssh -v -X usuari@maquina

Usar compressió:

... -C

Tunel Normal (obrir port d'escolta a màquina local)

ssh -L 3002:localhost:119 vecino@brutal


Tunnel Invers (Obrir port d'escolta a la màquina remota)

ssh -p4022 -g -R 10022 usuari@maquina

o bé:

ssh -p4022 -g -R 10022:localhost:80 usuari@maquina

(per la -g, cal GatewayPorts yes en la configuració del servidor.)

Un altre exemple util a Cafe:

ssh -p23 -g -R 20022:localhost:22 usuari@cube

o be

~/papes-emergencia-tunel-20022.sh

Tunnel invers per permetre connexions inverses de VNC:

ssh -p4022 -g -R 5500:10.0.2.2:5500 [email protected]


Tunnel Dinamic / crear proxy SOCKS5

Amb l'opció -D creem un port LOCAL que és un port proxy SOCKS5 a on tot surt per la màquina REMOTA.

ex.

ssh -C2qTnN -D 8080 username@remote_machine.com
-C Compression
-2 SSH2 only
-q Quite
-T Force pseudo-tty allocation
-n Redirect stdin from /dev/null
-N and Place the ssh client into "master" mode for connection sharing.

Més info:

https://calomel.org/firefox_ssh_proxy.html
http://embraceubuntu.com/2006/12/08/ssh-tunnel-socks-proxy-forwarding-secure-browsing/

Copiar fitxers entre màquines:

scp -P 4022 usuari@maquina:/home/usuari/...



Secure SSHD

More info: https://blog.devolutions.net/2017/4/10-steps-to-secure-open-ssh

/etc/ssh/sshd_config


#If no password authentication is allowed:
 PasswordAuthentication no
 UsePAM no

PubkeyAuthentication yes
ChallengeResponseAuthentication no


#PermitRootLogin without-password
PermitRootLogin no

PasswordAuthentication no
PermitEmptyPasswords no

#DenyUsers c m n d tinyproxy
#AllowUsers mar rsy

#MaxAuthTries 4


#Probably already by default:

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
#(now it is deprecated) RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no


sudo service sshd restart

Force Rsync to only one folder

Rsync


Més info

Aqui hi ha una copia d'una part de la pàgina:

Funcions

Todos los servicios funcionan a través del puerto 22/tcp del sistema:

  • Shell: Tal y como dice el nombre Secure Shell remoto, vamos a probarlo: ssh vecino.
    • Ojo porque si esto lo ejecutamos desde una sesión telnet no sirve de nada la criptografía que lleva.
    • La primera vez que nos conectamos al host, se produce una autentifiación a nivel de host.
    • Podemos acceder al menú del ssh escribiendo: <intro>~?
  • X-Forward. ssh -X vecino@brutal (también necesitamos la opción X11Forwarding yes en el servidor).
  • Copia: scp vecino@brutal:/etc .
  • FTP Seguro: sftp brutal.xxx
  • Ejecución. ssh vecino@brutal ps axf
  • Tuneling. Hay de dos tipos:
    • local. ssh -L 3002:localhost:119 vecino@brutal
    • remoto. ssh -g -R 8000:localhost:80 vecino@brutal (ojo con la -g, que necesitamos GatewayPorts yes en la configuración del servidor.
  • VPN. En combinación con el demonio pppd, puede funcionar como VPN.

Autentificació

Host

  • El host se autentifica de la siguiente forma:
  1. Cliente -> Servidor. Inicia conexión TCP por el puerto 22.
  2. Servidor -> Cliente. El servidor le envía al cliente su clave pública RSA de host (almacenada en /etc/ssh/ssh_host_rsa_key.pub). Para que el cliente acepte esta clave, la primera vez te pregunta si te fias de la clave que te envía el servidor imprimiendo el fingerprint. Es recomendable llamar al administrador del servidor para que ejecute ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub y comparar a viva voz el fingerprint de la clave.
  3. Cliente -> Servidor. El cliente pide al servidor que demuestre que él posee la clave privada asociada a la pública que está enviando. Esto se llama desafío o challenge en inglés. En este caso, le envía un TEXTO aleatorio que pide que firme.
  4. Servidor -> Cliente. Le envía el TEXTO firmado con su clave privada y el cliente verifica la firma con la clave pública del servidor. A continuación se cede el paso y se encripta la comunicación.
  5. La comunicación a partir de este punto está cifrada con una clave simétrica de sesión aleatoria (ya que la criptografía simétrica es mucho más rápida). Ésta se envía de forma asimétrica con las claves negociadas.

Usuaris

A continuación viene la autentificación de usuario (ya con la comunicación encriptada). Se puede hacer con password via PAM. Y este es la forma estándar. Pero hay una manera más segura, mediante criptografía de clave pública.

  • Las contraseñas pueden tener varios problemas: largas y difíciles de recordar, se pueden interceptar en el servidor o en el cliente si tienen un troyano y hay problemas con cuentas compartidas... Para solucionar esto se utiliza criptografía:
  1. Cliente -> Servidor. El cliente le envía el nombre de usuario.
  2. Servidor -> Cliente. El servidor no se lo cree y le envía un desafío con un TEXTO aleatorio para que lo firme con su clave privada de usuario.
  3. Cliente -> Servidor. El cliente le envía el TEXTO firmado y el servidor lo comprueba con su clave pública. A continuación le deja pasar.

Esto tiene diversas ventajas con respecto a las contraseñas:

  • Dos componentes secretos. La clave privada del usuario y la contraseña que cifra simétricamente esta clave privada.
  • No se están transmitiendo la contraseña ni la clave.
  • Las claves no se pueden adivinar tan facilmente como las contraseñas...

La instalación son dos pasos:

  1. Como usuario, ejecutamos ssh-keygen -t dsa
  2. Copiamos la clave pública ~/.ssh/id_dsa.pub al fichero del servidor ~/.ssh/authorized_keys2. Podemos poner varias públicas (una por línea). El fichero no puede ser escribible por nadie excepto el propietario.

Agents SSH

  • Es un programa en ejecución que guarda la clave privada desencriptada en su espacio de memoria RAM. Sirve para que no se tenga que escribir un password cada vez se usa la clave privada:
  1. ssh-agent /bin/bash
  2. ssh-add

A continuación funcionan las conexiones a otras máquinas sin que pida password, la clave sin encriptar no se almacena en ningún lugar.


ed25519 vs ecdsa

EdDSA Keys (Ed25519 & Ed448) are better than ECDSA Keys:

The Edwards-curve Digital Signature Algorithm was designed in 2011 and is highly optimised for x86-64 processors. It provides equivalent and usually better security than ECDSA and longer key length RSA keys.

ssh-keygen -t ed25519

Configuracio afegida /etc/ssh/sshd_config

#Added by ma:
MaxAuthTries 4
PermitEmptyPasswords no
#PasswordAuthentication no
#PermitRootLogin prohibit-password
#Protocol 2
#AllowUser rsync

#Mitigate https://access.redhat.com/security/cve/CVE-2024-6387
LoginGraceTime 0