HTTP

Hypertext Transfer Protocol o HTTP (protocolo de transferencia de hipertexto) es el protocolo usado en cada transmisión de lared. El HTTP fue desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force, colaboración que culminó en 1999 con la publicación de una serie de RFC, el más importante de ellos es el RFC 2616 que especifica la versión 1.1. HTTP define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador web o un spider) se lo conoce como "user agent" (agente del usuario). A la información transmitida se la llama recurso y se la identifica mediante un localizador uniforme de recursos (URL). Los recursos pueden ser archivos, el resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un documento, etc.
HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de "sesión", y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

Primeros Servidores

• CERN httpd Server
• NCSA httpd server
• Compuserve httpd server

Métodos de Petición

HTTP define 8 métodos (algunas veces referido como "verbos") que indica la acción que desea que se efectúe sobre el recurso identificado. Lo que este recurso representa, si los datos pre-existentes o datos que se generan de forma dinámica, depende de la aplicación del servidor. A menudo, el recurso corresponde a un archivo o la salida de un ejecutable que residen en el servidor.

HEAD

Pide una respuesta idéntica a la que correspondería a una petición GET, pero sin el cuerpo de la respuesta. Esto es útil para la recuperación de meta-información escrita en los encabezados de respuesta, sin tener que transportar todo el contenido.

GET

Pide una representación del recurso especificado. Por seguridad no debería ser usado por aplicaciones que causen efectos ya que transmite información a través de la URI agregando parámetros a la URL.

Ejemplo:

GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png

Ejemplo con parámetros:

/index.php?page=main&lang=es

POST

Somete los datos a que sean procesados para el recurso identificado. Los datos se incluirán en el cuerpo de la petición. Esto puede resultar en la creación de un nuevo recurso o de las actualizaciones de los recursos existentes o ambas cosas.

PUT

Sube, carga o realiza un upload de un recurso especificado (archivo), es el camino más eficiente para subir archivos a un servidor, esto es porque en POST utiliza un mensaje multiparte y el mensaje es decodificado por el servidor. En contraste, el método PUT te permite escribir un archivo en una conexión socket establecida con el servidor.

La desventaja del método PUT es que los servidores de hosting compartido no lo tienen habilitado.

Ejemplo:

PUT /path/filename.html HTTP/1.1

DELETE

Borra el recurso especificado.

TRACE

Este método solicita al servidor que envíe de vuelta en un mensaje de respuesta, en la sección del cuerpo de entidad, toda la data que reciba del mensaje de solicitud. Se utiliza con fines de comprobación y diagnostico.

OPTIONS

Devuelve los métodos HTTP que el servidor soporta para un URL especifico.Esto puede ser utilizado para comprobar la funcionalidad de un servidor web mediante peticion en lugar de un recurso especifico

CONNECT

Códigos de respuesta

Son códigos de tres dígitos:

• 1xx Mensajes

N°	Descripción
100	111	Conexión rechazada

• 2xx Operación exitosa

N°	Descripción
200	OK
201-203	Información no oficial
204	Sin Contenido
205	Contenido para recargar
206	Contenido parcial

• 3xx Redireción

N°	Descripción
301	Mudado permanentemente
302	Encontrado
303	Vea otros
304	No modificado
305	Utilice un proxy
307	Redirección temporal

• 4xx Error por parte del cliente

N°	Descripción
400	Solicitud incorrecta
402	Pago requerido
403	Prohibido
404	No encontrado
409	Conflicto
410	Ya no disponible
412	Falló precondición

• 5xx Error del servidor

N°	Descripción
500	Error interno
501	No implementado
502	Pasarela incorrecta
503	Servicio nodisponible
504	Tiempo de espera de la pasarela agotado
505	Versión de HTTP no soportada

TÚNELES SSH

Ssh nos ofrece entre otras cosas una consola remota segura, ftp seguro, X forwarding y lo que hoy vamos a ver, túneles a través del protocolo ssh. Básicamente hay dos tipos, túnel en modo listen y en modo remote; empezaré por el primero, que es el que más comúnmente suelo usar.

