Git seguro y acceso SSH

Antes de empezar: retoma tu puesto de trabajo

En P00/02 creaste el árbol de /optativa-nube/p00-puesto-nube. Ahora lo convertirás en un proyecto que conserva una historia de sus cambios. Durante el curso contendrá la web de prueba, scripts y evidencias, pero nunca secretos.

Si no lo tienes, crea la siguiente estructura de ficheros y directorios:

/optativa-nube/p00-puesto-nube/
├── README.md             # qué es el proyecto y cómo comprobarlo
├── notas/                # ficheros de las prácticas de shell
├── scripts/              # automatizaciones pequeñas
├── web/                  # web estática de prácticas posteriores
└── evidencias/           # notas y comprobaciones realizadas

Los comandos de esta página se ejecutan dentro del contenedor p00-lab. Desde la terminal del anfitrión, entra en él:

docker start -ai p00-lab
su - alumno

docker start abre la shell inicial del contenedor como root; su - alumno inicia la sesión de trabajo sin privilegios creada en P00/01. -a conecta la salida a tu terminal e -i mantiene abierta la entrada para que puedas escribir.

Punto de partida: ya ves el prompt que termina en $. Comprueba dónde trabajas, qué usuario eres y que Git forma parte de la imagen del curso:

pwd
whoami
git --version

pwd debe mostrar /home/alumno; entrarás en /optativa-nube antes de trabajar con el repositorio.
whoami debe mostrar alumno.
git --version muestra la versión instalada durante P00/01; no hace falta instalarlo de nuevo en cada sesión mientras conserves p00-lab.

Si alguno de esos resultados no coincide, no inicialices ningún repositorio. Comprueba que has iniciado p00-lab y que has ejecutado su - alumno. Git se instaló en el contenedor durante P00/01; no se ha creado ninguna imagen propia ni se ha usado docker commit.

Todo lo que versionarás se guarda en /optativa-nube, la carpeta compartida con el anfitrión. Las claves SSH se guardarán fuera de ella, en /home/alumno/.ssh. Así no entran por error en el repositorio.

Git: decidir qué historia conserva el proyecto

Git es un sistema de control de versiones distribuido. Te permite comparar cambios, recuperar una versión anterior y explicar qué decisión representa cada cambio. No sustituye una copia de seguridad completa, pero evita depender de archivos llamados final-definitivo-ahora-si.md.

Las tres zonas de Git

Antes de escribir comandos, distingue estas tres zonas:

Zona	Qué contiene	Pregunta que debes hacerte
Directorio de trabajo	Los archivos que editas ahora.	«¿Qué he cambiado?»
Área de preparación (staging)	Solo los cambios que eliges guardar juntos.	«¿Quiero incluir exactamente esto?»
Historial local	Los commits ya confirmados.	«¿Puedo explicar por qué se guardó?»

Flujo seguro de Git: directorio de trabajo, área de preparación e historial

Un commit no es un botón de guardar automático: es una fotografía pequeña y razonada. El recorrido será siempre: observar → elegir → volver a revisar → confirmar.

Crear el repositorio local

Punto de partida: terminaste P00/02 y existe /optativa-nube/p00-puesto-nube. Entra en la carpeta y observa su contenido antes de cambiar nada:

cd /optativa-nube/p00-puesto-nube
pwd
ls

Ahora inicializa Git y consulta su estado:

git init --initial-branch=main
git status

git init crea la carpeta oculta .git, donde Git guarda el historial. No la borres ni la copies a mano.
--initial-branch=main asigna el nombre main a la primera rama.
git status indica la rama, los archivos que Git todavía no sigue y los cambios pendientes. Será tu comando de orientación antes y después de cada operación importante.

Git necesita saber qué autor figura en los commits. Esta configuración es local: solo afecta a este repositorio, no a otros proyectos ni al anfitrión. Sustituye los ejemplos por los valores indicados para la práctica:

git config --local user.name "Nombre Apellido"
git config --local user.email "[email protected]"
git config --local --list

git config guarda una configuración; --local la limita a este proyecto; --list muestra lo guardado. La última orden no publica nada.

Proteger antes de guardar: `.gitignore`

.gitignore indica qué patrones debe ignorar Git antes de preparar un archivo. Con tu editor, crea .gitignore en la raíz del proyecto con este contenido:

# Secretos: nunca se versionan
.env
.env.*
*.pem
*.key

