# chiarimenti su sicurezza in openssh

## sometimes

 *Quote:*   

> sshd_config
> 
> RSAAuthentication yes
> 
> PubkeyAuthentication yes
> ...

 

il resto è commentato.

Accetta solo connessione trame chiave privata, vero?

Mi trovo i log pieni di tentavi di accesso (falliti) da estranei, è normale?

Posso ritenermi sufficentemente protetto?

Insomma posso stare tranquillo che senza la chiave nessuno entra?

Grazie.

----------

## Manuelixm

Cambia anche la porta del server sshd.

----------

## .:chrome:.

 *Manuelixm wrote:*   

> Cambia anche la porta del server sshd.

 

CAMBIARE LA PORTA DEL SERVER È SOLO UN BASSO TENTATIVO ATTUATO DA SISTEMISTI INCAPACI (tentativo per altro inutile)

se cambi la porta del server, le connessioni possono essere difficilmente identificate, quindi puoi incontrare problemi (sicuramente succederà) quando le connessioni passano attraverso firewall, o filtri vari.

quei tentativi di connessione sono del tutto inefficaci, quindi di fatto innoqui. se proprio danno fastidio basta DISATTIVARE OGNI POSSIBILITÀ DI EFFETTUARE IL LOGIN CON PASSWORD, e consentirlo solo con chiave.

solo così il server SSH è veramente sicuro, dal momento che il login con password è SEMPRE IRRIMEDIABILMENTE insicuro.

se sposti la porta del servizio, bastano pochi secondi per identificare la nuova porta, e si ritornerebbe nuovamente al punto di partenza. se i servizi sono fatti per stare su una data porta, non vedo perché dovrebbero essere cambiati. finiamola con queste idiozie da utenti windows.

l'unica vera soluzione a quel problema è TOGLIERE LA POSSIBILITÀ DI EFFETTUARE IL LOGIN CON PASSWORD

----------

## Manuelixm

Qui non sono proprio d'accordo, cambiando la porta riduci drasticamente i tentativi riscontrati nei log, il mio consiglio veniva dopo aver già impostato l'accesso tramite chiave pubblica/privata.

----------

## .:chrome:.

 *Manuelixm wrote:*   

> Qui non sono proprio d'accordo, cambiando la porta riduci drasticamente i tentativi riscontrati nei log, il mio consiglio veniva dopo aver già impostato l'accesso tramite chiave pubblica/privata.

 

allora... vediamo di capirci...

se abiliti l'accesso SOLO con chiave, ogni tentativo con password fallisce miseramente esattamente come se la macchina non esportasse nessun servizio SSH.

cambiando la porta i tentativi diminuiscono drasticamente. questo è vero

però ribadisco che quei tentativi sono pressoché innoqui. uno che vuole entrare per davvero nella tua macchina, lo fa anche se cambi porta, ed il fatto di permettere il login con password gli semplifica la vita non poco.

se anche cambi la porta è possibile con un nmap di pochi secondi identificare tutte le porte aperte (in modo generico) e successivamente effettuare una legale richiesta ad ognuna di esse, e vedere a quale di queste risponde il server SSH. in tutto ci metti pochissimo a trovare la nuova porta.

si tratta solo di un espediente del tutto inutile, che al massimo può dare problemi su reti filtrate.

dal momento che è risaputo essere poco più che una vaccata, e non un provvedimento serio, non mi sembra proprio il caso di darlo come indicazione a chi chiede aiuto. ci pensano già i giornali a disinformarci non serve che lo facciamo anche fra di noi

----------

## pava_rulez

 *k.gothmog wrote:*   

>  *Manuelixm wrote:*   Cambia anche la porta del server sshd. 
> 
> CAMBIARE LA PORTA DEL SERVER È SOLO UN BASSO TENTATIVO ATTUATO DA SISTEMISTI INCAPACI (tentativo per altro inutile)
> 
> se cambi la porta del server, le connessioni possono essere difficilmente identificate, quindi puoi incontrare problemi (sicuramente succederà) quando le connessioni passano attraverso firewall, o filtri vari.
> ...

 

Evviva le risposte civili...   :Laughing: 

----------

## randomaze

 *k.gothmog wrote:*   

> se cambi la porta del server, le connessioni possono essere difficilmente identificate, quindi puoi incontrare problemi (sicuramente succederà) quando le connessioni passano attraverso firewall, o filtri vari.

 

"sicuramente succederà" é tutto da vedere. Così come é tutto da vedere che "bastano pochi secondi", quando la nuova porta é oltre la centomila.

