Mostrando entradas con la etiqueta ssh. Mostrar todas las entradas
Mostrando entradas con la etiqueta ssh. Mostrar todas las entradas

miércoles, 30 de abril de 2025

Gitlab(5): Problemas

1. Después de funcionar bien VS con gitlab durante una temporada, se produce este error:

Node.js v20.18.3

git@gitlab.municipio.es: Permission denied (publickey,password).

fatal: No s'ha pogut llegir del repositori remot.


Assegureu-vos que tingueu els permisos

d'accés correctes i que el repositori existeixi.


SOLUCIÓN: Parece ser que se ha perdido la clave ssh. Para ello, se busc el nombre del fichero de clave ssh (en mi caso es id_ed25519.ximo) y  se ejecuta:

ssh-add ~/.ssh/id_ed25519.ximo

NOTA: Cuando se crea un usuario dentro de Gitlab, se le puede crear una clave ssh para que no vuelva a pedir más la contraseña. Esta clave se guarda en la carpeta ~/.ssh

Esto sucede si en VS se ha configurado para acceder a gitlab con ssh. Para comprobar que estamos accediendo con ssh se ejecuta dentro de la carpeta principal del proyecto

git remote -v

y si el resultado comienza por origin  git@   entonces es ssh y si empieza por origin https entonces es https




lunes, 7 de diciembre de 2020

Certificados en Java (3). Configurar JBoss Server con https. autentificacion del cliente con certificado.

 1. Introducción

En el fichero server.xml se indica donde localizar los certificados

para encontralo, si se sabe que cuelga de "/opt" se puede probar con este comando

find /opt -name server.xml -print

Y nos salen

/opt/jboss-X.X.X.ZZ/server/all/deploy/jboss-web.deployer/server.xml
/opt/jboss-X.X.X.ZZ/server/default/deploy/jboss-web.deployer/server.xml

Parece ser que el segundo fichero es el correcto.

Miramos el contenido del fichero, y solamente la parte que nos interesa es:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
               ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
               keystoreFile="${jboss.server.home.dir}/conf/myjbosscert.p12" keystorePass="mypassword" keystoreType="PKCS12"
               truststoreFile="${jboss.server.home.dir}/conf/server.truststore" truststorePass="otherpassword" truststoreType="JKS" />

Ahora hay que cambiar myjbosscert.p12 por el nuevo certificado y tener en cuenta la nueva contraseña e indicarlo en el fichero server.xml

OJO: solo se puede activar para que vea los certificados como jks o como PKCS12. Por tanto hay que tener cuidado y leerse la documentación para no terner problemas, y ver que está activado el APR para utilizar certificados ".p12" (PKCS12) 


2. Pero y si tenemos un certificado en formato crt?

Para ello tenemos que convertirlo a p12 y para ello hacemos

openssl pkcs12 -export -in myjbosscert.crt -inkey myjboss.key -out myjbosscert.p12 -name myjboss -CAfile myCA.pem -caname root -chain

Donde myjboss.key es la clave que hemos creado para el servidor

y myCA.pem es el certificado X509 de la entidad certificadora.

Lo que hacemos es que añadimos la cadena de certificados al almacén PKCS12


NO ES OBLIGADO e incluso puede ser recomendable en ciertos casos no utilizar las opciones 

   -name myjboss    ni tampoco

   -caname root 

Y nos pedirá una contraseña.

NOTA: Al convertir un certificado de X509 v3 (con datos adicionales como los diversos SAN o "nombre-maquina+dominio" alternativos), parece que se pierde parte de esta información adicional. Si queremos ver el certificado resultante y sabiendo la contraseña que nos pide anteriormente podemos hacer:


openssl pkcs12 -nokeys -info -in ximodante.p12 -passin pass:mypassword

OJO: este comando no muestra las SAN o DNS alternativos!!, pero si instalamos este certificado en un Tomcat y accedemos a este servidor desde Firefox y le decimos que muestre el certrificado de servidor, SI QUE NOS MUESTRA LOS SAN!!!!!

3. Apuntes de José María del Ayuntamiento de Mula

 1. En el servidor de la SEDE tenéis que modificar el nombre del certificado y pass en el server.xml de 

/opt/jboss-4.2.3.GA/server/default/deploy/jboss-web.deployer/server.xml

2. En Backoffice para el SELLO es en keystore.properties de la ruta 

