Tutorial de SSH para Linux

Este documento cubre el cliente SSH en el Linux del sistema operativo y otros

sistemas operativos que usan OpenSSH. Si se utiliza de Windows , por favor lea

el documento Tutorial de SSH para Windows Si utiliza Mac OS X o cualquier otro

sistema basado en Unix, ya debe tener OpenSSH instalado y se puede usar este

documento como referencia.

Este artículo es uno de los mejores tutoriales que cubren SSH a través de

Internet. Fue escrito originalmente en 1999 y se revisó completamente en 2006

para incluir información nueva y más precisa. A partir de octubre de 2008, ha

sido leído por más de 473.600 personas y siempre aparece en la parte superior

de los resultados de búsqueda de Google para SSH, SSH y Tutorial de Linux.

Contenido [ ocultar ]

1 ¿Qué es SSH?

2 Introducción

3 Generación de una clave

o 3.1 Instalación de la clave pública de forma manual

o 3.2 Instalación de la clave pública de forma automática

4 Utilización del programa ssh-agent

5 Reenvío de sesiones de X11

6 TCP Port Forwarding

7 proxy SOCKS5

8 comandos que se ejecutan a través de SSH

9 Uso de SCP

10 Mantener la sesión SSH Alive

11 Finalización de la sesión SSH

12 Referencias externas

13 créditos

¿Qué es SSH?

Hay un par de maneras que usted puede acceder a una shell (línea de

comandos) de forma remota en los sistemas Linux / Unix. Una de las formas más

antiguas es utilizar el programa telnet, que está disponible en la mayoría de los

sistemas operativos de red capaces. Acceso a una cuenta shell a través del

método de telnet, aunque representa un peligro en el que todo lo que usted

envía o recibe más de que la sesión de telnet es visible en texto plano en su red

local, y la red local de la máquina que se está conectando. Así que cualquiera

que pueda "oler" la conexión en el medio se puede ver su nombre de usuario,

contraseña, dirección de correo electrónico que usted lee, y los comandos que se

ejecuta. Por estas razones se necesita un programa más sofisticado que el telnet

para conectarse a un host remoto.

Una sesión de Telnet sin cifrar

SSH, que es un acrónimo de Secure Shell, fue diseñado y creado para ofrecer la

mejor seguridad al acceder a otro ordenador de forma remota. No sólo cifrar la

sesión, sino que también proporciona mejores servicios de autenticación, así

como las características como la transferencia segura de archivos,

redireccionamiento de X período de sesiones, el reenvío de puertos y más para

que pueda aumentar la seguridad de otros protocolos. Se pueden utilizar

diferentes formas de cifrado que van en cualquier lugar de 512 bits en un

máximo de hasta un máximo de 32768 bits e incluye algoritmos de cifrado como

AES (Advanced Encryption Plan), Triple DES, Blowfish, Cast128 o Arcfour. Por

supuesto, la más alta de los bits, más tiempo se necesita para generar y utilizar

claves, así como el tiempo que tardará en pasar los datos sobre la conexión.

Un cifrado sesión ssh

Estos dos diagramas de la izquierda muestran cómo una sesión de Telnet pueden

ser vistos por cualquiera en la red mediante el uso de un programa de sniffing

como Ethereal (ahora se llama Wireshark) o tcpdump. En realidad es bastante

fácil para hacer esto y por lo que cualquiera en la red puede robar sus

contraseñas y otra información. El primer diagrama muestra el usuario jsmith

iniciar sesión en un servidor remoto a través de una conexión telnet. Él tipos de

su nombre de usuario y contraseña jsmith C0lts06!, Que pueden ser vistos por

cualquier persona que está usando las mismas redes que se utilizan.

El segundo diagrama muestra cómo los datos en una conexión encriptada SSH al

igual que se cifra en la red y por lo tanto no puede ser leído por cualquier

persona que no tiene las claves negociadas sesión, que es sólo una forma

elegante de decir que los datos se encuentre codificada. El servidor todavía se

puede leer la información, pero sólo después de la negociación de la sesión

cifrada con el cliente.

Cuando digo revueltos, no me refiero al igual que los antiguos canales de pago

por cable donde todavía se puede ver un poco las cosas y escuchar el sonido, me

refiero a realmente revueltos. Por lo general, el cifrado significa que los datos se

ha cambiado a tal grado que a menos que tenga la clave, es realmente difícil de

descifrar el código con un ordenador. Se llevará en el orden de años para el

hardware comúnmente disponibles para descifrar los datos cifrados. La premisa

es que el momento en que podía romper, los datos no sirve para nada.

