Ho appena seguito alla lettera la guida
http://docs.fedoraproject.org/en-US/Fedora/17/html/Security_Guide/Security_Guide-Encryption-Data_in_Motion-Secure_Shell.html
per rendere più sicuro l’accesso SSH a una macchina.
Al termine della configurazione, ho fatto delle prove e ho scoperto che il server ancora mi permette il login da host senza la chiave RSA generata…
Consigli? Ho visto un RSAlogin commentato nel file di configurazione di SSH, ma la guida non lo considera
Mi sembra normale, dal computer/utente sul quale hai la chiave privata ti colleghi senza fare il login ma da altre macchine come ti colleghi in caso di necessità? fai il login con la password!
Si può disabilitare il login da password e lasciare solo il login con chiave RSA.
Provate a vedere l’opzione PasswordAuthentication nel man di sshd_config.
Scusate, nel leggere ho perso un dettaglio fondamentale, la chiave andava generata sul client e portata sul server, non il contrario, torno tra poco e vi dico se ho risolto 
in questo http://forum.fedoraonline.it/viewtopic.php?id=18726 avevo fatto delle prove con la chiave RSA, e funzionava a dovere, c’è anche la configurazione di sshd_config. Ma credo che il tuo problema sia stato proprio aver generato la chiave sul server. 
Ho risolto. Dopo vari smanettamenti sono riuscito a disabilitare il login con la password e a lasciarlo esclusivamente con la chiave RSA. Tuttavia mi piacerebbe sapere se è possibile avere entrambe le modalità di autenticazione, “con regola AND”
Vi allego il file di configurazione di SSH così mi dite se per caso ho introdotto qualche vulnerabilità smanettando qua e là
[root@PD-4 etc]# cat /etc/ssh/sshd_config
# $OpenBSD: sshd_config,v 1.84 2011/05/23 03:30:07 djm Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/local/bin:/usr/bin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# The default requires explicit activation of protocol 1
#Protocol 2
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6 RIPRISTINARE
#MaxSessions 10
RSAAuthentication yes
PubkeyAuthentication yes
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedKeysCommand none
#AuthorizedKeysCommandRunAs nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes
# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in Fedora and may cause several
# problems.
#UsePAM no
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none
# no default banner path
#Banner none
# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
# Uncomment this if you want to use .local domain
#Host *.local
# CheckHostIP no
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs serverin teoria questa #PermitRootLogin yes potrebbe essere una vulnerabilità. EDIT: scusa ho sbagliato, non avevo visto che la riga era commentata.
se questa la metti su yes PasswordAuthentication no hai la doppia autenticazione
Yattatux, così facendo non hai una doppia autenticazione “con regola AND”, piuttosto con regola OR.
Domanda stupida, ma penso sia meglio fare una domandina in più che magari avere il dubbio di aver creato qualche buco nel sistema…
Avendo una macchina server SSH, mettiamo che io mi sieda di fronte al monitor e da root tenti di accedere a una terza macchina, facendo:
# ssh [email protected]
The authenticity of host '81.20.100.21 (81.20.100.21)' can't be established.
RSA key fingerprint is a5:20:75:a2:f7:31:52:d0:b6:7d:9b:ed:a7:15:c0:59.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '81.20.100.21' (RSA) to the list of known hosts.
Il fatto che il sistema indichi:
Warning: Permanently added '81.20.100.21' (RSA) to the list of known hosts.Non centra nulla con gli host autorizzati ad accedere al server dal quale sto digitando giusto? Anche perché l’unico accesso che permetto è con le chiavi RSA che immetto manualmente nel file
$/.ssh/authorized_keysLo scambio di impronte RSA si tratta solo di una procedura per assicurarsi che dietro quell’IP si stia comunicando sempre con la stessa macchina, no?
Infatti. Se vuoi che venga anche digitata la password devi creare un certificato con password, nel qual caso ti viene chiesto, oltre al possesso della chiave pubblica, la password con cui hai creato il certificato stesso (che non coincide necessariamente con quella dell’utente).
[quote=Caterpillar]
Il fatto che il sistema indichi:
Warning: Permanently added '81.20.100.21' (RSA) to the list of known hosts.Non c’entra nulla con gli host autorizzati ad accedere al server dal quale sto digitando giusto? Anche perché l’unico accesso che permetto è con le chiavi RSA che immetto manualmente nel file
$/.ssh/authorized_keysLo scambio di impronte RSA si tratta solo di una procedura per assicurarsi che dietro quell’IP si stia comunicando sempre con la stessa macchina, no?[/quote]
Giusto. Il computer C (client) cerca di accedere al computer S (server). Quel ‘Permanently added’ indica solo che C è in grado di identificare S da altre macchine (prova a dare ad una terza macchina M l’ip che prima aveva S, e a collegarti. C sente puzza di imbroglio, e non si collega finché non rimuovi la riga relativa a S in ~/.ssh/known_hosts), e avviene PRIMA della richiesta di credenziali. quindi, se non fornisci le credenziali giuste (password o certificato che sia), anche se hai aggiunto S in ~/.ssh/known_host, S ti sbatte la porta in faccia, e ciccia.
Esempio:
C: “Voglio parlare con S. Sei S?”
S: “Ecco il mio documento”
C: “Nella mia agenda non sei ancora presente.” (rivolto al proprio utente) “Mi devo fidare?”
Utente di C: “Sì, fidati”
C: “Allora aggiungo le credenziali di S nella mia agenda, così la prossima volta non chiederò al mio utente che fare. Ora, S, ti dovrei dare degli ordini.”
S: “Dimostra che hai l’autorizzazione per darmeli.”
C: “La tua password è pincoPallino”
S: “Non accetto password”
C: “Avrei anche un certificato”
S: “Questo certificato non corrisponde al mio. Mi dispiace, ma non posso eseguire i tuoi comandi. Ti saluto”
@ Marco: hai pensato di scrivere per Folio una di queste sceneggiature ?
magari forzando sul lato comico ?
[quote=virus]@ Marco: hai pensato di scrivere per Folio una di queste sceneggiature ?
magari forzando sul lato comico ?
:)[/quote]
Ti ringrazio, ma di solito faccio solo il matematico, e non sono tanto bravo come letterato. Stavolta mi è venuta un’improvvisa ispirazione, ma potrebbe non essere ripetibile… Sarà il vino che mi sono fatto spedire da mio cugina (lo fa suo marito)… :cin:
thx