Hosting con accesso ssh probabilmente non così comune, almeno nella mia esperienza. Il mio ultimo hosting supporta SSH e ho deciso di provarlo, e avevo anche una buona ragione per farlo. Il punto è che il mio attuale hosting non mostra le dimensioni dei file in dettaglio.

Non puoi vederlo nemmeno attraverso il client FTP, ma ne ho davvero bisogno, poiché lo spazio di hosting si è esaurito rapidamente e ho bisogno di eliminare tutta la spazzatura per non acquistare megabyte aggiuntivi e non pagare extra. E più recentemente, i miei siti sono stati infettati e io, e senza l'accesso ssh, sarebbe stato impossibile.

Avrei saputo che il mio hosting non supporta una funzione così semplice, ho pensato cento volte se passarci o meno. Ma le recensioni sull'hosting erano buone e ho comprato un posto per due anni in una volta. Ma dal momento che ha ssh, penso che la domanda possa essere risolta. Quindi, hosting SSH, come puoi usarlo?

Che cos'è l'hosting ssh?

Ma prima ti parlerò di cos'è SSH, perché forse non tutti sanno che tipo di bestia sia. In breve, secondo Wikipedia, questo è:

SSH (inglese Secure SHell - "secure shell") è un protocollo di rete a livello di applicazione che consente il controllo remoto del sistema operativo e il tunneling delle connessioni TCP (ad esempio, per il trasferimento di file). SSH consente una scelta di diversi algoritmi di crittografia. I client SSH e i server SSH sono disponibili per la maggior parte dei sistemi operativi di rete.

È possibile accedere a Ssh direttamente dal terminale utilizzando i comandi di Linux. È molto facile connettersi al server, è necessario digitare il comando in questo formato:

Ssh nome utente @ indirizzo_server

Come puoi vedere, tutto è molto semplice. Proverò a connettermi tramite ssh al mio hosting. Ma non c'era, l'host si è ostinatamente rifiutato di accettarmi usando questo protocollo. Ho scritto al servizio di supporto e ora sto aspettando una risposta.

Nel frattempo, ti dirò quanto è conveniente connettersi via ssh tramite il file manager Nautilus. Collegandoti ad esso tramite SSH, lavorerai con i file che si trovano sull'hosting, come se fossero sul tuo computer. Apri Nautilus e premi Ctrl + L in modo da poter scrivere il percorso del server ssh nella barra degli indirizzi:

Sftp: // [e-mail protetta]

Quindi ti verrà chiesto di inserire una password e vedrai tutti i tuoi file nel file manager. Questi sono i vantaggi dell'hosting con ssh.

Pertanto, quando si sceglie un hosting, prestare attenzione a questo. Mio Hosting IHOR dà accesso a SSH ed è per questo che lo uso da qualche anno ormai...

SUGGERIMENTO AL WEBMASTER: La capacità di fare soldi su Internet è solo metà della battaglia, la seconda metà è la possibilità di incassare denaro elettronico in modo redditizio. Ecco un elenco di carte bancarie offshore che puoi utilizzare per prelevare fondi e quindi prelevare banconote nitide da loro:

1. pagatore- Il sistema di pagamento più popolare al mondo per i liberi professionisti. Emissione di carte, con sede negli Stati Uniti.

2. EpayService- Il sistema di pagamento americano, molto diffuso in molti paesi, offre una carta MasterCard in EVRO gratuitamente per i residenti della CSI e dell'Europa.

3. Skrill- L'unico sistema di pagamento che funziona con le criptovalute e allo stesso tempo emette carte bancarie MasterCard gratuite.

4. AdvCash- La banca offshore si trova in Belize, puoi aprire un conto in dollari, euro, sterline e rubli.

5. Contribuente- La sede di questo sistema di pagamento si trova in Georgia, qui puoi anche aprire un conto in dollari, euro e rubli.

Dominio RU - 99 rubli Dominio RF - 99 rubli

SSH (Secure Shell) è un protocollo di accesso remoto alla rete che utilizza la crittografia e la compressione per i dati trasmessi. In poche parole, è uno strumento molto utile e potente che consente di autenticarsi nel sistema e lavorare completamente per conto di un utente locale, trovandosi a molti chilometri di distanza da una macchina in funzione. Inoltre, a differenza di telnet e rsh, SSH crittografa tutto il traffico, in modo che tutte le informazioni trasmesse rimangano riservate.

Quindi, abbiamo già installato ssh e ssh-daemon viene aggiunto all'avvio all'avvio del sistema. Puoi controllarlo tramite il comando:

service ssh stop | start | restart

Su Ubuntu, oppure:

/etc/init.d/ssh (start | stop | reload | force-reload | restart | status)

Su Debian, oppure:

systemctl start | stop | riavviare sshd.service

In ArchLinux (dopo ogni modifica della configurazione, è necessario riavviare). Il kit include un client e un server.

Proviamolo in azione! Per prima cosa, crea una cartella ~ / .ssh

mkdir ~ / .ssh

Genera chiavi per l'utente del server specificato con il comando:

ssh-keygen (come utente normale).

