E aqui una pequeña wiki de SSH¡¡¡
SSH hacks
Cómo me conecto por ssh sin contraseñas
En primer lugar es necesario generar una pareja de claves en tu máquina (‘client‘), en este caso ‘bender‘:
cesar@bender ~ $ ssh-keygen -t dsa
Te preguntará un passphrase que es recomendable introducir, aunque también se puede dejar en blanco. Tras esta operación obtendrás los ficheros:
cesar@bender ~ $ ls ~/.ssh id_dsa id_dsa.pub known_hosts
El fichero ‘id_dsa‘ contiene la clave privada y no debería salir de tu ordenador. Debe tener permisos 600:
cesar@bender ~ $ chmod 600 .ssh/id_dsa
El fichero ‘id_dsa.pub‘ contiene tu clave pública. Para autorizar una clave pública en una máquina remota ‘kastor‘:
cesar@bender ~ $ cat ~/.ssh/id_dsa.pub | ssh kastor 'cat - >> .ssh/authorized_keys'
No olvides poner dos símbolos «>», puesto que en caso contrario te cargarás otras claves autorizadas en la máquina ‘kastor‘. La próxima vez que hagas ‘ssh kastor‘ entrará sin más. Si has puesto passphrase, tendrás que hacer primero:
cesar@bender ~ $ ssh-add
Solución de problemas
- Sigue sin dejar conectarme: Asegúrate de que los permisos de ‘~/.ssh/authorized_keys‘ en la máquina remota son 644.
- Cuando escribo ‘ssh-add‘ aparece el mensaje Could not open a connection to your authentication agent: La shell desde la que intentas conectarte no esta bajo el control del agente de autenticación.
- Solucion rápida: Lanza una shell con el agente de ssh.
cesar@bender ~ $ ssh-agent bash
- Solución mejor: lanza todas tus X bajo el ‘ssh-agent‘. Así todas las terminales colgarán de él.
El archivo /etc/hosts
Para un acceso rápido por ssh resulta muy útil definir alias de tus máquinas comunes en el fichero ‘/etc/hosts‘:
cesar@bender ~ $ sudo vim /etc/hosts # # Syntax: # # IP-Address Full-Qualified-Hostname Short-Hostname # 192.168.1.4 kastor.zylk.net kastor
Esta operación requiere privilegios de administrador o superusuario.
Como manejar las llaves de ssh ? Uso de keychain
Una posibilidad es iniciar el ordenador en ‘init 3‘ sin X y redefinir tu ‘startx‘: Este es mi ‘~/bin/startx-ssh‘:
cesar@bender ~ $ vim ~/bin/startx-ssh #!/bin/bash keychain ~/.ssh/id_dsa || exit source ~/.keychain/`hostname`-sh startx exit
Al iniciarlo, me pide el passphrase. Otra posibilidad es incluir estas dos líneas en tu archivo ‘.gnomerc‘ o similar en otros entornos gráficos.
keychain ~/.ssh/id_dsa source ~/.keychain/`hostname`-sh
Y ahora, si hago login desde otra máquina, o quiero que un cron pueda conectarse a otras máquinas, incluyo las siguientes líneas:
cesar@bender ~ $ source ~/.keychain/`hostname`-sh
Si quiero cerrar el acceso, hago:
cesar@bender ~ $ keychain --stop
Para volverlo a arrancar:
cesar@bender ~ $ keychain ~/.ssh/id_dsa
Cómo y por qué usar un túnel ssh?
Has trabajado alguna vez detrás de un firewall? Tienes una página web privada de una institución detrás de un firewall a la que sólo pueden acceder las máquinas de esa institución? Has intentado alguna vez mover un fichero desde detrás de un firewall a otra máquina que esta detrás de otro firewall? Entonces, lo que necesitas es hacer un túnel ssh.
La idea básica es que desde tu máquina (‘client.machine‘) tienes acceso a una máquina ‘bridge.machine‘ que no es a la que quieres acceder, pero que desde ella si podrías acceder a tu objetivo ‘target.machine‘. El túnel te permite operar de forma transparente desde ‘client.machime‘ hasta ‘target.machine‘. Hay dos tipos de túneles: túneles directos e inversos. En un túnel directo (forward) se hace corresponder un puerto de destino (‘dport‘) en la ‘target.machine‘, con un puerto local (‘lport‘) en tu máquina ‘client.machine‘. Esto se hace de la siguiente manera:
cesar@bender ~ $ ssh -NfL lport:target.machine:dport bridge.machine
Regla nemotécnica: acuérdate de la liga de futbol americano (NFL) y que la del medio es en minúscula.
HINT: Por cierto, aseguraros que el puerto local no está siendo usado, por ejemplo que apache este escuchando en ese puerto (aunque este mapeado con un virtual host deshabilitado). Por otro lado la opción verbose (-NfvL) puede ayudar en la traza de algún error.
Conectarse por ssh a target.machine
Primero construiríamos el túnel:
cesar@bender ~ $ ssh -NfL 6666:target.machine:22 bridge.machine
Y a continuación basta con hacer lo siguiente para entrar directamente en ‘target.machine‘:
cesar@bender ~ $ ssh -p6666 localhost
O bien:
cesar@bender ~ $ scp -P6666 fichero localhost:/el/path/que/te/venga/bien
Esto requiere que en tu ‘$HOME/.ssh/config‘ añadas la línea:
NoHostAuthenticationForLocalhost yes
Ejemplos de uso para los túneles ssh
Conexión a una web de una red privada
Si montas un servicio en un ordenador detrás de un firewall, este no va a estar disponible fuera porque en general los puertos estarán capados. Por ejemplo, una web dentro de una máquina de una red privada sin salida al exterior. A través de un túnel ssh se puede acceder a este servicio.
cesar@bender ~ $ ssh -NfL 8080:target.machine:80 bridge.machine
Después en el navegador, la web de ‘target.machine‘ estará disponible en ‘http://localhost:8080‘.
Conexión al LDAP de una red privada
cesar@bender ~ $ ssh -Nvf -L 9999:kastor.zylk.net:389 cesar@kastor.zylk.net
Aunque el puerto del LDAP (389) esta capado, yo puedo acceder a él desde fuera de la red si tengo un acceso a ‘kastor‘ haciéndolo pasar a través del puerto 22 (el del ssh) y mapeandolo a un puerto, digamos el 9999 en mi máquina local. Situación inicial:
| |
localhost:9999 ----------- | kastor.zylk.net:389
| |
Túnel:
| 22 | |
localhost:9999 ----------- kastor.zylk.net:22 kastor.zylk.net:389
| | |
Una vez hecho el túnel, puedo configurar en mi agenda el acceso al LDAP con servidor localhost y puerto 9999. Nota: En realidad el proceso incorpora tres máquinas, la local, la de salida y la del servicio. Lo que pasa es que en este caso las dos ultimas son la misma.
Administrar el servidor CUPS de una red privada
Desde mi máquina:
cesar@bender ~ $ ssh -Nvf -L 63131:cups.zylk.net:631 cesar@kastor.zylk.net
Túnel:
| 22 | |
localhost:63131 ----------- kastor.zylk.net cups.zylk.net:631
| | |
De este modo me puedo conectar a la interfaz web de administración desde mi máquina en http://localhost:63131
Cómo definir tus propios hosts sin ser root?
Una situación bastante común es que tener acceso a una cuenta en una máquina sin privilegios de administrador o superusuario. Para conectarte a ‘kastor.zylk.net‘ con login ‘cesar‘:
cesar@bender ~ $ ssh cesar@kastor.zylk.net
La solución está en el fichero ‘$HOME/.ssh/config‘:
Host kastor Hostname kastor.zylk.net User cesar Port 22 ForwardX11 no Protocol 2,1 Host cups Hostname localhost User zylk Port 9999
Con lo cual puedes hacer directamente:
cesar@bender ~ $ ssh kastor
El ssh sabe que tiene que conectarse a la máquina ‘kastor.zylk.net‘ y usar el login ‘cesar‘. Y ahora sabe que tiene que conectarse al puerto 9999 de ‘localhost‘ usando como login ‘zylk‘. Con esto tienes ya total transparencia en los túneles. Sobre todo si te haces un alias para levantarlo del tipo de:
cesar@bender ~ $ alias tncups='ssh -NfL 9999:cups.zylk.net:22 cesar@kastor'
Ejecutas el alias, que puedes copiar en tu ‘.bashrc‘:
cesar@bender ~ $ tncups
y te puedes conectar directamente a ‘cups.zylk.net‘ de forma transparente desde el exterior.
cesar@bender ~ $ ssh cups
Utilizando el sistema de ficheros sshfs
El objetivo es tener un sistema de ficheros remoto. Una especie de NFS o samba, pero seguro a través de ssh. Instalo sshfs:
$ sudo apt-get install sshfs
Me añado al grupo «fuse»:
$ sudo vi /etc/group
Luego ejecuto:
$ sshfs cesar@kastor.zylk.net:/data1/z-docs /mnt/z-docs/
Cómo conectarse unicamente via certificado?
Configurar el demonio de ssh de modo que sólo se puedan realizar conexiones ssh a la máquina si el usuario remoto está en la lista ‘authorized_keys‘.
$ sudo vim /etc/sshd_config PasswordAuthentication no UsePAM no
Por defecto esta opción está marcada como yes. También se puede definir donde están las listas autorizadas (claves públicas). Por defecto las define el usuario:
#AuthorizedKeysFile %h/.ssh/authorized_keys
Reinicio el servicio:
$ /etc/init.d/sshd restart
Desactivar el login a root por ssh
Desactivo conexiones remotas ssh a la cuenta root, como medida de prevención de ataques ssh.
$ sudo vim /etc/sshd_config PermitRootLogin no
Reinicio el servicio:
$ /etc/init.d/sshd restart