# Archivos generados o temporales
node_modules/
dist/
*.log

Los patrones .env y .env.* cubren configuraciones habituales; *.pem y *.key cubren nombres frecuentes de claves. Esta regla evita un descuido futuro, pero no borra un secreto que ya se haya incluido en un commit.

Comprueba que Git ve .gitignore y el resto de archivos de la práctica:

git status --short

--short muestra una versión abreviada del estado. Los archivos sin seguimiento empiezan con ??. Todavía no estás guardando nada: solo observas.

Primera fotografía: estructura y protección

Con tu editor, revisa que README.md contiene al menos esta información. Si ya contiene otro texto correcto de P00/02, añade lo que falte sin borrar tu trabajo:

# Puesto de nube

Repositorio de prácticas de P00.

## Comprobación

La web se servirá desde la carpeta `web/` en prácticas posteriores.

Prepara los archivos conocidos que forman esta primera decisión y mira exactamente su contenido preparado. No añadas una carpeta cuyo contenido no hayas revisado:

git add README.md .gitignore notas scripts web
git diff --staged
git status --short

git add copia al área de preparación la versión actual de cada ruta indicada. Aquí las rutas proceden del árbol conocido de P00/02; no uses git add ., porque podría añadir un archivo que no has revisado.
git diff --staged muestra la fotografía preparada; léela antes de continuar.
En git status --short, la letra A indica «preparado para añadir».

Si aparece una contraseña, una clave privada o un archivo que no esperabas, no hagas commit. Retíralo del área de preparación sin borrar el archivo de tu carpeta:

git restore --staged nombre-del-archivo
git status --short

git restore --staged deshace únicamente la selección previa de git add. Sustituye nombre-del-archivo por el nombre real que acabas de revisar; no copies esas palabras literalmente.

Cuando la fotografía sea correcta, confírmala y comprueba el resultado:

git commit -m "Crea la estructura inicial y protege secretos"
git status
git log --oneline --decorate -3

git commit -m "mensaje" crea una entrada de historial con una explicación breve.
git log --oneline muestra un commit por línea; --decorate añade nombres de ramas y -3 limita la salida a los tres últimos.

Verificación: git log debe mostrar tu commit en main. Si git status todavía muestra algún ejercicio de P00/02, no lo añadas por rutina: revisa su contenido y decide si pertenece a esta historia o debe permanecer fuera.

Segunda fotografía: una página y una bitácora

Una práctica posterior necesita una página. Con tu editor, crea o completa web/index.html con este ejemplo mínimo:

<!doctype html>
<html lang="es">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Puesto de nube</title>
  </head>
  <body>
    <h1>Mi puesto de nube</h1>
    <p>Esta página se versiona con Git.</p>
  </body>
</html>

Crea también evidencias/bitacora-git.md y escribe la fecha, una conclusión sobre Git y una sobre SSH. Son evidencias de tu proceso, no un lugar para copiar salidas completas ni datos personales.

Antes de seleccionar archivos, compara los cambios con el último commit:

git status
git diff

git diff muestra cambios del directorio de trabajo que aún no has preparado. Decide que la página y la bitácora son una misma mejora, prepáralas, revísalas y confírmalas:

git add web/index.html evidencias/bitacora-git.md
git diff --staged
git commit -m "Añade la página inicial y la bitácora de Git"
git log --oneline --decorate -3

El patrón que repetirás es: editar → git status → git diff → git add selectivo → git diff --staged → git commit. Los mensajes empiezan con un verbo y explican el cambio: «Añade…», «Corrige…», «Documenta…». No uses cambios, prueba o final.

Corregir antes de confirmar

Equivocarse forma parte del proceso; publicar el error sin revisarlo no es inevitable. Practica con un fichero inocuo que no forma parte de la entrega:

touch notas-privadas.txt
git add notas-privadas.txt
git status --short
git restore --staged notas-privadas.txt
git status --short

touch crea el fichero vacío y ya lo conoces de P00/02. Tras git restore --staged, el fichero continúa en tu directorio de trabajo, pero deja de estar preparado. Si no necesitas conservarlo, elimínalo con el gestor de archivos del anfitrión. Si fuera una clase de archivo que nunca debe versionarse, añade un patrón concreto a .gitignore, revisa el cambio y crea un commit que documente esa protección.

