Newsgroup: it.comp.os.linux.sys
Titolo: come faccio fare ad una macchina qualcosa di automatico?

so che vi sto smaronando alla grande, e per la vostra immensa pazienza 
vi ringrazio infinitamente (amen)!
spiego meglio l'oggetto:
Server A
Server B
il server B deve far fare automaticamente al server A delle operazioni 
(lanciare un file chiamato banalmente script.sh).
come faccio?
avevo pensato ad un'email che scatenasse un procmail, ma l'ho vista 
abbastanza rozza.
idee?
tnks

 abbastanza rozza.
Madonna se ti vai a complicare la vita! :)
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

writethem ha scritto:

Non sono un sistemista di professione, ma ogni tanto mi capita di 
smanettare su linux....ho appena provato e la soluzione mi pare funzioni
Fai in modo che serverB si possa collegare a serverA via ssh senza 
password (devi usare l'autorizzazione tramite chiavi)
A quel punto è sufficiente che serverB lanci il comando:
ssh UTENTE@indirizzo comando
es: ssh root@serverA sh /percorso/script.sh &
(la & per mandarlo in background in modo che lo script non si fermi dopo 
la disconnessione)
Prova e fammi sapere se va (io ho lanciato con successo un logwatch 
manuale su un server remoto, la sessione ssh si è connessa, ha eseguito 
il comando e si è disconnessa in meno di un secondo, logwatch ha 
macinato in background per i suoi soliti...15-20 secondi e subito dopo 
mi son ritrovato la mail)
Se ho detto qualche minchiata ditemelo che almeno imparo qualcosa :)
Ciao!

 abbastanza rozza.
Questa deve essere fatta propriamente, ma avrebbe il
vantaggio di poter fare eseguire lo script da ogni
luogo con email disponibile...
Riguardo il "propriamente", bisogna evitare che lo
script sia eseguibile da chiunque capace di mandare
un email.
bye,
-- 
piergiorgio

 la disconnessione)
Io ho dovuto usare "screen", ma magari non avevo fatto la stessa cosa...
Enrico

writethem wrote:

cron+ssh ?
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 ssh UTENTE@indirizzo comando
oppure usi uno script expect



riesci a usare screen in crontab?
mi sto perdendo qualcosa di interessante? Se non ricordo male io non sono 
riuscito a inviare le sequenze di tasti nemmeno con expect.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 Se ho detto qualche minchiata ditemelo che almeno imparo qualcosa :)
e vabbe', si vede che non sei sistemista. Credo che lo script dovrebbe 
restare attaccato alla tty anche quando lanciato in questo modo. Non 
riesci a fare logout e pertanto devi usare setsid o nohup.
Adesso non ho voglia di provare.... ma immagino che il comando dovrebbe 
essere:
ssh root@serverA sh setsid script.sh
oppure
ssh root@serverA sh nohup script.sh & >/dev/null



Facebook: Massimo Bacilieri

 ssh root@serverA sh setsid script.sh
Un sistemista che lascia l'accesso ssh direttamente a root??? Mah!


 Un sistemista che lascia l'accesso ssh direttamente a root??? Mah!
un momento, io ho fatto copia e incolla dalla sua riga senza nemmeno 
guardarla :-)
comunque il "permitrootlogin" mi pare che sia impostato su yes di default.


 riferimento sia su server esterni).
me incazzato con procmail perché non mi fa il log su syslog.... ma tu ci 
riesci a farlo loggare in syslog (eventualmente non tramite comando 
logger)?


 default.
Il fatto che sia la politica di default non vuol dire che sia quella 
giusta
-- 
"Le opinioni dei fanatici prescindono dai fatti"
python -c "print 'bG9ybWF5bmFAZ21haWwuY29t'.decode('base64')"
Linux Registered User: 461615

 giusta