Imaginemos que estamos por ejemplo en un aula de ordenadores en una biblioteca o en la universidad. Queremos conectar a nuestro emule en el puerto 4080 de nuestro ordenador sobremesa, para poder ver como van esas descargas o bien añadir algo que nos han recomendado para bajar, por poner un ejemplo. Pero claro sólo tenemos el router configurado para que funcione con los puertos de emule y el ssh hacia un ordenador cualquiera de nuestra red. Suponemos que el servicio ssh está corriendo en la misma máquina que el emule, que esta máquina se llama en la red molongo y que tiene la ip 192.168.1.110, ssh está en esta máquina en el puerto 22, sin embargo el router redirecciona el puerto 4422 al 22 de esa máquina.
Según esto, si queremos hacer sesión ssh tendríamos que ejecutar el comando ssh -p 4422 usuario@nombre_de_maquina_en_internet así conectaríamos haciendo sesión ssh al puerto 22 del ordenador de sobremesa. Pero realmente lo que queremos es tener acceso al puerto 4080, donde podemos conectar a la interfaz web de emule. Recordemos que no tenemos acceso desde internet a ese puerto, pues no tenemos las reglas de redireccionamiento activadas en el firewall de nuestro router, así que haremos un túnel del puerto 4080 del sobremesa molongo al puerto 8888 del ordenador desde el que estamos accedidendo.
El comando sería: ssh -p 4422 -L 8888:localhost:4080 usuario@nombre_de_maquina_en_internet
Con este comando conseguimos una sesión ssh, pero además el túnel, ahora si abrimos el navegador web y ponemos la dirección http://localhost:8888 veremos lo mismo que si ponemos http://localhost:4080 en molongo.
Ahora veamos cómo se sabe qué es cada opción, -p es para decir qué puerto usamos para la sesión ssh, por defecto es 22, pero en nuestro router hemos abierto el 4422 direccinoado al 22 de molongo. -L es para hacer un túnel en modo listen y se especifica puerto_local:maquina_remota:puerto_remoto, debemos tener en cuenta que puerto_local es el puerto al que queremos llevar el puerto_remoto mediante el túnel y que maquina_remota es el nombre o ip de la máquina visto siempre desde la máquina en la cual está ejecutando el sshd al que estamos conectando. En el ejemplo anterior también funcionaría si pusiéramos molongo o 192.168.10.110 en lugar de localhost.
Si quisiéramos conectar a otra máquina de la red, en lugar de al sobremesa, por ejemplo a un servidor web que tengamos para acceder sólo desde nuestra red local, bastaría con substuir localhost por la ip o el nombre de esa máquina y también el puerto por el que queremos acceder, por ejemplo quedaría -L 8888:servidorweb:80.
Por otro lado tenemos el túnel en modo remoto, que es algo más extraño. Imaginemos que lo que queremos es acceder al servidor web para administrarlo, usando para ello una sesión ssh, este servidor no tiene acceso desde internet, pues está detrás de un firewall y no diponemos de puertos que redireccionen a él. En este caso el comando lo ejecutamos en el servidor web, de manera que lo que hacemos en este caso es decirle que haga un túnel para llevar el puerto 22 local al puerto 5522 de un equipo que sea accesible desde internet. ssh -p 4422 -R 5522:localhost:22 usuario@nombre_de_maquina_en_internet.
La opción -N es para que no ejecute ningún comando remoto, y la opción -f para que pase a segundo plano.

FREENX

NX es una tecnología para manejar conexiones remotas a X Window de forma suficientemente rápida incluso sobre un módem de 56K. Para ello utiliza compresión de datos y mecanismos de caché, que le proporcionan un rendimiento netamente superior al de otras soluciones de este tipo como VNC. También emplea SSH para cifrar la conexión entre servidor y cliente. Además de permitir a los usuarios loguearse en una máquina remota accediendo al escritorio, permite también suspender y recuperar sesiones. NX es un producto de la empresa NoMachine, que dispone de licencia GPL sobre la propia tecnología NX, existiendo múltiples implementaciones, tanto comerciales como gratuitas, y tanto libres como propietarias, de servidores y clientes. Es necesario destacar que la mayoría de la información disponible en la Red sobre NX, tanto en español como en inglés, está en general totalmente desfasada, lo que obliga a una importante labor de rastreo a fin de localizar un repositorio adecuado de los paquetes necesarios en Debian. Por idéntica razón, es de prever que este mismo tutorial pierda vigencia sin tardar, pero ahora mismo permite instalar el servidor FreeNX en una máquina Debian (Lenny) de una forma absolutamente simple. Después, instalaremos el software cliente de NoMachine en una máquina remota con Windows XP SP2 a fin de acceder al escritorio de Debian...
Diferenciaremos por tanto la instalación en el lado servidor y en el lado cliente.