Quell'escamotage elimina un pò di spazzatura dai log, e taglia fuori il 90% degli imbecilli che, non sapendo come passare il tempo,  giocano con due script scaricati da internet.

Non é certo la soluzione ultima per salvare il mondo, ma non vedo perché scagliarsi contro la cosa con toni così vivaci.

----------

## sometimes

 *k.gothmog wrote:*   

> ...DISATTIVARE OGNI POSSIBILITÀ DI EFFETTUARE IL LOGIN CON PASSWORD, e consentirlo solo con chiave.
> 
> 

 

per farlo, devo aggiungere e/o modificare qualcosa nel file di configurazione di prima?

e se volessi cambire la porta, come faccio a sapere quali porte posso usare?Last edited by sometimes on Mon Mar 27, 2006 12:41 pm; edited 1 time in total

----------

## .:chrome:.

 *randomaze wrote:*   

> Quell'escamotage elimina un pò di spazzatura dai log, e taglia fuori il 90% degli imbecilli che, non sapendo come passare il tempo,  giocano con due script scaricati da internet.
> 
> Non é certo la soluzione ultima per salvare il mondo, ma non vedo perché scagliarsi contro la cosa con toni così vivaci.

 

scusatemi, i toni non volevano essere vivaci

comunque sia hai detto bene. si tratta di un escamotage, non di una soluzione ad un problema.

 *randomaze wrote:*   

> quando la nuova porta é oltre la centomila

 le porte sono 65535

----------

## .:chrome:.

 *sometimes wrote:*   

> per farlo, devo aggiungere e/o modificare qualcosa nel file di configurazione di prima?
> 
> e se volessi cambire la porta, come faccio a sapere quali porte posso usare?

 

PasswordAuthentication no

ChallengeResponseAuthentication no

comunque leggi la man di sshd_config per completezza, e dai un'occhiata ai commenti nel file, che sono abbastanza esplicativi

----------

## sometimes

 *k.gothmog wrote:*   

>  *sometimes wrote:*   per farlo, devo aggiungere e/o modificare qualcosa nel file di configurazione di prima?
> 
> e se volessi cambire la porta, come faccio a sapere quali porte posso usare? 
> 
> PasswordAuthentication no
> ...

 

ok. e grazie.

----------

## Manuelixm

Credo che la cosa importante sia identificare per che fine ha senso implementare tutta questa sicurezza ed essere così paranoici. Che interesse ha uno ad entrare in un server domestico tramite ssh? Per scaricarsi i vari xxx che ha la vittima in locale? IL discorso cambia se si parla di un server aziendale, ma in questo caso non lo abiliterei nemmeno.

Non credo di aver scritto vaccate, anzi ho scritto cose che riduco gli attacchi fuffosi e soprattutto la lunghezza dei log che a molti dannno fastidio.

----------

## Luca89

 *Manuelixm wrote:*   

> Credo che la cosa importante sia identificare per che fine ha senso implementare tutta questa sicurezza ed essere così paranoici. Che interesse ha uno ad entrare in un server domestico tramite ssh? Per scaricarsi i vari xxx che ha la vittima in locale? IL discorso cambia se si parla di un server aziendale, ma in questo caso non lo abiliterei nemmeno.
> 
> Non credo di aver scritto vaccate, anzi ho scritto cose che riduco gli attacchi fuffosi e soprattutto la lunghezza dei log che a molti dannno fastidio.

 

Avere il proprio server domestico hackerato non credo che faccia piacere a nessuno, se cambiando due righe in un file hai un livello di sicurezza ottimo non vedo il motivo per cui non bisogna farlo. Nei server aziendali perchè non lo vorresti abilitare ssh? Se serve la possibilità di agire sul pc da remoto è l'ideale, l'unico protocollo che ti da ottime garanzie di sicurezza.

----------

## SilverXXX

Calma, il tono di k.gothmog è il solito, manca un pò di tatto  :Very Happy:  ma in genere ha ragione e argomenta sempre bene i suoi motivi; non c'è motivo di scaldarsi.

----------

## Manuelixm

SilverXXX era rivolto a me? Se sì ti stai sbagliando di grosso  :Wink:  , conosco k.gothmog e conosco i suoi modi, solo che il mio intervento non mi sembrava troppo una cazzata.