ok, entra in ssh come root su questo host e io ti pago una cena:
maxadamo.dyndns.org
Se fosse 'sto gran buco di sicurezza sarebbe impostato su "no" per 
default.
root deve avere una password alfanumerica, con caratteri speciale e più 
lunga più di 12 caratteri (tipo quelle generate da keepassx) e la 
password va cambiata spesso e va aggiunto un fail2ban al terzo tentativo 
errato.
Questa è una cosa che era obbligatoria con telnet, per evitare di far 
passare la password in chiaro (anche se poi il "su -" te la passava 
sempre in chiaro).
Adesso bando alle ciancie e divertiti con il mio server.
Non venire a piangere qui se non ci riesci.


 
infatti è uno dei motivi per cui sto valutando meno ssh, proprio perchè 
le politiche di accesso al server non prevedono l'accesso a root ma un 
su dato da un utente autorizzato. e qui lo script si complica (salvo non 
impazzire con sudo -ed io sposo la politica suse "poco sudo meno sudo") :)



Puoi consentire l'autenticazione solo tramite chiave, e rimuovere la 
password del tutto. Se si potrà entrare solo tramite chiave, nessuno 
riuscirà mai a violare il sistema.
Non siate inutilmente paranoici. Non gestite i server della NASA.


 giusta
la prima cosa che faccio sempre dopo aver installato un server è quella
di andare a mettere a no quella voce, e ad aggiungere la seguente:
AllowGroups sshusers
Completano la configurazione un sano:
addgroup sshusers
addgroup sshusers $aventidiritto
Dove $aventidiritto sono gli utenti "reali" cui concedo la possibilità
di accedere in ssh.
Per vari motivi infatti mi può capitare di dover creare degli utenti
"fittizi", una sorta di demoni che si limitino a gestire script o
funzioni con privilegi non amministrativi o per fare delle aree ftp
autenticate o che altro, e che non voglio che possano entrare in console.


 piangere qui se non ci riesci.
anzi... se non hai niente da fare, provami la autenticazione smtp, imaps, 
imap e vedi se al terzo tentativo ti banna.
Secondo me su imap e imaps non l'ho configurato bene e su smtp potrebbe 
funzionare.


 Completano la configurazione un sano:
Crononauta, ma tu riusciresti a violare un server configurato con 
fail2ban, dove root non ha una password ed è necessaria la chiave?
Stai attento a rispondere, perché il mio server è lì pronto ad aspettarti 
e poi non ci riesci farai la figura barbina con tutti :)
E ti dico che per di più, da me la password non è stata tolta.
L'idea di usare il gruppo "sshuser" non è per nulla malvagia!


 logger)?
No, ho sempre fatto un log nella stessa home dell'utente, in
~/procmail.log o ~/.maillog a scelta.
Francamente non mi sono mai posto il problema, ma a naso non vedo come
possa scrivere in syslog visto che è un processo che gira completamente
coi permessi utente, quando gli viene consegnata della posta da
smistare. Prova ne sia che il log che ti crea ha ownership
tuoutente.tuoutente.
Perché poi leggere i log in syslog? Ammesso di riuscirci, dopo ti
ritroveresti lì dentro i log di *tutti* gli utenti :-O


 ritroveresti lì dentro i log di *tutti* gli utenti :-O
come con fetchmail quando imposti: set syslog
e comunque gli MTA loggano su syslog per tutti gli utenti.
Il problema è che il log di fetchmail su /var/log/mail.log è migliore 
rispetto a quello di procmail.


 fail2ban, dove root non ha una password ed è necessaria la chiave?
Non ci penso neanche.
Però credo che inibire root all'accesso diretto male non faccia. root è
un well-known user e non sia mai che salti fuori un exploit per ssh
che... :-p


 
Dici? se lo lancio così a me non resta attaccato alla console...riesco a 
fare tranquillamente logout e rimane in esecuzione.
Ho fatto uno script test.sh
#!/bin/sh
while /bin/true; do : ; done
l'ho richiamato con ssh -X root@myaddress sh /scripts/test.sh &
ho fatto logout, mi sono loggato nuovamente e da top vedo
31748 root      20   0  3944  560  468 R    3  0.0   0:02.53 sh
oppure
root@cvs-quadcore:/scripts# lsof | grep test.sh
sh        31748       root   10r      REG                9,2         39 
     103547 /scripts/test.sh
