Jan 19

SSH tricks: control usuaris i col·lisions en la fingerprint

Reading time: 2 – 3 minutes

Un parell de tricks per l’SSH un pel servidor (sshd) i l’altre pel client (ssh).

Si volem deixar accedir només a alguns usuaris al nostre sistema via SSH s’ha de posar al fitxer /etc/ssh/sshd_config la comanda AllowUsers. Aquest eginy l’he extret de Restrict SSH per user.

Un exemple:

AllowUsers root oysteivi otheradmin

L’altre enginy és molt útil quan programem scripts que usen per exemple: scp, rsync o d’altre similars. A vegades per molt que usem un sistema d’autenticació per clau pública amb ssh això no és suficient perquè hi pot haver un conflicte den la fingerprint que tenim guardada (o no) del servidor on anem a connectar. Llavors se’ns pregunta si volem guardar aquesta fingerprint sinó la tenim guardada o si assumim que hi ha conflicte entre la fingerprint guardada i la que ens esta enviant el sevidor. Per més detalls sobre el problema podeu consultar aquest article de securityfocus SSH Host Key Protection. A més segur que aquest exemple ajudarà a refrescar la memòria sobre el que em refereixo.

 $ ssh ssh-server.example.com
  The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
  RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
  Are you sure you want to continue connecting (yes/no)? yes

Per tal de controlar el comportament d’aquest event ho podem fer amb el paràmetre StrictHostKeyChecking=[yes|no|ask], això ho podem posar a /etc/ssh/ssh_config o bé a la línia de comandes a través del flag -o.

Exemple forçant la comprovació:

  $ ssh -o 'StrictHostKeyChecking=yes' ssh-server.example.com
  No RSA host key is known for localhost and you have requested strict checking.
  Host key verification failed.

Exemple preguntant la comprovació:

  $ ssh -o stricthostkeychecking=ask ssh-server.example.com
  The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
  RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
  Are you sure you want to continue connecting (yes/no)? yes
Dec 07

Montat unitats de xarxa via SSH amb Windows

Reading time: < 1 minute

Via caballe.cat he descobert que es pot mapejar una unitat de xarxa amb windows a través del protocol SSH. Concretament en la seva variant SFTP. Això s’ha de fer amb el software sftpDrive. Segons diu en Xavier funciona perfectament. Jo fa molt temps ja us havia parlat del sshFS per linux que funciona via LUFS. Jo amb la versió de linux hi he treballat força i de vegades dona alguns problemes, perquè al borrar o editar fitxers té comportaments una mica extranys. No tan si ho fem des de consola sinó com quan ho fem des de programes. Concretament jo els problemes els havia tingut amb editors de codi (IDEs de programació).

Nov 23

Script: entrar en un servidor protegit amb iptables

Reading time: 3 – 4 minutes

Un fenòmen molt humà i per tant habitual, quan estem configurant un firewall amb iptables contra un servidor remot al que no tenim accés, posem per cas que esta als EUA, és el de fer-nos fora a nosaltres mateixos al executar l’script que llença les regles de filtrat. Llavors podem reiniciar la màquina a través del panell de control que ens ofereix l’ISP, o qualsevol altre procediment. El problema esta en que si aquest script s’executa només iniciar la màquina en el rc.local o qualsevol altre procés d’arrencada serà impossible que ens autentiquem per SSH després de que arrenqui el servidor.

Però… com tots els que hem vist arrencar un servidor en linux sabem, entre crida el servidor SSH i es llença l’script de les regles del firewall, pot passar 1s (~aprox) segons el ràpid que sigui el servidor. Si fossim prou ràpids autenticant-nos a la màquina podriem llençar un procés que es llencés després de l’script de les iptables i aquest script ens podria tornar a donar accés a la màquina, per exemple, netejant les regles del firewall i canviant la política per defecte.