Per Luca89, il mio discorso era solo relativo ad un'ulteriore metodo per ridure gli attacchi almeno dai lameroni. Nel mio caso se su un server voglio aumentare il più possibile la sicurezza metto meno servizi possibili e lascio solo il minimo indispensabile, l'ssh non lo considero indispensabile, poi dipende dai casi sempre da valutare. C'è un interessante documento sul sito ufficiale che illustra molto bene come aumentare la sicurezza, almeno io l'ho trovato molto utile: http://www.gentoo.org/doc/en/security/security-handbook.xml., non solo esiste tutta la documentazione relativa ad hardened gentoo.

----------

## SilverXXX

 *Manuelixm wrote:*   

>  ...CUT... 

 

Era in generale, non intendevo additare o offendere nessuno  :Smile: 

Devo informarmi su ssh, lo uso solo internamente... ma magari, utilizzando il metodo con chiave...... mmmh  :Idea: 

----------

## X-Drum

ma non c'erano altri 3000406855490324*2 threads che trattavano lo stesso argomento?

 *Manuelixm wrote:*   

> Credo che la cosa importante sia identificare per che fine ha senso implementare tutta questa sicurezza ed essere così paranoici. Che interesse ha uno ad entrare in un server domestico tramite ssh?

 

non è questione di interesse...il fine ultimo del 70% di "attacchi fuffosi" che probabilemente

anche tu ricevi sono sferrati da script che "infettano" le altre macchine per poi usarle

per cercare di contaminarne delle altre: spesso su un mio server vedo bannati ip

di macchine di aziende (tipo aziende che si mettono il sito su una macchina in housing)

che evidentemente sono anche all'oscuro di questi eventi...no ma gg!

----------

## Manuelixm

No X-Drum, io non li ricevo faccio tutto a livello firewall sul router e sul server rimane tutto in default, tranne tutto quello descritto nel link precedente postato e indicato nella documentazione del progetto hardened. I fuffosi vanno in DMZ1 su indirizzo startrecchiano...  :Razz:  .

Aggiungo, se le cose non sono cambiate, il principale obbiettivo degli attacchi, se non erro, rimane la porta 80 e tutto quello legato ad http.

----------

## X-Drum

 *Manuelixm wrote:*   

> 
> 
> Per Luca89, il mio discorso era solo relativo ad un'ulteriore metodo per ridure gli attacchi almeno dai lameroni. Nel mio caso se su un server voglio aumentare il più possibile la sicurezza metto meno servizzi possibili e lascio solo il minimo indispensabile, 
> 
> 

 

ok ma se ti servono N servizi perche' il Server (con la S ovvero != da macchina casalinga) lo usano 60 persone che vogliono

questo e quello e l'altro che fai? "no subversion non lo metto su perche' una porta in piu' è una falla potenziale in piu!"

 *Manuelixm wrote:*   

> 
> 
> l'ssh non lo considero indispensabile, poi dipende dai casi sempre da valutare. 
> 
> 

 

per certa gente è indispensabile ed insostituibile, poi se il tuo server non è accessibile e...

[quote="sciabarra.com"][...]

Non riesci ad andare ogni giorno alla server farm sotto il Gran Sasso? Come sarebbe a dire che mi stai telefonando da lì? Ti hanno fermato perché è scaduto il tesserino e ti hanno rinchiuso nella cella perché dicono che sei un hacker? Perché urli? La corrente elettrica? Vogliono che gli dici dove sono i tuoi amici, quelli che stanno preparando l'attentato? Pronto? Pronto! Pronto. [...][quote] 

 *Quote:*   

> No X-Drum, io non li ricevo faccio tutto a livello firewall sul router e sul server rimane tutto... [bla bla bla]

 