Ok che non sono un sistemista (e l'ho specificato), ma ho pure detto che 
l'ho provato, prima di inviare una risposta :)

 riesci a fare logout e pertanto devi usare setsid o nohup.
Aspe, forse ho capito. Intendo che lo script fatto così da cron non 
funziona, ma solo se lo lancio via console? Se è così non ho provato allora!

 Un sistemista che lascia l'accesso ssh direttamente a root??? Mah!
Dipende dai contesti.

 default.
Dipende dalle distro.
Su debian è così, in effetti.

 while /bin/true; do : ; done
ok, evidentemente sono io che non ho provato :-)
A questo punto vuol dire cio' (sempre senza provare e senza leggere uno 
straccio di man-page):
il default è che ssh esegue la shell remota, la quale shell richiede a 
sua volta una tty e quindi se lancerai un processo si attaccherà alla tty.
Evidentemente lanciandolo nella modalità "ssh server comando" piuttosto 
che usare la shell remota e la tty userà direttamente "comando" senza tty.
non penso ci siano altre spiegazioni.


 su dato da un utente autorizzato.
Puoi mettere un cron job di root che controlla la presenza di certe
condizioni e, nel caso in cui tali condizioni si verifichino...
Ad esempio, dal primo server fai un ssh non da root sul secondo server
e fai il touch di un file di controllo.
Se il cron job trova quel file esegue il job e cancella il file 
di controllo, altrimenti esce senza eseguire nulla.
Questa soluzione può andar bene se non hai bisogno di una granularità
inferiore al minuto, ovviamente.

 fail2ban, dove root non ha una password ed è necessaria la chiave?
Se è una etch con openssl non pacthato, sì, ad esempio.

 ritroveresti lì dentro i log di *tutti* gli utenti :-O
Perche` mi permette di centralizzare un logging che altrimenti sarebbe
disperso su n macchine e su n utenti. Personalmente troverei la cosa
utile in almeno un paio di casi (uno e` quello descritto dall'OP)
Enrico

 $UTENTE/.procmail.log
fi
done
infine in crontab
*/1 * * * * root /usr/local/sbin/pmlogcollector.sh
Sarà una soluzione oscena, ma dovrebbe soddisfare lo scopo, no? :-)
Naturalmente se l'utente non chiama il suo logfile .procmail.log non
funzionerà :-/




è geniale... ma secondo me l'OP ci sta tirando scemi. Perchè non 
configurare un crontab sui vari server, se come dici tu, andrebbe 
configurato un crontab di qui e uno di li?
Ha questo punto è meglio un classico ciclo while sul server remoto che 
sta in sleep per 10 secondi (*) e che controlla l'esistenza di un 
file.... quindi se il file esiste fa qualcosa.
* questo è l'unico modo che ho trovate per fare un trigger sull'esistenza 
di un file.


 sull'esistenza di un file.
Beh, inotify o FAM...

 riferimento sia su server esterni).
questa soluzione a me piaceva molto perchè ti consentiva di permettere a 
degli utenti di effettuare una specie di "procedura d'emergenza".
se l'utente ha problemi, io sono alle bahamas, manda un'email ed i 
server si swappano.
il problema è che procmail dovrebbe utilizzare, nel mio caso, comandi 
che normalmente sono a lui inibiti: service e mysqldump. come consento 
ciò senza creare problemi di sicurezza?

 ciò senza creare problemi di sicurezza?