Durante la generazione, puoi impostare una passphrase per la chiave (è consigliabile impostarne una lunga - quindi anche dopo aver ottenuto la chiave ma non conoscendo la password dalla chiave, l'attaccante non sarà in grado di accedere), oppure puoi saltalo semplicemente premendo "Invio" - in questo caso, la password non verrà mai richiesta. Le stesse chiavi pubbliche e private sono apparse nella cartella ~ / .ssh.

Trova un'altra macchina (anche uno smartphone andrà bene - ci sono alcuni ottimi client SSH su Android, come ConnectBot o JuiceSSH), installa ssh su di essa e connettiti al server con il comando:

ssh [e-mail protetta]

Se tutto è stato eseguito correttamente, ti verrà richiesta la password dell'utente e, dopo essere entrato, ti ritroverai nel tuo sistema con una vista dalla riga di comando.

Per Windows, tra l'altro, ci sono anche server e client ssh.

Dopo aver apprezzato il risultato delle nostre fatiche, passiamo a una parte ancora più noiosa: l'impostazione del client/server.

La configurazione lato client è in /etc/ssh/ssh_config e quello del server - /etc/ssh/sshd_config... La guida alla configurazione più completa è probabilmente la pagina man per man ssh e man sshd_config, quindi consigliamo di leggerla. E in questo articolo considereremo le cose più necessarie.

personalizzazione

La porta ssh standard è 22. Può essere cambiata con qualsiasi non standard (rendendo più difficile l'hacking a causa della sicurezza attraverso l'oscurità o per attirare l'attenzione di potenziali aggressori :) - per fare ciò, decommenta la riga:

#Porta 22

E aggiungi quello che vuoi fino a 65535 (assicurandoti che la porta non sia in conflitto con altri servizi con il comando #netstat -tupln | grep ASCOLTA).

Ora, quando si connette al server, il client dovrà scrivere con la chiave:

ssh -p [porta]:

Per impostazione predefinita, è consentito l'accesso root. È altamente consigliabile limitarlo (e invece delimitare correttamente i diritti dell'utente locale utilizzando sudo). Per fare ciò, trova la riga "PermitRootLogin" e modifica il valore in "no". Puoi anche cambiarlo in "senza password" - in questo caso, l'accesso sotto root sarà consentito solo da macchine con una chiave attendibile.

Puoi disabilitare l'autenticazione della password e lavorare solo con le chiavi: trova la riga: "PasswordAuthentication" e modifica il valore in "no". Per che cosa? Se qualcuno vuole davvero ottenere l'accesso al tuo sistema, può eseguire la forza bruta della password quando tenta di autorizzare o ascoltare e decrittografare la tua connessione. Se disabiliti l'autenticazione della password e aggiungi a ~ / .ssh / authorized_keys sul server la chiave pubblica del tuo, ad esempio, laptop di lavoro, quindi, come ricordiamo, saremo immediatamente autorizzati al server. Ma cosa succede se stai lavorando sulla macchina di qualcun altro e hai urgente bisogno di accedere al server ssh, ma, come previsto, non ci farà entrare? Quindi non è possibile disabilitare l'autenticazione della password, ma utilizzare l'utilità fail2ban. Basta installarlo dal tuo repository, dopodiché applicherà le impostazioni predefinite e almeno proteggerà il tuo canale ssh dagli attacchi di forza bruta. Maggiori informazioni su fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.

Nel caso in cui il tuo server conservi le chiavi per il lancio di missili nucleari, puoi fare qualcosa del genere:

PermitRootLogin no - il login sotto root è proibito.

PasswordAuthentication no - login senza password

Generiamo una chiave lunga sulla macchina remota (-t tipo_crittografia, -b lunghezza in bit):

ssh-keygen -t rsa -b 4096

Con una passphrase altrettanto complessa (a proposito, non puoi recuperare una password dimenticata. Puoi cambiarla con il comando "ssh-keygen -p", ma ti verrà comunque richiesta quella vecchia). Trasferiamo la chiave pubblica della macchina locale remota su ~ / .ssh / authorized_keys sul server e voilà - ora l'accesso può essere ottenuto da una singola macchina, utilizzando la passphrase della chiave privata. SSH ti consente di impostare molte configurazioni di sicurezza e ha molte impostazioni specifiche per questo - leggile in man.

Due opzioni sshd_config hanno lo stesso scopo:

AccediGraceTime- imposta il tempo dopo il quale la connessione verrà disconnessa se non avviene l'autenticazione.

MaxAuthTries- imposta il numero di tentativi errati di accesso al login, al raggiungimento dei quali la connessione verrà interrotta.

MaxSesions- il numero di sessioni simultanee (se il server è il tuo computer di casa a cui ti collegherai dall'università o dal lavoro, allora sarebbe ragionevole limitare il numero di sessioni a una - un login rifiutato, in questo caso, diventare un motivo per aumentare la paranoia, generare nuove chiavi e cambiare password). Tuttavia, se stai attento, potresti aver notato che la riga "Last Login" viene visualizzata ad ogni accesso al server. Oltre ad esso, puoi aggiungere il tuo messaggio di saluto: trova la riga "Banner" e invece di nessuno, imposta il percorso del file con il testo che verrà letto e visualizzato al momento del login.

Tra le altre cose, puoi consentire solo a determinati utenti di accedere o consentire a tutti tranne a determinati utenti:

Consenti Utenti utente1- consentire l'accesso solo all'utente1.

DenyUsers utente1- consentire a tutti tranne utente1.

E parametri simili per l'accesso a determinati gruppi sono AllowGroups e DenyGroups.

Puoi anche SSH una sessione X11. Per fare ciò, trova la riga "ForwardX11" e modifica il valore in "yes".

Trova una riga simile nella configurazione del client - / etc / ssh / ssh_config e cambia anche in "yes".

Ora devi connetterti al server tramite ssh con l'argomento -X:

ssh -X [e-mail protetta]>

Puoi avviare immediatamente l'applicazione quando sei connesso:

ssh -X [e-mail protetta]"Appendice"

Ecco come appare un GIMP in esecuzione in una sessione ssh:

Oppure puoi ottenere l'output dalla webcam del laptop di un utente ignaro :)

I calcoli vengono eseguiti direttamente sul server e l'output viene inviato al computer client (ovvero, anche se il server stesso non dispone di X11, le applicazioni grafiche possono essere visualizzate sul computer remoto). Questo schema funziona piuttosto lentamente (non dimenticare che tutto il traffico è crittografato dinamicamente), ma questa funzione è molto utile.

Puoi anche copiare i file su una sessione SSH: esiste una semplice utility "scp" per questo. Puoi trasferire file direttamente nella sessione come dal server al client:

scp [e-mail protetta]: / percorso / a / file / su / server / dove / salva / su / locale / macchina

Quindi da client a server:

scp percorso / a / file / client [e-mail protetta]: / percorso / su / server

Questo è abbastanza comodo se devi copiare un libro di testo o una foto, ma cosa succede quando devi lavorare con molti file? C'è una cosa molto comoda per questo: sshfs (disponibile per l'installazione nei repository della maggior parte dei * nix-system).

Basta impostare il percorso come scp:

sshfs [e-mail protetta]: / home / utente / mnt /

E la cartella /home/utente del server apparirà nel punto di montaggio /mnt della macchina locale!

Lo smontaggio avviene tramite umount.

E per finire, parliamo di una caratteristica poco conosciuta. Se crei un file /.ssh/config e riempilo così:

Nome host]

Nome host

Utente [nome utente del server]

opzioni desiderate

Piace

AvantiX11 sì

Porta 30.000

Quindi possiamo accedere tramite:

ssh [nome]

ssh -X -p 30000 [e-mail protetta]

E tutte le opzioni verranno raccolte automaticamente. Pertanto, con l'autenticazione frequente su un server specifico, semplificherai questo processo in pochi istanti.

Bene, abbiamo coperto tutto (e anche di più) che devi sapere su SSH per il suo uso quotidiano: abbiamo imparato come utilizzare l'autenticazione con chiave, protetto il server dagli attacchi di forza bruta e, in generale, corretto la maggior parte dei potenziali buchi. In effetti, SSH può fare molte altre cose, ad esempio tunneling e port forwarding attraverso una sessione ssh, ma è improbabile che tu, come utente normale, lo utilizzerai mai. Risorse addizionali

SSH - (Secure Shell) è un protocollo per il controllo remoto di un computer che esegue Linux. Principalmente ssh viene utilizzato per gestire i server in remoto tramite terminale. Se sei un amministratore di diversi server o anche un webmaster avanzato, probabilmente devi affrontare spesso la necessità di lavorare con uno o un altro computer tramite ssh. In Linux, per questo, viene utilizzato un server ssh sulla macchina a cui devi connetterti e sul client su cui ti stai connettendo.

In questo tutorial, vedremo come utilizzare ssh e le sue funzionalità che non conoscevi nemmeno. Molto probabilmente, sai già come connetterti a un server usando ssh, ma questa utility ha molte più funzionalità, come il trasferimento di file ssh, la connessione senza password o l'esecuzione di script su un server remoto. Considereremo tutto questo più avanti nell'articolo.

Ma cominciamo dalle basi.

La sintassi del comando è la seguente:

$ ssh [opzioni] Nome utente@server [comando]

È importante notare che ssh può operare su due versioni di protocollo. Versioni 1 e 2. È chiaro che la versione 2 è migliore e supporta più tipi di crittografia e autenticazione. Non parleremo più delle differenze di protocollo in questo articolo e indicherò che stai usando la versione 2.

Opzioni del comando SSH

Ora diamo un'occhiata alle opzioni di base per il comando ssh:

• F- metti ssh in background
• G- consentire alle macchine remote di accedere alle porte locali
• io- nome utente nel sistema
• n- reindirizza l'output standard a / dev / null
• P- porta ssh sulla macchina remota
• Q- non mostrare messaggi di errore
• v- modalità di debug
• X- disabilitare il reindirizzamento X11
• X- abilitare il reindirizzamento X11
• C- Abilita la compressione

Queste non sono tutte le opzioni dell'utilità, il resto va oltre lo scopo di questo articolo. Molte impostazioni ssh possono essere modificate tramite il file di configurazione ~ / .ssh / config, ma non lo considereremo in dettaglio nemmeno qui.

Configurazione di un server SSH

Le impostazioni del server SSH si trovano in /etc/ssh/sshd_config. Non ne toccheremo nemmeno molti. Consideriamo solo quelli più interessanti. Per prima cosa apri il file /etc/ssh/sshd.conf

porta Ssh

Per impostazione predefinita, ssh viene eseguito sulla porta 22. Ma questo comportamento non è sicuro perché un utente malintenzionato conosce questa porta e può provare a eseguire un attacco di forza bruta per forzare la password. La porta è impostata dalla linea:

Modificare il valore della porta come richiesto.

protocollo SSH

Per impostazione predefinita, il server ssh può essere eseguito in due versioni del protocollo, per compatibilità. Per utilizzare solo la versione due del protocollo, decommenta la riga:

E portalo in questo modulo:

Accesso al percorso

Per impostazione predefinita, l'accesso Root ssh è consentito, ma questo comportamento è molto insicuro, quindi decommenta la riga:

PermitRootLogin no

Solo un utente specifico può accedere a SSH

Possiamo consentire l'accesso ssh solo a un utente o gruppo specifico. Per fare ciò, aggiungi le righe:

Consenti Utenti Utente1, Utente2, Utente3
ConsentiGruppi Gruppo1, Gruppo2, Gruppo3

Qui Utente1 e Gruppo1 sono l'utente e il gruppo a cui si desidera consentire l'accesso.

Esecuzione di applicazioni X11

Non tutti lo sanno, ma è possibile utilizzare ssh per eseguire applicazioni X11 a tutti gli effetti. Ne parleremo di seguito, ma affinché tutto funzioni, è necessario abilitare questa funzione sul lato server, aggiungere la seguente riga:

X11 Inoltro sì

Vengono considerate le opzioni principali, prima di proseguire, non dimenticare di riavviare il server ssh per salvare le modifiche:

riavvio del servizio sshd

Utilizzo di SSH

Lo scopo principale di questo articolo è mostrarti modi interessanti e utili per usare ssh di cui potresti non essere a conoscenza. Passiamo alla parte gustosa: le capacità ssh.

Connessione al server

Per connetterti semplicemente al server tramite SSH usa il seguente comando:

Esegui comando

Siamo abituati a connetterci a un server remoto e solo successivamente eseguire i comandi necessari, ma di fatto l'utility ssh consente di eseguire immediatamente il comando richiesto senza aprire il terminale della macchina remota. Ad esempio:

ssh [e-mail protetta] ls

Esegue il comando ls sul server remoto e restituisce il suo output al terminale corrente.

Esegui script locale

Eseguiamo l'interprete bash sul server remoto e gli forniamo il nostro script locale utilizzando il reindirizzamento dell'input di Bash:

ssh [e-mail protetta]"bash-s"< script.sh

Backup su un server remoto e ripristino

Possiamo salvare immediatamente un backup del disco su un server remoto utilizzando ssh. Reindirizza l'output di dd utilizzando l'operatore di reindirizzamento |, quindi salvalo su quel lato in un file:

sudo dd if = / dev / sda | ssh [e-mail protetta]"dd di = sda.img"

Ora, per ripristinare lo stato del disco dalla copia effettuata, eseguire:

ssh [e-mail protetta]"dd if = sda.img" | dd di = / dev / sda

Qui e sopra /dev/sda c'è il nome del file del tuo disco rigido.

Autenticazione senza password

L'uso di una password ssh per accedere al server non è solo scomodo ma anche poco sicuro, perché questa password può essere forzata in qualsiasi momento. Il metodo di autenticazione più sicuro e comunemente utilizzato è con una coppia di chiavi RSA. La chiave privata è memorizzata sul computer e la chiave pubblica viene utilizzata sul server per autenticare l'utente.

È molto facile configurare questo comportamento. Innanzitutto, crea una chiave con il comando:

ssh-keygen -t rsa

Durante la creazione della chiave, dovrai rispondere a diverse domande, lasciare la posizione predefinita, se vuoi connetterti senza password, lascia vuoto anche il campo Passphare.

Quindi inviamo la chiave al server:

ssh-copy-id -i ~ / .ssh / id_rsa.pub [e-mail protetta]

Prendi la password dal file locale

Lascia che ti ricordi che la memorizzazione delle password in normali file di testo non è sicura, ma se lo desideri, allora sì, è possibile. Per questo, viene utilizzato l'operatore di reindirizzamento dell'input Bash:

ssh [e-mail protetta] < local_file.txt

Modifica il messaggio di saluto SSH

Quando si accede tramite ssh, potrebbe essere visualizzato un messaggio di saluto ed è molto semplice modificarlo. Il file / etc / problema è responsabile di questo. Basta aprire questo file e inserire il testo desiderato:

Guardare tentativi di accesso SSH non riusciti

Vuoi vedere se ci sono stati tentativi di accesso senza successo al tuo server tramite ssh e da quali indirizzi IP? Facilmente, tutte le richieste vengono registrate nel file /var/log/secure, filtriamo solo i dati necessari con il comando:

cat / var / log / sicuro | grep "Password non riuscita per"

Trasferimento file SSH

Oltre all'esecuzione di comandi, puoi copiare i file tramite ssh. L'utilità scp viene utilizzata per questo. Basta specificare il file da trasferire, il server remoto e la cartella sul server, qui:

$ scp / indirizzo / locale / file utente @ host: sommatori / cartelle

Ad esempio:

scp ~ / test.txt [e-mail protetta]: documenti

Oltre all'utilità scp, i trasferimenti di file ssh possono essere eseguiti in un modo più complicato. Leggiamo il file e, usando cat, trasferiamolo e quindi salviamo il flusso in un file:

gatto localfile | ssh [e-mail protetta]"gatto> file remoto"

ssh [e-mail protetta]"gatto> file remoto"< localfile

tar czf - / home / utente / file | ssh [e-mail protetta] tar -xvzf -C / home / utente remoto /

Copiare i file ssh in questo modo consente di inviare intere cartelle contemporaneamente.

Esecuzione di applicazioni grafiche su ssh

Se hai bisogno di eseguire questa o quell'applicazione grafica su una macchina remota, non è necessario utilizzare VNC per questo, puoi cavartela con ssh. Il programma verrà eseguito sul lato server e ti verrà trasmessa solo una finestra in modo che tu possa fare tutto ciò che devi fare. Inoltre, tutti i dati sono crittografati. Affinché questa funzionalità funzioni, è necessario abilitarla sul lato server.

Quindi eseguiamo semplicemente il comando per avviare l'applicazione grafica sul server remoto in questo modo:

ssh -XC [e-mail protetta]"eclisse"

Come hai visto, l'opzione X consente il reindirizzamento X11 sul lato client e l'opzione C consente la compressione dei dati.

Fine della sessione ssh

Se hai utilizzato ssh con una Internet instabile, quando la connessione viene interrotta di tanto in tanto, probabilmente sei già stanco di chiudere il terminale, perché altrimenti, a prima vista, la sessione non verrà terminata. Quando la connessione al server remoto viene disconnessa, non è possibile immettere alcun comando e le scorciatoie da tastiera Ctrl + C, Ctrl + Z, Ctrl + D non funzionano. E non funzioneranno perché il client tenta di inviare questi comandi al server. Ma c'è una soluzione: sequenze di fuga. Per attivare il loro supporto aggiungi la riga:

Al file / etc / ssh / ssh_config

Questo articolo è contrassegnato come non finito. Vedi la nota alla fine dell'articolo.

Questo articolo riguarda il client e il server secure shell in Ubuntu, come configurarli e utilizzarli. SSH è uno speciale protocollo di rete che consente di accedere in remoto a un computer con una connessione altamente sicura. Puoi leggere di più sul protocollo ssh.

Descrizione dei principi di funzionamento e delle applicazioni utilizzate

Fondamentalmente, SSH è implementato come due applicazioni: un server SSH e un client SSH Ubuntu utilizza un'implementazione gratuita di un client e server SSH: OpenSSH. Al momento della connessione, il client esegue la procedura di autorizzazione sul server e tra di loro viene stabilita una connessione crittografata. Il server OpenSSH può funzionare con entrambi i protocolli ssh1 e ssh2. Il protocollo ssh1 è attualmente considerato non sicuro, quindi il suo utilizzo è altamente sconsigliato. Ometto volutamente vari dettagli tecnici del protocollo, poiché lo scopo principale di questo manuale è descriverne la configurazione e l'uso. Ci sono molti articoli su Internet sul protocollo stesso, sui suoi principi di funzionamento, sugli algoritmi di crittografia, ecc., Ad esempio, puoi leggerlo in dettaglio.

Installazione

Installare ApriSSH puoi usare il comando da terminale:

sudo apt-get install ssh

Il metapacchetto ssh contiene sia il client che il server, ma molto probabilmente installerà solo il server poiché il client è già incluso in Ubuntu per impostazione predefinita.

Ottimizzazione del server

Durante l'installazione, il server SSH viene registrato automaticamente all'avvio. Puoi controllarne l'avvio, l'arresto o il riavvio utilizzando i comandi:

sudo service ssh stop | inizio | ricomincia

Il file di configurazione del server SSH principale è / etc / ssh / sshd_config, che è leggibile o modificabile solo dal superutente. Dopo ogni modifica a questo file, è necessario riavviare il server ssh per applicare tali modifiche.

Un esempio di una configurazione del server SSH predefinita in Ubuntu:

# Un esempio di configurazione del server open-ssh con il russo # # commenti..2010. # # # # # # Legenda: # # Per impostazione predefinita, sshd deve comportarsi quando # # non viene specificata una direttiva esplicita. Vale la pena notare che in Ubuntu # # il file sshd_config contiene già una serie di impostazioni, che # # sono le impostazioni predefinite per Ubuntu in particolare. # # Queste impostazioni sono specificate in questo file. # # # ############################################## ############ ################ Impostazioni indirizzo/porta, ecc. ############ ##################################### ##################### # # ## Porta ######################## ############################# # # # Porta utilizzata. È possibile specificarne diversi, ad esempio: # # Porta 22 # # Porta 23 # # Porta 24 # # Si consiglia di utilizzare una porta non standard, perché # # standard viene spesso scansionato dai bot per # # potenziali "buchi". Può essere omesso se # # è specificato tramite indirizzo. Vedere anche il parametro ListenAddress. # # # Porta 22 # # ## ListenAddress ####################################### # ## # # # L'indirizzo di rete su cui il server "ascolta". L'indirizzo può # # essere scritto in questo modo: # # ListenAddress host | IPv4_addr | IPv6_addr # # ListenAddress host | IPv4_addr: port # # ListenAddress: port # # Se non viene specificata alcuna porta, sshd ascolterà su questo indirizzo e # # sul porta specificata nell'opzione Porta. Se si usa # # ListenAddress senza specificare una porta, l'opzione # # Port deve precedere l'opzione ListenAddress. Se # # non è specificato, per impostazione predefinita ascolta tutti gli indirizzi # # locali. È possibile specificare più indirizzi. # # # ## AddressFamily ########################################## # # # Specifica quale famiglia di indirizzi IP # # deve essere utilizzata da sshd. Opzioni possibili: # # “any” - any # # “inet” (solo IPv4) # # “inet6” (solo IPv6) # # L'impostazione predefinita è “any”. # AddressFamily inet # # ## UseDNS ######################################### # ####### # # # Specifica se sshd deve controllare l'hostname e # # usando questo nome controllare l'indirizzo IP trasmesso dal client con # # ottenuto dal DNS. # # L'impostazione predefinita è "sì". # # # ############################################## ############# ############# Impostazioni di accesso utente ############## ####### ################################################# # ## # # # Avvia/blocca un utente definito dalle direttive # # DenyUsers, AllowUsers, DenyGroups e AllowGroups. # # in questo caso, il controllo va dall'alto verso il basso lungo la catena: # # ## DenyUsers ## # # || # # ## ConsentiUtenti ## # # || # # ## DenyGroups ## # # || # # ## AllowGroups ## # # Sono accettati solo nomi utente e nomi di gruppi, gli identificatori numerici # # (UserID) non sono riconosciuti. Corretto # # scrivendo più utenti/gruppi a turno, separati da # # spazio. Se scritto nella forma user @ host - quindi # # user e host sono controllati separatamente, questo permette # # di delimitare l'accesso di certi utenti con # # di certi host. Vale la pena ricordare che # # le direttive DenyUsers e AllowUsers accettano # # un nome utente come parametro e DenyGroups e AllowGroups prendono # # un nome di gruppo. Vedere PATTERNS in man ssh_config per ulteriori # # informazioni su come vengono scritti i nomi di utenti e gruppi. # # # ## DenyUsers ########################################## # ## # # # Elenco degli UTENTI che NON POSSONO utilizzare sshd. # # Per impostazione predefinita - non specificato = nessuno è vietato. Quelli. se # # viene specificato un utente qui, gli verrà negato l'accesso # # al server ssh. # # # ## ConsentiUtenti ########################################### # # # # # Elenco di UTENTI che POSSONO essere utilizzati da sshd, # # Per impostazione predefinita - non specificato = tutti sono ammessi. Quelli. se # # è specificato almeno un utente, l'accesso ssh al server # # è disponibile solo per lui. # # # ## DenyGroups ########################################### # # # # # Elenco di GRUPPI che NON possono essere utilizzati da sshd. # # Per impostazione predefinita - non specificato = nessun gruppo è vietato. # # Cioè se viene specificato almeno un gruppo, agli utenti # # inclusi in questo gruppo verrà negato l'accesso al server ssh # #. # # # ## Consenti gruppi ########################################### # # # # Elenco di GRUPPI che possono essere utilizzati da sshd. # # Per impostazione predefinita - non specificato = consentito a tutti. Quelli. se # # viene specificato almeno un gruppo, solo gli utenti # # che ne fanno parte potranno accedere al server ssh. # # # ################## ## ###################################### ######### Opzioni che determinano lo stato della connessione ########### ################################# # ######################## # # ## TCPKeepAlive #################### ## ####################### # # # Indica se il sistema deve inviare messaggi TCP al client # # per mantenere la connessione. Se invii questi pacchetti, # # puoi determinare se la connessione è interrotta. Tuttavia, # # significa anche che la connessione potrebbe interrompersi nel caso # # di un'interruzione momentanea del routing e # # questo è molto fastidioso per alcuni. D'altra parte, se # # tali messaggi non vengono inviati, le sessioni sul server possono # # continuare all'infinito, generando # # utenti - "fantasmi", # # e divorando le risorse del server. L'impostazione predefinita è "sì", # # i.e. inviare tali messaggi. Per disabilitare l'invio di # # di tali messaggi, impostare il valore su "no". Questa # # opzione era precedentemente chiamata KeepAlive. Vale la pena notare che # # ci sono modi più sicuri per controllare lo stato della # # connessione (vedi sotto). # # # TCPKeepAlive sì # # ## ClientAliveCountMax ######################################## #### # # # Specifica il numero di messaggi ai client che sshd # # invia di seguito senza ricevere alcuna risposta dal # # client. Se la soglia viene raggiunta e il # # client non ha ancora risposto, sshd disconnetterà il client, interrompendo la # # sessione ssh. Va notato che l'uso di tali messaggi # # è fondamentalmente diverso dalla direttiva TCPKeepAlive. # # I messaggi da/verso i client vengono inviati su un canale # # crittografato e quindi non sono soggetti a spoofing. I messaggi # # TCPKeepAlive sono suscettibili di spoofing. Il meccanismo # # del client vivo è particolarmente utile nei casi in cui il server e il client hanno bisogno # # di sapere quando una connessione è diventata inattiva. Il valore predefinito # # è 3. Se ClientAliveInterval # # è impostato su 15 e ClientAliveCountMax viene lasciato su # # predefinito, i client che non rispondono verranno disconnessi circa # # dopo 45 secondi. Questa direttiva funziona solo per il protocollo # # ssh2. # # # ## ClientAliveInterval ################################### # # # Imposta l'intervallo di tempo in secondi. Se durante questo # # intervallo non c'è stata comunicazione con il client, sshd # # invia un messaggio su un canale crittografato, # # richiedendo una risposta dal client. Il valore predefinito è 0, ad es. # # non inviare tali messaggi. Questa direttiva funziona # # solo per il protocollo ssh2. # # # ############################################## ############ ################ Opzioni generali di autenticazione ################# ## ################################################# # ####### # # ## AuthorizedKeysFile ################################### # # # # Specifica un file che contiene chiavi pubbliche # # utilizzate per autenticare gli utenti. La direttiva # # può contenere marcatori come % M, che vengono sostituiti in # # durante la creazione della connessione. # # Sono definiti i seguenti token: # # %% - sostituito dal letterale "%" # #% h - sostituito dalla directory home # # dell'utente autenticante # #% u - sostituito dal nome dell'utente autenticante # # Pertanto, il file chiave può essere specificato come # # percorso assoluto (cioè un file condiviso con chiavi) e # # dinamicamente, a seconda dell'utente (cioè # # file per ogni utente). # # L'impostazione predefinita è ".ssh / authorized_keys". # # Esempio per un file chiave nella cartella home dell'utente: # # AuthorizedKeysFile% h / .ssh / authorized_key # # Esempio per un file condiviso: # # AuthorizedKeysFile / etc / ssh / authorized_keys # # Per ulteriori informazioni vedere la descrizione del file authorized_keys # # informazione. # # # ## ChallengeResponseAuthentication ######################### # # # Specifica se abilitare l'autenticazione challenge-response # # (autenticazione challenge-response ) . Sono supportati tutti i # # tipi di autenticazione da login.conf. Per impostazione predefinita - "sì", # # i.e. permettere. # # In Ubuntu, disabilitato per motivi di sicurezza. # # # ChallengeResponseAuthentication no # # ## HostbasedUsesNameFromPacketOnly ######################### # # # Specifica come il server dovrebbe ottenere il nome host del client # # quando uno schema di autenticazione basato sulla convalida dell'host. # # Se impostato su "yes", sshd # # utilizzerà il nome host fornito dal client durante il controllo delle corrispondenze nei file # # ~ / .shosts, ~ / .rhosts o /etc/hosts.equiv. # # (eseguendo la risoluzione DNS inversa) Se impostato su "no" # # - sshd risolverà il nome dalla connessione TCP stessa. # # Il valore predefinito è "no". # # # ## IgnoraRhosts ########################################### # # # Impedisce l'uso di file .rhosts e.shosts # # durante l'autenticazione basata su host. # # (RhostsRSAAuthentication o HostbasedAuthentication). # # I file /etc/hosts.equiv e /etc/ssh/shosts.equiv sono ancora # # in uso. # # L'impostazione predefinita è "sì". # # # IgnoreRhosts sì # # ## IgnoreUserKnownHosts #################################### # # # Indica se sshd deve ignorare l'utente # # file "known hosts" ~ / .ssh /known_hosts durante # # autenticazione basata su host # # (RhostsRSAAuthentication o HostbasedAuthentication). # # Il valore predefinito è "no". # # # ## PermitBlacklistedKeys ################################# # # # Indica se accettare chiavi sshd nella lista nera # # come compromesso (chiavi # # compromesse note (vedi ssh-vulnkey)). Se il valore è "yes" - # # i tentativi di autenticazione con tali chiavi verranno # # registrati e accettati, se il valore è "no" - i tentativi di autenticazione # # verranno rifiutati. # # Il valore predefinito è "no". # # # ## PermitEmptyPasswords ################################## # # # In caso di autenticazione consentita con utilizzando una password, # # indica se è possibile accedere con una password vuota. # # Il valore predefinito è "no". # # # PermitEmptyPasswords no # # ## PermitRootLogin ####################################### # # # # Indica se il login ssh è possibile come superutente # # (root). Può assumere i seguenti valori: # # “yes” - il superutente può accedere. # # Viene applicato lo schema di autenticazione globale corrente. # # # # “Senza password” - il superutente può effettuare il login. # # L'autenticazione della password sarà disabilitata. # # # # “Solo comandi forzati” - il superutente potrà accedere, # # utilizzando l'autenticazione con chiave pubblica e # # solo se dà il comando da eseguire. # # Questo è utile per eseguire backup, # # anche quando è normale (cioè non tramite ssh) # # l'accesso root è negato. Tutti gli altri # # metodi di autenticazione per il superutente verranno bloccati # # # # “No” - il superutente non può usare ssh per # # effettuare il login. # # # # L'impostazione predefinita è "sì". # # # PermitRootLogin si # # ## Protocollo ####################################### # ####### # # # Specifica quale protocollo deve usare sshd. # # I valori possibili per '1' e '2' sono ssh1 e ssh2 # # rispettivamente. È possibile la scrittura simultanea, con # # separando i valori con virgole. # # L'impostazione predefinita è “2.1”. # # Vale la pena notare che l'ordine dei protocolli in # # record non imposta la priorità, poiché il client sceglie quale # # dei vari protocolli offerti dal server utilizzare # # La voce "2,1" è assolutamente identica # # alla voce "1,2". # # # Protocollo 2 # # ## Usa PAM ###################################### ## ######## # # # Abilita l'interfaccia Pluggable Authentication Module # # Se impostato su "yes" - per tutti i tipi di autenticazione # # oltre al modulo di sessione e alla gestione dell'account # # Verrà utilizzata l'autenticazione PAM in base alla # # richiesta -response (ChallengeResponseAuthentication e # # PasswordAuthentication) # # L'autenticazione challenge-response in PAM di solito svolge lo stesso ruolo # # dell'autenticazione della password, dovresti # # disabilitare PasswordAuthentication o # # ChallengeResponseAuthentication. Vale la pena notare che # # se la direttiva UsePAM è abilitata, non sarai in grado di eseguire # # sshd come utente diverso da root. # # Il valore predefinito è "no". # # # UsePAM yes # # ## PasswordAuthentication ################################# # # # Indica se l'autenticazione utilizzando # # password. # # L'impostazione predefinita è "sì". # # # ## HostKey ########################################### # #### # # # Specifica il file contenente la chiave host privata # # utilizzata da SSH. Il valore predefinito è /etc/ssh/ssh_host_key ## per il protocollo ssh1 e /etc/ssh/ssh_host_rsa_key e ## /etc/ssh/ssh_host_dsa_key per il protocollo ssh2. Nota # # che sshd non utilizzerà un file che è # # accessibile a chiunque non sia l'utente. Puoi # # utilizzare diversi file con chiavi, chiavi “rsa1” - # # per il protocollo ssh1 e “dsa” / “rsa” per il protocollo ssh2. # # # HostKey / etc / ssh / ssh_host_rsa_key HostKey / etc / ssh / ssh_host_dsa_key # # ############################## # ############################################### Protocollo SSH opzioni versione 1 (ssh1) ### ########## ############################## ######## ##################### # # È fortemente SCONSIGLIATO l'uso del protocollo ssh1 # # Il protocollo ssh2 è molto più sicuro di ssh1 # ############ ################################## ############# # # ## KeyRegenerationInterval ############################### ########## # # Per il protocollo ssh1 - una volta a una certa ora # # viene generata automaticamente una nuova chiave temporanea del server # # (se utilizzata). Questo viene fatto per # # impedire la decrittazione delle sessioni intercettate, con l'obiettivo di # # accedere successivamente alla macchina con i parametri di queste sessioni e # # rubare le chiavi. Tale chiave non viene memorizzata da nessuna parte (memorizzata nella # # RAM). Questa direttiva specifica il # # periodo di "vita" della chiave in secondi, dopo il quale verrà # # rigenerato. Se il valore è impostato uguale a 0 - # # la chiave non verrà generata di nuovo. # # Il valore predefinito è 3600 (secondi). # # # KeyRegenerationInterval 3600 # # ## RhostsRSAAuthentication ############################### # # # Indica se l'autenticazione è basata su file # # rhosts o /etc/hosts.equiv in combinazione con # # autenticazione host riuscita tramite RSA. # # Rilevante solo per il protocollo ssh1. # # Il valore predefinito è "no". # # # RhostsRSAAuthentication no # # ## RSAAuthentication ####################################### ######################## # # Indica se è consentita l'autenticazione RSA pura. # # Rilevante solo per il protocollo ssh1. # # L'impostazione predefinita è "sì". # # # Autenticazione RSA sì # # ## ServerKeyBits ###################################### # ## # # # Specifica il numero di bit nella chiave temporanea del server per il # # protocollo ssh1. Valore minimo 512. # # Il valore predefinito è 1024. # ServerKeyBits 768 # # ############################### ## ############################################ Opzioni del protocollo SSH versione 2 (ssh2) #### ######## ################################## ###### ################### # # ## Cifrari #################### ####### ###################### # # # Specifica gli algoritmi di crittografia consentiti per # # il protocollo ssh2. Più algoritmi devono essere # # separati da virgole. Algoritmi supportati: # # “3des-cbc”, “aes128-cbc”, “aes192-cbc”, “aes256-cbc”, # # “aes128-ctr”, “aes192-ctr”, “aes256-ctr”, “ arcfour128 ”, # #“ arcfour256 ”,“ arcfour ”,“ blowfish-cbc ”,“ cast128-cbc ”. # # I valori predefiniti sono: # # aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, arcfour128, # # arcfour256, arcfour, aes192-cbc, aes256-cbc, aes128-ctr, # # aes192-ctr, aes256-ctr # # # ## HostbasedAuthentication ############################### # # # Indica se l'autenticazione è consentita in base a # # convalida dell'host. Controllare rhosts o /etc/hosts.equiv, # # e in caso di successo, combinato con un controllo riuscito # # della chiave pubblica, l'accesso è consentito. Questa direttiva # # è la stessa della direttiva RhostsRSAAuthentication e # # è adatta solo per il protocollo ssh2. # # Il valore predefinito è "no". # # # HostbasedAuthentication no # # ## MAC ####################################### # ############ # # # Specifica un algoritmo MAC valido (messaggio # # codice di autenticazione). L'algoritmo MAC è utilizzato # # dal protocollo ssh2 per proteggere l'integrità dei dati. Più # # algoritmi devono essere separati da virgole. # # Vengono utilizzati i valori predefiniti: # # hmac-md5, hmac-sha1, [e-mail protetta] , hmac-ripemd160, # # hmac-sha1-96, hmac-md5-96 # # # ## PubkeyAuthentication ########################## # ########## # # # Indica se l'autenticazione con chiave pubblica basata su # # è consentita. Rilevante solo per il protocollo ssh2. # # L'impostazione predefinita è "sì". # # # PubkeyAuthentication si ########################################## ## ############# ################### Opzioni GSSAPI ############# ### ########## ####################################### ################### # # ############ Applicabile solo al protocollo ssh2 ######## ### # # ## GSSAPIAuthentication ################################## # # # Indica se l'autenticazione dell'utente è # # basato su GSSAPI. L'impostazione predefinita è "no", ad es. proibito. # # # ## GSSAPIKeyExchange #################################### # # # Indica se # # È consentito lo scambio di chiavi basato su GSSAPI. Lo scambio di chiavi tramite GSSAPI non si basa su # # chiavi ssh per verificare l'identità dell'host. # # Il valore predefinito è "no" - ad es. lo scambio è vietato. # # # ## GSSAPICleanupCredentials ############################### # # # Specifica se distruggere automaticamente # # credenziali di autenticazione personalizzate cache quando # # termina la sessione. # # Il valore predefinito è "sì" - ad es. bisogno di essere distrutto. # # # ## GSSAPIStrictAcceptorCheck ############################## # # # Specifica quanto rigoroso deve essere il controllo di identità # # client durante l'autenticazione con GSSAPI. # # Il valore "yes" forza il client ad autenticarsi # # al servizio host ricevente sull'host corrente. Il valore "no" # # consente al client di autenticarsi con qualsiasi # # chiave di servizio. # # L'impostazione predefinita è "sì". # # Nota che l'impostazione del valore su "no" potrebbe # # funzionare solo con rare librerie Kerberos GSSAPI. # # # ############################################## ############ ################## Opzioni Kerberos ################ ## ####### ########################################### ################# # # ## Autenticazione Kerberos ######################### ## ###### # # # Specifica se la password fornita # # dall'utente per l'autenticazione # # (PasswordAuthentication) richiede la convalida in Kerberos KDC. # # Per utilizzare questa opzione, il server deve # # verificare che il KDC sia vero. (Il server necessita di una # # servtab Kerberos che permetta la verifica dell'identità del # # KDC) # # L'impostazione predefinita è “no”. # # # ## KerberosGetAFSToken ################################## # # # Se AFS è attivo e il l'utente ha ottenuto un Kerberos 5 TGT, # # se provare a ottenere il token AFS prima che l'utente # # ottenga l'accesso alla propria cartella home. # # Il valore predefinito è "no". # # # ## KerberosOrLocalPasswd ################################## # # # Indica come comportarsi se # # autenticazione tramite Kerberos non riuscita. Se # # value = "yes" - la password verrà verificata utilizzando # # qualsiasi meccanismo di autorizzazione locale aggiuntivo, # # ad esempio - / etc / passwd. # # L'impostazione predefinita è "sì". # # # ## KerberosTicketCleanup ################################## # # # Specifica se distruggere automaticamente c # # file con la cache dei ticket dell'utente al termine della sessione. # # L'impostazione predefinita è "sì". # # # ############################################## ############ ################# Opzioni di reindirizzamento ################## # ################################################# ########### # # ## AllowAgentForwarding ################################# # ## # # # Specifica se abilitare o disabilitare il reindirizzamento # # ssh-agent "a. L'impostazione predefinita è“ yes ", ovvero consenti. # # Va notato che disabilitare il reindirizzamento non # # aumenterà la sicurezza finché anche gli utenti # # l'accesso alla shell verrà negato in quanto sarà sempre possibile installare # # le proprie controparti dell'agente # # # ## AllowTcpForwarding ####################### # ############### # # # Specifica se abilitare o disabilitare il reindirizzamento TCP # # L'impostazione predefinita è “yes”, ovvero abilitare nel caso di AllowAgentForwarding, disabilitare # # reindirizzamento non aumenterà la sicurezza finché # # gli utenti avranno accesso alla console, dal momento che possono # # installare le loro controparti. # # # # # ## GatewayPorts ######### ## ################################# # # # Specifica se consentire agli host remoti l'accesso alle porte # # inoltrate. Per impostazione predefinita, sshd ascolta # # le connessioni alle porte inoltrate solo sull'interfaccia # # locale (loopback). Ciò impedisce ad altri # # host remoti di connettersi alle porte inoltrate. Puoi # # usare GatewayPorts per consentire a sshd di # # farlo. La direttiva può assumere 3 valori: # # "no" - solo loopback. # # "sì" - qualsiasi indirizzo. # # "specificato dal cliente" - indirizzi specificati dal cliente. # # # ## Permesso di apertura ########################################### # # # # # Specifica dove è consentito l'inoltro della porta TCP. # # Una specifica di reindirizzamento deve assumere una delle # # forme seguenti: # # PermitOpen host: port # # PermitOpen IPv4_addr: port # # PermitOpen: port # # È possibile specificare più voci separandole con spazi. # # L'argomento “any” può essere usato per rimuovere tutti i # # divieti di port forwarding. Per impostazione predefinita, è consentito qualsiasi # # reindirizzamento. # # # ## PermitTunnel ########################################## # # # Indica se il reindirizzamento del dispositivo tun è consentito. # # Valori possibili: # # “yes” # # “point-to-point” (3° livello di rete) # # “ethernet” (2° livello di rete) # # “no” # # Il valore “yes” consente sia il punto a -punto # # ed ethernet. L'impostazione predefinita è "no". # # # ############################################## ############ ################## Opzioni di registrazione ################# # ## ############################################# ## ########### # # ## SyslogFacility ############################## ### ####### # # # Specifica l'ID oggetto di registro per scrivere messaggi su # # sshd. Valori possibili: # # DAEMON # # USER # # AUTH # # LOCAL0 # # LOCAL1 # # LOCAL2 # # LOCAL3 # # LOCAL4 # # LOCAL5 # # LOCAL6 # # LOCAL7 # # Il valore predefinito è AUTH. # # # SyslogFacility AUTH # # ## LogLevel ##################################### ## ###### # # # Imposta il livello di verbosità del log sshd. # # Scelte possibili: # # SILENT # # QUIET # # FATAL # # ERROR # # INFO # # VERBOSE # # DEBUG # # DEBUG1 # # DEBUG2 # # DEBUG3 # # L'impostazione predefinita è INFO. # # DEBUG e DEBUG1 sono equivalenti tra loro. # # DEBUG2 e DEBUG3 impostano i livelli più alti di # # debug di output. La scrittura di log con livello DEBUG # # minaccia la privacy dell'utente e non è consigliata. # # # LogLevel INFO # # ######################################## ## ############### ################### Reindirizza X11 ############ ## ###### ############################################ ############### # # ## X11Inoltro ########################### ### ############# # # # Specifica se il reindirizzamento # # della grafica X11 è consentito. Può essere "sì" o "no". # # Il valore predefinito è "no". # # Attenzione - abilitare il semplice reindirizzamento X11 - # # grande rischio sia per il server che per i client come in # # tale reindirizzamento, il display proxy sshd # # accetta connessioni da qualsiasi indirizzo. Usa # # la direttiva X11UseLocalhost per limitare l'accesso al # # xx redirect server. Vale la pena notare che # # disabilitare il reindirizzamento non garantirà che # # utenti non saranno in grado di reindirizzare X11, poiché avendo # # accesso alla console impostano sempre il loro # # redirector. Il reindirizzamento X11 sarà # # automaticamente disabilitato se # # la direttiva UseLogin è abilitata. # # # X11Inoltro sì # # ## X11UseLocalhost ####################################### ##################### # # # # Specifica se sshd deve limitare l'area di reindirizzamento X11 # # a un indirizzo di loopback locale o # # deve consentire qualsiasi indirizzo. L'impostazione predefinita è sshd # # "aggancia" il server di reindirizzamento X11 all'indirizzo locale # # e imposta la parte della variabile d'ambiente DISPLAY # # responsabile del nome host come “localhost”. Vale la pena notare che # # alcuni vecchi client X11 potrebbero non funzionare con questa # # impostazione. L'impostazione predefinita è "sì", ad es. reindirizzamento # # limitato da localhost, valore - "no" - disabilita # # restrizioni. # # # ## XAuthLocation ######################################### # # # Specifica il percorso completo del programma xauth. # # Il valore predefinito è / usr / bin / X11 / xauth. # # # ## X11DisplayOffset ##################################### # # # Indica il numero del primo display accessibile da sshd in # # come reindirizzamento X11. Questo è # # in modo che le x reindirizzate non si intersechino con quelle # # reali. Il valore predefinito è 10. # # # X11DisplayOffset 10 # # #################################### # ##################### ################## Varie opzioni ####### ## ############### ################################ ### ################################# # # ## LoginGraceTime ############ ###### ################################### # # # Tempo trascorso il quale il server si disconnette # # l'utente se non è riuscito ad accedere in modo soddisfacente # #. Valore 0 - consente all'utente # # di accedere a tempo indeterminato. Il valore predefinito è 120 (secondi). # # # LoginGraceTime 120 # # ## MaxAuthTries ###################################### # ### # # # Specifica il numero massimo di tentativi di autenticazione # # consentiti per connessione. # # Quando il numero di tentativi non riusciti supera la metà # # del valore specificato, tutti i tentativi successivi verranno # # registrati. Il valore predefinito è 6. # # # ## MaxSessions ###################################### #### # # # Specifica il numero massimo di connessioni simultanee # # per ogni connessione di rete. Il valore predefinito è 10. # # # ## MaxStartups ##################################### ## #### # # # Specifica il numero massimo di # # connessioni simultanee non autorizzate a sshd. Se # # il numero di connessioni supera il limite, tutte le ulteriori # # connessioni verranno eliminate fino a quando le # # connessioni correnti non saranno completate tramite l'autorizzazione, # #, o entro la scadenza del periodo di tempo specificato nella direttiva # # LoginGraceTime . Il valore predefinito è 10. # # Inoltre, è possibile impostare il ripristino anticipato della connessione # # specificando tre valori come parametro, # # separati dai due punti “start: rate: full” (ad esempio: “10:30: 60”). # # sshd rifiuterà il tentativo di connessione con una probabilità di # # “rate / 100” (es. nel nostro esempio - 30%), se ci sono già # # “start” (10) connessioni non autorizzate. # # La probabilità aumenta in modo lineare e qualsiasi # # tentativi di connessione verrà rifiutato se il numero di # # connessioni non autorizzate raggiunge il "pieno" (60). # # # ## Compressione ########################################### # # # # Indica se la compressione dei dati è abilitata. Può essere # # "sì" - la compressione è abilitata. # # "delayed" - la compressione viene ritardata fino a quando # # l'utente viene autenticato con successo. # # "no" - nessuna compressione. # # Il valore predefinito è "ritardato". # # # ## UseLogin ########################################## ## ## # # # Specifica se il login deve essere usato per # # una sessione interattiva. L'impostazione predefinita è "no". # # Vale la pena notare che login non è mai stato usato per # # eseguire comandi remoti. Nota anche che # # usare login renderà impossibile # # usare la direttiva X11Forwarding, perché login non sa # # cosa fare con xauth. Se la direttiva # # UsePrivilegeSeparation è abilitata, verrà disabilitata dopo # # autorizzazione. # # # ## UsePrivilegeSeparation ######################################## # # # Specifica se sshd deve condividere i privilegi... Se sì # # - allora verrà creato prima un processo figlio senza privilegi # # per il traffico di rete in entrata. Dopo l'autorizzazione # # riuscita, verrà creato un altro processo con i privilegi # # dell'utente che ha effettuato l'accesso. Lo scopo principale della # # condivisione dei privilegi è impedire che i privilegi di accesso vengano superati. # # L'impostazione predefinita è "sì". # # # UsePrivilegeSeparation sì # # ## StrictModes ####################################### ############## ##### # # # Specifica se sshd deve controllare le modalità di accesso e # # la proprietà delle cartelle e dei file dell'utente prima di # # consentire all'utente di accedere. Questo di solito è perché # # i neofiti spesso rendono i propri file # # scrivibili da tutti.Il valore predefinito è "sì". # # # StrictModes yes # # ## AcceptEnv ####################################### # ###### # # # Specifica quali variabili d'ambiente passate # # dal client verranno accettate. Vedere l'opzione SendEnv sul client. # # Va notato che il trasferimento delle variabili è possibile solo # # per il protocollo ssh2. Le variabili sono specificate per nome, # # puoi usare le maschere ('*' e '?'). È possibile specificare # # più variabili separate da uno spazio o suddividerle in # # più righe AcceptEnv. Fai attenzione: alcune # # variabili d'ambiente possono essere usate per bypassare # # ambienti utente vietati. Usa questa # # direttiva con attenzione. Per impostazione predefinita, non sono accettate # # variabili di ambiente definite dall'utente. # # # AcceptEnv LANG LC_ * # # ## PermitUserEnvironment ################################## # # # Specifica se sshd deve accettare # # ~ / .ssh / environment e l'opzione environment = in # # ~ / .ssh / authorized_keys. L'impostazione predefinita è "no". Vale la pena # # notare che # # consentire l'elaborazione dell'ambiente può dare agli utenti la possibilità di aggirare le restrizioni in alcune # # configurazioni utilizzando meccanismi come # # LD_PRELOAD. # # # # # ## PidFile ######################################## # ###### # # # Specifica il file contenente l'ID processo # # (ID processo, PID) del demone SSH. # # Il valore predefinito è /var/run/sshd.pid # # # # # ## PrintLastLog ########################### # ############## # # # Specifica se sshd deve visualizzare la data e l'ora # # dell'ultimo servizio quando un utente accede in modo interattivo. # # L'impostazione predefinita è "sì". # # # PrintLastLog sì # # ## PrintMotd ###################################### # ###### # # # Specifica se sshd deve visualizzare / etc / motd # # quando un utente accede in modo interattivo. Su alcuni # # sistemi (es. Ubuntu) queste informazioni sono # # visualizzate anche dalla shell. # # L'impostazione predefinita è "sì". # # # PrintMotd no # # ## Banner ####################################### # ######### # # # Specifica quale file contiene un banner di testo che # # verrà mostrato all'utente PRIMA della # # procedura di autenticazione. Questa opzione è disponibile solo per il protocollo ssh2 # # Per impostazione predefinita, non mostra nulla. # # Su Ubuntu, il file issue.net contiene la frase Ubuntu (versione), # # ad esempio, per karmic è "Ubuntu 9.10". Può essere # # utilizzato per disorientare potenziali aggressori, # # scrivendoci ad esempio "My D-Link Interet Router" =) # # # Banner /etc/issue.net # # ## ChrootDirectory ######### ## ############################################# # # # Se specificato, fornisce il percorso in cui # # verrà utilizzato per eseguire il chroot dopo l'autenticazione. Il percorso e tutti i suoi # # contenuti devono corrispondere alle cartelle di # # di proprietà del superutente ed essere # # scrivibili da altri utenti. # # Il percorso può contenere etichette che vengono sostituite nel # # processo di autenticazione: # # %% - viene sostituito dal letterale "%" # #% h - viene sostituito dalla home directory # # dell'utente autenticato # #% u - è sostituito dal nome dell'utente autenticato # # chroot -folder dovrebbe contenere tutti i file e le # # cartelle necessari per la sessione utente. Una sessione interattiva # # richiede almeno: # # una shell, solitamente sh # # dispositivi di base in / dev come: # # null, zero, stdin, stdout, stderr, arandom e tty # # per una sessione di trasferimento dati utilizzando sftp nessuna impostazione aggiuntiva # # richiesta se si utilizza # # un processo server sftp interno. Vedere Sottosistema per # # ulteriori informazioni. Per impostazione predefinita, nessun chroot viene eseguito. # # # ## ForceCommand ########################################## # # # Forza l'esecuzione del comando specificato. Ignora # # qualsiasi comando dato dal client o scritto in # # ~ / .ssh / rc. Il comando viene invocato da una # # shell dell'utente con l'opzione -c. Adatto per avviare una shell, # # comando o un sottosistema. Molto utile all'interno di un blocco # # Match. Il comando originariamente emesso dal client è memorizzato # # nella variabile di ambiente SSH_ORIGINAL_COMMAND. Se # # specifica il comando "internal-sftp", # # verrà avviato un server sftp interno, che non necessita dei file e delle cartelle # # aggiuntivi descritti nella direttiva ChrootDirectory. # # # ## Sottosistema ########################################### # ## # # # Definisce e configura un sottosistema esterno (ad esempio # # demone di trasferimento file). # # Gli argomenti sono il nome e il comando (con eventuali # # argomenti) che verrà eseguito durante la richiesta # # ai sottosistemi. Il comando sftp-server avvia il sottosistema di trasferimento file "sftp" - # #. Inoltre, puoi specificare # # come sottosistema "internal-sftp" - che avvierà # # il server sftp interno. Questo può semplificare notevolmente la # # configurazione quando si usa la # # direttiva ChrootDirectory Per impostazione predefinita, nessun sottosistema # # viene invocato. Rilevante solo per il protocollo ssh2. # # # Sottosistema sftp / usr / lib / openssh / sftp-server # # ################################ # ############################################## Blocco di corrispondenza # ################################################# ###### ####################################### # # # # # scrivere le regole di corrispondenza. # # MadKox. # # # # La direttiva Match è l'inizio di un blocco # # condizionale. Se tutti i criteri specificati nella riga # # Match sono soddisfatti, vengono eseguite le direttive nelle righe successive del blocco, # # permettendo di bypassare i valori delle direttive globali nel file # # sshd_config per il caso il criterio per la direttiva # # Match. Si considera blocco tutte le righe che seguono la riga # # con il criterio (Corrispondenza - righe) fino alla riga di corrispondenza successiva # # o fino alla fine del file. L'argomento della direttiva Match è una o # # più coppie di record di criteri. Possibili tipi di record: # # Utente # # Gruppo # # Host # # Indirizzo # # I record possono contenere sia singoli valori # # (ad esempio Utente = utente), sia più valori, # # separati da virgole (Utente = utente1 , utente2). Anche # # espressioni regolari possono essere usate come descritto nella sezione # # PATTERNS del file ssh_config. Le voci nei criteri # # Indirizzo possono contenere indirizzi nella notazione CIDR # # (Indirizzo / Lunghezza maschera, ad esempio "192.0.2.0/24" o # # "3ffe: ffff :: / 32"). Vale la pena notare che la # # lunghezza della maschera data deve corrispondere all'indirizzo e che un indirizzo # # troppo lungo / corto non funzionerà. # # Come direttive Match può utilizzare solo # # un determinato insieme di direttive: # # AllowTcpForwarding # # Banner # # ChrootDirectory # # ForceCommand # # GatewayPorts # # GSSAPIAuthentication # # HostbasedAuthentication # # KbdInteractiveAuthentication # # KerberosAuthentication # # MaxAuthries PasswordAuthentication # # PermitOpen # # PermitRootLogin # # RhostsRSAAuthentication # # RSAAuthentication # # X11DisplayOffset # # X11Forwarding # # X11UseLocalHost #

Puoi copiare il testo sopra nel tuo sshd_config e usarlo in seguito per la configurazione.

Di per sé, un server SSH configurato in modo errato è un'enorme vulnerabilità nella sicurezza del sistema, poiché un potenziale aggressore ha la capacità di ottenere un accesso quasi illimitato al sistema. Inoltre, sshd ha molte opzioni utili aggiuntive che dovresti abilitare per una maggiore usabilità e sicurezza.

Porta, ListenAddress e AddressFamily

Questi tre parametri determinano su quali porte e indirizzi il tuo server attenderà le connessioni in entrata. In primo luogo, ha senso, se possibile, limitare la famiglia di indirizzi in elaborazione a quelli effettivamente utilizzati, ovvero se si utilizza solo IPv4, disabilitare IPv6 e viceversa. Questo può essere fatto utilizzando il parametro AddressFamily, ad esempio (per abilitare IPv4 e disabilitare IPv6):

IndirizzoFamiglia inet

In secondo luogo, è consigliabile cambiare la porta standard (22) su cui sshd è in ascolto. Ciò è dovuto al fatto che numerosi scanner di rete cercano costantemente di connettersi alla 22a porta e almeno di ottenere l'accesso tramite login/password a forza bruta dal loro database. Anche se hai disabilitato l'autenticazione della password, questi tentativi intasano pesantemente i log e (in gran numero) possono influenzare negativamente la velocità del server ssh. Se per qualche motivo non si desidera modificare la porta standard, è possibile utilizzare sia varie utilità esterne per combattere la forzatura bruta, ad esempio fail2ban, sia quelle integrate, come MaxStartups.
La porta può essere impostata sia come valore assoluto per tutte le interfacce che utilizzano la direttiva Port, sia come valore specifico per ciascuna interfaccia utilizzando la direttiva ListenAddress. Ad esempio:

Porto 2002

ListenAddress 192.168.0.1:2003 ListenAddress 192.168.1.1:2004

Nega l'accesso remoto al superutente

Per impostazione predefinita, l'accesso root è negato tramite password (per chiave - è possibile) - l'opzione PermitRootLogin è impostata su senza password. Ma, a condizione che per impostazione predefinita in Ubuntu l'utente aggiunto durante l'installazione del sistema abbia la capacità di risolvere tutte le attività amministrative tramite sudo, sembra irragionevole creare l'accesso root al sistema tramite ssh (anche con l'autenticazione tramite chiave). Si consiglia di disabilitarlo del tutto. questa opzione o usala solo in modalità solo comandi forzati. Puoi disabilitare l'accesso root in questo modo:

PermitRootLogin no

Autenticazione con password

L'autenticazione della password predefinita è quasi il modo più primitivo per accedere a sshd. Questo da un lato semplifica la configurazione e la connessione di nuovi utenti (l'utente deve solo conoscere il proprio login/password di sistema), dall'altro la password è sempre reperibile e gli utenti spesso trascurano la creazione di complesse e lunghe Le password. Bot speciali scansionano costantemente i server ssh disponibili da Internet e provano ad accedervi tramite login/password a forza bruta dal loro database. L'utilizzo dell'autenticazione con password è fortemente sconsigliato. Puoi disabilitarlo in questo modo:

PasswordAuthentication no

Se per qualche motivo desideri ancora utilizzare l'autenticazione con password, assicurati che nessuno possa accedere con una password vuota. Per fare ciò, imposta la direttiva PermitEmptyPasswords:

PermessoVuotoPassword no

Protocolli SSH1 e SSH2

Come già accennato, sshd può gestire i protocolli SSH1 e SSH2. Tuttavia, l'uso di SSH1 insicuro è altamente sconsigliato. Puoi forzare sshd a funzionare solo con il protocollo SSH2 in questo modo:

Autenticazione basata su chiavi RSA SSH2

Il metodo di autenticazione preferito è l'autenticazione con chiave RSA SSH2. Con questo metodo, l'utente genera dalla sua parte una coppia di chiavi, di cui una chiave è segreta e l'altra pubblica. La chiave pubblica viene copiata sul server e serve a verificare l'identità dell'utente. Per maggiori dettagli sulla creazione di una coppia di chiavi e su come posizionarle sul server, vedere la descrizione del client SSH. È possibile abilitare l'autenticazione con chiave pubblica come segue:

PubkeyAuthentication sì

Il server deve sapere dove cercare la chiave pubblica dell'utente. A tale scopo viene utilizzato il file speciale authorized_keys. La sua sintassi può essere la seguente:

# I commenti vengono scritti solo su una nuova riga # vista generale delle voci nel file authorized_keys # [opzioni] key_type (ssh-rsa o ssh-dss) very_long_string_incomprehensible_for_imple_human [login @ host] ssh-rsa AAAAB3Nza ... LiPk == [e-mail protetta] from = "*. sales.example.net,! pc.sales.example.net" ssh-rsa AAAAB2 ... 19Q == [e-mail protetta] command = "dump / home", no-pty, no-port forwarding ssh-dss AAAAC3 ... 51R == example.net allowopen = "192.0.2.1:80", allowopen = "192.0.2.2:25" ssh -dss AAAAB5 ... 21S == tunnel = "0", comando = "sh / etc / netstart tun0" ssh-rsa AAAA ... == [e-mail protetta]

È possibile specificare un file condiviso con chiavi o un file per ogni utente. Quest'ultimo metodo è più conveniente e sicuro, perché, in primo luogo, è possibile specificare diverse combinazioni di chiavi per ciascun utente e, in secondo luogo, limitare l'accesso alla chiave pubblica dell'utente. Puoi impostare un file con chiavi usando la direttiva AuthorizedKeysFile:

AuthorizedKeysFile% h / .ssh / my_keys

per l'utente dello schema - file
o

AuthorizedKeysFile / etc / ssh / authorized_keys

per uno schema con un file condiviso. Per impostazione predefinita, il client SSH cerca le chiavi nel file ~/.ssh/authorized_keys.

Maggiori informazioni sulla sicurezza

Altre impostazioni

Utenti e gruppi.

Se sono presenti molti utenti sul server e si desidera consentire l'accesso tramite ssh solo ad alcuni di essi, è possibile utilizzare le direttive DenyUsers, AllowUsers, DenyGroups e AllowGroups. Per maggiori dettagli su queste direttive, vedere i commenti nell'esempio sshd_config.

Opzioni dello stato della connessione

Per impostazione predefinita, tra i metodi per determinare lo stato della connessione, è incluso solo il metodo per verificare la connessione TCP - TCPKeepAlive, tuttavia, sshd è in grado di determinare lo stato della connessione in modi più convenienti e sicuri. Per i dettagli, vedere la sezione correlata nell'esempio sshd_config.

Prestazione. MaxStartup

Port forwarding

Reindirizzamento X11

Sul server, impostare il parametro nel file /etc/ssh/sshd_config (abilitato per impostazione predefinita):

AvantiX11 sì