Primeros pasos

Este tutorial no va a cubrir cómo instalar SSH, sino que abarcará la forma de

utilizar para una variedad de tareas. Consulte el documento de su distribución de

Linux para obtener información sobre cómo configurar OpenSSH.

Lo más probable es que si usted está utilizando una versión de Linux que fue

puesto en libertad después de 2002, que ya han OpenSSH instalado. La versión

de SSH que usted desea utilizar en Linux se llama OpenSSH. Al escribir estas

líneas (octubre de 2009), la última versión disponible es de 5,3, pero puede

encontrar versiones de la 3.6 en adelante. Si usted está usando cualquier cosa

inferior a la versión 3.9, yo te aconsejo encarecidamente que lo actualice.

OpenSSH puede obtenerse a partir de http://www.openssh.org/~~V

Para realmente hacer ssh útil, necesita una cuenta de depósito en una máquina

remota, como por ejemplo en un Suso cuenta.

Lo primero que vamos a hacer es simplemente conectar a una máquina

remota. Esto se logra mediante la ejecución de 'ssh hostname' en el equipo

local. El nombre de host que se proporciona como un argumento es el nombre

del equipo remoto que desea conectarse. De forma predeterminada ssh a

suponer que usted desea autenticar con el mismo usuario que utilice en el equipo

local. Para modificar esto y utilizar un usuario diferente, sólo tiene que utilizar

remoteusername @ nombre de host como argumento. Tal como en este

ejemplo:

ssh username@username.suso.org

La primera vez que le preguntará si desea añadir el host remoto a una lista de

known_hosts, seguir adelante y decir que sí.

La autenticidad de acogida arvo.suso.org (216.9.132.134) 'no puede

ser establecida. Huellas dactilares de claves RSA es de 53: b4: ad:

c8: 51:17:99:4 b: c9: 08: AC: c1: b6: 05:71:9 b. ¿Seguro que desea

continuar la conexión (sí / no)? Sí Advertencia: de forma permanente

"arvo.suso.org '(RSA) a la lista de hosts conocidos.

Es importante prestar atención a esta cuestión, sin embargo, porque esta es una

de las principales características de SSH. Sede de la validación. En pocas

palabras, ssh se compruebe que se está conectando al servidor que usted cree

que se está conectando. De esta manera si alguien trata de engañarte para que

inicien sesión en su máquina, en vez de modo que puedan rastrear su sesión

SSH, tendrá algún tipo de advertencia, de esta manera:

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ ADVERTENCIA:

POSIBLE DNS Spoofing DETECTADO! @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @

@ @ @ @ @ @ @ @ La clave RSA de arvo.suso.org ha cambiado, y la

clave para la dirección IP 216.9.137.122 acuerdo no se ha

modificado. Esto podría significar que DNS Spoofing que está

sucediendo o la dirección IP para el host y su clave de host ha

cambiado, al mismo tiempo. Ofender clave para la propiedad

intelectual en / home / Suso / .ssh / known_hosts: 10 @ @ @ @ @ @ @

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ ADVERTENCIA: IDENTIFICACIÓN

host remoto ha cambiado! @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @

@ @ @ @ ES POSIBLE que alguien está haciendo algo malo! Alguien

podría estar espiando ahora mismo (man-in-the-middle)! También es

posible que la clave RSA acaba de ser cambiado. La huella de la

clave RSA enviado por el host remoto es 96:92:62:15:90: EC:

40:12:47:08:00: B8: F8: 4b: df: 5b. Por favor, póngase en contacto

con el administrador del sistema. Añadir clave de host correcta en /

home / Suso / .ssh / known_hosts para deshacerse de este mensaje.

Ofender clave en / home / Suso / .ssh / known_hosts: 53 una clave

RSA de arvo.suso.org ha cambiado y que ha solicitado la comprobación

estricta. Verificación de clave de host ha fallado.

Si alguna vez tienes una advertencia como esta, usted debe parar y determinar

si hay una razón por la clave de host del servidor remoto para cambiar (por

ejemplo, si se ha actualizado SSH o el propio servidor actualizado fue). Si no hay

una buena razón para que la clave de host para cambiar, entonces usted no debe

tratar de conectarse a la máquina hasta que no haya contacto con su

administrador acerca de la situación. Si esta es tu propio equipo que está

intentando conectarse, usted debe hacer algunas informática forense para

determinar si la máquina fue hackeado (sí, Linux puede ser hackeado). O tal vez

la dirección IP de su ordenador personal ha cambiado, como si usted tiene una

