Saltar al contenido

ssh

Passwordless SSH

  • admin 

Passwordless SSH can be accomplished using SSH’s public key authentication. To configure passwordless SSH, follow the directions below. Warning: passwordless SSH will make your systems less secure. If you are comfortable with that, the directions below will walk you through server and client configurations. Then, I’ll show you how to debug SSH if you encounter problems.

SSHD Server Configuration

First, you must ensure that your SSHD server allows for passwordless authentication using public keys. If you do not have root access to the server, do not worry. By default, public key authentication over protocol 2 is enabled. Skip this step. If you have any problems, contact your System Administrator.

If you have root privileges, edit your system’s /etc/ssh/sshd_config and apply the following settings. I suggest you disable protocol 1 RSA key based authentication and leave all other settings alone for now. Visit the man page SSHD_CONFIG(5) for details.

# Disable protocol 1 RSA key based authentication
RSAAuthentication no
# Protocol 2 public key based authentication
PubkeyAuthentication yes
# Authorized public keys file
AuthorizedKeysFile .ssh/authorized_keys

If you make any changes, save them and restart your SSH server.

service sshd restart

SSH Client Configuration

Now that the server is configured, log into your client system and examine /etc/ssh/ssh_config. This is the SSH client configuration file and you do not need to edit it.

less /etc/ssh/ssh_config

By default, public key authentication over protocol 2 is enabled for clients. You only need to make sure that it is not disabled. If it is, create an ~/.ssh/config to override the /etc/ssh/ssh_config options.

cp -a /etc/ssh/ssh_config ~/.ssh/config

Then edit it and add this to the «Host *» block:

PubkeyAuthentication yes

Create Client Key

With the client in order, you need to create a public and private key pair. The following command will build a DSA key pair. Hit for all questions asked. This will create a DSA key pair in ~/.ssh/. The private key is called id_dsa and the public key is id_dsa.pub.

ssh-keygen -t dsa

Use Key for Authentication

Now that you have a public and private key pair, put the public key on the server you wish to log into without a password. You will need to put the public key inside the server’s /home/user/.ssh/authorized_keys file. This file can contain multiple keys, so you generally do not want to just copy over it. Note that the authorized_keys2 file was deprecated in OpenSSH 3.0 (2001).

cat ~/.ssh/id_dsa.pub | ssh user@server "cat - >> ~/.ssh/authorized_keys"

Alternatively, modern releases of SSH have a command to help you copy keys.

ssh-copy-id -i ~/.ssh/id_dsa.pub user@server

Test and Debug SSH

Now, test.

ssh username@server date

If you get prompted for a password, check the server’s system logs for clues. You can also enable debugging in /etc/ssh/sshd_config with the following directive.

LogLevel DEBUG

Other options are INFO, VERBOSE, DEBUG2 and DEBUG3. See the man page SSHD_CONFIG(5) for details. For the client, the exact same option can be placed inside a /etc/ssh/ssh_config’s Host block. See SSH_CONFIG(5) for client debugging details.

man 5 sshd_config
man 5 ssh_config

 

Fuente: http://hacktux.com/passwordless/ssh

Tunnelling SSH over a SOCKS proxy

  • admin 

http://crysol.org/es/node/1355

Proxy SOCKS con SSH: más fácil imposible

Pequeña receta para montar un proxy SOCKS en tu PC para salir a internet a través de un túnel SSH.

Ingredientes

  • openssh
  • autossh
  • netcat-openbsd
  • tsocks

¿Para qué quiero yo esto?

Buena pregunta. Pues sin entrar en detalles «podríamos decir» que un proxy SOCKS es una buena forma de salir a Internet por un solo puerto aunque uses distintas aplicaciones y protocolos: web, jabber, FTP,…

¿Por qué querría yo hacer algo tan raro?

Pues eso es lo bueno, que tú no quieres. Pero a veces tu empresa, instituto, universidad, el Partido, etc. decide que si te concede la gracia de darte acceso al puerto 80 (y si acaso al 443) ya tienes bastante ¿«pa» qué más?

Así que, si tienes una máquina fuera (en tu casa por ejemplo) puedes utilizarla como proxy hacia Internet.