Sul client, imposta i parametri nel file /etc/ssh/ssh_config (disabilitato per impostazione predefinita):

ForwardAgent sì ForwardX11 sì

Puoi eseguire sul client in questo modo ssh [e-mail protetta] firefox. Oppure vai prima su ssh [e-mail protetta] quindi esegui, ad esempio sudo synaptic.

SFTP

Sshd ha un server SFTP integrato per impostazione predefinita. SFTP (SSH File Transfer Protocol) è un protocollo di trasferimento file SSH. È progettato per copiare ed eseguire altre operazioni sui file tramite una connessione affidabile e sicura. In genere, il protocollo SSH2 viene utilizzato come protocollo di connessione sottostante. Per abilitare il supporto SFTP aggiungi la linea a sshd_config

Sottosistema sftp / usr / lib / openssh / sftp-server

Per impostazione predefinita, il supporto SFTP è abilitato.

Utilizzando criteri. Direttiva sulla partita

Configurazione di un client SSH

L'accesso più sicuro è tramite chiave e nella maggior parte dei casi questa funzione è abilitata sul lato server, quindi non sono necessari diritti di superutente per utilizzarla. Genera una chiave sul computer client:

ssh-keygen -t rsa

Riceviamo un'offerta per inserire una password per proteggere il file chiave (si rivela utile quando il file cade nelle mani sbagliate). Se eseguiremo script tramite SSH, lo lasciamo vuoto. Trasferiamo la chiave pubblica al server con il comando