/opt/jboss-4.2.3.GA/server/default/conf/keystore.properties



 



viernes, 27 de diciembre de 2019

Samba y ssh: Compartir recursos en red (3) RECOMENDABLE!!!. ssh. keygen

1. Introducción


Parece ser que cuando apagamos el ordenador y lo volvemos a enchufar tenemos problemas de conexión con las unidades de otros sistemas mapeadas.

En esta entrada vamos a seleccionar lo mejor de los blogs 1 y 2 anteriores.

Para ello vamos a resumir los pasos mas interesantes y luego se hará un script que deberíamos utilizar cada vez que arrancamos los ordenadores.

Si alguien sabe la forma de hacer las conexiones para que sean permanentes, le agradecería que nos aportara la solución.

2. Acceso mediante ssh. Resumen de esta entrada. Compartición de claves RSA


a. Verificar que está instalado Openssh tanto en cliente como en el servidor con el comando:

ssh -V

b. Generar la clave en el cliente mediante

ssh-keygen -q -f ~/.ssh/id_rsa_server_name -t rsa

y nos pide una contraseña( esta contraseña nos la pedirá para acceder por ssh cada vez que rearranquemos el sistema). La clave se guarda en el fichero ~/.ssh/id_rsa siendo "~" la ruta del /home/usuario .

c. Desde el cliente, copiar la clave al sevidor. (y puede pedirnos la contraseña del usuario remoto)

scp ~/.ssh/id_rsa.pub  remoteUser@remoteServer_ip:   # No olvidar los 2 puntos ":" 

d. En el servidor hacemos un append (añadir al final del fichero) de dicha clave al fichero  ~/.ssh/authorized_keys y le añadimos finalmente una línea en blanco:

cat ~/id_rsa_server_name.pub >> ~/.ssh/authorized_keys
echo "" >> ~/.ssh/authorized_keys  # y metemos una linea en blanco!!! MUY IMPORTANTE
rm ~/id_rsa.pub                    # y borramos el fichero que hemos descargado
NOTA: ChatGPT nos dice que se puede copiar como
cat ~/.ssh/id_rsa_server_name.pub | ssh your_user@remote_server 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

NOTA1En el servidor se puede realizar mediante el programa PuTTY que es un shh client. Pero el problema es que no se puede hacer copy + paste. También se puede hacer utilizando el comando "ssh" directamente por ejemplo:
   ssh remopteUser@repoteServer_ip 'cat ~/id_rsa.pub >> ~/.ssh/authorised_keys'
observando las comillas simples.

NOTA2: Tambien se puede utilizar el software Remina que si que deja copiar y pegar. Para conectar hay que apretar la cruz verde de arriba a la izquierda, y llenar los campos como indica la figura




e. Ejecutamos la primera vez el acceso al servidor y nos pedirá la contraseña que le hemos dado al generar la clave

ssh -o PreferredAuthentications=publickey remoteUser@remoteServer_ip

f. Ya podemos ejecutar cualquier comando ssh (rsync, rcp ..) sin que nos vuelva a pedir la contraseña hasta que rearranquemos el sistema

g. Si rearrancamos el sistema basta con ejecutar

ssh remoteUser@remoteServer_ip

y nos pedirá la contraseña que valdra otra vez para el próximo reaarranque. Este paso lo utilizaremos para ejecutar un script cada vez que se arranca la máquina.


3. Montar un disco de un servidor windows en una carpeta local


a. Crear la carpeta local

sudo mkdir /mnt/WINDOWS01_C

el directorio mnt en principio solo accede root, por eso utilizamos sudo. WINDOWS01 es el nombre del servidor windows, y _C lo utilizamos para indicar que es la unidad C.

b. Montar la carpeta remota del servidor en dicha carpeta local con samba. Según Jim Fell y si queremos evitar dar una contraseña (perjudicando la seguridad del sistema) como dice Jesse Web

Si el servidor windows tiene instalada la version 2 de Samba (SMB2Protocol) entonces esto funciona

echo 'rootPassword' | sudo -S mount -t cifs -o "domain=CORPORACION,username=myuser,password=mypassword,vers=2.0,rw,hard,nosetuids,noperm" //192.168.x.x/c$ /mnt/WINDOWS01_C

Si está instalada la versión 3 hay que cambiar vers=2.0 por vers=3.0

Si por el contrario, está activada la versión 1 que es antigua, funcionará con 
 