possibile scenario (uno dei piu' comuni):

-1 macchina

-non accessibile fisicamente

-che devi poter amministrare da remoto

cosa fai? ovvio prendi tutte le precauzioni del caso come credo tu abbia fatto adesso, ma il punto è

quanto dicevo "che probabilemente anche tu ricevi" era per dire: non ti puoi sottrarre ai tentativi

di lamer & c alla fine il tuo maledetto log e purtroppo la tua macchina sarranno zeppi di tentativi

di login, nella migliore delle ipotesi, falliti

----------

## .:chrome:.

 *Manuelixm wrote:*   

> No X-Drum, io non li ricevo faccio tutto a livello firewall sul router e sul server rimane tutto in default

 

continuo a sollevare il problema a cui non mi è stata data nessuna risposta.

nelle reti filtrate come si deve, non come si legge su topolino, i firewall filtrano anche le porte in uscita. cosa fai se devi collegarti alla porta 22222 e ti trovi dietro un firewall che permette si lìuscita sulla porta 22, ma non sulla 22222?

e comuqnue ribadisco che si tratta di un escamotage, non di una soluzione al problema, perché quello rimane sempre.

inoltre il problema non è la spazzatura nei log, ma quello che ti ha segnalato giustamente X-Drum. come la mettiamo con quello?

il login solo con chiave non è un mezzo da attuare solo ed esclusivamente sulle macchine per produzione. è un mezzo da usare SEMPRE

----------

## Manuelixm

X-Drum non credo che il discorso fosse relativo ad un server aziendale, in quel caso io ho scritto questo precedentemente:

 *Quote:*   

> Nel mio caso se su un server voglio aumentare il più possibile la sicurezza metto meno servizi possibili e lascio solo il minimo indispensabile, l'ssh non lo considero indispensabile, poi dipende dai casi sempre da valutare.

  Probabilmente non sono stato chiaro, infatti la frase è contorta sarà colpa dell'influenza, intendevo che per ogni caso bisogna valutare.

Nella discussione mi è sembrato di capire che si trattasse di un server casalingo e ho sempre parlato riguardo a quello se non erro.

Ultima cosa, forse la più importante, il mio intervento era solo una cosa in più a quello che era già stato fatto, ho dato per scontato:

- accesso negato a root tramite ssh;

- accesso tramite chiave pubblica/privata con DSA;

- numero di tentativi errati di login limitati;

ultima cosa che ho aggiunto io è stato di cambiare la porta di default del server sshd in una alta per limitare le rotture dei log conteneti user administrator, o guest, ecc... Non mi sembra difficile.

----------

## Manuelixm

k.gothmog 

 *Quote:*   

> nelle reti filtrate come si deve, non come si legge su topolino, i firewall filtrano anche le porte in uscita. cosa fai se devi collegarti alla porta 22222 e ti trovi dietro un firewall che permette si lìuscita sulla porta 22, ma non sulla 22222?

 

In quel caso lascio tutto in default(come descritto precedentemente) sulla macchina, ma lavoro sul firewall che è nato apposta. Posso nattare una porta alta e redirigerla sulla porta 22 del server, ma mi esprimo così male?

----------

## X-Drum

 *Manuelixm wrote:*   

> ma mi esprimo così male?

 

non so che dirti evidentemente non ci stiamo capendo,

quindi io mi fermo qui è inutile proseguire oltre siamo sempre 

ad un punto fermo

----------

## Manuelixm

X-Drum concordo pienamente.

----------

## FonderiaDigitale

 *k.gothmog wrote:*   

>  *Manuelixm wrote:*   Cambia anche la porta del server sshd. 
> 
> CAMBIARE LA PORTA DEL SERVER È SOLO UN BASSO TENTATIVO ATTUATO DA SISTEMISTI INCAPACI (tentativo per altro inutile)
> 
> 

 

Grazie. quindi sono un incapace?

 *Quote:*   

> 
> 
> se cambi la porta del server, le connessioni possono essere difficilmente identificate, quindi puoi incontrare problemi (sicuramente succederà) quando le connessioni passano attraverso firewall, o filtri vari.
> 
> 

 

falso. esempio. mettilo su una tcp 110, e vedi. io il mio openvpn di lavoro ad esempio, l'ho messo su quella porta. passo ovunque.

 *Quote:*   

> 
> 
> quei tentativi di connessione sono del tutto inefficaci, quindi di fatto innoqui. se proprio danno fastidio basta DISATTIVARE OGNI POSSIBILITÀ DI EFFETTUARE IL LOGIN CON PASSWORD, e consentirlo solo con chiave.
> 
> 

 

Questo non ti copre da Buffer Overflow e d aexploit sul demone.

 *Quote:*   

> se sposti la porta del servizio, bastano pochi secondi per identificare la nuova porta
> 
> 

 

Dubito fortemente.

se sposti il servizio su una porta alta, eg 5567, per trovarmela devi farmi uno scan semantico di TUTTE le porte, e come ben sai sicuramente cosi mi accorgo che ci stavi provando.senza contare che un portscan detector qualsiasi ti chiude fuori ben prima (es. psad)

la soluzione nel post dopo.

----------

## FonderiaDigitale

 *sometimes wrote:*   

> sshd_config
> 
> ```
> 
> RSAAuthentication yes
> ...

 

No.

Aggiungi

```
UsePrivilegeSeparation yes

PermitUserEnvironment no

```

Dopo questo hai due opzioni, in ordine di efficacia.

- installi un programa sentinella che controlla che qualcuno non stia tentando un brute force attack su quella porta, io uso http://denyhosts.sourceforge.net/

- installi un knocking daemon, ovvero un coso che ti mantiene chiusa (lavorando con iptables) quella porta fintanto che tu dall'esterno non invii una sequenza particolare di pacchetti, configurabile (ad esempio tre ping e un syn verso la porta 5600, o un hash md5, o come preferisci)e ti abilita la connessione per quella sessione.

in questo modo sei sicuro che solo TU e chi hai abilitato possa accedere al servizio, per gli altri la porta e' del tutto trasparente (se in iptables e' configurata come REJECT)

ps. in linea generale, invece di offendere la gente e erigersi a massimi custodi del sapere, e' sempre bene semplicemente dare le proprie opinioni rispettando gli altri. e questo vale per tutti, secondo me.

----------

## gutter

 *FonderiaDigitale wrote:*   

> 
> 
> ps. in linea generale, invece di offendere la gente e erigersi a massimi custodi del sapere, e' sempre bene semplicemente dare le proprie opinioni rispettando gli altri. e questo vale per tutti, secondo me.

 

Al di la del discorso puramente informatico, credo che questa sia la cosa più interessante scritta in questo topic.

----------

## makoomba

 *k.gothmog wrote:*   

> se anche cambi la porta è possibile con un nmap di pochi secondi identificare tutte le porte aperte (in modo generico) e successivamente effettuare una legale richiesta ad ognuna di esse, e vedere a quale di queste risponde il server SSH. in tutto ci metti pochissimo a trovare la nuova porta.

 

beh, no.

i "wannabe hackerz" fanno generalmente scan di classi per identificarne gli host vulnerabili e molto spesso i frw sono configurati in DROP.

questo implica che, per determinare se la porta sia aperta o meno, lo scanner deve attendere lo scadere di un certo timeout.

64K porte X n° host sarebbe troppo lento, per cui vengono prese di mira solo le porte "canoniche"

non sono contrario all'uso di porte non standard per ssh, ma è pur vero che resta il problema dei firewalls.

in alcune webfarms, ad esempio,  esistono delle politiche molto stringenti a riguardo.

in assenza di limitazioni, preferisco di gran lunga spostare la porta che utilizzare soluzioni tipo denyhosts/portknocking.

----------

## Kernel78

ho dovuto mettere in ascolto un'altra porta perchè sono dietro un proxy che non mi faceva collegare alla 22 (sono incompetente anche io ? direi di si ma per altri motivi  :Laughing:  )

Vorrei provare portknock ma essendo dietro questo cavolo di proxy avrei problemi a "bussare" ...

----------

## FonderiaDigitale

potresti bussare sulla porta X da te specificata inviando 2 syn,1 ack,e 1 stringa a quella porta.

e' giusto un'idea.

----------

## makoomba

@Kernel78

non puoi semplicemente limitare l'ip sorgente a quello del proxy ?

----------

## Kernel78

@FonderiaDigitale

Lo sapevo che avrei dovuto guardare meglio il suo funzionamento, pensavo che si dovessero per forza usare altre porte ...

@makoomba

Ci avevo pensato ma ad aprile cambio finalmente lavoro (e lascio questi simpaticoni nella cacca ma questo è OT) e mi piace potermi collegare anche da altre parti.

----------

## Frez

Se non ricordo male era un argomento gia' trattato ed erano gia' volati "ceffoni"  :Smile:  sull'uso della porta 22, e anche sulla comodita' dell'accesso con password, fermo restando che l'accesso passwordless sia piu' sicuro.

Alla fine era venuto fuori DenyHosts (in portage) che sembrava un sistema comodo e ragionevole a molti

----------

## makoomba

questo, come altri, è un 3d della serie "a volte ritornano".

ognuno, alla fine, ha una sua teoria e sceglie la soluzione che ritiene migliore.

personalmente, non uso sw che va ad interagire dinamicamente con iptables, senza nulla togliere all'utilità dei programmi in questione.

----------

## Manuelixm

[OT]Noto con dispiacere che il forum è mutato e sempre più spesso l'educazione non esiste, avessi scritto una stupidata immane! Una volta un forum era un posto dove si poteva discutere civilmente, cercando di portare l'argomento su qualcosa di produttivo, ora per inserire un post bisogna essere guru, mi limiterò a leggere i post altrui e rinnovo sempre la mia ammirazione per fonderiadigitale.[/OT]

----------

## nick_spacca

 *Manuelixm wrote:*   

> [OT]Noto con dispiacere che il forum è mutato e sempre più spesso l'educazione non esiste, avessi scritto una stupidata immane! Una volta un forum era un posto dove si poteva discutere civilmente, cercando di portare l'argomento su qualcosa di produttivo, ora per inserire un post bisogna essere guru, mi limiterò a leggere i post altrui e rinnovo sempre la mia ammirazione per fonderiadigitale.[/OT]

 

Per evitare di sfociare in un altro OT lungo millemila km consiglio eventualmente di inserire le proprie idee/opinioni sull'educazione del forum in questo thread

----------

## .:chrome:.

 *Manuelixm wrote:*   

> In quel caso lascio tutto in default(come descritto precedentemente) sulla macchina, ma lavoro sul firewall che è nato apposta. Posso nattare una porta alta e redirigerla sulla porta 22 del server, ma mi esprimo così male?

 

non hai capito cosa intendevo

a casa hai un server sulla 2222

sei al lavoro, e vuoi collegarti a casa. scopri però che il firewall, dove lavori, è fatto come si dovrebbe, e permette di collegarti alla porta 22 ma non 2222

che fai? non puoi fare altro che fare ponte su una terza macchina, con tutto quello che deriva da questo (lentezza della connessione. latenza, carico sulle macchine, ecc...) e la macchina che fa da ponte resta comunque insicura.

se invece permetti il login SOLO con chiave, tutti i tentativi di connessione da parte di chi non dispone di chiave vengono droppati automaticamente dal server SSH, e la tua macchina è come se non avesse nessun server in ascolto

----------

## Kernel78

 *k.gothmog wrote:*   

> a casa hai un server sulla 2222
> 
> sei al lavoro, e vuoi collegarti a casa. scopri però che il firewall, dove lavori, è fatto come si dovrebbe, e permette di collegarti alla porta 22 ma non 2222
> 
> che fai? non puoi fare altro che fare ponte su una terza macchina, con tutto quello che deriva da questo (lentezza della connessione. latenza, carico sulle macchine, ecc...) e la macchina che fa da ponte resta comunque insicura.
> ...

 

e se, come nel mio caso, ci si trova dietro un proxy che non permette di collegarti alla 22 ma ad altre porte come la 443 ?

Se non ho un https sulla mia macchina mi concedi di poterci mettere in ascolo ssh ? altrimenti chiave o password non mi ci collego e basta ...

----------

## Manuelixm

Sì k.gothmog, in quel caso non posso collegarmi, per farlo mi appoggio ad una terza . Come hai appena indicato tu non è una buona soluzione, ma bisogna sempre vedere dove si trova la tua macchina e che funzioni svolge. Nel mio specifico caso e quindi, per il server che ho a casa, l'ssh sull'esterno non mi è indispensabile anche perhè non ha servizi indispensabili per nessuno, dall'esterno accedo all'ftp e ai siti hostati e nel 99% dei casi è sempre funzionante.

----------

## sometimes

...a parte il cambio di porta ho fatto tutto quello che mi avete consigliato (accesso solo tramite chiave publica).

nei log trovo questo

 *Quote:*   

> Mar 29 07:17:45 [sshd] Did not receive identification string from 148.243.191.5
> 
> Mar 29 07:26:28 [sshd] Invalid user db2inst1 from 148.243.191.5
> 
> Mar 29 07:26:28 [sshd] reverse mapping checking getaddrinfo for na-148-243-191-5.na.avantel.net.mx failed - POSSIBLE BREAKIN ATTEMPT!
> ...

 

 :Question: 

----------

## Manuelixm

I log ti dicono che i vari utenti segnalati hanno tentato di loggarsi sulla porta 22, ma il login è fallito.

----------

## mouser

 *k.gothmog wrote:*   

> ...
> 
> se invece permetti il login SOLO con chiave, tutti i tentativi di connessione da parte di chi non dispone di chiave vengono droppati automaticamente dal server SSH, e la tua macchina è come se non avesse nessun server in ascolto
> 
> ...

 

Scusa, k.gothmog, e se nel caso mi capita di dovermi collegare da un picci "nuovo" (ex. mi fermo ad un internet-cafè e mi attacco al tram   :Laughing:  )

Sicuramente la chiave pubblica è sicurissima, ma comunque non è detto che possa sempre avere registrate le chiavi pubbliche di ogni posto da cui desidero collegarmi.

Ciriciao

mouser  :Wink: 

----------

## .:deadhead:.

io metto ssh in ascolto sulle porte di altri demoni e via, evitando la 80 che altrimenti mi troverei i log pieni di tentativi di bucare IIS   :Razz: 

----------

## Ic3M4n

dopo essermi letto il tutto posso solo dire che sotto il profilo della sicurezza è meglio utilizzare l'autenticazione via chiave, in quanto la password può non rivelarsi sicura in certi casi. io per esempio sapendo che sconosciuti possono mettersi li a provare ogni password possibile ed inimmaginabile fino a trovare la mia non mi farebbe dormire la notte. per quello che riguarda la porta di connessione abbiamo visto al termine della discussione che ognuno ha delle esigenze, dover mantenere la 22 per potersi connettere, o doverla spostare per lo stesso identico motivo. di sicuro avere la possibilità di spostare il servizio permette di avere dei log più puliti. questa cosa può in ogni caso essere evitata abilitando il port knocking anche sulla 22.

----------

## .:chrome:.

 *mouser wrote:*   

> e se nel caso mi capita di dovermi collegare da un picci "nuovo" (ex. mi fermo ad un internet-cafè e mi attacco al tram   )
> 
> Sicuramente la chiave pubblica è sicurissima, ma comunque non è detto che possa sempre avere registrate le chiavi pubbliche di ogni posto da cui desidero collegarmi

 

è il problema che ho riguardo alle macchine che gestisco. ho sempre con me una memoria USB con le chiavi private

@kernel78:

ok, hai ragione, ma quello è un caso estremo (il fatto che il tuo router non permetta la connessione alla porta 22). normalmente non è così

----------

## salade

 *k.gothmog wrote:*   

> @kernel78:
> 
> ok, hai ragione, ma quello è un caso estremo (il fatto che il tuo router non permetta la connessione alla porta 22). normalmente non è così

 

Beh.. mica tanto estremo.. E' anche il mio caso  :Wink: 

Se non avessi una macchina ponte in ascolto sulla 443, non riuscirei ad uscire dal proxy aziendale...  :Wink: 

----------

## Manuelixm

 *Quote:*   

> è il problema che ho riguardo alle macchine che gestisco. ho sempre con me una memoria USB con le chiavi private 

 

Al massimo saranno le chiavi pubbliche  :Wink:  .

----------

## .:deadhead:.

 *salade wrote:*   

> Se non avessi una macchina ponte in ascolto sulla 443, non riuscirei ad uscire dal proxy aziendale... 

 come mai non metti direttamente ssh in ascolto sulla 443 e buonanotte al secchio?

----------

## salade

 *.:deadhead:. wrote:*   

> come mai non metti direttamente ssh in ascolto sulla 443 e buonanotte al secchio?

 

Perchè devo accedere a server che sono anche web con ssl e la 443 è già occupata   :Wink: 

----------

## Frez

 *Manuelixm wrote:*   

>  *Quote:*   è il problema che ho riguardo alle macchine che gestisco. ho sempre con me una memoria USB con le chiavi private  
> 
> Al massimo saranno le chiavi pubbliche  .

 

Tutti hanno le tue chiavi pubbliche. Tu sei "tu" solo se hai le tue chiavi private  :Smile: 

----------

## .:chrome:.

 *Manuelixm wrote:*   

>  *Quote:*   è il problema che ho riguardo alle macchine che gestisco. ho sempre con me una memoria USB con le chiavi private  
> 
> Al massimo saranno le chiavi pubbliche  .

 

no. sono private. non mi sono confuso  :Smile: 

uno die punti che fanno la sicurezza di questo mezzo è che la chiave pubblica è tale e va copiata in giro. è la chiave privata che fornisce l'autenticazione presso l'host tramite la corispettiva chiave pubblica.

è la chiave privata che devi portarti in giro, e proteggere (e cercare di non perdere)

EDIT: mi sa che la brodaglia che ho appena scritto è il post più confuso, contorto, e peggio scritto del forum.

chiudo le trasmissioni e vado a ristudiare la grammatica delle medie

----------

## Manuelixm

Sì ma le chiavi pubbliche risiedono sul client e non devono essere portate in giro, al contrario sono le chiavi pubbliche che devono essere distribuite sulle macchine che si vogliono connettere al determinato server.

----------

## .:chrome:.

 *Manuelixm wrote:*   

> Sì ma le chiavi pubbliche risiedono sul client e non devono essere portate in giro, al contrario sono le chiavi pubbliche che devono essere distribuite sulle macchine che si vogliono connettere al determinato server.

 

ok. fino a qui ci siamo

quello che voglio dire è che se voglio accedere ad un host che ha già la mia chiave pubblica, devo portarmi in giro la privata, nel caso che l'host che sto usando in questo momento non sia il mio calcolatore

capito adesso?

----------

## Manuelixm

Sì esatto, io preferisco ternerla sul mio pc la chiave privata, non me la porto in giro, ma questo non vuol dire che uno non possa farlo.

EDIT:

tendo a definire a priori i client che possono accedere alla macchina remota, quindi creo n chiavi per ogni client per un account con pochi diritti e inserisco le chiavi pubbliche generate sulla macchina remota.

EDIT2:

 *Quote:*   

> Sì ma le chiavi pubbliche risiedono sul client e non devono essere portate in giro, al contrario sono le chiavi pubbliche che devono essere distribuite sulle macchine che si vogliono connettere al determinato server.

 

intendevo le private, ho sbagliato a scrivere:

```
Sì ma le chiavi "private" risiedono sul client e non devono essere portate in giro, al contrario sono le chiavi pubbliche che devono essere distribuite sulle macchine che si vogliono connettere al determinato server.
```

----------

## Ic3M4n

e come fai ad accedere al server con la chiave pubblica scusa?   :Shocked: 

sarebbe come dire:  ho la chiave privata sulla mia macchina, le pubbliche le distribuisco ed ogni chiave publica permette di accedere al server. è una cosa illogica che va contro i principi basilari della sicurezza informatica.

----------

## Manuelixm

Si parla sempre di coppia di chiavi, non una per tutte, ma chi lo ha scritto??? Era implicito che si parlasse di una copia di chiavi.

----------

## .:chrome:.

 *Manuelixm wrote:*   

> Si parla sempre di coppia di chiavi, non una per tutte, ma chi lo ha scritto??? Era implicito che si parlasse di una copia di chiavi.

 

veramente secondo me tu non hai capito come funziona il meccanismo.

per accedere ad una macchina remota con chiave SSH hai bisogno di possedere, in quel momento solo la chiave privata, ed è quella che ti devi portare dietro, non di certo la pubblica. prova a leggere un buon libro sulla configurazione di openSSH

----------

## Manuelixm

 *Quote:*   

> per accedere ad una macchina remota con chiave SSH hai bisogno di possedere, in quel momento solo la chiave privata

 

Se intendi la chiave privata della macchina remota stiamo dicendo le stesse cose ma in modo diverso, altrimenti è probabile che io non abbia capito un tubo... il discorso è che l'implementazione che ho fatto sul mioserver e sui 2 client che si collegano funziona, quindi la mia ipotesi è la prima: diciamo le stesse cose in modo diverso.

Edit:

Questo è quello che faccio e per come ho capito io il funzionamento di sshd tramite public key:

Ho una macchina A che si vuole connettere a una macchina B, sulla macchina A ho 2 account:

-	root

-	utenteA

sulla macchina A mi loggo con utenteA e creo la mia coppia di chiavi.

Aggiungo in autorizzed_keys su macchina B dell'utente(qualsiasi, preferibilmente non root), la mia chiave pubblica appena generata

Tento la connessione da macchina A a B.

----------

## .:chrome:.

chiave privata della macchina? uhm... io credo che tu abbia un po' di confusone in testa

l'host dispone di due chiavi, una pubblica, ed una privata, ma questo avviene in modo indipendent dal tipo di autenticazion scelto dall'utente/amministratore, perché quelle chiavi sevono al server SSH per gestire tutta l'autenticazione ad un livello inferiore a quello in cui si trova l'utente.

l'utente PUÒ SCEGLIERE DI GENERARE una coppia di chiavi utente. a questo punto le chiavi diventano quattro, ma quelle che ci sono in ballo per l'autenticazione utente sono sempre le chiavi, appunto, dell'utente.

se l'utente vuole collegarsi ad un host mediante chiave allora deve copiare la sua chiave PUBBLICA di utente sull'host a cui si vuole collegare, ed ogniqualvolta che intende utilizzare il meccanismo delle chiavi, dovrà avere a disposizione la sua chiave PRIVATA di utente, ce è protetta da una password d blocco, ma che riguarda la chiave, e non l'account

----------

## Manuelixm

Esatto quello che ho appena scritto precedentemente solo che la mia chiave privata è stabile sul client che si vuole connettere alla macchina remota.

----------

## .:chrome:.

 *Manuelixm wrote:*   

> Esatto quello che ho appena scritto precedentemente solo che la mia chiave privata è stabile sul client che si vuole connettere alla macchina remota.

 

ok. il problema iniziale era: com faccio a connettermi da unaltro client? emplice basta che ti porti in giro la chiave privata, ad esempio su una memoria USB, poi basta usare il parametro -i di ssh

----------