Doncs bé, després de provar de fer-ho a mà vaig arribar a la conclusió que malgrat haver fet un curs de mecanografia quan era petit, encara era massa lent i l’enllaç es tallava abans no pogués recuperar el control de la màquina. Així doncs, vaig decidir comprovar si la màquina disposava d’un llenguatge que s’anomena expect i que es basa en TCL/TK. Aquest llenguatge com ja he comentat algún cop al blog ens permet automatitzar processos intereactius. Així doncs, vaig fer-me aquest petit script:

#!/usr/bin/expect -f

spawn /usr/bin/ssh root@ip_del_servidor expect "ssword: $" { send "password_de_root\n" } expect "#" { send "echo \"sleep 30;iptables -F;iptables -P INPUT ACCEPT;iptables -P FORWARD ACCEPT;iptables -P OUTPUT ACCEPT\" > rest.sh \nchmod 700 rest.sh\nnohup ./rest.sh\nsleep 5\n./rest.sh" } interact

Fixeu-vos que és molt senzill, el que fa és connectar-se per SSH amb el servidor remot, enviar el password de root; després crea un script molt senzill que es guarda a rest.sh li dona permisos d’execusió i l’executa amb un nohup perquè si la nostre consola perd la connexió amb el servidor l’script no deixi d’executar-se. El contingut d’aquest petit script que es crea és tan senzill com esperar-se 30s perquè així s’assegura que la màquina ha acabat el procés d’arrencada i després neteja les regles del firewall i posa les polítiques en ACCEPT. Així doncs, ja podem entrar sense problemes.

Doncs bé amb això un ping que vigili quan s’ha aixecat la targeta de xarxa i després executant aquest script que us he posat aquí, jo el dimarts vaig aconseguir ressussitar un servidor remot al que no tenia accés físic, només forçant reboots a través del panell de control que em van facilitar. El senzill que hagués estat tenir una consola d’administració remota i tot llest amb un segon. Però suposo que la necessitat desperta l’enginy, no?

Sep 18

La comanda screen

Reading time: 2 – 4 minutes

Doncs la veritat és que amb els anys que fa que uso linux que no són pocs ja, havia sentit ha parlar moltes vegades d’eines com l’screen però no sé per quin motiu mai m’havia dedicat a mirar-les a fons. Doncs bé aprofitant que ara mateix estic a Andorra més sol que un mussol, que no fan res a la TV i que no tinc cap peli en DIVX per mirar al portatil m’he llegit un article de NOVELL que tenia descarregat sobre el tema de l’screen i realment m’he quedat sorprés de la potència i la de coses interessants que ens permet fer.

Havia pensat en reescriure el manual que acabo de llegir en anglès en català però crec que no val la pena perquè el manual és molt simple. Així que us recomano que el mireu: Turbocharge an SSH Connection with screen (cache local)a més és molt fàcil de llegir i ple de captures de pantalla. El que si que faré és argumentar-vos perquè l’heu de llegir i què té de bo l’screen.

Una de les avantatges que més m’han agradat és el fet de poder mantenir sessions amb aplicatius de linia de comanda sense que aquestes es perdin quan perdem una sessió remota. O sigui, que podem fer el mateix que fem amb la comanda nohup (man nohup) deixar aplicacions funcionant quan sortim de la sessió però a més aquestes aplicacions poden ser interactives i les podem recuperar quan vulguem. Bàsicament la diferència esta en que nohup llença comandes sense associar-les a un tty i screen treballa amb pseudo-ttys (pts).

L’altre avantatge que m’ha agradat molt és el fet de poder tenir multiples sub-consoles dins de la propia consola remota. O sigui, que només obrint un SSH (un sol socket) podem tenir més d’un programa funcionant a la vegada (encara que sigui interactiu) i podem anar canviant de l’un a l’altre sense haver d’obrir més sessions. En el document de NOVELL usen d’exemple 3 comandes simultanees: top, vi i ps. A més ens permet saltar d’una sessió a l’altre o fer coses tan espectaculars com partir la pantalla i veure la sortida de les dues aplicacions simultaneament.

La potència de la comanda no acaba aquí, podeu copiar i enganxar texte entre consoles i moltes altres coses així que us recomano que us passeu pel wiki del programa i aprofundiu en el tema si us ha agradat tan com a mi.