serbidorera akzesoa badaukagu:
konektatu behar garen ordenadorean llaveak sortu eta gero publikoa serbidoren kopiatu behar da
ssh-keygen -t ed25519 -C “xlizarralde@email.com”
cd ~/.ssh
ssh-copy-id xabi@164.90.187.25
konfigurazioa hemen dago:
sudo nano /etc/ssh/sshd_config
sudo systemctl restart ssh
llave pribatuakin beti sartu daiteke:
ssh -i C:\Users\xlizarralde.ssh\ssh-key-2025-12-01.key ubuntu@143.47.47.165
2 llave izen berdinakin badaude:
~/.ssh/config artxiboa sortu:
# --- Configuración para Servidor A ---
Host servidor-a-alias
HostName [IP_o_Dominio_de_Servidor_A]
User [Tu_usuario_en_A]
IdentityFile ~/.ssh/vps_servidor_a_key
# --- Configuración para Servidor B ---
Host servidor-b-alias
HostName [IP_o_Dominio_de_Servidor_B]
User [Tu_usuario_en_B]
IdentityFile ~/.ssh/vps_servidor_b_key
Nere tailnet tailscale:
ssh opc@oracle admin:root 77Laekinu.7
ssh xabi@contabo 77lua3
ssh root@proxmox 77Laekinu.7
Rustdesk
https://community-scripts.github.io/ProxmoxVE/scripts?id=rustdeskserver
https://wiki.hakedev.com/docs/proxmox/rustdesk-server/
termix server ssh
termix.xabi.ovh
La sincronización con un sistema remoto es trivial si tiene acceso SSH al equipo remoto y rsync instalado en ambos sitios. Una vez que tenga el acceso SSH verificado entre los dos equipos, puede sincronizar la carpeta dir1 anterior con una computadora remota utilizando esta sintaxis (tenga en cuenta que, en este caso, queremos transferir el propio directorio, por lo que omitimos la barra diagonal):
rsync -a ~/dir1 username@remote_host:destination_directory
Eso se conoce como una operación “push” porque empuja un directorio del sistema local a un sistema remoto. La operación opuesta se conoce como “pull”. Se utiliza para sincronizar un directorio remoto con el sistema local. Si el dir1 estuviera en el sistema remoto, y no en nuestro sistema local, la sintaxis sería la siguiente:
rsync -a username@remote_host:/home/username/dir1 place_to_sync_on_local_machine
my aliases
alias = con=‘ssh xabi@161.97.168.69 ‘
alias = pi=‘ssh xabi@192.168.68.70’
Velocidad de internet — comparativa (2026-10-30)
Método: librespeed-cli v1.0.11 (amd64 en Proxmox y VPS, arm64 en Oracle), servidor 50 (Frankfurt, Clouvider), 3 rondas separadas 3 s y se reporta la mediana. Mismo servidor para que la comparación sea objetiva.
| Máquina | Enlace | Ping | Jitter | Bajada | Subida |
|---|---|---|---|---|---|
| Proxmox (casa, Antzuola) | fibra casa | 41 ms | 0,04 ms | 257,7 Mbps | 159,5 Mbps |
| VPS Contabo (Lauterbourg, FR) | plan ~200 Mbps | ~10 ms | 0,4-1,5 ms | ~194 Mbps | ~185 Mbps |
| Oracle Cloud (Oracle Linux 9.8, aarch64, 4 OCPU Neoverse-N1) | ~1 Gbps | 16 ms | 0,14 ms | 3182 Mbps | 990 Mbps |
Notas:
- Oracle: subida muy variable entre rondas (1013 / 103 / 990 Mbps); mediana 990. Puede ser el límite de egress de la instancia ARM.
- VPS: mediana de 3 rondas del 2026-10-29; una ronda dio 149,6 Mbps de bajada. Techo del plan ~200 Mbps.
- Casa: el cuello de botella es la subida (159,5), no la bajada.
- Comando:
librespeed-cli --server 50 --json(duración por defecto, 15 s por fase). - Descartada una medición previa con
speedtest-cli(sivel) que eligió un servidor de Albania a 1400 km: no era comparable.
Caracteristicas servidores
- Proxmox (pve): AMD Ryzen 5 PRO 5650U, 6 núcleos / 12 hilos, 11 GB RAM, 94 GB disco (73 libres), red 258/160, bench 0,219 s
- Oracle: 4 vCPU Neoverse-N1 (ARM64), 22 GB RAM, 30 GB disco (18 libres), red 3182/990, bench 0,406 s
- VPS Contabo: 4 vCPU EPYC (x86), 7,8 GB RAM, 390 GB disco (220 libres), red 194/185, bench 0,427 s
El Ryzen va casi al doble por hilo que el Oracle y tiene 3× más hilos: es el más “rápido”, aunque esos 4 GB ya los tiene gastados en sus LXC. El Oracle sigue ganando en RAM (22 vs 11 GB) y en red (16× el Contabo), y el Contabo es el único con disco de verdad (390 GB).
Resumen: Proxmox = CPU; Oracle = RAM y ancho de banda; Contabo = almacenamiento. Ninguno es “mejor” en todo.
Ojo con el Oracle: 4 núcleos ARM compartidos y 30 GB de disco es su techo real; para cargas pesadas de CPU el Ryzen de casa le pasa por encima.