SERVIDOR

1. Instalación

Instalaremos el servidor FreeNX en una máquina corriendo Debian (Lenny), aunque creo poder afirmar que funcionaría exactamente igual en Debian Etch. De hecho los paquetes que utilizaremos están diseñados para Etch, representando este tutorial la primera y única confirmación que yo haya podido encontrar de que también funcionan perfectamente en Lenny.
El punto fundamental radica en añadir la siguiente línea a /etc/apt/sources.list:

deb http://krnl.nl/freenx/ ./

Operación que seguiremos del imprescindible:

# apt-get update

Los repositorios de FreeNX se muestran especialmente volátiles y desactualizados, por lo que es posible que éste tampoco dure demasiado.
La instalación y puesta en marcha de SSH representa el principal requisito previo. Por tanto, si no está instalado, es el momento de escribir:

# apt-get install ssh

Y, por supuesto también:

# apt-get install freenx

A mitad de esta instalación nos saltará la siguiente pantalla:

A los efectos de este tutorial seleccionaremos "NoMachine key", por ser la opción recomendada para facilitar la configuración, aunque para entornos de producción donde la seguridad es importante resulta mucho más recomendable utilizar "Custom Keys" (que nos obliga a copiar las claves a la máquina cliente), o al menos cambiar el puerto de escucha por defecto de SSH e incluso impedir el acceso remoto a root, es decir, las medidas habituales de protección frente a los ataques habituales contra este servicio.

2. Configuración

Una vez completada la instalación, podemos comprobar que el servidor está en efecto funcionando:

# nxserver --status 

NX> 100 NXSERVER - Version 1.5.0-60 OS (GPL)
NX> 110 NX Server is running 

NX> 999 Bye

CLIENTE

1. Instalación

Descargamos NX Client for Windows y procedemos a su instalación:
http://www.nomachine.com/download.php

2. Configuración

FUNCIONAMIENTO

Arrancamos NX Client y se nos solicita el nombre de usuario y password que configuramos antes, al crear nuestra sesión "debian":

Ya estamos dentro de Ubuntu, desde nuestra máquina remota con Windows XP, pudiendo trabajar exactamente igual que si estuviéramos sentados ante la máquina.

SERVIDOR SSH EN UBUNTU

Instalación

Vamos a usar OpenSSH por tanto vamos a instalarlo:

sudo apt-get install openssh-server

Ahora procedemos a su configuración.

Comandos que debemos tener en cuenta

Para editar la configuración del servidor SSH debemos hacer en consola:

sudo gedit /etc/ssh/sshd_config

Para arrancar el servidor:

sudo /etc/init.d/ssh start

* Starting OpenBSD Secure Shell server sshd
Para parar el servidor:

sudo /etc/init.d/ssh stop

* Stopping OpenBSD Secure Shell server sshd
Para reiniciar el servidor:

sudo /etc/init.d/ssh restart

* Restarting OpenBSD Secure Shell server sshd

Configuración del servidor

Una vez instalado, vamos a configurar el servidor, hacemos en consola:

sudo gedit /etc/ssh/sshd_config

Y podremos editar sus opciones:

# Package generated configuration file
# See the sshd_config(5) manpage for details
# Ponemos el puerto a escuchar por el SSH, por defecto es el 22. Deberemos abrir un puerto en nuestro router redirigiendo hacia la IP interna de la máquina donde lo tengamos.
Port 1234
# Usaremos el protocolo 2 de SSH, mucho más seguro, por tanto forzamos a que siempre conecten por protocolo 2.
Protocol 2
# HostKeys for protocol version 2. El lugar donde se guardan las keys.
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 2048
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication, importante la parte PermitRootLogin
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile    %h/.ssh/authorized_keys
# 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
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don’t trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
MaxAuthTries 2

Opciones adicionales de Seguridad

Podemos conectarnos al servidor sin usuario clave, utilizando un certificado RSA que proporcionará mucha más seguridad, pero como siempre que sucede en estos casos…es más incómodo y no siempre vas a llevar encima tu certificado...

Para ver los LOGS de conexión:

