TeamViewer e porta 8080

Questi sono i classici problemi che ti fanno tirare giù tutti santi del paradiso. 😀 Recentemente ho scoperto che TeamViewer impegna la porta 8080. Questo perchè ho la malsana abitudine di utilizzare la porta 8080 facendo SSH tunneling. Siete avvisati. 😀

Backup tramite rsync e ssh

La vecchia scuola non si batte mai. 😉 SSH ed rsync sono da sempre una coppia vincente. L'altro giorno stavo usando WinSCP e avevo la necessità di copiare dei file da un server remoto ad un altro, senza dover passare per il pc locale. Con mio grande dispiacere noto che WinSCP non offre questa funzionalità e quindi chiuso il programma e avvio KiTTY. Con questa semplice stringa è possibile copiare file/cartelle da un server remoto ad un altro tramite SSH. E' necessario però sapere i path di destionazione, in quando non è possibile "esplorare" il server e non è disponibile nemmeno l'autocompletamento. [crayon-5900da375a440572023197/] Le voci fra le parentesi angolari vanno ovviamente modificate addentandole alle vostre necessità. I parametri per rsync sono i seguenti: -a: modalità archivio -v: verbose attivo -z: compressione dei dati durante il trasferimento -e: copia su PC remoto SSH invece vuole: -p: nel caso non utilizziate la porta standard 22 -i: per utilizzare la chiave privata al posto di username e password.   Sotto ambienti Linux questi strumenti sono disponibili nativamente, in ambienti Windows invece è possibile utilizzare Cygwin.  

Configurare valori di default di putty e kitty

putty e kitty sono due fra i più comuni client SSH per Windows. Personalmente uso kitty, non è altro che un fork del primo e ottimizzato per ambienti Windows. Entrambi i programmi sono due piccolissimi eseguibili portable e permettono in pochi secondi di collegarci tramite SSH ai nostri sistemi. Entrambi offrono una "rubrica" per accedere in modo più veloce, senza dover reimpostare tutti i parametri della connessione. kitty permette di memorizzare anche nome utente e password per la connessione. La password viene salvata sul PC cifrata e non in plaintext. Ogni entry della rubrica tiene in memoria tutte le importazioni del client SSH. La prima voce "Default Settings" include tutte le impostazioni che verranno utilizzate per le connessioni di default. Io solitamente effettuo queste modifiche: disattivazione dei suoni - Terminal -> Bell -> None attivazione del tastierino numero se la tastiera lo mette a disposizione - Terminal -> Features -> Disable applicazion keypad mode aumento delle linee di scrollback - Windows -> Line of scrollback -> 2000 attivazione clear type - Window -> Appearance -> Clear Type font consolas - Window -> Appearance -> Font -> Change cambio nome alla finestra - Window -> Behaviour -> Windows title: -> %%P - %%u@%%h:%%p -

Continua a leggere >>>

Unmount di un datastore NFS da ESXi 5.x

Oggi mi sono trovato davanti alla necessità di dover fare l'unmount di due datastore NFS da un server ESXi. Tramite la web gui dando il comando unmount l'operazione non andava a buon fine, indicandomi che il datastore era attualmente in uso. La prima cosa che ho pensato è che questo fosse causato da qualche ISO montata su alcune VM risiedenti nei datastore da rimuovere, ma niente da fare era tutto OK. Facendo una piccola ricerca mi imbatto in questa KB. La seguo alla lettera e il problema è risolto in baleno. Ricapitolando. Attiviamo il servizio SSH dell'host ESXi sulla quale vogliamo effettuare l'operazione di rimozione.1 Tramite client SSH autentifichiamoci sull'host e diamo il comando: [crayon-5900da375b78e366322107/] Verranno listati tutti i datastore NFS registrati sull'host. Prendete nota del nome dei datastore che volete eliminare e date il comando: [crayon-5900da375b798088367153/] Dato questo comando al successivo login in vSphere client o vSphere webclient il datastore sarà sparito. 😉 Ora ricordatevi di fermare il server SSH. Nella KB linkata sopra trovate i comandi da dare nel caso utilizziate ESXi 4.x. --- INIZIO NOTE ---Per fare questo basta selezionare l'host, andare alla tab "Configuration" e selezionare "Security profiles". Qui ci basterà premere attivare il servizio SSH.

Continua a leggere >>>

SSH two-step authentication con Google authenticator su CentOS 6.x e SELinux

Oggi ho lottato duramente contro SELinux, in una sfida uomo-macchina dove alla fine l'uomo è risultato vincitore. 😀 Non sto qui a spiegarvi l'impatto che ha l'autenticazione a due fattori sulla sicurezza, mi limito a dire "something you know, something you have". Installata la CentOS 6.4 e configurato il webserver passo al SSH server. Cambio la porta, rimuovo l'accesso per l'utente root e limito la connessione solo a certi utenti. Stabilisco i gracetime, le connessioni massime, fail2ban per i brute force e le regole per iptables. Fatto questo passo a configurare il two-step authentification e mi imbatto sempre in "Access Denied". Guardo il log con: [crayon-5900da375bda5289497519/] e noto: [crayon-5900da375bdaf662726748/] Faccio una veloce ricerca su Google e noto che il problema è dovuto a SELinux (Security-Enhanced Linux). Ovviamente col cavolo che lo disabilito solo per far funzionare l'autenticazione a due fattori. I problemi tra SELinux e pam_google_autheticator sono ben noti, fortunatamente esiste un semplice workaround. Approfitto di questo per scrivere un intero post dedicato su come integrare Google Authenticator nel SSH server, sicuramente mi servirà anche a me in futuro. 😀 Sicuramente il pacchetto "pam_google_authenticator" sarà disponibile in qualche repository di terze parti già in forma binaria, io in questo post

Continua a leggere >>>

VNC, RDP ed everything via tunneling SSH

  In questo post voglio andare a spiegare come utilizzare la funzionalità di incapsulamento TCP del protocollo SSH. In questo modo possiamo veicolare traffico VNC, RDP o qualsiasi altra cosa tramite SSD. L'unica cosa che serve è un piccolo server SSH attivo da qualche parte all'interno della rete a cui vogliamo accedere da remoto. Questo server SSH opportunamente esposto sul web e disponibile su una porta diversa dalla 22 fungerebbe da entry point per tutta la rete. Questo ovviamente ci impone di forwardare il traffico del router in entrata dalla porta X verso l'indirizzo IP del server SSH. La porta che andrò ad utilizzare in questo post è la 6010, ovviamente voi potete scegliere quello che più preferite, basta che non sia una porta in uso o quelle canoniche. Il server SSH deve essere piazzato da qualche parte e per ovvi motivi sarebbe meglio se fosse sempre disponibile e magari anche sotto UPS. Le soluzioni a questo problema sono tante: se avete un server potete usare questo, se avete qualche NAS di un certo livello molto probabilmente avete a disposizione un server SSH. Nella peggiore delle ipotesi potete installare una macchina ad impatto 0, probabilmente anche un bel Raspberry Pi

Continua a leggere >>>

Site Footer