Ssh-copy-id -i ~ / .ssh / id_rsa.pub [e-mail protetta] server

Tutto, puoi andare.

Quando ssh è in esecuzione su una porta non standard:

Ssh-copy-id -i ~ / .ssh / id_rsa.pub "-p port [e-mail protetta]"

Se si verifica un errore: porta errata "umask 077; test -d .ssh || mkdir .ssh; cat >> .ssh / authorized_keys"

prova a prendere i parametri tra virgolette:

Ssh-copy-id "-i /home/user/.ssh/id_rsa.pub" -p port [e-mail protetta]""

È conveniente utilizzare l'utilità dello schermo durante la connessione a un sistema remoto.

Configurare una directory ssh remota in Nautilus

Montare una directory remota usando sshfs

Monta la directory remota nella directory locale

sshfs [e-mail protetta] hostingserver.ru:/ home / userdir ~ / sshfsdir

smontare

Fusermount -u ~ / sshsfdir

Alias ​​SSH

Quando si utilizzano più server con parametri di accesso diversi (porta non standard, nome host lungo, accesso diverso da quello locale, ecc.), a volte è noioso inserire nuovamente tutte le impostazioni di connessione ogni volta. È possibile utilizzare alias per facilitare questo.

Le impostazioni sono memorizzate in ~ / .ssh / config per un utente e / etc / ssh / ssh_config globalmente per tutti gli utenti.

Un esempio di configurazione. Molti server possono essere descritti. Di più in man ssh_config(da non confondere con sshd_config)

Host AliasName # Nome host arbitrario HostName 1.2.3.4 # È possibile specificare sia l'IP che il nome host (se il DNS funziona) User YourUserName # Se l'utente non corrisponde all'utente locale Port YourSSHPort # Se una porta non standard

Successivamente, puoi connetterti al server con il comando

ssh Nome Alias

ssh-agente

Diagnosi dei problemi di connessione

Analisi del log di connessione:

ssh -vvv [e-mail protetta] ospite

Analisi dei file di configurazione client e server.

La posizione dei file di configurazione può essere trovata da

Uomo ssh uomo sshd

Utilizzo di smart card

1. La creazione di un certificato e l'esportazione di una chiave pubblica, così come la parte client su Windows + Putty SC, sono descritte sul sito Web: http://habrahabr.ru/post/88540/ Descritto il componente aggiuntivo Key Manager è disponibile solo nelle versioni precedenti di Firefox. Testato sulla versione 3.5 per Windows. Link diretto al componente aggiuntivo: https://addons.mozilla.org/en/firefox/addon/key-manager/

2. Preparazione del server. È necessario assicurarsi che la configurazione di sshd consenta l'autenticazione tramite chiavi pubbliche. A tale scopo, impostare il valore del parametro PubkeyAuthentication su yes nel file sshd_config. Quindi aggiungi la nostra chiave pubblica ottenuta in precedenza (in una riga) al file "~ / .ssh / authorized_keys". Si prega di notare che il file ".ssh/authorized_keys" si trova nella home directory dell'utente che poi accederà con la chiave pubblica.

3. Parte client su Linux. Dovrai ricostruire il pacchetto OpenSSH senza parametri. Si consiglia di specificare solo i prefissi delle directory, ad esempio –prefix = / usr. Va anche notato che i file di configurazione saranno in / usr / ecc. Prima di iniziare, hai bisogno dei seguenti pacchetti: opensc-lite-devel, zlib-devel, openssl-devel. Installazione del driver della smart card. Per comodità, nella configurazione ssh_config (da non confondere con sshd_config) specificare il percorso della libreria pkcs: PKCS11Provider =<путь к библиотеке>

4. Sul client, esegui ssh [e-mail protetta] Se una smart card (token) è connessa, chiederà una password e accederà alla sessione SSH.

Possibili problemi durante l'utilizzo

La familiare combinazione di tasti Ctrl + S utilizzata in molti editor per salvare le correzioni, quando si lavora in un terminale con un server ssh, porterà all'esecuzione del comando XOFF, che sembra un blocco della sessione. Tuttavia, non lo è. Il server continua ad accettare caratteri e comandi immessi, ma non li visualizza sullo schermo. Per uscire da questa situazione è sufficiente applicare la combinazione Ctrl + Q, riattivando così la modalità XON.

Link

Cioè, user1 può essere registrato sia in se stesso - nel file /home/user1/.ssh/keys) che in un altro utente, che gli permetterà di accedere dal suo computer sia "sotto sé" che sotto "altro"

O SSH in breve, è una delle tecnologie più avanzate per la protezione dei dati in transito. L'utilizzo di questa modalità sullo stesso router consente di garantire non solo la riservatezza delle informazioni trasmesse, ma anche di velocizzare lo scambio di pacchetti. È vero, non tutti sanno com'è SSH e perché tutto questo è necessario. In questo caso, dovrai dare una spiegazione costruttiva.

Porta SSH: cos'è e perché ne hai bisogno?

Trattandosi di sicurezza, in questo caso, la porta SSH va intesa come un canale di comunicazione dedicato sotto forma di tunnel che fornisce la crittografia dei dati.

L'operazione più primitiva di un tale tunnel è che la porta SSH aperta viene utilizzata per impostazione predefinita per crittografare le informazioni all'origine e decrittografare all'endpoint. Ciò può essere spiegato come segue: che ti piaccia o no, il traffico trasmesso, a differenza di IPSec, viene crittografato in modo forzato sia all'uscita di un terminale di rete che all'ingresso del lato ricevente. Per decifrare le informazioni trasmesse su questo canale, il terminale ricevente utilizza una chiave speciale. In altre parole, nessuno può interferire con la trasmissione o violare l'integrità dei dati trasmessi senza una chiave.

La semplice apertura di una porta SSH su un qualsiasi router o l'utilizzo delle opportune impostazioni di un client aggiuntivo che interagisce direttamente con il server SSH consente di sfruttare appieno tutte le capacità di sicurezza delle reti moderne. Il punto qui è utilizzare la porta predefinita o le impostazioni personalizzate. Questi parametri possono sembrare piuttosto complicati nell'applicazione, ma qui è indispensabile comprendere l'organizzazione di tale connessione.

Porta SSH standard

Se parti davvero dai parametri di un qualsiasi router, per prima cosa devi decidere che tipo di software verrà utilizzato per utilizzare questo canale di comunicazione. In realtà, la porta SSH predefinita può avere impostazioni diverse. Tutto dipende dalla tecnica utilizzata al momento (connessione diretta al server, installazione di un client aggiuntivo, port forwarding, ecc.).

Quindi, ad esempio, se Jabber viene utilizzato come client, la porta 443 deve essere utilizzata per la connessione, la crittografia e il trasferimento dati corretti, sebbene la porta 22 sia impostata per impostazione predefinita.

Per riconfigurare il router per allocare i prerequisiti per un programma o processo specifico, sarà necessario eseguire il port forwarding SSH. esiste un'assegnazione di determinati accessi per un programma separato che utilizza una connessione Internet, indipendentemente dalle impostazioni del protocollo di comunicazione corrente (IPv4 o IPv6).

Giustificazione tecnica

Come già saprai, la porta SSH 22 standard non viene sempre utilizzata. Tuttavia, qui è necessario evidenziare alcune delle caratteristiche e dei parametri utilizzati durante la configurazione.

Perché la riservatezza del trasferimento di dati crittografati richiede l'uso di SSH come porta utente esclusivamente esterna (guest)? Sì, solo perché il tunneling utilizzato consente di utilizzare la cosiddetta shell remota (SSH), accedere alla gestione del terminale tramite login remoto (slogin), e utilizzare procedure di copia remota (scp).

Inoltre, la porta SSH può essere utilizzata anche quando l'utente ha bisogno di eseguire script X Windows remoti, che nel caso più semplice è il trasferimento di informazioni da una macchina all'altra, come già detto, con crittografia dei dati forzata. In tali situazioni, il più necessario sarà l'uso di algoritmi basati su AES. Questo è l'algoritmo di crittografia simmetrica, originariamente fornito nella tecnologia SSH. E non solo è possibile usarlo, ma anche necessario.