dirección IP dinámica para DSL. Una vez que ha recibido este mensaje al intentar

conectar a la línea de mi máquina de casa de DSL. Pensé que era extraño ya que

no había actualizado SSH o cualquier cosa en mi máquina de casa y por eso

optan por no tratar de anular la clave de caché. Fue una buena cosa que yo no

intentarlo porque me enteré de que mi dirección IP dinámica había cambiado y

que de casualidad, otra máquina Linux corriendo OpenSSH tomó mi IP antigua.

Después de decir que sí, se le pedirá su contraseña en el sistema remoto. Si el

nombre de usuario que ha especificado existe y que escriba la contraseña remota

de forma correcta, entonces el sistema en caso de que dejen entrar si no es así,

intente de nuevo y si el error persiste, se podría verificar con el administrador

que usted tiene una cuenta en ese equipo y que su nombre de usuario y la

contraseña es correcta.

Generar una clave

Ahora que ha pasado todo ese tiempo leyendo y están conectados ahora, seguir

adelante y cerrar la sesión. ;-) Cuando esté de nuevo al mando del equipo local

ingrese el comando "ssh-keygen-t dsa '.

ssh-keygen-t dsa

Se debe comenzar a escupir lo siguiente:

Generación de par dsa pública / clave privada. Introduzca archivo en

el que guardar la clave (/ home / LocalUser / .ssh / id_dsa): Enter

passphrase (vacío sin contraseña): Introduzca misma contraseña de

nuevo: Su identificación se ha ahorrado en / home / LocalUser / .ssh

/ id_dsa. La clave pública se ha ahorrado en / home / LocalUser /

.ssh / id_dsa.pub. La huella digital es: 93:58:20:56:72: d7: bd:

14:86:9 f: 42: aa: 82:3 d: f8: e5 localuser@mybox.home.com

Se le preguntará por la ubicación del archivo de claves. A menos que usted ya ha

creado un archivo de claves en la ubicación predeterminada, puede aceptar el

valor por defecto pulsando la tecla 'enter'.

A continuación se le pedirá una contraseña y le pedirá que lo confirme. La idea

detrás de lo que debes usar una frase de acceso es diferente a la de una

contraseña. Idealmente, usted debe elegir algo único e imposible de adivinar,

como tu contraseña, pero probablemente debería ser algo mucho más tiempo,

como una frase entera. Estos son algunos ejemplos de frases de paso que he

usado en el pasado:

Los cambios de lo correcto de estado a estado

con el fin de la vida es darle propósito

No van a adivinar esta contraseña!

La RIAA solo puede aspirar a mi gran culo

Nunca es un buen día en Teletron

Algunas frases de paso que he utilizado han tenido hasta 60 caracteres, junto

con puntuacion y números. Esto hace que la frase de contraseña difícil de

adivinar. Para que os hagáis una idea de cuánto más seguro es una frase de

paso de una contraseña. Considere esto. Incluso si usted reducido el número de

palabras que alguien podría utilizar una frase de paso de 2.000 palabras

posibles, si esa persona utiliza 5 palabras en una frase de ese conjunto de Word

2000, significaría que hay 32,000,000,000,000,000 diferentes

combinaciones. Compare esto con 6.095.689.385.410.816, que es el total de

combinaciones posibles en una contraseña de 8 caracteres utilizando mayúsculas

y caracteres en minúsculas, números, y la puntuacion (alrededor de 94

caracteres posibles). Así que una contraseña de 8 caracteres tiene 5,25

veces menos combinaciones que una palabra de 5 frase de contraseña. En la

actualidad, la mayoría de la gente elige palabras de un conjunto de 10.000 o

más palabras, con lo que la complejidad de una palabra contraseña 5 a 16.405 o

más veces mayor que la de una contraseña de 8 caracteres. Así, en promedio, la

dificultad de formación de grietas en una palabra de paso es mucho mayor que

cualquier contraseña que podría ser utilizado. Curiosamente, el número potencial

de combinaciones, de 8 de la palabra contraseña de alguien con un vocabulario

adulto (8000 palabras o más) es casi igual a la cantidad de 8 combinaciones de

caracteres de contraseña multiplicado por sí mismo o sobre

16,777,216,000,000,000,000,000,000,000,000 combinaciones.

No utilice frases famosas o frases de la contraseña, que puede ser fácil de

adivinar por otra persona o por un programa de formación de grietas en la fuerza

bruta.

La razón por la que se generará un archivo de claves es para que pueda

aumentar la seguridad de su sesión de SSH al no utilizar la contraseña del

sistema. Cuando se genera una clave, en realidad se está generando dos

