[glux] ssh... client

[Cristian Rigamonti]

On Mon, Apr 26, 2004 at 06:28:45PM +0200, @arminillo wrote:
> Idee per risolvere questo problema?
> 
> racf@kdeb:~$ ssh $altroipinterno
> Permission denied, please try again.
> Permission denied, please try again.
> Permission denied (publickey,password,keyboard-interactive).

Non riesce ad autenticarsi; che metodo usi? Password? Host key? Chiave
dell'utente? Prova ad aggiungere -v[vv] alla linea di comando...

> racf@kdeb:~$ rm -rf .ssh
> racf@kdeb:~$ ssh $altroipinterno
> Host key verification failed.

Ci credo, hai appena rimosso la directory che contiene le tue chiavi...

Prova a dare un'occhiata al file allegato: sono un po' di miei vecchi
appunti sull'uso di ssh, magari trovi qualche ispirazione.

Cri

-- 
[         Cristian Rigamonti  -  cri@linux.it  -  +39 347 1043466          ]
[      GPG/PGP Key-Id: 943A5F0E  -  http://www.linux.it/~cri/cri.asc       ]
[    GLUX! - http://www.lecco.linux.it  -  irc.eu.freenode.net -> #glux    ]
-------------- parte successiva --------------


*** 
ssh 
***



- Procedura di connessione in breve:

  - il client contatta il server sulla porta 22 e scambia informazioni (in
    chiaro) sulla propria versione di ssh (idem il server) e sui metodi di
    cifratura

  - autenticazione del server:

    - Protocollo 1: il server spedisce la propria host key (di solito 1024bit) e
      server key (768 bit, generata ogni ora, non scritta su disco). Il client
      confronta la chiave del server con quella contenuta nel proprio database
      (tranne la prima volta, per cui viene chiesto all'utente di accettarla
      esplicitamente), genera una chiave di sessione, la cifra con le chiavi
      ricevute e la invia al server (assieme all'indicazione sull'algoritmo di
      cifratura); il server decifra la chiave di sessione con la propria chiave
      privata e manda una risposta cifrata con essa (da questo punto in poi le
      comunicazioni sono cifrate)

    - Protocollo 2: non c'e' server key, ma scambio di chiave di sessione alla
      Diffie-Hellman; prevede metodi di cifratura e di integrita' della
      connessione (MAC) piu' robusti del protocollo 1
    
  - autenticazione del client (cfr oltre per dettagli): 
  
    - Protocollo 1: rhosts, rhosts+RSAhost, RSA, password
    - Protocollo 2:    -  , hostbased, pubkey, password
  
  - vengono eseguiti i programmi disponibili per la sessione: shell, X,
    forwarding di connessioni TCP/IP


- Tipi di autenticazione client (con i nomi usati in ssh_config):

  - Protocollo 1: 
  
    - RhostsAuthentication
      Usa i file /etc/hosts.equiv o /etc/ssh/shosts.equiv (oppure ~/.rhosts e
      ~/.shosts) sul server: se contengono una riga con "host utente" della
      macchina da cui ci si connette, il login e' automaticamente autorizzato.
      
      Implica che il client si fidi dell'utente root del server, del DNS e,
      parzialmente, della rete (e' possibile fare ip spoofing, ma non in modo
      "cieco" come e' possibile con rlogin, cfr documentazione per
      approfondimenti).
      
    - RhostsRSAAuthentication
      Simile al metodo precedente, ma viene fatta un'autenticazione con chiave
      pubblica a livello di host (non di utente, che e' ancora identificato
      tramite hosts.equiv); oltre alla coppia utente/host, il client invia anche
      la propria host key pubblica (del client, non dell'utente!); il server
      controlla di averla in /etc/ssh/ssh_known_hosts o ~/.ssh/known_hosts
      (il modo piu' veloce per mettercela e' connettersi una volta dal server al
      client, altrimenti occorre copiarla manualmente), spedisce un numero
      casuale (challenge) cifrato con la chiave del client, che rispondera'
      decifrandolo con la propria chiave privata; il server controlla la
      risposta e autorizza il client.

      Questo metodo evita la possibilita' di spoofing da parte del client
      (oltre a spoofare occorre avere la chiave privata del client!) ma implica
      fidarsi dell'utente root sul client.
      
    - RSAAuthentication
      Qui l'autenticazione a chiave pubblica viene fatta a livello di utente.
      L'utente crea sul client una coppia di chiavi RSA (ssh-keygen) e al
      momento della connessione manda al server la propria chiave pubblica,
      segue un meccanismo di challenge simile a quello descritto sopra (le
      chiavi pubbliche autorizzate devono essere copiate in
      ~/.ssh/authorized_keys sul server).
      
      Questo metodo implica fiducia SOLO sulla chiave privata in possesso del
      client.

      
    - PasswordAuthentication
      Il server chiede la password dell'account su cui si vuole fare login (la
      password viaggia cifrata, cfr come avviene la procedura di connessione).

      Questo metodo implica fiducia SOLO sulla password in possesso del client.

      

  - Protocollo 2 (non ha rhosts):

    - HostbasedAuthentication
      Autenticazione a chiave pubblica (su host); e' l'equivalente della
      RhostsRSAAuthentication del protocollo 1.

    - PubkeyAuthentication
      Autenticazione a chiave pubblica (su utente): oltre all'algoritmo RSA usa
      il DSA: il client all'inizio FIRMA l'identificativo di sessione (alla
      Diffie-Hellman) con la propria chiave privata (~/.ssh/id_dsa o
      ~/.ssh/id_rsa) e il server controlla.
      
    - PasswordAuthentication
      Come quella del protocollo 1

     

- Sicurezza:

  The SSH protocol offers major security advantages over existing telnet and
  rlogin protocols.  IP spoofing is restricted to closing a connection (by
  encryption, host keys, and the special random cookie).  If encryption is not
  used, IP spoofing is possible for those who can hear packets going out from
  the server.  DNS spoofing is made ineffective (by host keys).  Routing
  spoofing is made ineffective (by host keys).  All data is encrypted with
  strong algorithms to make eavesdropping as difficult as possible.  This
  includes encrypting any authentication information such as passwords.  The
  information for decrypting session keys is destroyed every hour.  Strong
  authentication methods: .rhosts combined with RSA host authentication, and
  pure RSA authentication.  X11 connections and arbitrary TCP/IP ports can be
  forwarded securely.  Man-in-the-middle attacks are deterred by using the
  server host key to encrypt the session key.  Trojan horses to catch a
  password by routing manipulation are deterred by checking that the host key
  of the server machine matches that stored on the client host.

  The security of SSH against man-in-the-middle attacks and the security of
  the new form of .rhosts authentication, as well as server host validation,
  depends on the integrity of the host key and the files containing known host
  keys.

  The host key is normally stored in a root-readable file.  If the host
  key is compromised, it permits attackers to use IP, DNS and routing
  spoofing as with current rlogin and rsh.  It should never be any
  worse than the current situation.

  The files containing known host keys are not sensitive.  However, if
  an attacker gets to modify the known host key files, it has the same
  consequences as a compromised host key, because the attacker can then
  change the recorded host key.

  The security improvements obtained by this protocol for X11 are of
  particular significance.  Previously, there has been no way to
  protect data communicated between an X server and a client running on
  a remote machine.  By creating a fake display on the server, and
  forwarding all X11 requests over the secure channel, SSH can be used
  to run any X11 applications securely without any cooperation with the
  vendors of the X server or the application.

  Finally, the security of this program relies on the strength of the
  underlying cryptographic algorithms.  The RSA algorithm is used for
  authentication key exchange.  It is widely believed to be secure.  Of
  the algorithms used to encrypt the session, DES has a rather small
  key these days, probably permitting governments and organized
  criminals to break it in very short time with specialized hardware.
  3DES is probably safe (but slower).  IDEA is widely believed to be
  secure.  People have varying degrees of confidence in the other
  algorithms.  This program is not secure if used with no encryption at
  all.




Installazione e configurazione (Debian)

  - La versione in uso su sistemi liberi e' OpenSSH, derivata da OpenBSD. Su
    Debian e' il pacchetto (non-US) ssh (esiste anche ssh-nonfree).

  - Generazione delle host key: dopo aver chiesto se avviare automaticamente al
    boot e se abilitare anche il protocollo 1 (considerato meno sicuro del 2),
    vengono generate le (coppie di) chiavi per l'host (RSA e DSA) e salvate in
    /etc/ssh/...  (da conservare con le solite precauzioni usate per le chiavi
    private). Possono essere generate anche manualmente da root con ssh-keygen.

  - Generazione delle chiavi utente:
  
    'ssh-keygen [-t tipo] [-C commento]'
    
    - Utility per creare coppie di chiavi (per utente o host) e per modificarne
      le proprieta' (es. per cambiare la passphrase: ssh-keygen -p)

    - Nota: se si perde la chiave pubblica, puo' sempre essere rigenerata a
      partire da quella privata con "ssh-keygen -t dsa -y"

  - (opzionale) Abilitare ssh-agent, che permette di gestire le autenticazioni
    in modo pratico (es. evitando di dover inserire la passphrase ogni volta che
    si compie un'operazione).

    ssh-agent viene avviato dall'utente al login (o all'inizio di una sessione
    X, come di default in Debian, cfr /etc/X11/Xsession.d) e vengono
    "registrate" le chiavi private da usare (con ssh-add) immettendo solo una
    volta la passphrase; per ogni operazione che richiede la chiave
    privata, il client ssh si rivolgera' ad ssh-agent (attraverso una socket
    unix che dev'essere leggibile dall'utente, di default /tmp/ssh.../agent...).

    'ssh-add nomefile' registra l'identita' contenuta nel nomefile (controllando
    che sia accessibile solo all'utente e chiedendo la passphrase); se non viene
    dato nessun nomefile, vengono letti ~/.ssh/id_rsa, ~/.ssh/id_dsa,
    ~/.ssh/identity). (cfr man ssh-add per altre opzioni utili: es 'ssh-add -l'
    elenca le identita' registrate, 'ssh-add -d identity' rimuove l'identita'
    dalla lista di quelle registrate, -t per dare scadenza...). Per
    automatizzare la procedura, ssh-add puo' essere inserito nel proprio .xsession.

    La connessione a ssh-agent viene automaticamente esportata alle connessioni
    ssh attive sull'host, senza che passphrase o chiavi private passino sulla
    rete (quindi un utente puo' avviare ssh-agent sulla sua macchina e poi
    "usarlo" in modo sicuro loggandosi via ssh da un'altra macchina).

  - Controllare /etc/hosts.allow e /etc/hosts.deny

  - Controllare che eventuali firewall non blocchino la porta TCP 22

  - Impostazioni predefinite in Debian:
    - PermitRootLogin e' a yes di default; metterla a no non aumenta la
      sicurezza se comunque gli utenti autorizzati a connettersi possono fare
      su.  
    - Protocollo di default del server: 2
    - X11 forwarding (ForwardX11) e' disabilitato di default: da abilitare solo
      per i server in cui ci si fidi dell'account root (altrimenti si renderebbe
      insicura la propria macchina, visto che ssh-agent e' suidroot); per lo 
      stesso motivo e' disabilitato il forward dell'autorizzazione


- Formati delle chiavi pubbliche

  Esempio SSH1: "[opzioni] lunghezza esponente modulo commento"
  Esempio SSH2 dsa: "[opzioni] ssh-dss (chiave in base64) commento"
  Esempio SSH2 rsa: "[opzioni] ssh-rsa (chiave in base64) commento"


- File di configurazione:

  /etc/ssh/sshd_config
  Configurazione del server (man sshd_config)

  ~/.ssh/config (/etc/ssh/ssh_config)
  Configurazione del client (man ssh_config)

  ~/.ssh/known_hosts (/etc/ssh/known_hosts preparato da root)
  Lista chiavi pubbliche DEGLI HOST a cui ci si e' connessi (sul client) o da
  cui sono arrivate connessioni (sul server).
  Usate dal server per l'autenticazione rhosts+RSA (protocollo 1) o per
  l'autenticazione host-based (protocollo 2).
  Usate dal client per assicurarsi dell'autenticita' del server (alla prima
  connessione viene chiesto all'utente di "riconoscere" la chiave, nelle
  connessioni successive ssh la confrontera' con quella comunicatagli dal
  server). 
  Formato: "hostname[,aliases] chiave"
  
  ~/.ssh/authorized_keys: contiene (una per linea) le chiavi pubbliche DEGLI
  UTENTI autorizzati a connettersi a questo account con autenticazione con
  chiave pubblica (protocollo2: id_dsa.pub o id_rsa.pub; protocollo 1:
  ~/.ssh/identity.pub)
  
  ~/.rhosts e /etc/hosts.equiv (usati anche da rlogin) o
  ~/.shosts e /etc/ssh/shosts.equiv (usati solo da ssh): file usati per
  autenticazione di tipo rhost (formato: "[+-] host [utente]")
  
      
  ~/.ssh/rc (e /etc/ssh/sshrc): comandi eseguiti da sshd appena prima di
  eseguire la shell dell'utente che ha fatto login al server

  ~/.ssh/environment: ambiente ereditato dalla shell ssh


- File delle chiavi:

  /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_dsa_key.pub
  /etc/ssh/ssh_host_rsa_key, /etc/ssh/ssh_host_rsa_key.pub
  
  Chiavi dell'host (pubbliche e private, dsa e rsa) per l'autenticazione
  dell'HOST con chiave pubblica: le chiavi pubbliche vanno copiate in
  ~/.ssh/known_hosts sul server a cui si vuole accedere (un modo veloce, ma
  non sempre possibile, per farlo e' connettersi dal server al client).
  
    
  ~/.ssh/identity, ~/.ssh/identity.pub (prot 1, rsa)
  ~/.ssh/id_dsa, ~/.ssh/id_dsa.pub (prot 2, dsa)
  ~/.ssh/id_rsa, ~/.ssh/id_rsa.pub (prot 2, rsa)
  
  Chiavi private/pubbliche usate per l'autenticazione con chiave pubblica.
  Le chiavi private devono essere readonly dal proprietario e sono cifrate
  con 3DES (tramite una passphrase). Le chiavi pubbliche vanno copiate in
  ~/.ssh/authorized_keys sul server a cui si vuole accedere.
  


- Connessione

  ssh [-v] [-l user] [opzioni] host | user@host [comando]

- Trasferimento di file

  scp [opzioni] fonte destinazione

  fonte e/o destinazione possono essere in forma utente@host:/percorso


Funzionalita' avanzate:

- X: se ForwardX11 e' settata nella configurazione e il cliente sta usando X,
  viene avviato sul DISPLAY :1 un "proxy Xserver" che permette di visualizzare
  i programmi eseguiti sulla macchina remota. Anche Xauthority sulla macchina
  remota e' impostato automaticamente e in modo sicuro.
  cfr Remote-Xapps-mini-howto
    
- Forwarding di connessioni TCP/IP su canale sicuro