Continuando a fare le cose con l'accetta:
nel procmail dell'utente che scarica la posta (sia esso es. "gestapp"),
metti come regola
:0:
^Subject: ATTIVAZIONE-FUNZIONE
| echo 1 > $HOME/.flagstatus
:0:
^Subject: DISATTIVAZIONE-FUNZIONE
| echo 2 > $HOME/.flagstatus
Poi fai uno script in /usr/local/sbin tipo:
#!/bin/bash
STATUS=`cat /home/gestapp/.flagstatus`
echo 0 > /home/gestapp/.flagstatus
case $STATUS in
1) ... (quel che deve fare per attivare) ;;
2) ... (disattivare) ;;
*) exit 0 ;;
esac
A questo punto metti nel cronjob di sistema questo script eseguito coi
permessi di root. Non è il massimo della sicurezza, perché se qualcuno
scopre i subject delle mail per dare i comandi, può farti degli scherzi,
però non è neanche troppo insicuro perché alla fine non possono mai fare
nulla più di quello che quei due comandi prevedono.
Volendo integrare la cosa, puoi anche fare una "ricevuta di ritorno", cioè
il procmailrc farlo diventare:
:0c:
| mutt -s "Ricevuta attivazione" 
tuoind...@personale.it
 < "."
:0:
^Subject: ATTIVAZIONE
| echo 1 > $HOME/.flagstatus
:0c:
| mutt -s "Ricevuta disattivazione" 
tuoind...@personale.it
 < "."
:0:
^Subject: DISATTIVAZIONE
| echo 2 > $HOME/.flagstatus
In questo modo ogni volta che impartirai un comando via e-mail al server, ti
tornerà una ricevuta a un indirizzo tuo personale: va da sé che se ti torna
una ricevuta per un comando che non hai mai impartito... c'è qualcuno che ti
sta "sabotando" :-)


 
ok, ti ringrazio.
per la cronaca, la sintassi che ho utilizzato è :
:0f (i: vogliono il lock file)
* ^To:.*xxxx@xxxxx\.xxxx\.loc (ovviamente lo vede nel dns e quindi sa a 
chi recapitarlo)
* ^Subject:.ATTIVABLABLABLA
| /bin/ATTIVABLABLA_on.sh (non interpreta la stringa echo etc etc, 
quindi gliel'ho scritta in un file)

 quindi gliel'ho scritta in un file)
Questo è curioso! Io usavo proprio il pipe su echo 1 > .flagstatus, e
funzionava. Anche perché echo è un comando eseguibile al pari dello script
che usi tu, quindi non capisco perché echo non debba andare!
A meno che non sia un problema di shell, prova ad esplicitare a inizio del
.procmailrc SHELL=/bin/bash.


 
bho, credimi sono impazzito :D ora funziona e pace :P

 bho, credimi sono impazzito :D ora funziona e pace :P
Un vecchio adagio dice che se funziona, è giusto :-)


 riesci a usare screen in crontab?
Se non erro
screen -d -m comando
detacha la sessione, in modo che il comando può continuare ad eseguire 
ed io staccarmi e andarmene.
Sinceramente non ricordo se lo usai con crontab o a mano.
Enrico

 nulla più di quello che quei due comandi prevedono.
risolvibile in 3 secondi passando nel corpo della mail una password
dinamica che magari cambia ogni ora. ad esempio un hash md5 composto
dalla concatenazione di una stringa segreta da cambiare di tanto in
tanto e anno mese giorno ora.
per eseguire i comandi devi sapere sia l'algoritmo di concatenazione
che la stringa segreta ed un brute force non sarebbe possibile dato
che ogni ora cambia l'hash.
il controllo si può fare direttamente nello script richiamato da
procmail. prima controlla poi esegue il comando@
sei hai la possibilità di mandare una mail vuol dire che hai internet
e che puoi raggiungere anche una pagina creata per l'occasione che
chiede la stringa segreta e genera l'hash valido in quel momento da
incollare nel corpo mail.

 soluzione sporca:
Giusto per curiosita`, ma provieni dalla Cimmeria?
Enrico

 tanto e anno mese giorno ora.
Non serve reinventare la ruota
apt-cache show opie-server opie-client libpam-opie
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 apt-cache show opie-server opie-client libpam-opie
Io provengo da slackware, o la ruota la reinventi, o non lavori :D

 Un sistemista che lascia l'accesso ssh direttamente a root??? Mah!
Se sei in LAN, perchè no?
Tanto se hai qualcuno dentro la LAN 
1) se è un attaccante esterno, sei fottuto lo stesso, è già entrato
2) se è uno interno, avrà un utente interno, ergo ti frega in un altro modo
accesso a root al massimo lo disabiliti su ssh aperti a tutti fuori, ma 
generalmente NON si apre ssh a tutti fuori.
Infine disabilitare ssh da root ti difende solo (AFAIK) dal bruteforcing per 
un utente conosciuto, null'altro.
-- 
Vide

 Giusto per curiosita`, ma provieni dalla Cimmeria?