archivos más importantes. Una clave privada y una clave pública, que es

diferente de la clave privada. La clave privada debe permanecer siempre en el

equipo local y se debe tener cuidado de no perderlo o permitir que caiga en las

manos equivocadas. La clave pública se puede poner en las máquinas que desee

conectar en un archivo llamado .ssh / authorized_keys. La clave pública es

seguro para ser visto por nadie y matemáticamente no puede ser utilizado para

derivar la clave privada. Su justo como si te diera un número 38147918357 y le

pidió a encontrar los números y las operaciones que se utilizan para generar ese

número. Las posibilidades son casi infinitas.

Cada vez que se conecte a través de ssh a un host que tiene su clave pública

carga en el archivo authorized_keys, se utilizará un tipo de respuesta al desafío

de autenticación que utiliza su clave privada y clave pública para determinar si

debe concederse el acceso a ese equipo se le pedirá por su frase clave sin

embargo. Sin embargo, esta es tu proceso local ssh que está pidiendo la palabra

de paso, no el servidor de ssh en el lado remoto. Se pide que se autentifique de

acuerdo a los datos de su clave privada. Uso de la autenticación basada en clave

de lugar de la autenticación por contraseña del sistema puede no parecer gran

parte de la ganancia al principio, pero hay otros beneficios que se explicarán más

adelante, como el registro de forma automática a partir de X Windows.

Instalación de la clave pública de forma manual

Si usted no tiene el programa ssh-copy-id disponible, entonces se debe utilizar

este método manual para la instalación de la clave ssh en la máquina

remota. Incluso si usted no tiene el programa ssh-copy-id, es bueno para hacer

la instalación manual de al menos una vez para que tenga una buena

comprensión de lo que está pasando, porque aquí es donde muchas personas

acaban teniendo problemas.

Vaya por delante y copiar la clave pública que se encuentra en ~ / .ssh /

id_dsa.pub a la máquina remota.

scp ~ / .ssh / id_dsa.pub username@arvo.suso.org: .ssh /

authorized_keys

Se le pedirá la contraseña del sistema en la máquina remota, y después de la

autenticación que se transfiera el archivo. Puede que tenga que crear el

directorio. Ssh en su directorio home en la máquina remota en primer lugar. Por

cierto, SCP es un programa de transferencia de ficheros que utiliza

SSH. Hablaremos más sobre esto más adelante.

Ahora, cuando ssh a la máquina remota, se debe solicitar su clave de contraseña

en lugar de su contraseña. Si no lo hace, podría ser que los permisos y el modo

del archivo authorized_keys y. Ssh en el servidor remoto es necesario establecer

de manera más restrictiva. Usted puede hacer eso con estos comandos en el

servidor remoto:

chmod 700 ~ /. ssh

chmod 600 ~ / .ssh / authorized_keys

También puedes poner la clave pública en el archivo authorized_keys a distancia

con sólo copiar en el búfer de pasta, ingresando en la máquina remota y pegarlo

directamente en el archivo de un editor como vi, emacs o nano. Yo recomiendo

usar el 'gato' para ver el contenido del archivo de clave pública, porque aunque

el uso de menos va a terminar rompiendo la única línea en múltiples líneas.

cat ~ / .ssh / id_dsa.pub

Instalación de la clave pública de forma automática

Una nueva forma que usted puede fácilmente instalar su clave pública ssh en un

host remoto con el programa ssh-copy-id así:

ssh-copy-id yourusername@your.website.com

Se le pedirá su contraseña en la máquina remota y tomar el cuidado del

resto. Eso fue fácil. Así que ¿por qué no te acabo de decir cómo usar este

programa en el primer lugar? Bueno, en mi experiencia, muchos de los

problemas de la gente tiene con ssh giran en torno a tratar de obtener su clave

pública ssh instalado correctamente. Es una buena cosa que han hecho un

programa para hacer el trabajo sucio por ti, pero en aras de la construcción de

sus habilidades, al menos debe hacer la instalación manual de una vez para que

usted sepa lo que está involucrado.

Con el programa ssh-agent

La verdadera utilidad del uso de la autenticación basada en clave viene en el uso

del programa ssh-agent. Por lo general, el programa ssh-agent es un programa

que se inicia antes de iniciar X Windows y, a su vez se inicia X Window para

usted. Todos los programas X ventanas heredan una conexión con el ssh-agent,

incluyendo las ventanas de terminal, como Gnome Terminal, Konsole, xfce4-

terminal, aterm, xterm, etc. Lo que esto significa es que después de haber

