No more maintained.
Now just a test in a lab.
SSH
Il protocollo, i server, i client. OpenSSH
Overview di Openssh
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
La suite di Openssh nasce dal gruppo (ma non solo) che sviluppa OpenBSD, ha come scopo la sostituzione di tutti quei comandi intrinsecamente pericolosi come telnet, rcp poiche' il traffico passa in chiaro (comprese le nostre preziosissime password) con comandi e tools che implementano protocolli criptati considerati sicuri come SSH protocol
versione 1.3, 1.5 e 2.0.
Lo sviluppo della suite e' gestita da due team, uno che si focalizza sullo sviluppo del codice in ambiente OpenBSD ed un secondo che si preoccupa del porting della suite su altri OS.
Anche se lo sforzo e' notevole (Updates,patchs non mancano di certo ed escono con una certa frequenza) molto spesso affiorano problemi di sicurezza non indiferrenti (Addirittura Troyan nei sorgenti) che richiedono un immediato patching. La suite di Openssh include:
ssh Per la sostituzione di telnet e rlogin
scp Per la sostituzione di rcp
sftp Per la sostituzione di ftp
sshd Il comando per lanciare un server ssh.
Inoltre sono fornite utility per la gestione delle chiavi pubbliche e private. (ssh-add ssh-keygen ...).
Di sicuro la sua portabilita', facilita' di installazione e l'innumerevoli features lo rendono il mezzo piu' utilizzato al mondo per aprire conessione in quelle reti non considerate trusted.
Ecco alcune features:
Open Source Project Il codice sorgente e' disponibile a tutti, con tutti i vantaggi del caso.
Free Licensing La suite openssh non ha una licenza ristrettiva e puo' essere utilizzata anche per scopi commerciali.
Strong Encryption Openssh utilizza algoritmi come 3DES e Blowfish per una miglior e sicura compressione dati.
X11 Forwarding (encrypt X Window System traffic) Permette la compressione del traffico di un remoto X windows, quindi possiamo esportare sul nostro display senza preoccuparci di una possibile intercettazione della nostra password
Port Forwarding (encrypted channels for legacy protocols) Ci permette di forwardare le connessioni TCP/IP standard su una macchina remota attraverso canali sicuri ovvero criptati. Ad esempio il POP si potrebbe rendere sicuro in questo modo.
Strong Authentication (Public Key, One-Time Password e Kerberos Authentication) Molteplici tipi di autentificazione robusti.
Openssh Security Hardening
Tipo Infobox: TIPS - Skill: 2- JUNIOR
Avendo disposizione i sorgenti possiamo modificarli a nostro piacimento, cosi abbiamo la possibilita' di nascondere, modificare la versione per rendere difficoltoso lo scouting delle informazioni.
Inoltre e' bene modificare alcuni parametri del demone.
Nella directory dei sorgenti vi e' un file chiamato version.h, il quale definisce semplicemente la versione del package.
$ cat version.h
#define SSH_VERSION "OpenSSH_3.4p1"
Modificate il valore OpenSSH_3.4p1 in quello che volete, salvate il file e compilate come meglio credete.
Potete verificare il vostro operato facendo un semplice telnet sulla porta 22:
$ telnet 0 22
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
SSH-2.0-CORE 1.0
in questo caso la versione e' CORE 1.0 (ovviamente dopo aver modificato i sorgenti)
Nel vostro /var/log/messages se incontrate entry simili a queste significa che avete subito uno scan sulla porta 22 per identificare la versione del package di Openssh:
Sep 10 21:02:52 morpheus sshd[10190]: Did not receive identification string from 10.0.0.100
Esistono tools che fanno un probe sulla porta 22 per identificare che versione di openssh si ha installato sul proprio server
Inoltre e' bene "correggere" alcuni valori di default del demone sshd, in sshd_config modificare:
Limitare al solo protocollo 2, intrinsecamente piu' sicuro
Protocol 2
Limitare il listening solo sulle interfacce da cui effettivamente devono avvenire le connessioni
ListenAddress 10.0.0.1
Aumentare il serverKeyBits almeno a 1024, valido solo per il protocollo 1
ServerKeyBits 1024
Aumentare il livello di logging
LogLevel INFO
Non permettere il login come root e con password empty
PermitRootLogin no
PermitEmptyPasswords no
Inoltre e' bene filtrare le connessioni da ip considerati trusted o tramite iptables oppure tramite tcpwrappers se il package e' stato compilato per il supporto di questa feature.
sshd
Tipo Infobox: COMMANDS - Skill: 2- JUNIOR
Server della suite di Openssh.
Puo' essere configurato per girare sia come server standalone, sia come servizio gestito da inetd o xinetd con tutti i vantaggi del caso. (Es: tcpwrappers)
Qualunque sia la sua modalita' di avvio, la configurazione del demone e' gestita tramite il file sshd_config il quale racchiude tutte le opzioni che possono essere passate anche in linea di comando.
Di seguito vengono riportate le opzioni piu' utilizzate:
sshd [-dtiq] [-b bits] [-f config_file] [-h host_key_file] [-p port]
-d Abilita il debug mode, il server invia i messaggi in stdout e non permette al server di girare in background, e' possibile aumentare la verbosita' aggiungendo altre "d" fino ad un max di 3.
-t Test mode, verifica il file di configurazione ela validita' delle chiavi senza far partire il servizio.
-i Flag specifico per identificare, che il servizio parte da inetd.
-q Abilita il quit mode, solo alcuni messaggi vengono loggati
-b Specifica il numero di bits della key server per il protocollo 1
-f config_file Specifica il file di configurazione. Default /etc/ssh/sshd_config
-p Specifica la porta, dove il server rimarra' in Listenig. Default 22
/etc/ssh
Tipo Infobox: PATH - Skill: 3- INTERMEDIATE
Directory (rpm standard) ove risiedono i file di configurazione e i file contenenti le chiavi private e pubbliche della suite openssh.
Altrimenti, se la suite e' stata compilata da sorgenti senza passargli nessun parametro, il path standard e' /usr/local/etc.
Vale per qualsiasi sistema *Unix
Esempio di un ls -l della directory /etc/ssh:
-rw-r--r-- 1 root root 1110 Feb 25 2002 ssh_config
-rw------- 1 root root 1773 Jul 4 17:47 sshd_config
-rw------- 1 root root 668 Nov 2 2001 ssh_host_dsa_key
-rw-r--r-- 1 root root 590 Nov 2 2001 ssh_host_dsa_key.pub
-rw------- 1 root root 515 Nov 2 2001 ssh_host_key
-rw-r--r-- 1 root root 319 Nov 2 2001 ssh_host_key.pub
-rw------- 1 root root 883 Nov 2 2001 ssh_host_rsa_key
-rw-r--r-- 1 root root 210 Nov 2 2001 ssh_host_rsa_key.pub
ssh_config e' il file di configurazione del client ssh il quale contiene le opzioni utilizzate di default con il comando ssh.
# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsAuthentication no
# RhostsRSAAuthentication yes
# RSAAuthentication yes
# PasswordAuthentication yes
# FallBackToRsh no
# UseRsh no
# BatchMode no
# CheckHostIP yes
# StrictHostKeyChecking yes
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_rsa
# Port 22
# Protocol 2,1
# Cipher blowfish
# EscapeChar ~
sshd_config e' il file di configurazione del demone sshd:
Porta tcp da bindare
Port 22
I protocolli con cui negoziare la connessione
Protocol 1,2
Su quale ip rimanere in ascolto
#ListenAddress 0.0.0.0
Elenco dei file contenenti le varie chiavi
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
Indica il numero di bit per la chiave lato server per il protocollo 1
ServerKeyBits 1024
Tempo in secondi per chiudere la connessione quando un utente non si e' ancora loggato
LoginGraceTime 600
Il tempo in secondi per la rigenerazione della chiave lato server, protocollo 1
KeyRegenerationInterval 3600
Permette o meno il login come root
PermitRootLogin yes
#
# Don't read ~/.rhosts and ~/.shosts files
Specifica l'utilizzo o meno dei file .rhosts e .shosts quando si utilizza
IgnoreRhosts yes
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
ignora o meno il contenuto del file $HOME/.ssh/known_hosts per RhostsRSAAuthentication e HostbasedAuthentication.
#IgnoreUserKnownHosts yes
Abilita o meno il check dei permessi della home dell'utente e del suo contenuto prima di abilitare l'utente al login
StrictModes yes
Abilita o meno i il forwarding dei pacchetti di X
X11Forwarding no
Specifica il primo numero del display disponibile
X11DisplayOffset 10
Visualizza al login il contenuto di /etc/motd
PrintMotd yes
Visualizza alcune informazioni sull'ultimo login effettuato sulla macchina
PrintLastLog no
Mantiene attiva la connessione (lato server)
KeepAlive yes
Opzioni per il Logging
SyslogFacility AUTHPRV
LogLevel DEBUG
#obsoletes QuietMode and FascistLogging
Abilita o meno RhostsAuthentication
RhostsAuthentication no
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
Abilita o meno RhostsRSAAuthentication
RhostsRSAAuthentication no
# similar for protocol version 2
Abilita o meno HostbasedAuthentication
HostbasedAuthentication yes
Abilita o meno SAAuthentication
RSAAuthentication yes
# To disable tunneled clear text passwords, change to no here!
Abilita o meno PasswordAuthentication
PasswordAuthentication yes
Permette di l'utilizzo o meno le password empty
PermitEmptyPasswords no
# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no
# Uncomment to enable PAM keyboard-interactive authentication
# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt yes
# To change Kerberos options
Opzioni per kerberos
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no
# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes
Verifica la presenza di mail nella mailbox dell'utente che si e' loggato
#CheckMail yes
Utilizzo o meno del login in alcune situazioni particolari
#UseLogin no
Specifica il numero delle connessioni non autentificate da droppare
#MaxStartups 10:30:60
Visualizza il contenuto del file
#Banner /etc/issue.net
Verifica o meno del reverse del'ip da cui provenie la connessione
#ReverseMappingCheck yes
Configurazioni per i subsystem esterni
#Subsystem sftp /usr/libexec/openssh/sftp-server
$home/.ssh/
Tipo Infobox: PATH - Skill: 3- INTERMEDIATE
Directory contenente le chiavi pubbliche e private e file di configurazione del singolo utente
Ecco il classico contenuto della directory
[neo@dido neo]$ ls -l .ssh/
total 28
-rw-r--r-- 1 neo neo 456 Jun 4 15:30 configure
-rw------- 1 neo neo 736 Jul 4 15:02 identity
-rw------- 1 neo neo 736 Jul 4 15:02 identity.pub
-rw------- 1 neo neo 736 Jul 4 15:02 id_dsa
-rw-r--r-- 1 neo neo 598 Jul 4 15:02 id_dsa.pub
-rw------- 1 neo neo 736 Jul 4 15:02 id_rsa
-rw-r--r-- 1 neo neo 598 Jul 4 15:02 id_rsa.pub
-rw-r--r-- 1 neo neo 15463 Sep 13 12:14 known_hosts
-rw-r--r-- 1 neo neo 3931 Jun 24 12:25 known_hosts2
In particolare avremo:
identity / identity.pub File contenenti le chiavi private e pubbliche di tipo rsa per il protocollo 1
configure File di configurazione del client ssh del singolo utente. La struttura del file e' uguale a quello generale che di default e' .../ssh/ssh_configure
id_dsa / id_rsa File contenente le chiavi private dell'utente per il protocollo 2
id_dsa.pub / id_rsa.pub File contenente le chiavi pubbliche dell'utente per il protocollo 2
know_host / know_host2 File che ha la funzone di db per i vari host key dei server a cui ci si collega. rispettivamente per il protocollo 1 e 2
ssh
Tipo Infobox: COMMANDS - Skill: 2- JUNIOR
Client per il login o lancio di comandi da remoto attravero la suite di ssh.
ssh [-l login_name] [hostname | user@hostname] [command]
ssh [-afgknqstvxACNPTX1246] [-c cipher_spec] [-e escape_char] [-i identity_file] [-l login_name] [-m mac_spec] [-o option] [-p port] [-L port:host:hostport] [-R port:host:hostport] [hostname | user@hostname] [command]
-lSpecifica il nome dell'utente con cui aprire la connessione sull'host remoto.
user@hostname Come sopra
-f Manda in background ssh prima di lanciare il comando
-i [identity_file] Specifica il file contenente la chiave privata (rsa e dsa)
-v Abilita il verbose mode.
-x Disabilita x11 forwarding
-X Abilita x11forwarding
-C Richiede la compressione dati
-1 Forza l'uso del protocollo 1
-2 Forza l'uso del protocollo 2
scp
Tipo Infobox: COMMANDS - Skill: 2- JUNIOR
Secure copy, permette di copiare file, directory da host remoti utilizzando il protocollo ssh.
Utile anche per backup o restore veloci, valida alternativa a ftp soprattutto se si considera la criptazione del traffico.
comando [opzioni] [argomenti]
scp [-pqrvC46] [-S program] [-P port] [-c cipher] [-i identity_file] [-o option] [[user@]host1:]file1 [...] [[user@]host2:]file2
-p Preserva alcune opzioni sul file, come access time, modification time etc..
-r Recursive mode
-v Verbose mode
-P Specifica la porta a cui connettersi sull'host remoto
Utilizzo chiavi crittografiche con SSH
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
L'uso delle chiavi con SSH permette di eseguire un login senza dover digitare la password con questi due vantaggi:
1- Sicurezza: si fa a meno di usare le password che possono essere indovinate o rubate.
2- Si possono effetture collegamenti in "batch" e quindi scrivere script che prevedono un collegamento ssh.
1. Generazione sul client delle chiavi pubblica e privata:
[utente_cli@client]$ ssh-keygen -t rsa
(è possibile evitare di digitare la passphrase)
2. Invio della chiave pubblica al server
[utente_cli@client]$ scp ~/.ssh/id_rsa.pub utente_ser@server:
3. Sul server inserire il contenuto di id_rsa.pub appena trasferito in /home/utente_ser/.ssh/authorized_keys2:
[utente_ser@server]$ cat id_rsa.pub >> .ssh/authorized_keys2
(Questo comando va eseguito sul server)
Da ora in poi se ci si connette al server partendo dalla shell dell'utente che ha trasmesso la chiave non verrà chiesta la password e funziona l'opzione "-o BatchMode=yes" (necessaria se usiamo il comando in uno script)
NOTA: Se la password viene ancore richiesta, provare a controllare sul server in /etc/ssh/sshd_config l'opzione "StrictModes": inserire
StrictModes no
e far ripartire il servizio sshd.
L'opzione a "yes" (default su molte distro) dice al server sshd di non accettare la connessione con la chiave pubblica se la home dell'utente e il file authorized_key hanno permessi diversi da 700 (per la dir) e 640 (per il file). Spesso però sui server le home degli utenti di un certo gruppo sono leggibili dagli utenti appartenenti al gruppo.
Tunnel SSH
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
A volte si ha la necessità di collegarsi ad un server che sta dietro un firewall e quindi non è raggiungibile.
Col comando qui sotto è possibile creare un tunnel dal server (dietro il firewall) al client attraverso cui far passare in senso contrario la connessione al servizio che ci occorre, in questo caso 'telnet'.
Sul server lanciare il comando per creare il tunnel fino al nostro client:
$ ssh -f -N -R 2333:localhost:23 [email protected]
2333 porta usata sul client
23 porta del servizio sul server (telnet)
guest è un utente presente sul client
80.100.100.100 indirizzo IP (su internet) del client
Il server si collega con il client usando ssh e gli dice di redirigere le richieste alla porta 2333 sul client alla porta 23 del server.
Se va tutto bene verrà chiesta la password per accedere sul client come utente guest (a meno che ci sia autenticazione con chiave criptata).
Ora sul client è possibile collegarsi via telnet al server:
$telnet localhost 2333
Il comando è utile se il tunnel viene mantenuto attivo e quindi è possibile sfruttarlo, quindi attenzione ai tempi di Timeout di ssh (V. configurazione SSH).
GNU/Linux hardening: chroot environment
Tipo Infobox: WHITE PAPER - Skill: 4- ADVANCED
Chroot ci permette di "imprigionare" un utente in una radice diversa da quella che il kernel usa realmente (/).
Ciò che andremo a realizzare in questo tutorial è la creazione di un environment chroot per SSH mediante il quale potremo, appunto, “rinchiudere” gli utenti in un'unica cartella nella quale destinarvi lo stretto indispensabile.
Definiamo in primo luogo una serie di domande che ci consentiranno di svolgere più facilmente il nostro lavoro:
1. Cosa vogliamo consentire all'utente ?
2. A chi è destinata la shell ?
3. Quanti utenti dovrà contenere l'ambiente chroot ?
4. Che genere di restrizioni vogliamo applicare ?
Rispondere correttamente a queste quattro domande consente di eliminare qualsiasi forma di lavoro inutile permettendo di focalizzare la nostra attenzione ai reali bisogni dell'utente.
Partiamo col dare un'immagine (puramente soggettiva) di ciò che dovrà contenere la nostra cartella ove creeremo l'env. chroot:
1. elenco software essenziale da installare:
bash
cat
cp
ls
mkdir
mv
pwd
rm
uname
2. elenco software opzionale da installare:
gcc
id
perl
pwd
vi
wget
Definito ciò che l'environment dovrà contenere iniziamo a lavorare.
Per far si che ssh funzioni in ambiente chroot dovremo ricorrere alla patch offerta da http://chrootssh.sourceforge.net/download/ scarichiamo quella per la nostra versione di ssh (o in alternativa usuiamo un pacchetto già patchato del tipo openssh-3.9p1-chroot.tar.gz).
Se si è optato per la patch (in formato .diff) scarichiamo i sorgenti di openssh per la versione di patch scaricata, applichiamola ed installiamo openssh patchato:
$ wget ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-versione.tar.gz
$ tar zxvf openssh-versione.tar.gz
$ patch -p0 < /patch/scaricata
$ ./configure --with-md5-passwords
$ make
# make install
Oppure, qualora volessimo la versione già patchata:
$ wget http://chrootssh.sourceforge.net/download/openssh-versione-chroot.tar.gz
$ tar zxvf openssh-versione-chroot.tar.gz
$ ./configure --with-md5-passwords
$ make
# make install
Riavviamo sshd:
# /etc/rc.d/rc.sshd stop
# /etc/rc.d/rc.sshd start
Arrivati a questo punto non ci resta altro da fare se non creare l'ambiente chroot vero e proprio.
Creiamo una directory per chroot:
# mkdir /home/chrooted
All'interndo della stessa creeremo un finto filesystem:
# mkdir /home/chrooted/bin
# mkdir /home/chrooted/usr
# mkdir /home/chrooted/usr/bin
# mkdir /home/chrooted/usr/lib
# mkdir /home/chrooted/lib
# mkdir /home/chrooted/sbin
# mkdir /home/chrooted/etc
# mkdir /home/chrooted/home
Ora procediamo con la copia del software necessario:
# cp /bin/bash /home/chrooted/bin
# cp /bin/ls /home/chrooted/bin
# cp /bin/mv /home/chrooted/bin
# cp /bin/cp /home/chrooted/bin
# cp /bin/cat /home/chrooted/bin
# cp /bin/mkdir /home/chrooted/bin
# cp /bin/pwd /home/chrooted/bin
# cp /bin/rm /home/chrooted/bin
# cp /usr/bin/id /home/chrooted/usr/bin
# cp /usr/bin/gcc /home/chrooted/usr/bin
# cp /usr/bin/perl /home/chrooted/usr/bin
# cp /usr/bin/pwd /home/chrooted/usr/bin
# cp /usr/bin/vi /home/chrooted/usr/bin
# cp /usr/bin/wget /home/chrooted/usr/bin
# cp /sbin/ldconfig /home/chrooted/sbin
Copiato il software penseremo alle librerie:
# ldd /bin/ls
librt.so.1 => /lib/librt.so.1 (0x47d97000)
libc.so.6 => /lib/libc.so.6 (0x47da9000)
libpthread.so.0 => /lib/libpthread.so.0 (0x47ed8000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x47d6d000)
# cp /lib/librt.so.1 home/chrooted/lib
# cp /lib/libc.so.6 home/chrooted/lib
# cp /lib/libpthread.so.0 home/chrooted/lib
# cp /lib/ld-linux.so.2 home/chrooted/lib
Copiate tutte le librerie creeremo /etc/ld.so.conf ed /etc/resolv.conf:
# touch /etc/ld.so.conf
# touch /etc/resolv.conf
All'interno del primo inseriremo il percorso delle librerie (/lib e /usr/lib), nel secondo i dati relativi il nostro nameserver.
Terminati questi passaggi l'albero del nostro filesystem falso dovrà essere simile a:
# tree /home/chrooted
/home/chrooted
|-- bin
| |-- bash
| |-- cat
| |-- cp
| |-- ls
| |-- mkdir
| |-- mv
| |-- pwd
| `-- rm
|-- etc
| |-- ld.so.conf
| `-- resolv.conf
|-- home
|-- lib
| |-- ld-linux.so.2
| |-- libc.so.6
| |-- libcrypt.so.1
| |-- libdl.so.2
| |-- libgpm.so.1
| |-- libm.so.6
| |-- libncurses.so.5
| |-- libnsl.so.1
| |-- libpthread.so.0
| |-- libresolv.so.2
| |-- librt.so.1
| |-- libtermcap.so.2
| `-- libutil.so.1
|-- sbin
| `-- ldconfig
`-- usr
|-- bin
| |-- gcc
| |-- id
| |-- perl
| |-- pwd
| |-- vi
| `-- wget
`-- lib
|-- libcrypto.so.0
`-- libssl.so.0
Cosa carina sarebbe riscrivere il software uname in maniera tale che l'utente, nell'ambiente chroot, dando il comando uname abbia in risposta un qualcosa di inventato a nostro piacimento.
Scriviamo quindi una versione finta di uname che accetti come parametri unicamente -a, -n ed -r:
<--uname.c----------------------------------------CUT HERE---------->
/*
* uname.c
* GNU/Linux hardening and chroot environment
* by mozako
*/
#include <stdio.h>
int
main(argc, argv)
int argc;
char **argv;
{
int c;
if ( argc == 1 ) {
printf("Linux\n");
} else {
while ( (c = getopt(argc,argv,"anrh")) != -1 ) {
switch ( c ) {
case 'a' : printf("Linux chrooted v.0.1\n");
break;
case 'n' : printf("chrooted\n");
break;
case 'r' : printf("v.0.1\n");
break;
case 'h' :
printf("Usage: uname [-a -n -r -h]\n");
printf("-a: print all information\n");
printf("-n: print the network node hostname\n");
printf("-r: print the kernel release\n");
break;
}
}
}
}
<--uname.c---------------------------------------/CUT HERE/--------->
$ gcc uname.c -o uname
$ ./uname
Linux
$ ./uname -a
Linux chrooted v.0.1
$ ./uname -n
chrooted
$ ./uname -r
v.0.1
$ ./uname -h
Usage: uname [-a -n -r -h]
-a: print all information
-n: print the network node hostname
-r: print the kernel release
Accertato che il programmino funzioni passiamo alla copia nell'ambiente chroot:
# cp /path/uname_falso /home/chrooted/bin/uname
Et voilà, anche l'uname falso è servito.
Abbiamo concluso con la creazione del “sistema fasullo”, non rimane altro da fare che provarlo:
# chroot /home/chrooted
I have no name!@web:/#
Proviamo qualche comando:
I have no name!@web:/# ls
bin etc home lib sbin usr
I have no name!@web:/# uname -a
Linux chrooted v.0.1
I have no name!@web:/# su
bash: su: command not found :)
I have no name!@web:/# cd home/
I have no name!@web:/home# ldconfig
I have no name!@web:/home# cat /etc/ld.so.conf
/lib
L'ambiente chroot funziona alla perferzione. E' ora che entra in azione la patch chroot di ssh.
Aggiungiamo un utente con il classico comando adduser ed alla richiesta “Home directory [ /home/user ]” inseriamo: /home/chrooted/./user:
# adduser
Login name for new user []: user
...
Home directory [ /home/user ] /home/chrooted/./home/user
...
Home directory...: /home/chrooted/./home/user
...
Account setup complete.
Aggiungendo, infatti, /./home/user al percorso /home/chrooted si fà capire a SSH che l'env. chroot risiede, appunto, in /home/chrooted e, pertanto, il nuovo utente avrà come directory root /home/chrooted e non la root del sistema.
Proviamo:
mozako@genesis:~$ ssh -l user 192.168.1.102
[email protected]'s password:
-bash-2.05b$ uname -a
Linux chrooted v.0.1
-bash-2.05b$ cd /; ls
bin etc home lib sbin usr
-bash-2.05b$ cat /etc/resolv.conf
nameserver 192.168.1.1
L'ambiente SSH chrooted funziona alla grande !
Sarà premura dell'amministratore, capito ormai come usare chroot e ssh, scegliere quali software copiare all'interno del “finto sistema”.
Rimandiamo pertanto l'admin alla lettura delle 4 domande poste come base della nostra trattazione.
Configurare OpenSSH per un utilizzo di base ma ottimale
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
Spesso quando si cerca di configurare un servizio di ssh su server casalinghi (o comunque di basso interesse) si riscontrano problemi d'accesso e restituzione di Permission Denied per problemi dovuti alle publickey, che, avendo registrato le chiave pubbliche degli accessi, non riconosce la nuova provenienza come "fidata". Risolviamo il problema ed eseguiamo una configurazione di base.
Scarichiamo il tarball di OpenSSH oppure procuriamoci il pacchetto
In Debian è sufficente un la prima connessione, per poi verificare e confrontare la chiave salvata con quella inviata dal server ad ogni nuovo login. Se queste assumono valori diversi il server assume la differenza come un possibile attacco man-in-the-middle e quindi blocca istantaneamente l'accesso e restituisce un "Permission Denied".
Innanzitutto dobbiamo prendere delle precauzioni iniziali: se si guarda in /etc/ssh si vedranno diversi file che assumono come nome ssh_host_dsa_key, ssh_host_dsa_key.pub e la stessa cosa per RSA.
Questi sono i file contenenti le chiavi generate dal server al momento dell'installazione, è buona norma farne un backup, perchè la perdita di queste chiavi può compromettere la sicurezza del servizio.
Spostiamoci nella directory /etc/ssh:
# cd /etc/ssh
# cp /etc/ssh/ssh_host*_key* /mnt/backupdevice
Nel caso in cui le chiavi vengano perse bisogna rigenerarne
# ssh-keygen -t rsa -b 1024
(con -b si possono modificare i bit disponibili alla chiave).
Ora andiamo a modificare il file di configurazione che risiede in /etc/ssh/sshd_config
Ecco le variabili essenziali da modificare per garantire un livello base di sicurezza:
# Per impedire che possano essere fatti accessi root tramite ssh
PermitRootLogin no
# Per impedire che l'uso e l'invio di password vuote durante il login
PermitEmptyPassword no
Ed infine:
# Con questa variabile si ignora l'utilizzo dei file ~/.ssh/known_hosts, in questo modo si evitano problemi dovuti ai mismatch delle chiavi pubbliche e ci si bassa unicamente sul login tramite user e password
IgnoreUserKnownHosts yes
E' possibile anche aggiungere una maggiore ristrettezza ai login utilizzando queste opzioni:
AllowUsers utente1 utente2 utente3
AllowGroups group1 group2 group3
Ma bisogna utilizzare con cautela perchè il server SSH gestisce questi parametri come AND: ossia il login deve essere sia un user permesso sia un group permesso.
Al contrario è anche possibile configurare SSH per far eseguire il login senza password, unicamente tramite le chiavi pubbliche.
Per fare questo è sufficiente copiare la nostra chiave pubblica in fondo all'apposito file di configurazione (o comunque dell'utente a cui si vuole permettere l'accesso):
# cat pubkey_user.pub >> ~/.ssh/authorized_keys
Al contrario, per revocare il permesso di una chiave basta semplicemente editare il file authorized_keys e rimuovere la chiave.
ATTENZIONE: per effettuare questo tipo di login (quindi unicamente basato sulle chaivi) è necessario che l'opzione IgnoreUserKnownHosts sia commentata o settata su no
# IgnoreUserKnownHosts yes
oppure
IgnoreUserKnownHosts no
Infine per puro senso estetico o pratico è possibile anche inserire un banner per ogni login nel nostro server SSH.
Bisogna abilitare la seguente opzione sempre in /etc/ssh/sshd_config:
banner /dir/banner_server.txt
Una volta applicati i cambiamenti restartiamo il server ssh:
# /etc/init.d/sshd restart
Questo è tutto quello che serve per una configurazione essenziale di un server ssh senza troppe pretese.
scp -C -r [file] utente@host:/[file]
Tipo Infobox: BOFH - Skill: 2- JUNIOR
Permette di effettuare la copia compressa (opzione -C), ricorsiva (opzione -r), e crittata di directory e dei file in esse contenuti tra due host.
Un esempio di utilizzo di copia da locale ad un host remoto:
[homer@Enigma homer]$ scp -C -r * homer@joker:/home/users/homer
Viene indicato di copiare tutto quanto presente nella directory corrente * sull'host joker identificandosi come utente homer nella cartella /home/users/homer
homer@joker's password: ******
Una effettuata l'autenticazione come utente homer ha inizio il trasferimento crittato dei dati
elenco.txt 100% |********************************************************| 0 00:00
pratice 100% |********************************************************| 18 00:00
programmatori.txt 100% |********************************************************| 0 00:00
main.c 100% |********************************************************| 0 00:00
test-sviluppo.txt 100% |********************************************************| 0 00:00
test.sh 100% |********************************************************| 103 00:00
winedoc-html.tgz.tar 100% |********************************************************| 5306 00:00
La struttura delle directory e i file contenuti sono copiati sull'host remoto
In caso di copia da remoto a locale la sintassi non varia di molto, è solamente necessario indicare prima l'host dal quale copiare i dati:
[homer@Enigma homer]$ scp -C -r homer@joker:/home/users/homer/* /home/homer/
homer@joker's password: ******
elenco.txt 100% |********************************************************| 0 00:00
pratice 100% |********************************************************| 18 00:00
programmatori.txt 100% |********************************************************| 0 00:00
main.c 100% |********************************************************| 0 00:00
test-sviluppo.txt 100% |********************************************************| 0 00:00
test.sh 100% |********************************************************| 103 00:00
winedoc-html.tgz.tar 100% |********************************************************| 5306 00:00
Per utilizzare scp, è necessario conoscere in anticipo la struttura delle directory ed avere un account sull'host remoto.
WinSCP
Tipo Infobox: ETCETERA - Skill: 2- JUNIOR
WinSCP, scritto da Martin Prikryl, permette di collegarsi ad un host remoto tramite SSH, e compiere operazioni di base quali, creare, cancellare, copiare, e rinominare file e directory. L'utente può scegliere tra due stili di interfaccia: Norton Commander o Explorer.
Per il collegamento via SSH è possibile generare tramite l'utility fornita a corredo di nome PuTTYgen le chiavi pubbliche di tipo RSA or DSA. WinSCP dispone inoltre di un piccolo text editor integrato con funzioni di base che si permette di modificare i file sull'host remoto, elaborandolo in locale e inviandolo via SSH una volta chiuso. Se già si utilizza PuTTY, è possibile importare da quest'ultimo l'elenco degli host name.
Infine è possibile avere un log delle operazioni compiute, e memorizzare l'elenco dei dei server, a cui di solito ci si connette, comprendente Host, porta, user e password o chiave pubblica ed il tipo di protocollo da utilizzare.
Modifica della passhprase
Tipo Infobox: STDOUT - Skill: 3- INTERMEDIATE
Output di modifica della passphrase.
homer@pluto:~/.ssh$ ssh-keygen -t dsa -p
Viene indicato a ssh-keygen il tipo di chiave (-t) da modificare in questo caso di tipo dsa
Enter file in which the key is (/home/admimg/.ssh/id_dsa):
Viene richiesto il file in cui si trova la chiave privata, di default viene ricercata nella home dell'utente
Enter old passphrase: ********
Per modificare la passhphrase è necessario inserire quella precedente
Key has comment '/home/admimg/.ssh/id_dsa'
Enter new passphrase (empty for no passphrase): *******
Enter same passphrase again: *******
Doppio inserimento per conferma della nuova passhprase
Your identification has been saved with the new passphrase.
Aggiornamento del file nel sistema
ssh utente@host [comando]
Tipo Infobox: BOFH - Skill: 3- INTERMEDIATE
Permette di eseguire un comando su un host remoto, senza necessità di aprire una shell.
Nel caso si renda necessario reperire velocemente dei valori da un macchina connessa in rete, accessibile tramite SSH, è possibile utilizzare il client Secure Shell utilizzando come parametri i comandi da eseguire sull'host remoto.
Esempio:
homer@Joker:~$ ssh homer@enigma "who; uptime"
homer@enigma's password: ********
homer pts/0 Dec 5 12:25 (192.168.0.94)
13:17:59 up 2:02, 1 user, load average: 0.00, 0.00, 0.00
homer@Joker:~$
Vengono eseguiti nell'ordine i comandi who e uptime sull'host remoto restituendo poi il prompt locale
In caso di utilzzo frequente di questa tecnica, è possibile generare delle chiavi SSH per evitare di inserire la password.
False positives di rootkithunter su fedora core 2 (riguardo OpenSSH)
Tipo Infobox: BOFH - Skill:
una breve riflessione sui false positives su fedora core 2 di rootkithunter in funzione di OpenSSH.
rootkithunter http://www.rootkit.nl/ è un potente strumento che permette di realizzare scansioni molto efficaci di rootkit, worm e altri files infetti che potrebbero trovarsi sul vostro pc.
molte volte questi programmi stampano dei false positives ossia non restituiscono valori attendibili non conoscendo a fondo la gestione e la configurazione attuale del sistema.
l'esempio seguente vede come file vulnerabili su fedora core 2, OpenSSL v 0.9.7a e OpenSSH v 3.6.1p2.
I files , se non patchati, sono potenzialmente vulnerabili. Nel caso di fedora core 2 (ben aggiornato) questi files sono stati automaticamente patchati dal team core, ma mantengono la stessa estensione. esempio: 0.9.7a
nulla di cui preoccuparci. infatti le informazioni riguardo il fix sono presenti nel changelog:
$ rpm -q --changelog openssl | head -3
* gio mar 25 2004 Joe Orton <[email protected]> 0.9.7a-35
- add security fixes for CAN-2004-0079, CAN-2004-0112
infatti le vulnerabilità erano proprio:
CAN-2004-0079
CAN-2004-0112
Propagazione delle chiavi per SSH
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
L'uso delle chiavi per l'autenticazione utente via ssh e' una modalita' che permette di gestire con una certa sicurezza e con comodita' l'accesso ai sistemi, nasce dunque l'esigenza di propagare la chiave sui sistemi gia' esistenti.Di seguito e' illustrato un modo comodo e veloce:
Creazione della chiave, in questo caso DSA
neo@eva:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/neo/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/neo/.ssh/id_dsa.
Your public key has been saved in /home/neo/.ssh/id_dsa.pub.
The key fingerprint is:
b5:4c:6e:a9:01:6e:33:e1:c5:47:e6:b4:b1:d0:5d:64 neo@eva
Avvio dell'ssh-agent
neo@eva:~$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-xCLiUW3380/agent.3380; export SSH_AUTH_SOCK;
SSH_AGENT_PID=3381; export SSH_AGENT_PID;
echo Agent pid 3381;
Acquisizione della chiave pubblica da copiare.
neo@eva:~$ ssh-add
Identity added: /home/neo/.ssh/id_dsa (/home/neo/.ssh/id_dsa)
Copia della chiave sul server remoto
neo@eva:~$ ssh-copy-id neo@remoteserver
Viene richiesta la password per propagare la chiave
neo@remoteserver's password:
Now try logging into the machine, with "ssh 'neo@remoteserver'", an d check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
Verifica della procedura
neo@eva:~$ ssh neo@remoteserver
La chiave e' stata propagata sul remoteserver, senza dover copiare direttamente nel file .ssh/authorized_keys la propria chiave pubblica.
Al primo login di ogni server occorre semplicemente ricordarsi di lanciare queste tre istruzioni e il gioco e' fatto.
Nel caso in cui si presenti il seguente errore:
neo@eva~$ ssh-add
Could not open a connection to your authentication agent.
Occorre semplicemente eseguire l'export delle variabile che sono state printate a video dal comando ssh-agent:
neo@eva:~$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-xCLiUW3380/agent.3380; export SSH_AUTH_SOCK;
SSH_AGENT_PID=3381; export SSH_AGENT_PID;
neo@eva:~$ SSH_AUTH_SOCK=/tmp/ssh-xCLiUW3380/agent.3380; export SSH_AUTH_SOCK
neo@eva:~$ SSH_AGENT_PID=3381; export SSH_AGENT_PID
ssh -C user@server -L porta:server:portalocale
Tipo Infobox: BOFH - Skill: 3- INTERMEDIATE
Ssh può essere un comodo e sicuro strumento per crittografare connessioni a server che non supportano la cifratura delle loro comunicazioni. In sostanza si usa ssh per creare un tunnel cifrato in cui far passare i dati non cifrati del servizio in oggetto.
Questo metodo si può utilizzare per molti servizi diversi (X11, vnc, pop3, swat) unico suo difetto è generare un traffico maggiore e dev'essere preso in considerazione nel caso in cui la rete sia lenta.
Poniamo di essere costretti a connetterci da remoto per configurare samba con swat.
Come si sa swat non cripta le password inviate sul network.
root@adminhost#ssh -C root@sambaserver -L 901:sambaserver:901
root@sambaserver's password:
Last login: Tue Jun 3 23:49:04 2003 from 192.168.0.111
Linux 2.4.20.
root@sambaserver#
In questo modo con l'opzione -C abilito la compressione dati e con l'opzione -L faccio in modo di forwardare la porta locale specificata con la porta server. In parole povere tutti i dati che sono diretti alla porta 901 dell'host locale vengono inviati alla porta 901 su cui ascolta swat.
Ora se dalla macchina adminhost mi collego con un browser a http://localhost:901/ sarò automaticamente connesso al tool di gestione di samba swat e mi verrà richiesta la password ma questa volta non sarà trasmessa in chiaro sulla rete.
Keep Alive con Openssh
Tipo Infobox: TIPS - Skill: 2- JUNIOR
E' utile in alcune situazioni che la connessione in ssh rimanga "ESTABLISHED" (cioe' non vada in time-out ) anche se effettivamente sulla shell non vengono effettuate operazioni e nessun dato viene scambiato fra client e server ssh.
Per abilitare la funzione KeepAlive bisogna agire in due sensi:
- Lato server: Abilitare nel file sshd_config la funzione KeepAlive inserendo la seguente riga
KeepAlive yes
- Lato client: Se si utilizza Openssh anche come client modificare il file ssh_config inserendo la seguente riga (o nella sezione generale o destinata al singolo host)
KeepAlive yes
Login via ssh
Tipo Infobox: STDOUT - Skill: 2- JUNIOR
Ecco il classico output del debug un login su una macchina remota effettuato attraverso ssh.
Linea di comando, abilitando il verbose per vedere tutti i passaggi effettuati per l'autentificazione
[neo@dido pippo]$ ssh -v -l neo remotehost
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to remotehost [10.0.0.143] port 22.
debug1: Connection established.
debug1: identity file /home/neo/.ssh/identity type -1
debug1: identity file /home/neo/.ssh/id_rsa type -1
debug1: identity file /home/neo/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version CORE 1.0
debug1: no match: CORE 1.0
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 126/256
debug1: bits set: 1598/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'arena.rete039.it' is known and matches the RSA host key.
debug1: Found key in /home/neo/.ssh/known_hosts:49
debug1: bits set: 1611/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: next auth method to try is publickey
debug1: try privkey: /home/neo/.ssh/identity
debug1: try privkey: /home/neo/.ssh/id_rsa
debug1: try pubkey: /home/neo/.ssh/id_dsa
debug1: authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: next auth method to try is password
richiede di inserire la password
neo@remotehost's password:
Password errata (controllate sempre il caps lock!!)
debug1: authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
[email protected]'s password:
La password inserita e' corretta
debug1: ssh-userauth2 successful: method password
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: channel request 0: x11-req
debug1: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
[neo@remotehost pub]$
Se e' la prima volta che vi connettete al remote host da una cerrta postazione o con un nuovo utente vi verra' visualizzato un messaggio simile al quale dovrete rispondere sempre yes (per esteso)
The authenticity of host 'morpheus (10.0.0.145)' can't be established.
RSA key fingerprint is d8:aa:6b:71:3f:ee:8a:a1:73:21:81:c1:7e:48:fc:a2.
Are you sure you want to continue connecting (yes/no)
Chiavi di SecureCRT
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
E' possibile che per utilizzare le chiavi pubbliche (rsa,dsa) create in ambiente windows, piu' specificamente da SecureCRT, per autentificarsi tramite lo scambio di chiavi e non con la classica user e password, si debba fare una operazione specifica.
Ammettiamo che la vostra chiave pubblica sia gia' presente sul server remoto e sia in pippo.pub:
ssh-keygen -X -f pippo.pub >> [home_utente]/.ssh/authorized_keys*
* Ricorda che se utilizzi il protocollo 1 il file e' esattamente quello segnalato altrimenti se utilizzi il protocollo 2 il file corretto che deve contenere la lista delle chiavi, e' authorized_keys2
Ricorda di fare un'append (>>) altrimenti verranno cancellate tutte le vecchie public key
ssh-keygen -b 1024 -t dsa
Tipo Infobox: BOFH - Skill: 4- ADVANCED
Creazione di chiavi (pubblica e privata) di tipo dsa, per permettere l'autentificazione via ssh protocollo 2 con chiave pubblica.
[pippo@dido pippo]$ ssh-keygen -b 1024 -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/pippo/.ssh/id_dsa): Created directory '/home/pippo/.ssh'.
Viene chiesto di inserire una passphrase per le vostre chiavi, per motivi di sicurezza e' bene usufruirne
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Viene creato la vostra chiave privata che dovra' rimanere sulla macchina locale
Your identification has been saved in /home/pippo/.ssh/id_dsa.
file contenente la chiave pubblica che dovra' essere presente anche sul server remoto
Your public key has been saved in /home/pippo/.ssh/id_dsa.pub.
The key fingerprint is:
31:ec:ee:82:52:2f:3e:46:6f:18:97:9d:3a:a5:7b:dc pippo@dido
ssh-keygen
Tipo Infobox: COMMANDS - Skill: 4- ADVANCED
Genera le chiavi pubbliche per l'autentificazione con la suite ssh oltre che la gestione e conversione delle stesse.
Generazione chiavi
-b Numero di bits della chiave. default 1024
-t tipo di chiave, rsa1 per il protocollo 1 e rsa,dsa per il protocollo 2
-N Passphrase
-C Commento da inserire nella chiave, utile per distinguerle l'una dall'altra
-f Viene specificato il nome del file key
Modifica della passphrase
ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]
-f File contenente la chiave privata
Interogazione/managment delle chiavi pubbliche e private
ssh-keygen -i [-f input_keyfile] Legge chiavi (pubbliche e private) non criptate SSH2-compatibili ed esporta in stdout la chiave Openssh-compatibile. Utile per gli import delle chiavi.
ssh-keygen -e [-f input_keyfile] Legge chiavi Openssh-compatibili ed esporta in stdout chiavi SSH2-compatibili. utile per l'export delle chiavi
ssh-keygen -y [-f input_keyfile] Legge una chiave privata Openssh-compatibile e printa in stdout la chiave pubblica
File di configurazione di ssh e parsing della linea di comando
Tipo Infobox: TIPS - Skill: 2- JUNIOR
Il client di ssh acquisice le varie informazioni e opzioni per aprire la connessione in diverse risorse nel seguente ordine:
1- Linea di comando [obbligatorio]
2- File di configurazione del singolo utente [opzionale]
3- File generale di configurazione [obbligatorio]
L'estrema flessibilita' nella configurazione dei parametri per la connessione via ssh ci permette di "giocare" molto con queste tre possibilita' di gestione delle sessioni.
Un esempio potrebbe essere il fatto che si possono configurare le singole opzioni solo per un pool o per un singolo host.
Di fatto piuttosto che specificare le singole opzioni (forzare un protocollo, abilitare x11 forwarding, ecc.) del singolo host in linea di comando si puo' farlo a livello di file di configurazione.
[neo@dido neo]$ cat /etc/ssh/ssh_config
Opzioni per il singolo host
Host socrate.openskills.info
ForwardX11 yes
Protocol 2
Opzioni di default per tutte le connessioni
Host *
ForwardAgent no
ForwardX11 no
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
FallBackToRsh no
UseRsh no
BatchMode no
CheckHostIP yes
StrictHostKeyChecking yes
IdentityFile ~/.ssh/identity
IdentityFile ~/.ssh/id_dsa
IdentityFile ~/.ssh/id_rsa
Port 22
Protocol 2,1
Cipher blowfish
EscapeChar ~
Le opzioni di default devono essere scritte alla fine.
La sintassi del file di configurazione generale e quello relativo al singolo utente sono uguali
SSH su Windows
Tipo Infobox: ETCETERA - Skill: 2- JUNIOR
SSH è un protocollo e in quanto tale se ne possono trovare implementazioni su diversi sistemi operativi.
Su Windows sono disponibili vari client SSH che permettono la connessione a server UNIX in forma criptata:
- Secure CRT e F-Secure sono due ottimi programmi shareware o comunque commerciali.
- Putty è una valida alternativa freeware.
- Esiste un funzionale port di OpenSSH per WIN32.
- Si può usare l'ottimo CYGWIN e la versione di openssh incorporata.
Per un elenco completo, seguire il link su Tucows riportato.
/etc/xinetd.d/ssh
Tipo Infobox: PATH - Skill: 3- INTERMEDIATE
File di configurazione per l'avvio del demone sshd da xinetd.
Descrizione del servizio
# describe : OPENSSH DAEMON
Nome servizio
service ssh
{
Flag per la disabilitazione dell'avvio di startup. configurabile anche da ntsysv o analoghi
disable = no
Paramatri indispensabili per l'avvio da xinetd
Tipo di socket
socket_type = stream
tipo di Protocollo (deve essere presente in /etc/protocols)
protocol = tcp
Il numero di server che partono simultaneamente
instances = 3
priorita' del demone
nice = 10
Attributo che identifica se il processo e' single-threaded (value=yes) o multi-threaded (value=no)
wait = no
Identifica l'uid del processo con cui viene eseguito il servizio
user = root
Il comando da eseguire per lanciare il servizio
server = /usr/sbin/sshd
I Possibili argomenti da passare al comando
server_args = -i
}
inetd e Openssh
Tipo Infobox: TIPS - Skill: 2- JUNIOR
E' possibile gestire il demone sshd da inetd, aggiungendo semplicemente una linea in /etc/inetd.conf.
[neo@socrate neo]$ cat /etc/inetd.conf
ssh stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sshd -i
# End of inetd.conf
- Assicurarsi di avere i privilegi di root
- Aggiungere alla fine del file la riga riportata di sopra.
- Riavviare il servizio inetd
[root@socrate /root]# /etc/rc.d/init.d/inetd restart
Stopping INET services: [ OK ]
Starting INET services: [ OK ]
- Verificare se il server e' partito ed ha bindato la porta.
[root@socrate /root]# netstat -nat | grep 22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
Ok, la porta e' stata bindata
[root@socrate /root]# telnet 0 22
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
SSH-2.0-CORE 1.0
Ok , server risponde almeno da locale
- Effettuate un ulteriore prova facendo un login da remoto oppure eseguendo un comando con scp.