Para que ese ejemplo no quede como cambio pendiente, muévelo a .env, que ya está excluido por la regla creada antes:

mv notas-privadas.txt .env
git status --ignored --short

mv cambia la ubicación o el nombre de un fichero. --ignored añade a la salida los archivos excluidos. Por ejemplo:

?? evidencias/desde-contenedor.txt
!! .env

Cada línea de git status --short comienza con dos posiciones. La primera indica el estado del área de preparación y la segunda, el estado de tu carpeta de trabajo. Un espacio significa que no hay cambio en esa posición.

Marca	Significado	Qué haces en esta práctica
`?? archivo`	Git todavía no sigue el archivo.	Revísalo; usa `git add archivo` solo si debe formar parte del repositorio.
`!! archivo`	El archivo coincide con una regla de `.gitignore`.	Déjalo fuera. En el ejemplo, `.env` está correctamente excluido.
`M archivo`	Has modificado un archivo que Git ya sigue, pero todavía no lo has preparado.	Revisa con `git diff` antes de usar `git add`.
`M archivo`	El cambio ya está preparado para el siguiente commit.	Revisa con `git diff --staged`.
`A archivo`	Es un archivo nuevo preparado para añadir.	Comprueba su contenido antes del commit.
`D archivo` o `D archivo`	El archivo se ha borrado, respectivamente, solo en tu carpeta o ya en el área de preparación.	Detente y comprueba que el borrado era intencionado.
`R antiguo -> nuevo`	Has preparado un cambio de nombre.	Comprueba que el nombre nuevo es correcto.
`UU archivo` u otra marca con `U`	Hay un conflicto de fusión sin resolver.	No hagas commit: detente y pide ayuda.

También pueden aparecer C para una copia preparada o T para un cambio de tipo de archivo. No son necesarias en esta práctica. Lo importante es leer las dos posiciones antes de añadir o confirmar cambios: ?? no se sigue todavía, !! se ignora y una letra en cada posición indica qué parte de Git conoce el cambio.

Para renombrar un archivo que ya está versionado, usa git mv; equivale a mover o renombrar el archivo y preparar el cambio a la vez:

git mv evidencias/bitacora-git.md evidencias/bitacora-p00.md
git status
git diff --staged
git commit -m "Renombra la bitácora general de P00"

No ejecutes comandos de recuperación que no entiendas ni copies instrucciones que usen --force para «arreglar» un historial. Ante la duda, detente, ejecuta git status y conserva una evidencia útil antes de pedir ayuda.

Retos de comprobación de Git

Punto de partida: has realizado las dos fotografías y estás en /optativa-nube/p00-puesto-nube. Realiza cada reto en orden. En evidencias/bitacora-p00.md, anota la orden que has usado y una conclusión; no copies secretos ni salidas completas.

Comprueba en qué rama estás y describe qué cambios pendientes hay, si los hubiera. Antes de añadirlos, indica por qué pertenecen o no al repositorio.
Muestra los dos últimos commits en una línea cada uno e identifica qué decisión representa cada uno.
Modifica una frase de README.md; compara el cambio antes de prepararlo y después de prepararlo.
Retira README.md del área de preparación sin perder su cambio y explica qué zona de Git ha cambiado.
Prepara de nuevo README.md, revísalo y crea un commit con un mensaje que explique la mejora.
Crea un fichero vacío llamado .env y comprueba que Git lo ignora. Pista: git status --ignored --short.
Añade al menos un patrón concreto a .gitignore para un fichero temporal que hayas creado durante P00. Revisa y confirma solo esa modificación.

Después de intentar el reto 6, conserva esta idea: --ignored muestra también los archivos excluidos y la salida !! .env confirma que .gitignore funciona. No escribas una credencial real para hacer la prueba.

Compartir solo cuando exista un destino aprobado

Un repositorio local ya sirve para aprender y para entregar una carpeta comprimida si se solicita. Git no exige GitHub ni publicar el proyecto en Internet.

La conexión con un remoto queda fuera del bloque hasta que estén confirmados plataforma, URL y flujo de entrega. No inventes ni reutilices URLs, usuarios, tokens ni claves de otra persona. Tampoco clones repositorios dentro de p00-puesto-nube ni sustituyas el repositorio local de esta práctica.

SSH: un canal cifrado que exige verificar la identidad