echo 'rootPassword' | sudo -S mount -t cifs -o "domain=CORPORACION,username=myuser,password=mypassword,sec=ntlm,vers=1.0,rw,hard,nosetuids,noperm//192.168.x.x/c$ /mnt/WINDOWS01_C

 o mejor visto


# Esto me funcionaba ayer y hoy NO!!
echo 'rootPassword' | sudo -S mount -t cifs -o "domain=CORPORACION,username=myuser,password=mypassword,vers=2.0,rw,hard,nosetuids,noperm" //192.168.x.x/c$ /mnt/WINDOWS01_C

# Esto si me funciona hoy!!!
echo 'rootPassword' | sudo -S mount -t cifs -o "domain=CORPORACION,username=myuser,password=mypassword,vers=2.0,rw,hard,nosetuids,noperm" //192.168.x.x/c$ /mnt/WINDOWS01_C

Tener cuidado con no meter espacios en blanco al lado de las comas !!!!!

siendo:
  'rootPassword' la contraseña que pide al hacer "sudo"
  'myuser' el usuario remoto de windows
  'mypassword' la contraseña del usuario remoto de windows
 //192.168.x.x/c$ hace referencia a la unidad C del servidor windows cuya IP es //192.168.x.x
 /mnt/WINDOWS01_C la carpeta local donde mapear


c. Esto nos vale como siempre hasta que rearrancamos el ordenador.

4. Un shell script para después de arrancar el ordenador.


Ahí tenemos el shell script


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
# 1. Activates ssh asking for the pwd of the ssh key
# 2. Mounts remote folders in the /mnt directory

# For using arrays in a shell script:  
# @see: https://www.cyberciti.biz/faq/bash-for-loop-array/

#0. sudo password
rootPwd='rootPassword'


#1. For connecting alfresco files with RSA password. "myRSAPassword"
ssh remoteUser@192.x.x.10

#2.1 Define the local folders to mount
mntFolders[0]=/mnt/WINDOWS01_C
mntFolders[1]=/mnt/WINDOWS02_F
mntFolders[2]=/mnt/WINDOWS03_D

#2.2 Define the remote connections to be mounted to local folders
folders[0]=//192.x.x.1/C$ folders[1]=//192.x.x.2/F$ folders[2]=//192.x.x.3/D$ #3. Unmount the folders for var in "${mntFolders[@]}" do echo "Unmounting ${var}" echo "$rootPwd" | sudo -S umount "$var" done echo Por favor, intro continua.. read continuar #4. Create the folders for var in "${mntFolders[@]}" do echo "Creating mount folder ${var}" echo "$rootPwd" | sudo -S mkdir "$var" done echo Por favor, intro continua.. read continuar #5. Mount the folders # Use c style for loop # get total subscripts in an array total=${#mntFolders[*]} # for (( i=0; i<=$(( $total -1 )); i++ )) do # echo "$rootPwd" | sudo -S mount -t cifs -o "domain=CORPORACION,username=myuser,password=mypassword,vers=2.0,rw,hard,nosetuids,noperm" "${folders[$i]}" "${mntFolders[$i]}"
    echo "$rootPwd" | sudo -S mount -t cifs -o "domain=CORPORACION,username=myuser,password=mypassword,sec=ntlm,vers=1.0,rw,hard,nosetuids,noperm" "${folders[$i]}" "${mntFolders[$i]}"
done echo Por favor, intro continua.. read continuar

Cuando ejecutemos, en la línea 13 nos pedirá la contraseña de la clave RSA y una vez dentro hay que salirse de la sessión ssh mediante Crtl-d

En la línea 25 se quejará pues cuando se arranca el sistema, no hay nada montado en esas carpetas de montaje, pues se han pedido las conexiones.

En la línea 35 también se quejará pues las carpetas ya existen.

Pero a partir de la línea 49 hay que ir con mucho cuidado pues es ahí donde se conectan las unidades remotas a las carpetas del /mnt

5. Averiguar si el Windows Server tiene configurado SAMBA

Según Microsoft Vamos al PowerSell de Windows (no vale para el simple cmd !!!) y ejecutamos para ver si tiene SAMBA 1

Get-SmbServerConfiguration | Select EnableSMB1Protocol

y devolverá True o false



Y para el SAMBA 2 y 3 que normalmente vienen por defecto.

Get-SmbServerConfiguration | Select EnableSMB2Protocol