Ehm che sarebbe la Cimmeria? :-O


 Ehm che sarebbe la Cimmeria? :-O
Io ricordo di averlo letto (è il nome di una nazione, non so se inventata o
meno, e non mi va di googlare) in "Una notte d'inverno un viaggiatore", di
Calvino.
Enrico: citavi? :)
David
-- 
 . ''`.  Debian maintainer | 
http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- 
http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- 
http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

 Enrico: citavi? :)
Miii, ma qui mancano i fondamentali!!!
Conan, citava Conan...
Tutti e due bocciati! :-)
bye,
-- 
piergiorgio



Compratevi una macchina con le ruote che è meglio.
Le giornate hanno sempre 24 ore, sia che usi la Slack, sia che usi 
un'altra cosa, e il tempo, o lo sprechi per una cosa o lo sprechi per 
un'altra.


 Miii, ma qui mancano i fondamentali!!!
Per fortuna che c'e` ancora qualcuno di acculturato... :D
Enrico
P.S. attualmente sto acquistando la serie a fumetti edita da Panini
Comics. Notevole, anche perche` molte storie sono degli adattamenti
presi dalle novelle di Howard (a tal proposito, chi le pubblica qua in
italia?)

 generalmente NON si apre ssh a tutti fuori.
Dipende, personalmente ho delle macchine (una fisica, due virtuali) in
colocazione presso un ISP, il cui unico modo di accedervi e` via SSH
(ovviamente l'accesso a root e` disabilitato, posso accedere solo
tramite certificato con passphrase e il demone gira su di una porta non
standard)
Enrico

 password (devi usare l'autorizzazione tramite chiavi)
X client intendo il computer o server che deve collegarsi per lanciare  lo 
script.
Sostituire i valori tra parentesi quadre con quelli appropriati.
Crei chiave con certificato (anche tramite puttygen se ti č piů comodo, 
sfrutta comando esporta chiave...)
Salvi la chiave pubblica nel percorso qui sotto consigliato, con permessi 
"ristretti" (600 per esempio):
#server dello script
/home/[utente]/.ssh/authorized_keys2
(vedi qualcosa tipo)
ssh-rsa AAAAB... ...== nomedellachiavesshgenerata
e quella privata nel percorso qui sotto, con permessi "ristretti" (600 per 
esempio):
#server dello script
 /root/.ssh/identita_server2
Quindi fai un test di collegamento, dal client verso il server.
(in questo modo ti aggiunge la chiave pubblica del server sul file 
/root/.ssh/known_hosts)
/usr/bin/ssh -i  /root/.ssh/identita_server2 [utente]@[server]
Ok abbiamo raggiunto obbiettivo ci colleghiamo (personalmente su tutti i 
server disattivo l'accesso tramite password e permetto solo tramite 
certificato).
Ora vediamo come far girare lo script, senza essere eccessivamente 
permissivi, rimanendo collegato in ssh (mentre con altra connessione diretta 
in ssh modifichi il file sudoers)
Modificare file /etc/sudoers, tramite comando visudo
aggiungendo una riga tipo:
[utente] [ip client ssh]=([root]) NOPASSWD: [percorso completo script] 
[eventuale parametri script]
-> non ho fatto prova, forse al posto di [ip client ssh] va messo ALL
eventulamente inizia piů largo tipo, poi stringi fino a quando non funziona 
piů
[utente] ALL=(ALL) NOPASSWD: [percorso completo script] [eventuale parametri 
script]
Poi facci sapere.
Ciao,
ScriptJus

 standard)