SSH (Secure Shell) permite ejecutar órdenes o transferir archivos mediante una conexión cifrada. Aquí el objetivo no es memorizar una conexión: es saber a quién te conectas y qué credencial utilizas.

SSH interviene en dos identidades diferentes:

Identidad	Para qué sirve	Dónde se registra
Clave de host del servidor	Demuestra que el servidor al que llegas es el esperado.	`known_hosts` del cliente, tras verificar su huella.
Clave del usuario	Demuestra que puedes acceder a una cuenta autorizada.	Clave privada en tu entorno y clave pública en el servidor autorizado.

Identidades SSH separadas: huella del host y known_hosts por un lado; clave privada y pública del usuario alumno en su carpeta personal, fuera de optativa-nube y Git.

Aceptar una clave de host desconocida sin comprobar su huella equivale a no verificar quién está al otro lado. Antes de una primera conexión, el docente o la documentación oficial debe proporcionar la huella del servidor por un canal fiable.

Configuración servidor SSH (profesor)

Este apartado prepara un servidor SSH de aula para que el alumnado practique una conexión real. El servidor es un contenedor independiente llamado p00-ssh-aula, creado en el equipo del profesor. No reutilices p00-lab: cada alumno tiene uno en su propio equipo y ese contenedor es solo su puesto cliente.

p00-lab del alumnado → red local del aula → IP del equipo del profesor:2222 → p00-ssh-aula:22

La dirección que recibirá el alumnado es la IP de la red local del equipo del profesor, no la IP interna de Docker. Las IP internas de los contenedores solo sirven dentro del Docker del mismo equipo y pueden cambiar.

1. Comprobar la red antes de crear el servidor

Desde el anfitrión del profesor, confirma que Docker está iniciado y anota la dirección IPv4 de la red del aula. En Windows puedes verla con ipconfig; en Linux, con ip -4 addr. Elige la dirección de la interfaz conectada realmente a la red de aula, no una dirección de Docker, VPN o 127.0.0.1.

Antes de continuar, verifica estas condiciones:

el equipo del profesor y los del alumnado están en la misma red o VLAN;
la red Wi-Fi no aísla a los dispositivos entre sí;
el puerto TCP 2222 está libre en el equipo del profesor;
el cortafuegos del equipo permite conexiones entrantes al puerto 2222 solo desde la red del aula.

Si la dirección IP del profesor cambia entre sesiones, no reutilices la dirección anterior. Como el puerto se publicó ligado a la IP anterior, tendrás que recrear el contenedor con la nueva dirección y obtener de nuevo la huella de host antes de comunicarla al alumnado.

2. Construir el servidor dedicado

En la carpeta P00/, construye la imagen a partir de Dockerfile.ssh-aula. El archivo instala openssh-server, impide el acceso de root y permite entrar únicamente a cuentas que pertenezcan al grupo ssh-aula. La contraseña se admite solo al principio para que cada alumno use ssh-copy-id; se desactiva al terminar ese paso.

Si prefieres crearlo copiando el contenido, guarda esto como assets/Dockerfile.ssh-aula:

# Servidor SSH dedicado del profesorado para P00.
# Se construye localmente y no se publica en un registro.
FROM debian:trixie-slim