cd /var/log/
gedit auth.log

COMANDOS SSH

Comandos SSH Shell frecuentes

Este es un listado de los comandos SSH que se usan con más frecuencia. Los comandos se encuentran organizados por tema e incluyen una descripción breve para comprender como usarlos.

Comandos de navegación

pwd muestra el path completo del directorio en el que se encuentra

cd cambia de directorio, por ejemplo cd directorio/subdirectorio

cd ~ lleva a su directorio home

cd - lleva al último directorio en el que estuvo

cd .. sube a un directorio superior

Listado de archivos

ls lista archivos y directorios de un directorio

ls -al lista archivos y directorios e información sobre los mismos

ls -aR lista archivos e información incluyendo todos los subdirectorios

ls -aR | more lista archivos e información incluyendo todos los subdirectorios por pantallas

ls -alR > resultado.txt lista archivos e información de subdirectorios y lo guarda en un archivo

cat resultado.txt mostraría en pantalla el contenido del archivo

ls *.html lista todos los archivos acabados en .html

ls -al directorio/subdirectorio/ lista archivos e información de ese subdirectorio

Crear, editar o eliminar archivos y directorios

pico /home/usuario/public_html/index.html edita el archivo index.html con el editor pico

touch /home/usuario/public_html/404.html crea el archivo vacio 404.html en ese directorio

rm archivo.txt elimina archivo.txt

rm -rf directorio/ ¡CUIDADO! elimina el directorio indicado, los subdirectorios y todos sus archivos

mkdir descargas Crea un directorio llamado descargas

rmdir descargas Elimina el directorio llamado descargas

Compresión y descompresión de archivos

zip archivo.zip /home/usuario/public_html/directorio Comprimir directorio

unzip archivo.zip Descomprimir archivo.zip

unzip -v archivo.zip Ver contenido de archivo.zip

Otros comandos SSH