Configuración del proxy SOCKS (en el PC de casa)

Lo único que necesitas es una computadora al otro lado del firewall (en tu casa) con un servidor SSH no demasiado viejo que esté configurado para escuchar en el puerto 443, 80 o alguno de los que te permita acceder el firewall fascista de tu empresa. Algunos incluso te permiten usar el 21 (FTP). Llamaremos a esa máquina: micasa.example.net.

Abriendo el túnel (desde el PC del trabajo)

También necesitas SSH. Ejecuta lo siguiente en una consola:

$ ssh -N -D localhost:1080 micasa.example.net -p 443

Si no tienes configurada una clave pública para acceder a esa máquina (algo que te recomiendo) te pedirá la clave. Si todo va bien se quedará ahí haciendo su trabajo como buen túnel que es. No cierres esa consola. 1080 es el puerto estándar para SOCKS pero puedes usar otro si quieres.

Configurando las aplicaciones

Muchas aplicaciones de red (aunque no todas) tienen la posibilidad de utilizar un proxy. La ventana en cuestión tendrá una pinta similar a la siguiente. Esta concretamente es la de Firefox 3.5 y la puedes encontrar en Edit->Preferences->Advanced->Network->Settings:

 


 

Debes editarlo para que quede como en la figura, que corresponde con los datos de la consola de antes.

Y ya está, ahora todas las conexión que haga el navegador se las pedirá al servidor SSH de tu casa (que actúa de proxy SOCKS).

En lugar de hacer esto en cada aplicación, tienes la posibilidad de configurar el proxy globalmente y decir a las aplicaciones que usen la configuración del sistema. Por ejemplo en GNOME 2.30 se hace en System->Preferences->Network Proxy.

Doctor, el túnel se me cae

Pues sí, los túneles tienen la mala costumbre de caerse y dejarte tirado si se rompe la conexión. Pero hay solución, se llama autossh (es paquete Debian). Y para usarlo simplemente ejecuta el comando de antes, cambiando ssh por autossh:

$ autossh -N -D localhost:1080 micasa.example.net -p 443

En este casi si que es casi obligado usar la clave pública porque si no, cuando intente recuperar el túnel, va a pedir la clave y la gracia de autossh (que es automático) no servirá de mucho.

¿Y qué pasa con SSH?

Es decir, ¿cómo puedes conectar por SSH con una máquina remota? Pues hay que hacer que el tráfico de la conexión SSH pase también a través del túnel, esto es lo que se llama «socksificar» un cliente. Es fácil socksificar el cliente SSH gracias a la opción ProxyCommand, que como su nombre indica (más o menos) sirve para conectar a un servidor SSH a través de un proxy. Aquí va un ejemplo

$ ssh -o "ProxyCommand /bin/nc.openbsd -x localhost %h %p" server.minimor.com

«socksificando» lo que haga falta

Hay muchas aplicaciones (la mayoría) que no fueron diseñadas para utilizar proxies SOCKS. Sin embargo hay un medio muy sencillo para lograr que usen el proxy sin que lo sepan.

Se basa en interceptar la invocación a la llamada connect() de la librería de sockets, de modo que cuando la aplicación abra ingenuamente una conexión normal hacia un servidor remoto, los datos serán enviados de forma transparente hacia el proxy SOCKS configurado. Esta magia (que no es tal) es posible gracias a la precarga de librería de los sistemas GNU (LD_PRELOAD) y el programa tsocks que aprovecha este principio.

Después de instalar el paquete tsocks tienes que configurar el proxy SOCKS que debe usar. Si has seguido las instrucciones anteriores, edita el fichero/etc/tsocks.conf y cambia el valor de la opción «server» para que quede así (se muestran las últimas líneas del fichero):

server = 127.0.0.1
server_type = 5
server_port = 1080

Y para socksificar cualquier programa simplemente ejecuta algo como:

$ tsocks claws-mail

o bien:

$ tsocks          # <— esto abre una nueva shell socksificada
$ claws-mail

looping the loop

Y si lo que quieres es conectar tu máquina a una VPN cuyo servidor está al otro lado del firewall. Un tema interesante…

[ToDo]

Referencias