puesto en marcha a través de ventanas X de ssh-agent, puede utilizar el

programa ssh-add para agregar su contraseña una vez que el agente y el

agente, a su vez, transmitirá esa información de autenticación automáticamente

cada vez que necesite para usar la frase de contraseña. Así que la próxima vez

que ejecute:

ssh username@arvo.suso.org

usted podrá acceder de forma automática sin tener que introducir una

contraseña o password. La mayoría de distribuciones recientes se iniciará

automáticamente ssh-agent cuando se conecta a través de ventanas X, como un

gestor de sesiones GDM (login gráfico). He encontrado que a partir de este

escrito las siguientes distribuciones comenzó ssh-agent por defecto.

Debian

Fedora

Gentoo

SuSE

Ubuntu

La mayoría de las distribuciones previas a alrededor de 2002 no se iniciará.

No se preocupe si usted no ve su distribución aparece aquí. Puede comprobar si

ya se está ejecutando mediante la ejecución de este comando.

ps auxw

Si hay un proceso de ssh-agent en la lista, entonces puedes empezar a usarlo,

de lo contrario, usted debe consultar la documentación de su distribución en

OpenSSH y ejecutar el ssh-agent.

Una vez que hayas verificado que ssh-agent se está ejecutando, puede agregar

la clave ssh para que al ejecutar el comando ssh-add:

ssh-add

Si el programa encuentra la clave DSA que ha creado anteriormente, se le pedirá

la contraseña. Una vez que usted ha hecho por lo que debe decirle que se ha

añadido a su identidad para el ssh-agent:

Identidad añadido: / home / usuario / .ssh / id_dsa (/ home /

usuario / .ssh / id_dsa)

Ahora usted puede tratar de iniciar sesión en la máquina remota, y esta vez te

darás cuenta de que simplemente se conecta justo en sin pedir ninguna

contraseña o frase de contraseña.

Para hacer más fácil la adición de la frase de contraseña, puede agregar el

programa ssh-add a sus programas de escritorio de inicio de sesión y se abrirá

un mensaje de ventanas X para pedir su contraseña cada vez que inicie sesión

en su escritorio. Usted también debe tener el programa instalado gtk2-

askpass. O x11-askpass. Son los programas reales que la realidad le pedirá su

contraseña. ssh-add simplemente se ejecuta si no su se está ejecutando en un

terminal. A continuación se muestra una captura de pantalla del cuadro de

diálogo de configuración de Gnome Sesiones con ssh-add añade a los programas

de inicio.

Sesión de GNOME con ssh-add programa configurado para ejecutarse y le pedirá su clave para la contraseña de

Desvío de sesiones de X11

Una característica menos conocida de X Windows es su transparencia de la

red. Se diseñó para ser capaz de transmitir la información de ventana y de mapa

de bits sobre una conexión de red. Así que, esencialmente, puede acceder a una

máquina de escritorio remoto y ejecutar un programa de ventanas X, como

Gnumeric, Gimp o incluso Firefox y el programa se ejecutará en el equipo

remoto, pero mostrará su producción gráfica en su computadora local.

Para probar esto, usted necesitará una cuenta en un equipo remoto que tiene la

instalación de ventanas X con algunas aplicaciones X Windows. suso.org

servidores no tienen ningún tipo de programas por lo que tendrá que o bien

acceder a uno de sus otras estaciones de trabajo u otro servidor que tiene

ellos. La clave para hacer que el trabajo está utilizando la opción-X, lo que

significa "adelante la conexión X a través de la conexión SSH". Esta es una forma

de túnel.

ssh-X username@desktopmachine.domain.com

Si esto no funciona, puede que tenga que configurar el demonio SSH en el

equipo remoto para permitir X11Forwarding, compruebe que las siguientes líneas

se establecen en / etc / ssh / sshd_config en ese equipo:

X11Forwarding sí X11DisplayOffset 10 X11UseLocalhost sí

Para algunos programas nuevos y nuevas versiones de X Windows, es posible

que necesite usar el Y-opción en lugar de confianza para el reenvío de X11. Trate

de usar esta opción si su programa de ventanas X11 no empezar a correr con un

mensaje como éste, que era para Gimp:

El programa 'gimp-2.2' recibió una X Window System error. Esto

probablemente refleja un error en el programa. El error fue

'BadWindow (parámetro de la ventana no válido) ". (Detalles: 154