Cronologia dell'implementazione

La tecnologia stessa è apparsa molto tempo fa. Lasciamo da parte la domanda su come effettuare il port forwarding SSH per ora e soffermiamoci su come funziona.

Di solito si tratta di utilizzare proxy basati su Socks o tunneling VPN. Se qualche applicazione software sa come lavorare con VPN, è meglio preferire questa particolare opzione. Il fatto è che quasi tutti i programmi conosciuti oggi che utilizzano il traffico Internet possono funzionare con una VPN e l'impostazione del routing non è difficile. Questo, come nel caso dei server proxy, permette di non riconoscere l'indirizzo esterno del terminale, dal quale si sta attualmente accedendo alla rete. Cioè, nel caso di un proxy, l'indirizzo cambia costantemente, ma nella versione VPN rimane invariato con la fissazione di una determinata regione, diversa da quella in cui è vietato l'accesso.

La stessa tecnologia, quando viene aperto il porto SSH, è stata sviluppata nel 1995 presso l'Università Tecnologica della Finlandia (SSH-1). Nel 1996 è stato aggiunto un miglioramento sotto forma del protocollo SSH-2, che è diventato abbastanza diffuso nello spazio post-sovietico, sebbene per questo, così come in alcuni paesi dell'Europa occidentale, a volte sia necessario ottenere il permesso di utilizzare tale tunnel, inoltre, dalle agenzie governative.

Il vantaggio principale dell'apertura di una porta SSH, a differenza di telnet o rlogin, è l'uso di una firma digitale RSA o DSA (usando una coppia sotto forma di chiave pubblica e nascosta). Inoltre, in questa situazione, può essere utilizzata una cosiddetta chiave di sessione basata sull'algoritmo Diffie-Hellman, che implica l'uso della crittografia simmetrica in uscita, sebbene non escluda l'uso di algoritmi di crittografia asimmetrica nel processo di trasmissione e ricezione dei dati da un'altra macchina.

Server e shell

Windows o no, non è così difficile. L'unica domanda è che tipo di strumenti verranno utilizzati per questo.

In questo senso, va posta attenzione al tema del trasferimento delle informazioni e dell'autenticazione. Innanzitutto, il protocollo stesso risulta essere sufficientemente protetto dal cosiddetto sniffing, che è la più comune "intercettazione" del traffico. SSH-1 si è dimostrato indifeso contro gli attacchi. L'intervento nel processo di trasferimento dei dati sotto forma di uno schema "man in the middle" ha avuto i suoi risultati. Le informazioni potrebbero essere semplicemente intercettate e decifrate in modo molto semplice. Ma la seconda versione (SSH-2) era assicurata contro questo tipo di interferenza, chiamata dirottamento di sessione, grazie alla quale è diventata la più diffusa.

Divieti di sicurezza

Per quanto riguarda la sicurezza in relazione ai dati trasmessi e ricevuti, l'organizzazione di una connessione realizzata utilizzando tali tecnologie evita i seguenti problemi:

• determinazione della chiave all'host in fase di trasmissione, quando viene utilizzata l'impronta digitale "snapshot";
• supporto per sistemi simili a Windows e UNIX;
• sostituzione di indirizzi IP e DNS (spoofing);
• intercettazione di password aperte durante l'accesso fisico al canale di trasmissione dati.

In realtà, l'intera organizzazione di un tale sistema è costruita sul principio di "client-server", ovvero, prima di tutto, la macchina dell'utente, tramite un programma speciale o un componente aggiuntivo, fa riferimento al server, il che rende appropriato reindirizzamento.

Tunneling

Va da sé che nel sistema deve essere installato un driver speciale per effettuare questo tipo di connessione.

Di norma, sui sistemi Windows, questo è il driver Microsoft Teredo integrato nella shell del software, che è una sorta di mezzo virtuale per emulare il protocollo IPv6 nelle reti con solo supporto IPv4. è in stato attivo per impostazione predefinita. In caso di guasti ad esso associati, puoi semplicemente riavviare il sistema o eseguire i comandi di spegnimento e riavvio nella console dei comandi. Le seguenti righe vengono utilizzate per disattivare:

• rete;
• interfaccia teredo imposta lo stato disabilitato;
• interfaccia isatap set stato disabilitato.

Dopo aver inserito i comandi, segue un riavvio. Per riabilitare l'adattatore e verificarne lo stato, anziché disabilitato, viene scritto il permesso abilitato, dopodiché, di nuovo, dovrebbe essere riavviato l'intero sistema.

server SSH

Vediamo ora quale porta SSH viene utilizzata come principale, partendo dallo schema "client-server". In genere, l'impostazione predefinita è la porta 22, ma, come accennato in precedenza, può anche utilizzare la 443. L'unica domanda è la preferenza del server stesso.

I server SSH più comuni sono considerati i seguenti:

• per Windows: Server Tectia SSH, OpenSSH con Cygwin, MobaSSH, KpyM Telnet / Server SSH, WinSSHD, copssh, freeSSHd;
• per FreeBSD: OpenSSH;
• per Linux: Tectia SSH Server, ssh, openssh-server, lsh-server, dropbear.

Tutti i server elencati sono gratuiti. Tuttavia, puoi anche trovare servizi a pagamento che si distinguono per un maggiore livello di sicurezza, estremamente necessario per organizzare l'accesso alla rete e proteggere le informazioni nelle aziende. Il costo di tali servizi non è attualmente in discussione. Ma in generale, possiamo dire che è relativamente economico, anche rispetto all'installazione di un software specializzato o di un firewall "hardware".

client SSH

La porta SSH può essere modificata in base al programma client o alle impostazioni corrispondenti durante l'inoltro delle porte sul router.

Tuttavia, quando si tratta di shell client, i seguenti prodotti software possono essere utilizzati per diversi sistemi:

• Windows - SecureCRT, PuTTY \ KiTTY, Axessh, ShellGuard, SSHWindows, ZOC, XShell, ProSSHD, ecc.;
• Mac OS X: iTerm2, vSSH, NiftyTelnet SSH;
• Linux e BSD: lsh-client, kdessh, openssh-client, Vinagre, putty.

Autenticazione con chiave pubblica e modifica della porta

Ora alcune parole su come il server è verificato e configurato. Nel caso più semplice, è necessario utilizzare un file di configurazione (sshd_config). Tuttavia, puoi farne a meno, ad esempio, nel caso di utilizzo di programmi come PuTTY. Cambiare la porta SSH dal valore predefinito (22) a qualsiasi altro è abbastanza semplice.

La cosa principale è che il numero della porta aperta non supera il valore di 65535 (semplicemente non ci sono porte più alte in natura). Inoltre, ci sono alcune porte predefinite da notare che possono essere utilizzate da client come database MySQL o FTPD. Se specifichi la loro configurazione per SSH, ovviamente, smettono semplicemente di funzionare.

Vale la pena considerare che lo stesso client Jabber deve essere in esecuzione nello stesso ambiente utilizzando un server SSH, come una macchina virtuale. E al server localhost stesso dovrà essere assegnato il valore 4430 (e non 443, come menzionato sopra). Questa configurazione può essere utilizzata quando il firewall sta bloccando l'accesso al file principale jabber.example.com.

È invece possibile inoltrare le porte sul router stesso, utilizzando le impostazioni della sua interfaccia con la creazione di regole di esclusione. Sulla maggior parte dei modelli, il login viene effettuato inserendo indirizzi che iniziano con 192.168 con l'aggiunta di 0.1 o 1.1, ma su router che combinano le capacità di modem ADSL come Mikrotik, l'indirizzo finale presuppone l'utilizzo di 88.1.

In questo caso viene creata una nuova regola, dopo di che vengono impostati i parametri necessari, ad esempio, per stabilire una connessione dst-nat esterna, e anche le porte vengono registrate manualmente non nella sezione delle impostazioni generali, ma nella sezione Preferenze azione . Non c'è niente di particolarmente complicato qui. La cosa principale è specificare i valori delle impostazioni necessarie e impostare la porta corretta. Di default è possibile utilizzare la porta 22, ma se si utilizza un client specializzato (uno dei precedenti per sistemi diversi), il valore può essere modificato arbitrariamente, ma solo affinché questo parametro non superi il valore dichiarato, al di sopra del quale ci sono semplicemente nessun numero di porta.

Quando si imposta una connessione, è necessario prestare attenzione anche ai parametri del programma client. Potrebbe essere che nelle sue impostazioni dovrai specificare la lunghezza minima della chiave (512), sebbene il valore predefinito sia solitamente 768. È anche consigliabile impostare il timeout di accesso a 600 secondi e consentire l'accesso remoto utilizzando i diritti di root. Dopo aver applicato tali impostazioni, devi anche concedere il permesso di utilizzare tutti i diritti di autenticazione, ad eccezione di quelli basati sull'utilizzo di .rhost (ma questo è necessario solo per gli amministratori di sistema).

Tra l'altro, se il nome dell'utente registrato nel sistema non corrisponde a quello immesso al momento, sarà necessario specificarlo in modo esplicito, utilizzando il comando user ssh master con parametri aggiuntivi (per chi capisce cosa c'è in gioco ).

Il comando ~ / .ssh / id_dsa (o rsa) può essere utilizzato per convertire la chiave e il metodo di crittografia stesso. Per creare una chiave pubblica, viene utilizzata una trasformazione che utilizza la riga ~ / .ssh / identity.pub (ma non è richiesta). Ma, come dimostra la pratica, il modo più semplice è usare comandi come ssh-keygen. Qui il nocciolo della questione si riduce solo all'aggiunta di una chiave agli strumenti di autorizzazione disponibili (~ / .ssh / authorized_keys).

Ma siamo andati troppo oltre. Tornando al problema della configurazione della porta SSH, come già chiaro, cambiare la porta SSH non è così difficile. È vero, in alcune situazioni, come si suol dire, devi sudare, poiché dovrai prendere in considerazione tutti i valori dei parametri principali. Il resto del problema di configurazione si riduce all'accesso al server o al programma client (se fornito inizialmente) o all'utilizzo del port forwarding sul router. Ma anche se cambi la porta predefinita 22 con la stessa 443a, devi capire chiaramente che tale schema non funziona sempre, ma solo nel caso di installazione dello stesso componente aggiuntivo Jabber (anche altri analoghi possono utilizzare le porte corrispondenti , diverso dallo standard). Inoltre, occorre prestare particolare attenzione all'impostazione dei parametri del client SSH, che interagirà direttamente con il server SSH, se si suppone che utilizzi la connessione corrente.

In caso contrario, se non previsto inizialmente (sebbene sia auspicabile eseguire tali azioni), non è necessario modificare le impostazioni ei parametri per l'accesso tramite protocollo SSH. In generale, non ci sono problemi particolari nella creazione di una connessione e nel suo ulteriore utilizzo (a meno che, ovviamente, non vengano utilizzate impostazioni di configurazione manuali basate sul server e sul client). Il modo più comune per creare una regola di esclusione su un router risolverà tutti i problemi o li eviterà.