Quindi, che sicurezza *in più* ti da root disabilitato, se hai accesso solo 
con certificato e frase magica? 
Cosa cambia a fini pratici? Cosa deve avere un attaccante esterno per poter 
entrare con root disabilitato? E con root abilitato?
-- 
Vide

 italia?)
mondadori. ce ne sono disponibili 3 volumi, quindi non tutte...
e credo che Kull sia quasi introvabile, ormai.
ilSimo
-- 
now playing: 
Talking about a past
And future secret
Most call him once
And future king
                                Blind Guardian - A Past And Future Secret

 solo con certificato e frase magica?
Il fatto di dover indovinare ANCHE la password di root, dopo avermi rubato 
il certificato per l'utente. O di doversi sbattere a cercare un exploit 
locale usabile.
Puo` anche essere utile fare un account apposta senza nessun privilegio se 
non quello di usare "su", e senza accesso ad alcuna cartella in tutto il 
server (tranne quelle necessarie a bash e su. In questo modo sei costretto 
a un passo in piu` anche per accedere ai dati.
Ogni blocco aggiunge sicurezza, per quanto piccolo.
Bye.

 Ogni blocco aggiunge sicurezza, per quanto piccolo.
Sì ma ci sono pratiche fomentate dalla "cultura popolare" che danno un falso 
senso di sicurezza aggiuntiva senza in realtà cambiare una cippa o quasi. 
Quello di disabilitare l'accesso di root sempre e comunque "perchè sì" IMO è 
una di queste pratiche.
Ergo: farlo sì, ma sapendo che è solo un piccolo passo, non il primo e 
sicuramente non l'unico.
-- 
Vide

 Quindi se ti compromettono l'utente potranno essere root in ogni caso.
Dovranno, anche lì, fare bruteforcing per la password di root o trovare
un exploit locale per scalare.

 un exploit locale per scalare.
Sì claro, però quel che voglio dire è che se c'hai qualcuno dentro como www-
data per dire un utente a caso, danni già te ne fa.
-- 
Vide

 www- data per dire un utente a caso, danni già te ne fa.
Hanno qualche difficoltà in più a nascondersi, però, eh...

 un exploit locale per scalare.
Macche`, ti installano un "su" modificato, cosi`
quando uno si collega e` fa "su -" si copiano la
password di root da qualche parte (variazioni a
piacere, ovviamente).
Una volta entrati per la stessa porta, non servono
altre chiavi.
bye,
-- 
piergiorgio

 Macche`, ti installano un "su" modificato
Con l'aiuto del Supremo, credo, visto che /bin/su
è di proprietà di root.
Certo, potrebbero alterare PATH, è vero...

 Certo, potrebbero alterare PATH, è vero...
Appunto, potrebbero mettere "su" dentro ~/bin e
cambiare la priorita` del $PATH.
Persino se lanci /bin/su potrebbero interccettarti.
Per esempio cambiando IFS, oppure lanciando un wrapper
sopra "bash" che intercetta tutto quello che fai.
Come scrivevo, varie ed eventuali.
Se accedono all'account, questo diventa intoccabile.
bye,
-- 
piergiorgio

 e credo che Kull sia quasi introvabile, ormai.
:(
Enrico

It was 23:59, mercoledì 1 aprile 2009, and Enrico 'Henryx' Bianchi, in
message <gr0o3m$5bc$1...@abraham.hellfish.home> wrote:

si, situazione bruttina (ma altre sono peggiori)...
comunque per Kull magari su ebay trovi (la mia copia l'ho trovata *nuova*)
ilSimo
-- 
now playing: 
Shine on, Rising Star
We travelled such a long way but still you seem so far
Shine on, Rising Star
Forever light the darkness in our hearts
Rising Star, Rising Star
                                Gammaray - Shine On

 Hanno qualche difficoltà in più a nascondersi, però, eh...
Senza dubbio... poi dipende sempre dal tipo di attacante e attacco, se è 
qualcosa ad-hoc per prendere dati a *te* oppure se è qualcosa di generico 
per usare fin quando è possibile le tue risorse per fare altri lavori.
-- 
Vide