serie 3 error_code request_code 38 minor_code 0) (Nota para los

programadores:. Normalmente, los errores de X se presentan de forma

asíncrona, es decir, usted recibirá el error después de un tiempo

haciendo que para depurar el programa, se ejecuta con la - comando

sync opción de la línea para cambiar este comportamiento. A

continuación, puede obtener una traza significativa de su depurador

si se rompe en el gdk_x_error () función.)

TCP Port Forwarding

Al igual que el reenvío de sesión X11, SSH también puede reenviar los otros

puertos TCP a nivel de aplicación, tanto hacia adelante y hacia atrás a través de

la sesión de SSH que usted establezca.

Por ejemplo, puede configurar un puerto de interés para la conexión de la

máquina de casa de arvo.suso.org para que se llevará a conexiones a localhost

puerto 3306 y las remitirá a la mysql.suso.org lado remoto puerto 3306. Puerto

3306 es el puerto que el servidor MySQL escucha en, por lo que le permitiría

pasar por alto los controles normales del huésped que el servidor MySQL se

hacen y permite llevar a cabo programas de interfaz gráfica de usuario de MySQL

en el equipo local durante el uso de la base de datos en su cuenta de Suso. Este

es el comando para lograr esto:

ssh-L 3306: mysql.suso.org: 3306 username@arvo.suso.org

La L-(lo que significa que el puerto local) toma un argumento de

<local-port>: <connect-to-host>: <connect-to-port>

por lo que se especifique lo host y el puerto de la conexión se vaya a en el otro

lado de la conexión SSH. Cuando usted hace una conexión con el puerto <local-

port>, envía los datos a través de la conexión SSH y luego se conecta a

<connect-to-host>: <connect-to-port> en el otro lado. Desde el punto de vista

de la <connect-to-host>, es como si la conexión fue desde el servidor de SSH

que te conectes a. En el caso anterior, arvo.suso.org.

Esto es muy similar a una conexión VPN le permite actuar como si están

haciendo las conexiones de la red remota que en VPN.

Tómese un momento para pensar en otras conexiones útiles que usted puede

hacer con este tipo de túneles de la red.

Otra utilidad es para cuando estás fuera de casa y no puede enviar correo a

través del servidor de correo ISP de su casa, ya que sólo permite conexiones

locales para bloquear el spam. Usted puede crear un túnel SSH a un servidor

SSH que es local a su ISP y luego hacer que su cliente de correo como

Thunderbird interfaz gráfica de usuario establecer una conexión al servidor local

puerto 8025 para enviar el correo. Este es el comando para crear el túnel:

ssh-L 8025: smtp.homeisp.net: 25 username@shell.homeisp.net

Una cosa a notar es que los usuarios no root normalmente no tienen la

capacidad de escuchar en los puertos de red inferiores a 1024, por lo que

escucha en el puerto 25 no iba a funcionar, por lo tanto usamos

8025. Realmente no importa, puede utilizar cualquier puerto, siempre y cuando

el cliente de correo electrónico puede conectarse a él.

También puede invertir la dirección y crear un puerto de atrás hacia

adelante. Esto puede ser útil si desea conectarse a una máquina remota para

permitir las conexiones con Facebook, por ejemplo, yo uso esto a veces de modo

que pueda crear un puerto de reversa 22 (SSH) del túnel para que yo pueda

volver a conectar a través de SSH a una máquina que está detrás de un firewall,

una vez me he ido de esa red.

ssh-R 8022: localhost: 22 username@my.home.ip.address

Este se conectará a mi máquina de casa y empezar a escuchar en el puerto 8022

no. Una vez que llego a casa, entonces se puede conectar a la máquina que ha

creado la conexión de usar el siguiente comando:

ssh-p 8022 usuario @ localhost

Recuerde que debe utilizar el nombre de usuario correcto para la máquina que

inició el túnel. Puede ser confuso. También hay que tener en cuenta que desde

que se conecta con el host llama localhost, pero es realmente un puerto va a

otro servidor SSH, puede terminar con una clave de host diferente para localhost

la próxima vez que se conecte a localhost. En ese caso, tendría que editar su

fichero .ssh / known_hosts para eliminar la línea de localhost. Usted realmente

debe saber más sobre SSH antes de hacer esto a ciegas.

Como ejercicio final, usted puede mantener su puerto de atrás hacia delante

abierto todo el tiempo al iniciar la conexión con este circuito:

Si bien es cierto, hacer ssh-R 8022: localhost: 22

suso@my.home.ip.address; sleep 60; hacer

De esta manera, si le toca reiniciar el equipo en casa, el túnel inverso intentará

volver a conectarse después de 60 segundos. Siempre tienes las claves de

instalación y de su agente ssh-en la máquina remota. ;-)

Proxy SOCKS5