cp -a /home/usuario/public_html/origen/* /home/usuario/public_html/destino/

Copia todos los archivos de un directorio a otro manteniendo sus respectivos permisos

du -sh muestra es espacio total ocupado por el directorio en el que se encuentra

du -sh * muestra el espacio ocupado de cada archivo y directorio

lynx aemilius.net usar el navegador Lynx para acceder a www.aemilius.net

whoami muestra su nombre de usuario

PUTTY

Configurar un acceso y conectar a un servidor SSH con PuTTY

Para ejecutar PuTTY no es necesario instalarlo, se ejecuta directamente. También se puede crear un acceso directo al escritorio para futuras conexiones.
1. Ejecutamos PuTTY
2. En el menú de configuración seleccionamos la categoría Session
3. Introducimos el nombre del dominio o IP en el campo Host Name y seleccionamos el protocolo SSH
4. Introducimos un nombre para esta conexión en el campo Saved Sessions
5. Volvemos al menú de configuración y seleccionamos la categoría SSH
6. Hay que asegurarse de que está marcada la opción 2 en Preferred SSH protocol version

7. Seleccionamos nuevamente la categoría Session
8. Para guardar la configuración pulsamos Save y Open para conectar

Iniciar una sesión SSH usando  nombre de usuario y contraseña

Al iniciar la conexión, se abrirá la ventana del terminal. Introducimos el  nombre de usuario y pulsamos Intro, después, introducimos la contraseña y pulsamos Intro. Si el nombre de usuario y password son correctos podremos iniciar la sesión SSH.

Cuando se realiza una conexión SSH por primera vez, el servidor entrega al cliente de SSH la clave pública del servidor. PuTTY nos alertará de ello y  ofrecerá la opción de aceptar la clave o rechazarla.
Si aceptamos la clave, se almacenará en el registro y se utilizará para compararla con la que el servidor envíe en cada conexión. Si por algún motivo la clave cambia, PuTTY generará un nuevo aviso en el que se planteará la autenticidad de la clave recibida, ya que alguien podría estar haciéndose pasar por el servidor al que nos queremos conectar.

Trabajando con PuTTY, funciones principales

PuTTY es muy sencillo de utilizar, la mayor o menor complejidad a la hora de usarlo depende principalmente de los conocimientos que tengamos con los comandos SSH desde el terminal
.
El menú de sistema permite acceder a opciones bastante interesantes mientras se trabaja. Para mostrar el menú de sistema, haremos clic con el botón derecho sobre la barra de titulo de la ventana del terminal.

Duplicate Session abre una nueva ventana de terminal basada en la conexión actual.
Saved Sessions permite iniciar una nueva sesión basada en una conexión guardada con anterioridad.  
Copy All to Clipboard copia en el portapapeles de Windows todo el texto impreso en la ventana del terminal.


PuTTY permite copiar y pegar texto entre entre la ventana del términal y el portapapeles de Windows.

Selección del algoritmo de encriptación

PuTTY soporta una gran variedad de algoritmos de encriptación. Podemos definir el orden seleccionando el tipo de difrado en la sección Encryption options de la categoría SSH y haciendo clic sobre los botones Up y Down para indicar cual de ellos prefiere utilizar si el servidor al que estamos conectandso nos ofrece esa posibilidad.
Actualmente PuTTY soporta los siguientes algoritmos:

• AES (Rijndael) - 256, 192, or 128-bit CBC (solo para SSH-2)
• Blowfish - 128-bit CBC
• Triple-DES - 168-bit CBC
• Single-DES - 56-bit CBC

Para cerrar una sesión, no hay que cerrar PuTTY como cualquier otra aplicación(vamos, pinchando en la X de la esquina..).Mejor escribimos "Exit" y pulsamos intro.

ALGUNAS COSILLAS CON SSH

Utilización básica del cliente

Utilizar el cliente es muy sencillo; nos basta con utilizar la orden:

$ ssh -l user@<maquina>

donde <maquina>  peude ser un nombre de host o bien una dirección IP.
La opción -l nos permite indicar el usuario con el que queremos loguearnos en la máquina remota.
Una vez conectado será como si estuviéramos físicamente en la máquina ya que tendremos un terminal qeu nos ofrecerá todo lo que pudiera tener el usuario como el que hemos entrado.

Subir y bajar ficheros

Para enviar y recibir ficheros usulizando ssh, tenemos varias opciones, como scp (Secure CoPy) o sftp (Secure FTP). Aquí veremos el uso de scp, ya que sftp tiene los mismos comandos que el protocolo ftp normal.

Sintaxis de scp

La sintaxis básica es la siguiente:

scp <origen> <destino>

donde <origen> y <destino>pueden ser un nombre de fichero, un directorio o un nombre de host (o ip) y nu directorio. Veamos algun ejemplo para ver como especificamos el nombre de host remoto:
Para subir cosas de un pc a un host remoto la sintaxis seria:

scp fichero1 <usuario>@<maquina>:<directorio>

donde <usuario> es el usuario remoto, <maquina> el nombre de host o ip de la maquina remota, y <directorio> el directorio remoto donde queremos subirlo. Por ejemplo:

$ scp fichero1 nacx@172.16.0.2:/home/nacx/

Para bajar cosas de un host remoto a un PC la sintaxis seria:

scp <usuario>@<maquina>:<directorio>/<fichero> <directorio_local>

Así, por ejemplo, para descargar un fichero remoto al directorio local donde nos encontremos, haríamos algo asi:

scp nacx@172.16.0.2:/home/nacx/fichero1 ./

Resumiendo ficheros mediante rsync

Hay veces en que no podemos terminar de bajar por completo un archivo grande entonces lo que hay que hacer es conectarnos via rsync, con la siguiente sintaxis:

$ rsync -ve ssh -avz <usuario>@<maquina>:<direcotio>/<fichero> <directorio_local>

nos conectamos via rsync, ssh a la máquina remota y descargamos el fichero.
El fichero debe descargarse al directorio donde quedó incompleto para que pueda resumirse; si por alguna razon cancelamos la transferencia, se perdera lo que llevamos resumido. Antes de cerrar el la transferencia tenemos que hacer una copia: siempre que se esta resumiendo aparece como .fichero.bla, donde bla son caracteres raros:

$ cp .fichero.bla fichero.back

Una vez copiado, cancelamos el la transferencia; el .fichero.bla desaparecerá instantáneamete y nos quedara:

fichero fichero.back

fichero es el que descargamos con ssh pero incompleto, y fichero.back es el fichero incompleto mas los bytes que bajamos mientras resumía, asi que borramos fichero y solo nos quedaremos con fichero.back:

$ mv fichero.back fichero

Renombramos el fichero para que se pueda resumir con el mismo nombre que el fichero original.