Aparentemente me he bloqueado de ssh en una de mis instancias de Google Compute

2

Tan recientemente como ayer, pude conectarme a nuestra instancia de desarrollo a través de mi cliente ssh local, usando una de las varias claves ssh enumeradas bajo sshKeys en los metadatos personalizados de la instancia (la forma antigua). ("Bloquear claves ssh para todo el proyecto" está marcado). También esa tarde, mientras estaba conectado, estaba haciendo algo donde sería conveniente una segunda sesión de SSH. Intenté abrir una segunda conexión a través del cliente ssh local y obtuve "Permiso denegado (clave pública)". Intenté abrir una segunda conexión desde la página de la consola de instancia, y tampoco se conectó. Mientras tanto, la sesión ssh que estaba usando continuó funcionando bien.

Esta mañana no puedo obtener una sesión ssh en esa instancia en absoluto.

Lo único que recuerdo haber hecho ayer, que fue lo menos inusual, fue un chmod en mi directorio de inicio, configurándolo en "777".

Traté de extraer los metadatos sshKeys e intenté la consola ssh nuevamente. Sin alegría. Luego miré el registro del puerto serie 1 y noté esto, con marcas de tiempo que muestran GMT aproximadamente cuando lo probé:

Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.

Puedo acceder a la solicitud de contraseña en el puerto serie, pero nunca me he configurado con acceso de contraseña, según lo que recuerdo.

ssh google-compute-engine hbquikcomjamesl
fuente
"Lo único que recuerdo haber hecho ayer, que fue lo menos inusual, fue un chmod en mi directorio de inicio, configurándolo en '777'". Eso lo habrá hecho. Si otros usuarios pueden escribir sus claves SSH, SSH se negará a usarlas.
ceejayoz
2
¡Haz de eso una "respuesta", "ceejayoz", y lo llamaré resuelto! Descubrí que podía decirle a web-to-ssh en la consola de la instancia que me registrara como otro usuario, a quien le había otorgado la autoridad sudo, y desde ese usuario, pude modificar mi directorio de inicio al 755, y una vez que hice eso, pude una vez más ssh como yo.
hbquikcomjamesl

Respuestas:

2

Lo único que recuerdo haber hecho ayer, que fue lo menos inusual, fue un chmod en mi directorio de inicio, configurándolo en "777".

Esto es probablemente lo que te ha bloqueado.

El demonio SSH es bastante paranoico (por una buena razón), y verificará varios permisos antes de permitir una conexión. Si su .ssh/authorized_keysarchivo puede ser escrito por otros usuarios en el servidor, SSH no permitirá conexiones entrantes para las claves públicas enumeradas allí.

(También hará lo mismo para las conexiones salientes si detecta que sus claves privadas son demasiado legibles / grabables).

ceejayoz
fuente
Gracias por la informacion adicional. Desafortunadamente, no tengo suficientes puntos de reputación para que mi voto positivo se muestre realmente, pero marqué la respuesta como aceptada. A veces, me olvido de que, en comparación con OS / 400, donde el microcódigo generalmente impedirá que hagas algo estúpido, * nix puede ser como caminar sobre cáscaras de huevo extraídas. He escrito los detalles de cómo deshací el daño y lo pegué en una imagen de disco segura en mi Mac de trabajo, con un icono especial que superpone el símbolo internacional "no" sobre el número 777.
hbquikcomjamesl