RUN apt-get update \
    && DEBIAN_FRONTEND=noninteractive apt-get install --yes --no-install-recommends openssh-server adduser passwd \
    && groupadd --system ssh-aula \
    && for numero in $(seq -w 1 10); do \
         adduser --disabled-password --gecos "" --ingroup ssh-aula "alumno${numero}"; \
       done \
    && for numero in $(seq -w 1 10); do \
         echo "alumno${numero}:123123"; \
       done | chpasswd \
    && install -d --mode=0755 /run/sshd \
    && rm -f /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_*_key.pub \
    && rm -rf /var/lib/apt/lists/*

COPY sshd_config.aula /etc/ssh/sshd_config.d/90-p00-aula.conf
COPY iniciar-sshd.sh /usr/local/bin/iniciar-sshd.sh
RUN chmod 0755 /usr/local/bin/iniciar-sshd.sh

EXPOSE 22
ENTRYPOINT ["/usr/local/bin/iniciar-sshd.sh"]

El Dockerfile copia dos archivos auxiliares desde la misma carpeta assets/. Si los creas manualmente, copia también estos contenidos.

assets/sshd_config.aula:

# Configuración restrictiva para el servidor SSH docente de P00.
PermitRootLogin no
PasswordAuthentication yes
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowGroups ssh-aula
X11Forwarding no
AllowTcpForwarding no
LogLevel VERBOSE

assets/iniciar-sshd.sh:

#!/bin/sh
set -eu

# Crea las claves de host únicamente si aún no existen.
# Al reutilizar el mismo contenedor, se conserva la misma identidad SSH.
ssh-keygen -A
exec /usr/sbin/sshd -D -e

docker build --tag p00-ssh-aula:1.0 --file assets/Dockerfile.ssh-aula assets
docker image ls p00-ssh-aula

La segunda orden debe mostrar la etiqueta 1.0. La imagen se construye localmente para la práctica; no contiene claves privadas del alumnado ni se publica en un registro.

3. Iniciar el servidor y publicar solo el puerto necesario

Primero identifica la dirección IPv4 de la red del equipo del profesor.

ip -4 route get 1.1.1.1 | awk '{for (i = 1; i <= NF; i++) if ($i == "src") print $(i + 1)}'

En macos:

route -n get default | awk '/interface:/{print $2}' | xargs -I{} ipconfig getifaddr {}

Anota la dirección que muestre la orden. Este ejemplo usa 192.168.1.50; debes sustituirla por tu dirección real de aula. El puerto externo 2222 evita usar el puerto privilegiado 22 en el anfitrión; dentro del contenedor, SSH escucha en el puerto habitual 22.

docker run --detach --name p00-ssh-aula \
  --publish 192.168.1.50:2222:22 \
  p00-ssh-aula:1.0
docker ps --filter name=p00-ssh-aula
docker logs --tail 30 p00-ssh-aula

En Windows PowerShell, usa la misma estructura en una sola línea, sustituyendo la IP:

docker run --detach --name p00-ssh-aula --publish 192.168.1.50:2222:22 p00-ssh-aula:1.0

La lista y los registros deben confirmar que p00-ssh-aula permanece activo. Si el puerto no se publica o el contenedor se detiene, no entregues todavía ninguna dirección al alumnado: revisa los registros y el cortafuegos primero.

4. Cuentas de práctica

Al construir la imagen, el Dockerfile crea las diez cuentas alumno01 a alumno10, con su carpeta personal y su pertenencia al grupo ssh-aula. Todas usan inicialmente la contraseña 123123, que permite a cada alumno ejecutar ssh-copy-id con su cuenta.

5. Comunicar la identidad verificable del servidor

Obtén la huella de la clave pública de host ED25519 y comunícala junto con la dirección, el puerto y el usuario. Hazlo por un canal fiable del aula, no copiando una huella vista sin comprobar en una primera conexión.

docker exec p00-ssh-aula ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ed25519_key.pub

Entrega a cada alumno estos cuatro datos:

Dato	Ejemplo de formato
Dirección del profesor	`192.168.1.50`
Puerto publicado	`2222`
Usuario asignado	`alumno01` a `alumno10`
Huella de host ED25519	`SHA256:...` obtenida con la orden anterior

6. Desactivar el acceso con contraseña y cerrar el servidor

Cuando las diez cuentas hayan comprobado su conexión por clave, desactiva el acceso con contraseña y reinicia el servidor:

docker exec p00-ssh-aula sed -i 's/^PasswordAuthentication yes$/PasswordAuthentication no/' /etc/ssh/sshd_config.d/90-p00-aula.conf
docker restart p00-ssh-aula

Después de reiniciarlo, una conexión nueva debe permitir la clave autorizada, pero no aceptar la contraseña 123123.

7. Cierre y continuidad

Al terminar cada sesión, detén el servidor, pero no lo elimines mientras la práctica continúe: así conserva su clave de host y las cuentas autorizadas.

docker stop p00-ssh-aula
docker ps --all --filter name=p00-ssh-aula

Para la siguiente sesión, inicia el mismo contenedor con docker start p00-ssh-aula y vuelve a comprobar registros, puerto y huella antes de comunicar la conexión. Al finalizar definitivamente la práctica, inventaría las cuentas y claves autorizadas, detén el contenedor y elimina solo ese recurso identificado con docker rm p00-ssh-aula.

Instalar el cliente y preparar la carpeta privada

Git se instaló al preparar p00-lab en P00/01; SSH se instala ahora porque se introduce en esta práctica. Punto de partida: sigues dentro de p00-lab como alumno.

sudo apt-get update
sudo apt-get install --yes openssh-client nano
ssh -V

sudo eleva permisos solo para esa orden; apt-get update actualiza el índice de paquetes; apt-get install --yes openssh-client nano instala el cliente SSH y el editor nano sin pedir confirmación; ssh -V muestra su versión. El cliente permite conectar desde p00-lab a otro equipo que tenga un servidor SSH. No instala openssh-server, no inicia sshd y no convierte este contenedor en un servidor al que otros equipos puedan conectarse. Esta instalación permanece mientras exista el contenedor. Si el cliente SSH se convierte en una herramienta recurrente, se añadirá al Dockerfile versionado con una etiqueta nueva de p00-lab; no se usará docker commit.

Las claves pertenecen a tu identidad, no al proyecto. ~ representa tu carpeta personal y, como eres alumno, ~/.ssh equivale a /home/alumno/.ssh:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ls -ld ~/.ssh

mkdir -p crea la carpeta solo si falta; chmod 700 permite acceder únicamente a su propietario; ls -ld muestra los permisos de la carpeta, sin listar su interior. No apliques chmod -R de forma indiscriminada ni intentes corregir con permisos un problema de un montaje del anfitrión.

Crear una pareja de claves para una práctica autorizada

Primero mira qué hay en la carpeta. Si ves p00_ed25519 o p00_ed25519.pub, no ejecutes la orden de creación con el mismo nombre: conserva la clave existente y consulta qué hacer.

ls -la ~/.ssh

Solo si esos nombres no aparecen, crea la pareja de práctica:

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/p00_ed25519 -C "p00-clave-practica"
chmod 600 ~/.ssh/p00_ed25519
chmod 644 ~/.ssh/p00_ed25519.pub
ls -l ~/.ssh/p00_ed25519*

ssh-keygen crea y gestiona claves SSH.
-t ed25519 elige el tipo de clave Ed25519.
-a 64 aumenta el trabajo necesario para comprobar la frase de paso de una clave privada cifrada.
-f fija el nombre y la ruta de los dos archivos; -C añade una etiqueta reconocible a la clave pública.
chmod 600 deja la clave privada solo para su propietario; chmod 644 permite leer la pública, que no es secreta.

La orden te pedirá una frase de paso: elige una que recuerdes y no la compartas. Si la olvidas, no se puede recuperar de forma legítima; será necesario crear otra clave y revocar la anterior si se hubiera autorizado.

Archivo	¿Se puede compartir?	Uso
`~/.ssh/p00_ed25519`	No. Es privado.	Demuestra que controlas la identidad de usuario.
`~/.ssh/p00_ed25519.pub`	Sí, solo con el destino autorizado.	Se instala en el servidor para autorizar el acceso.

En la práctica del servidor de aula, tú mismo copiarás el archivo terminado en .pub con ssh-copy-id; no lo envíes al profesor ni copies tu clave privada:

cat ~/.ssh/p00_ed25519.pub

cat muestra el contenido de un fichero de texto. No ejecutes la misma orden sobre p00_ed25519: una clave privada no se copia a una actividad, captura, correo, repositorio ni conversación. Fuera de esta práctica, el docente o administrador puede añadir la clave pública a la cuenta remota autorizada; no modifiques a ciegas authorized_keys de un servidor compartido.

Primera conexión: verificar primero el host

Cuando el profesor haya preparado p00-ssh-aula, te comunicará cuatro datos por un canal fiable: dirección, puerto, tu usuario (alumno01 a alumno10) y huella SHA256 de host. No inventes esos valores ni uses otra dirección que veas en Docker.

Conéctate con el usuario que te haya asignado el profesor. En este ejemplo se usa alumno01; sustitúyelo por el tuyo y cambia la IP si el profesor te ha indicado otra:

ssh -p 2222 [email protected]

SSH mostrará la huella del servidor desconocido. Compárala carácter por carácter con la huella que has recibido.
Escribe yes únicamente si ambas huellas coinciden exactamente. SSH registrará entonces esa identidad en ~/.ssh/known_hosts.
Escribe la contraseña 123123, ejecuta whoami y comprueba que aparece tu usuario asignado. Sal con exit.

Una advertencia de cambio de clave no se ignora: puede corresponder a un cambio legítimo —por ejemplo, si el profesor ha recreado el servidor—, pero debes detenerte y verificar la nueva huella antes de actualizar nada.

Copiar tu clave pública con `ssh-copy-id`

Después de comprobar la primera conexión, copia tú mismo tu clave pública al servidor. ssh-copy-id pide la contraseña 123123 una única vez y añade la clave pública a authorized_keys:

ssh-copy-id -i ~/.ssh/p00_ed25519.pub -p 2222 [email protected]

Sustituye alumno01 por tu cuenta. Comprueba después que puedes entrar con la clave:

ssh -p 2222 [email protected]

La orden puede pedir la frase de paso de tu clave privada, pero no debe pedir la contraseña del servidor. Ejecuta whoami, comprueba que aparece tu usuario y sal con exit.

Personalizar los prompts de tu contenedor

Esta personalización se realiza en tu contenedor p00-lab, no en el servidor SSH del profesor. Después de salir del servidor con exit, vuelves a estar en tu cuenta local alumno. Debian slim usa una configuración mínima y Bash puede mostrar un prompt sin color.

Abre el archivo de configuración de tu usuario:

nano ~/.bashrc

Ve al final del archivo y pega esta línea:

PS1='\[\e[1;32m\]\u@\h\[\e[0m\]:\[\e[1;34m\]\w\[\e[0m\]\$ '

Guarda con Ctrl+O, confirma con Intro y sal con Ctrl+X. Para cargar la nueva configuración de alumno, sal de su sesión y vuelve a entrar:

exit
su - alumno

Ahora verás el prompt verde de alumno.

Vuelve a root con exit y abre su configuración:

exit
nano /root/.bashrc

Al final, pega esta línea para que el usuario y equipo aparezcan en rojo cuando trabajes como root:

PS1='\[\e[1;31m\]\u@\h\[\e[0m\]:\[\e[1;34m\]\w\[\e[0m\]\$ '

Guarda y sal de nano. Esta vez no necesitas salir ni volver a entrar: fuerza la carga del archivo en la sesión actual de root:

source /root/.bashrc

El prompt de root cambiará inmediatamente a rojo. Para volver a tu cuenta alumno, ejecuta su - alumno.

Retos de comprobación de SSH

Comprueba que ~/.ssh pertenece a alumno y que sus permisos no dan acceso a otros usuarios.
Identifica cuál de los dos archivos de la pareja puede facilitarse a un servidor autorizado y explica por qué.
Busca el lugar donde SSH registrará la identidad de un host y explica qué verificación falta antes de crearlo.
Explica qué harías ante una advertencia de cambio de huella. No borres known_hosts para resolverla.

A entregar

Entrega o conserva en tu carpeta de trabajo:

El repositorio /optativa-nube/p00-puesto-nube con .gitignore, README.md, la página mínima y una bitácora sin datos sensibles.
Al menos tres commits pequeños, revisados y con mensajes explicativos.
En evidencias/bitacora-p00.md, las conclusiones de los retos de Git y SSH; no incluyas claves privadas, contraseñas, tokens, credenciales ni salidas completas.
La pareja SSH almacenada exclusivamente en /home/alumno/.ssh, con los permisos comprobados. Si no hay destino autorizado, no se realiza una conexión real.

Ideas que reaparecerán en las prácticas de nube

Trabajarás desde una carpeta persistente y comprobarás el estado antes de cambiar nada.
Harás commits pequeños que expliquen una mejora concreta; así podrás justificar decisiones y recuperar una versión estable.
No versionarás secretos: .env, claves privadas y archivos de credenciales se excluyen antes del primer commit.
Verificarás la identidad de un host SSH antes de enviar una clave o contraseña. La misma precaución se aplicará a dominios, certificados y servicios de nube.

Fuentes para ampliar y comprobar

Documentación oficial de Git: referencia de comandos y conceptos.
Libro oficial Pro Git: explicación progresiva de repositorios, área de preparación e historial.
Manual de ssh-keygen de OpenSSH: referencia para claves, huellas y archivos conocidos.
Manual de ssh de OpenSSH: referencia del cliente y de la comprobación de hosts.
Configuración de sshd: acceso por clave pública, grupos autorizados y restricciones del servidor.
Docker Docs: publicar puertos: publicación de un puerto de contenedor en el anfitrión.
Docker Docs: volúmenes: ciclo de vida de los datos de un contenedor y persistencia.