Así que eso es grande y todo, pero a la larga usted va a querer saber cómo se

puede hacer un túnel sin tener que especificar la dirección que desea que

transmita al.

Esto se logra a través de la D-SOCKS5 opción.

ssh-D 9999 username@remotehost.net

Cualquier aplicación que soporte el protocolo SOCKS5 (y la mayoría de los

grandes programas de la red lo hacen) puede enviar su conexión de red a través

de SSH y dinámicamente hacia delante a cualquier host que usted

especifique. Así que para un navegador web, cualquier URL que se escribe en el

campo de URL, se envía a través del túnel SSH. Firefox, Xchat, Gaim y muchos

otros con todo el apoyo SOCKS5. El escenario es por lo general bajo en las

preferencias de los ajustes de conexión.

Recuerde que, en palabras de Benjamín "Tío Ben" Parker, con gran poder

conlleva una gran responsabilidad. Sólo porque usted puede conseguir alrededor

de los firewalls y utilizar otras máquinas para el envío de tráfico de la red, no

quiere decir que algún administrador del sistema no se va a notar.

Comandos que se ejecutan a través de SSH

A veces, usted realmente no desea ejecutar un shell como bash en el cual se

está conectando. Tal vez lo que desea es ejecutar un comando y la salida. Esto

es muy simple lleva a cabo poniendo el comando que desea ejecutar al final de

su comando de conexión ssh.

ssh username@remotehost.net ls-l /

Esto probablemente generará una salida similar a la siguiente.

total de 220 drwxr-xr-x 2 root root 4096 09 de noviembre 04:08 bin

drwxr-xr-x 3 root root 4096 11 de noviembre de inicio 09:29 drwxr-

xr-x 23 root root 122880 14 de noviembre 02:36 dev drwxr-xr -x 68

root root 12288 10 de enero 04:03 etc drwxr-xr-x 189 root root 4096

09 de enero en casa doce y cuarenta drwxr-xr-x 2 root root 4096 12

de marzo 2004 initrd drwxr-xr-x 9 root root 4096 noviembre 9 04:07

lib drwx ------ 2 root root 16384 26 de septiembre 2004 lost + found

drwxr-xr-x 2 root root 4096 14 de abril 2004 misc drwxr-xr-x 6 root

root 4096 12 de noviembre 02:11 mnt drwxr-xr-x 3 root root 4096 15

de octubre 22:17 opt dr-xr-xr-x 307 root root 0 14 de noviembre

02:36 proc drwx ------ 44 root root 8192 09 de enero 16:23 drwxr

raíz -xr-x 2 root root 8192 09 de noviembre 04:08 sbin drwxr-xr-x 2

root root 4096 12 de marzo 2004 selinux drwxr-xr-x 9 root root 0 14

de noviembre 02:36 sistemas drwxrwxrwt 20 root root 4096 10 de enero

06 : 46 tmp drwxr-xr-x 17 root root 4096 07 de diciembre 2004 usr

drwxr-xr-x 26 root root 4096 10 de enero 2005 var

A continuación, puede procesar la salida lo que le apetezca con las convenciones

de shell normales.

También se puede hacer algo que se llama obligados al mando en el que la

fuerza cualquier intento de inicio de sesión para ejecutar un comando específico,

independientemente de lo que se especifica en la línea de comandos por parte

del cliente.

Para ello, se pone esta variable y el comando que desea a la fuerza en el archivo

authorized_keys en la máquina remota:

command = "/ usr / bin / backup" ssh-rsa

AAAAB3NzaC1yc2EAAAABIwAAAIEAvna .....

Poner la variable antes del inicio de la línea para la llave. Hay otras variables que

se pueden utilizar aquí como de = "" para permitir que sólo desde un host

específico. Estas variables se pueden poner juntos separados por comas.

(Este espacio se ha dejado intencionadamente en blanco)

Uso de SCP

SCP es básicamente un programa que utiliza el protocolo SSH para enviar

archivos entre máquinas a través de y conexión cifrada. Usted puede transferir

archivos desde el equipo local a un host remoto, o viceversa, o incluso desde un

host remoto a otro host remoto.

Aquí hay un comando básico que copia un archivo llamado informe.doc desde el

equipo local a un archivo con el mismo nombre en el equipo remoto.

scp informe.doc username@remote.host.net:

Tenga en cuenta que la falta de un nombre de archivo de destino sólo conserva

el nombre original del archivo. Este es también el caso si el destino remoto

incluye la ruta a un directorio en el host remoto.

Para copiar el archivo desde el servidor, que acaba de invertir la de ya.

