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. 😀 …
Tag: 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. rsync -avz -e "ssh -p 22 -i <private-key>" <path-file/cartelle-da-copiare> [email protected]:<path-di-destinazione> 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. …
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 - …
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. ((Per fare questo basta selezionare l'host, andare alla tab "Configuration" e selezionare "Security profiles". Qui ci basterà premere attivare il servizio SSH. A servizio attivo ci comparirà un warning, è naturale e questo sta ad indicare una potenziale falla di sicurezza. Ci basterà stoppare il servizio SSH una volta terminato il lavoro.)) Tramite client SSH autentifichiamoci sull'host e diamo il comando: esxcli storage nfs list Verranno listati tutti i datastore NFS registrati sull'host. Prendete nota del nome dei datastore che volete eliminare e date il comando: esxcli storage nfs remove -v Dato questo comando al …
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: tail /var/log/secure -n 100 e noto: Jul 16 17:15:32 sshd(pam_google_authenticator)[5646]: Did not receive verification code from user Jul 16 17:15:32 sshd(pam_google_authenticator)[5646]: Invalid verification code Jul 16 17:15:32 sshd(pam_google_authenticator)[5646]: Failed to update secret file "/home//.google_authenticator" 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 …
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 …