Portada
mis comunidades
otras secciones
#2:
Este tipo me dice que generar una clave con ssh-keygen es manual, difícil y que puede crear errores, pero me propone un método manual, difícil y que además implica abrir una web para registrarse en Google u otro proveedor de identidades.
Igual es que me estoy haciendo viejo y tengo reticencias al cambio, pero o me lo explican mejor o me quedo con el método viejo, que ya conozco y tengo pulido.
También me da la sensación de que si usas una misma CA para toda la empresa, como te roben la CA pueden entrar en cualquier ordenador, mientras que en el otro método autenticas por clave y si te roban una clave entrarán sólo donde esa clave tenga permisos.
Si tienes que poner varias CAs y una forma de validar las claves que has creado, el método parece similar al de ssh-keygen pero más complicado
Igual es que me estoy haciendo viejo y tengo reticencias al cambio, pero o me lo explican mejor o me quedo con el método viejo, que ya conozco y tengo pulido.
También me da la sensación de que si usas una misma CA para toda la empresa, como te roben la CA pueden entrar en cualquier ordenador, mientras que en el otro método autenticas por clave y si te roban una clave entrarán sólo donde esa clave tenga permisos.
Si tienes que poner varias CAs y una forma de validar las claves que has creado, el método parece similar al de ssh-keygen pero más complicado
#1:
El carretera al infierno está asfaltada con tickets de Jira.
Comentarios
Este tipo me dice que generar una clave con ssh-keygen es manual, difícil y que puede crear errores, pero me propone un método manual, difícil y que además implica abrir una web para registrarse en Google u otro proveedor de identidades.
Igual es que me estoy haciendo viejo y tengo reticencias al cambio, pero o me lo explican mejor o me quedo con el método viejo, que ya conozco y tengo pulido.
También me da la sensación de que si usas una misma CA para toda la empresa, como te roben la CA pueden entrar en cualquier ordenador, mientras que en el otro método autenticas por clave y si te roban una clave entrarán sólo donde esa clave tenga permisos.
Si tienes que poner varias CAs y una forma de validar las claves que has creado, el método parece similar al de ssh-keygen pero más complicado
#2 No serás el mismo musg0 de #escomposlinux ...
#11 El de hace tanto tiempo que ya ni me acuerdo, sí
#2 Obviamente si te roban la CA estás jodido. Por naturaleza, una CA tiene que ser confiable. Partimos de la base de que tomarás medidas para que eso no ocurra. Pero el mayor problema sería más bien que suplanten tus certificados y puedan hacer cosas malvadas (como robar contraseñas). Precisamente eso se evitaría usando certificados en vez de contraseñas.
Además, el principal problema de tener mil contraseñas es que las acabas olvidando, o las acabas apuntando en un lugar donde son fáciles de robar, o acabas usando la misma en todos lados. Aparte de eso, desactivando el acceso por contraseña en el servidor SSH impides ataques por diccionario o fuerza bruta, con lo que es más ventajoso usar certificados que contraseñas.
Lo único en lo que tienes que poner cuidado es que no te roben la clave privada, pero a los certificados les puedes (y debes) poner passphrase. Jamás generaría una clave privada para algo serio sin ponerle passphrase.
#2 El artículo es malo. Habla de autenticación de usuarios por certificado y no dice como configurar el SSH cliente para hacerlo
El carretera al infierno está asfaltada con tickets de Jira.
#1 Dices eso porque no has sufrido BMC Remedy...
Es mucho mejor, claro, así si consigues entrar en una máquina puedes entrar sin contraseña alguna en todas las demás. Y si ya pones a todos los usuarios en sudoers con asterisco es todo mas suave y placentero.
La autenticación por certificados con SSH sólo se debe hacer para automatizar procesos entre máquinas y usando un usuario completamente capado. A no ser que tu modelo de seguridad sea muy particular.
#3 correcto, aquí solo los usamos así y en casos muy contados cuando un usuario no le queda otra que lanzar algún proceso en otra máquina además de en la que está y es un usuario completamente capado y que no puede acceder nada más que a esa otra máquina y hacer muy poca cosa, lanzar el script y poco más
#3 #5 En la red de casa tengo todas las máquinas con acceso SSH con certificado y pass desactivada. Es más seguro así, porque impides ataques por diccionario o fuerza bruta, ya que el servidor rechaza todo intento de autenticación con contraseña.
Lo que no te evitas, obviamente, es si te roban la clave privada ... pero mi clave privada tiene passphrase. Jamás usaría un certificado sin passphrase, excepto para el GitHub y poco más.
#27
Discrepo. Con eso sólo estas protegiendo una máquina, y desprotegiendo todas las demás.
Y lo del miedo a las contraseñas es una falacia.
El ataque por fuerza bruta en internet es inaplicable, es demasiado lento (a menos que tu contraseña sea AAB, claro). Nunca lo he visto. Y si te preocupa, un proxy de aplicación te bloquea la IP atacante en segundos. En mi caso tengo un script en cron que hace lo mismo.
El ataque por diccionario es maś habitual, pero se prueban las 100 contraseñas más frecuentes. Los atacantes no van a estar eternamente probando claves. Es inútil si tu clave es medianamente digna.
Que te roben la clave privada es lo menos probable. No va a salir de tu ordenador a menos que tu la saques.
Es más probable que entren por cualquier otra vulnerabilidad, sea o no de ssh. Y una vez dentro, si no tienes claves diferenes para cada máquina, el movimiento lateral es trivial, todo es campo.
#29 Con eso sólo estas protegiendo una máquina, y desprotegiendo todas las demás.
¿Puedes desarrollar esa idea? No entiendo cómo estás desprotegiendo las demás máquinas por restringir el acceso SSH con contraseña.
El ataque por fuerza bruta en internet es inaplicable
Si hablamos del entorno corporativo, no se trata sólo de impedir accesos de fuera hacia dentro, sino escaladas de privilegios o acceso a máquinas no autorizadas, p.ej. evitar que un trabajador sin los privilegios necesarios o un intruso (quizá incluso intruso físico) te acceda a un servidor crítico. No es sólo proteger de WAN a LAN, sino también dentro de la LAN.
Que te roben la clave privada es lo menos probable. No va a salir de tu ordenador a menos que tu la saques.
Yo diría que es más probable que lo que piensas. A menudo invertimos mucho en asegurar nuestros servidores, pero descuidamos las estaciones de trabajo y los portátiles, y además son las máquinas que usan los usuarios finales con menos conocimientos, por lo que son las más vulnerables a virus, phishing, etc. En mi curro actual tenemos bloqueo de BIOS y cifrado de disco con BitLocker, pero en otros curros he tenido la BIOS abierta e incluso un Windows con privilegios de admin.
Si te vulneran una estación de trabajo, te podrían meter un keylogger o robarte ficheros, y ahí te podrían robar tanto las contraseñas como el certificado, pero el certificado no les serviría de mucho a menos que tengan tu passphrase, y además lo puedes revocar fácilmente. En cambio, una contraseña vulnerada es una contraseña menos que puedes usar, y nuestra creatividad a la hora de inventarnos contraseñas que podamos recordar es muy limitada.
#31
" No entiendo cómo estás desprotegiendo las demás máquinas por restringir el acceso SSH con contraseña."
No las estás desprotegiendo por restringir la contraseña, las estás desprotegiendo por permitir el acceso SIN contraseña.
Movimiento lateral. Si cualquier máquina del círculo de confianza es vulnerada, todas las demás son fácilmente accesibles.
"Si hablamos del entorno corporativo, no se trata sólo de impedir accesos de fuera hacia dentro, sino escaladas de privilegios o acceso a máquinas no autorizadas"
Perdóname pero en este caso me parece más seguro que cada usuario en cada máquina tenga una clave segura y diferente a que los usuarios puedan saltar de una a otra sin autenticarse cada vez, solo por el hecho de hacerlo desde una confiable. Está cambiando 2FA por 0FA.
"Yo diría que es más probable que lo que piensas... Windows con privilegios de admin"
Perdona, como hablábamos de certificados ssh creí que nos referíamos a entornos *nix.
"Si te vulneran una estación de trabajo, te podrían meter un keylogger o robarte ficheros, y ahí te podrían robar tanto las contraseñas como el certificado"
No hace falta robar nada. Si te vulneran la estación de trabajo, pueden ejecutar comandos y tienes la clave pública compartida en el servidor, ya está todo hecho.
#27 Para tu red casera no hace falta que te lies con estos temas. Simplemente utiliza certificado(temporal) + pass(temporal) y a campeonar.
El artículo no está enfocado a los que tienen máquinas con 20 usuarios, ni 50 si no muchos más.
#3 Mi voto a favor de los usuarios en sudoers con nopasswd:all
#3 Como dice el gran
enderwiggins, Nunca hay problemas de permisos si lo ejecutas todo como root. 
Será más manual pero jamás voy a confiar en un tercero para gestionar las identidades de accesos de seguridad de claves SSH.
No obstante en mi curro nos lo hemos montado bien, tenemos un bastion host que tiene un authorized keys que esta versionado en git. Continee la clave publica de todos los empleados (el authorized keys) y con unos scripts automaticamente crea o elimina usuarios en el bastion segun los cambios que se hagan en git de ese fichero. Al repo solo tienen acceso unos pocos que gestionan las altas y bajas de empleados.
El resto de servicios de otros hosts estan mapeados ya con tuneles SSH permanentes al bastion, de manera que si un developer quiere acceder a sonar, solo tiene que hacerse un tunel al bastion y mapearse el puerto 9000 a su 9000 local y acceder a http://localhost:9000,y asi con todos nuestros servicios internos.
Tenemos unos scripts que les pasamos a los developers que te abren los tuneles a todos los servicios que tenemos, asi que ya tienen mapeado todo lo que necesitan de normal en sus equipos.
Y voila, nada de accesos SSH multiples para los empleados, todo esta controlado en un unico host.
#4 ¿no era más fácil gestionar una VPN que tantos tuneles?
#6 Tu propuesta entonces es crear VPN's exponiendo las ip's públicas de todos los servicios de las máquinas y tener que gestionar usuarios en cada VPN individual?
Eso si que es un lío de cojones
Los servicios no tienen por qué estar en la misma red, así que una VPN única no me valdría.
#7 exponiendo las ip's públicas de todos los servicios de las máquinas
Una VPN es justo lo contrario. Obviamente en ambos necesitas una IP pública, el nivel de exposición de los servicios dependerá de si usas o no una VPN en modo NAT o un proxy inverso para el túnel SSH.
tener que gestionar usuarios en cada VPN individual?
Eso es precisamente lo único que suele ser más sencillo en una VPN que un túnel SSH.
Eso si que es un lío de cojones
Desde la perspectiva del administrador de la red sin duda. Pero pregúntales a los desarrolladores si prefieren conectarse a una VPN con un split tunneling a esos servicios o tener que configurar el túnel ssh para cada aplicación con la que necesiten conectarse...
Los servicios no tienen por qué estar en la misma red, así que una VPN única no me valdría.
Desde un único túnel VPN puedes acceder al mismo tiempo a diferentes subnets.
Túneles SSH y VPNs tienen sus ventajas e inconvenientes. Montar una VPN para un entorno pequeño y autogestionado suele ser overkill, pero no verás muchos túneles SSH en las redes de corporaciones.
#21 Las máquinas no estan todas en la misma red, no hablo de subnets ni vlans sino de redes físicamente separadas.
Para cada máquina con VPN necesitaría exponer el servicio de VPN al mundo para que los trabajadores puedan conectar.
Si creo una VPN, tendría luego que tener túneles o algún tipo de enrutamiento para que todo fuese privado y no queden expuestos los servicios al mundo. El embudo lo necesito igual.
Además no todas las máquinas son mías y es muy fácil pedir un acceso SSH pero no tán fácil crear una VPN, y aunque me la creen, no van a gestionarme los usuarios ellos ni tienen por qué darme acceso a gestionar los usuarios.
Como comentaba, con los scripts que hemos generado, dar de alta o de baja a un usuario es tan sólo añadir una línea de texto a un repo. Me parece muy sencillo de gestionar y nos cuesta unos 2 minutos.
Conozco cómo funcionan las corporaciones y sus grandes VPN's. Valoramos en su momento montar una VPN y veíamos más problemas que ventajas. Nos decidimos por túneles SSH permanentes y accesos desde el bastion a los servicios y fué un acierto. Va rápido, es seguro y es fácil de gestionar.
Se me olvidaba mencionar que los trabajadores son remotos, así que no puedo tampoco permitir orígenes de confianza.
#23 Del mismo modo que tienes un bastion host para gestionar todas las claves podrías tener un único endpoint para subnetear todas las VPNs, aunque seguramente sería demasiado para el caso que planteas.
No dudo en absoluto de que la solución que habéis implementado sea la más adecuada para vuestro caso, ni soy un fan de las VPNs. Sólo comento que algunos de los inconvenientes que planteas son equivalentes a los que plantea un túnel SSH aunque la solución en ambos casos sea diferente y, sobre todo, que las ventajas de una solución sobre otra están muy relacionadas con el número de servicios a los que dar acceso.
no puedo tampoco permitir orígenes de confianza
Que es un caso común en muchas VPNs en las que las directivas se establecen sobre la IP del proxy y no sobre la de origen.
#4 y si se cae ese host, vacaciones para todos.
#9 Backups diarios, es un host en AWS, boton derecho crear instancia usando esa AMI, apuntar DNS a la nueva IP.
Unos 5 minutos.
#13 Pues no tengo más pegas.
Una idea, o consejo.
Tal vez sería interesante escribir un artículo o un tutorial y compartirlo en linkedin o tal, si encaja con la estrategia de comunicación de la empresa.
#15 No sé si daría para un artículo, pero en realidad es bastante sencillo de implementar (si conoces AWS).
1) Security groups en las máquinas con servicios web permitiendo el trafico TCP al puerto del servicio desde la IP pública del bastion (obviamente).
2) Tuneles SSH permanentes para mapear los servicios web en puertos de tu Bastion, concretamente yo uso este porque si un tunel se cae te lo reinicia automáticamente: https://github.com/tinned-software/ssh-tunnel-manager
3) Los túneles estan monitorizados con scripts que hacen curls a localhost:puerto para cada servicio, si alguno no va es que el tunel no esta funcionando correctamente aun reinciandose (posiblemente problema del servicio remoto).
4) Tener un authorized_keys en git en un repo privado, gestionar todas las claves públicas ahí.
5) Por cada empleado que se da de alta en la empresa, tiene que ejecutar esto y pasarnos la clave pública que le genera:
ssh-keygen -t rsa -b 4096 -C "youremail@company.com" -N '' -f ~/.ssh/jumpkey > /dev/null && cat ~/.ssh/jumpkey.pub
Y dicha clave se añade en git al authorized_keys.
6) Un script en el Bastion comprueba cada X tiempo si hay actualizaciones en el repo de git, de haberlas se lo descarga.
El script, usando lógica de git, sabe si has quitado una línea (dado de baja un empleado) o añadido y te saca el diff de las líneas afectadas.
Si han sido borradas, coge el usuario (la parte antes de@company.com del correo) y lo borra del sistema con $ userdel usuario
Si han sido añadidas, por cada línea crea el usuario y le añade el authorized_keys correspondiente a su usuario.
Y.. eso es todo
#17 Y si se rompe el servidor y le pones a otro el mismo nombre le dropea ERROR a todo el mundo y tienes flood de gente diciendo que les han hackeado porque SSH es TOFU, además que las keys entregadas por ssh no suelen expirar y tener por ahí cientos o miles de claves que no expiran es super seguro, y además te obliga a mantener el archivido de marras actualizado.
Me parece bastante irresponsable decir que lo del artículo es inseguro cuando el artículo mismo linka a empresas como Facebook, google, uber o Netflix que utilizan este sistema de certificados temporales.
Que si, que te puedes montar tu chiringuito como te de la gana, pero de ahí a decir que el chiringuito que ha hecho el vecino es una mierda because potatoe es pecar de soberbia.
Quizá no funcione para la escala a la que trabajas. En mi caso, por ejemplo, sería matar moscas a cañonazos por siemple escala, pero entiendo que en empresas enormes el sistema pinta muy bien por su seguridad y por lo fácil que resulta de mantener.
#34 " Y si se rompe el servidor y le pones a otro el mismo nombre le dropea ERROR a todo el mundo"
stricthostkeycheking=no, facil arreglo.
"las keys entregadas por ssh no suelen expirar"
Es precisamente la idea de tener un mantenimiento de clave por persona... que no expiren hasta que salga de la empresa o haya algo de fuerza mayor que obligue a rotarlas, como que le han robado el portátil.
"tener por ahí cientos o miles de claves que no expiran es super seguro"
Son unas 40, entre tuneles fijos + empleados con su ID unico, perfectamente gestionable.
"y además te obliga a mantener el archivido de marras actualizado."
Exactamente igual que los usuarios de una VPN.
"Me parece bastante irresponsable decir que lo del artículo es inseguro"
No he dicho eso en ningun momento, yo solo he dicho que jamás confiaría mi generación de claves a un tercero, no he dicho que no sea seguro.
"de ahí a decir que el chiringuito que ha hecho el vecino es una mierda"
No lo he dicho en ningun momento.
"entiendo que en empresas enormes el sistema pinta muy bien por su seguridad y por lo fácil que resulta de mantener. "
En mi experiencia, en empresas enormes tampoco quieren confiar en autenticación con terceros, por temas de privacidad sobre todo. Lo habitual es tener un Active Directory enorme, y tirar de VPN integrada con el AD.
#36
1) estás disminuyendo la seguridad.
2) keys han de expirar, por seguridad.
3) login mediante certificado dinámico no es para empresas de 40 personas, si no de cientos. Pese a que con 40 puede funcionar igual.
4) No significa nada. Que algo requiera mantenimiento no significa que sea bueno si puedes hacerlo de otra manera que te lo evite.
5) La gestión la haces tu mismo que para eso instalas el servidor CA. El sistema que te de el token, puede ser google o puede ser propio, y puedes incluir hasta un 2FA en el proceso de la generación del token que es incluso más seguro.
6) ok
7) Si son empresas que funcionan bajo Windows seguro, pero estas empresas tampoco hacen uso extensivo de ssh. Microsoft tiene otras herramientas. Pero cuando ya pone que Netflix, Google o mismo amazon con los AWS lo usan e implementan es por algo.
#4 edit-o
#18 "tenéis granularidad en la autorización de tipo usuario/todo, pero no usuario/servicio"
¡¡¡Correcto!!! Somos muy conscientes y tenemos una tarea de mejora ya definida para poder tener granularidad por usuario/servicio.
Vamos a poner contenedores docker "temáticos" en plan: "developer", "marketing", "devops", etc... cada container tendra un servidor SSH en un puerto y sus propios ususarios locales con los servicios "temáticos" añadidos sólo a ese container (o a varios si son comunes a distintos perfiles).
Lo único que cambia es que el usuario tendrá que acceder a un puerto distinto del mismo host (para el SSH de otro container distinto) en lugar de todos al mismo SSH del host físico, y que añade un pelín de lógica al script que crea usuarios, pero poca cosa.
"es un único punto de fallo"
Exactamente igual que un servidor VPN, con la diferencia de que a mi me cuesta 5 minutos levantarlo desde 0 en el momento en que de problemas y puedo hacer un análisis de la máquina a posteriori en lugar de tener que estar mirando que le ocurre al servidor VPN y arreglarlo. ¿No va la máquina? la tiro a la basura y saco otra.
"su pila TCP debe de estar flipando en colores "
La verdad es que no. Ahora mismo tenemos unos 15 túneles a servicios y 30 empleados. 45 conexiones SSH. Nada del otro mundo.
"¿Eso es estable? ¿El/los puertos del bastión soportan el tráfico?"
Lleva 2 años montado, 0 caídas, el rendimiento es bueno.
#19 Exacto, lo comento en #20
No obstante la mayoría de servicios sí tienen sus propios usuarios, esto sólo facilita los accesos a dichos servicios de manera controlada.
#4 Entiendo que eso es una forma de dar autorización a servicios que no lo tienen. Pero si lo he entendido bien, la granularidad es usuario/total y no usuario/servicio.
Entre la prepotencia del titular y la cara del pavo, gran noticia para el viernes por la mañana.
Stackflow?
#12 El over ha rebosado de la pila
Si usas una foto como avatar de 2667x2667px de 1.3MB para escalarlo luego a 64x64px también lo estas haciendo mal.
SSH user onboarding with public key authentication usually starts with some baroque incantation of ssh-keygen, hopefully pulled from a runbook, but more likely cribbed from stack overflow.
Estos millenials, qué panda de gandules que son.
El man está para algo.
Aunque yo siempre uso el comando a secas y las opciones por defecto van sin problema. La única que quizá necesites si tienes varios certificados es -f, pero ¿por qué ibas a querer varios certificados, si se trata de identificar únivocamente a una persona?