scp username@remote.host.net: informe.doc informe.doc

Si desea especificar un nuevo nombre para el archivo en el equipo remoto, sólo

tiene que dar el nombre a los dos puntos en el lado de.

scp informe.doc username@remote.host.net: monday.doc

O si desea copiar a un directorio relativo al directorio home del usuario remoto

especificado.

scp informe.doc username@remote.host.net: informes / monday.doc

También puede utilizar fullpaths que están precedidos con un /.

Para copiar un directorio entero de forma recursiva a un lugar remoto, utilice la

opción-r. El siguiente comando copia un directorio con el nombre de correo en el

directorio home del usuario en el equipo remoto.

scp-r username@remote.host.net electrónico:

A veces se desea conservar las marcas de tiempo de los archivos y directorios y,

si es posible, los usuarios, grupos y permisos. Para ello, utilice la opción-p.

scp-rp username@remote.host.net electrónico:

Manteniendo su período de sesiones SSH Alive

A veces usted puede tener problemas para mantener su sesión de SSH y de

reposo. Por alguna razón, la conexión que acaba de morir después de X minutos

de inactividad. Por lo general, esto sucede porque hay un cortafuegos entre

usted y el Internet que está configurado para mantener sólo las conexiones con

estado en su memoria durante 15 minutos más o menos.

Afortunadamente, en las últimas versiones de OpenSSH, no hay una solución

para este problema. En pocas palabras lo siguiente:

Host * Protocolo n º 2 TCPKeepAlive sí ServerAliveInterval 60

en el archivo

~ / .ssh / Config

El archivo anteriormente puede ser utilizado para cualquier lado de configuración

del cliente SSH. Vea la página man ssh_config para más detalles. El

'TCPKeepAlive sí "directiva le dice el cliente ssh que debe enviar un poco de

datos a través de la conexión periódicamente para permitir que el servidor sepa

que todavía está allí. 'ServerAliveInterval 60' establece este período de tiempo

de estos mensajes de 60 segundos. Este truco muchos cortafuegos que de otro

modo perder la conexión, para mantener su conexión va.

Finalización de la sesión SSH

Todas las cosas buenas llegan a su fin. Y hay muchas formas más comunes para

poner fin a la sesión de SSH.

salir de

cierre de sesión

(Ctrl-D)

La última es en realidad el usuario presionando la tecla 'Ctrl' y 'd' de la carta, al

mismo tiempo. Todas éstas son formas de terminar la sesión SSH desde el lado

del servidor. Por lo general, salir de la cáscara, que a su vez se cierra la sesión

en la máquina.

Lo que no saben, es que no hay otra manera de cerrar una sesión SSH. Esto es

útil si se pierde la conectividad con la máquina y que no hay manera de poner fin

a la sesión de la shell. Por ejemplo, esto sucede por un momento si usted

permanece conectado a un equipo cuando éste está apagado. SSH tiene sus

propios comandos de secuencias de escape de la línea. Estos pueden ser

utilizados para poner fin a las conexiones, crear nuevas delante del puerto o una

lista de los actuales y algunas otras funciones. Para finalizar una conexión,

incluso cuando usted no tiene un símbolo del sistema, el tipo de volver dos veces

(por si acaso) y luego '~'. La secuencia. Eso es una tilde seguida de un período.

(RETURN) (RETURN) ~.

Esto terminará la conexión SSH desde el cliente final en vez del lado del servidor.

Feliz SSH'ing!

Referencias externas

Estos son algunos enlaces donde se puede encontrar más información sobre SSH

Notas de Mark presentación de la reunión de enero 2006 BLUG

OpenSSH Web

Las preguntas más frecuentes de SSH

El artículo Secure Shell en Wikipedia

El viejo no la versión wiki de este tutorial (Actualizado 08/04/2007)

La versión muy anterior de este tutorial (21/02/1999)

Vinculada a la página principal de digg.com (03/03/2006) (823 votos en!)

Créditos

El documento original, gráficos y ejemplos de Mark Krenz (mark@suso.org)

Gracias a las siguientes personas para el envío de correcciones:

o Zake Stahl (varias correcciones)

o Christopher Mylonas (darse cuenta de que MySQL debería ser 3306, no

3066)

o Tehiri Tehiri (lo que sugiere una aclaración en la sección de nombre de

usuario y contraseña)

o Behrang Saeedzadeh (Al darse cuenta de contacto error tipográfico)

o Pratik Mallya (lo que sugiere que menciono ssh-copy-id)

o Otras personas que aparece en la página de la historia de este documento.