Connessione VTY via SSH a chiave pubblica

Mettete al sicuro la vostra rete!

Moderatore: Federico.Lagni

Rispondi
realnot
n00b
Messaggi: 5
Iscritto il: mar 25 nov , 2014 4:50 pm

Salve, ho configurato il mio router in modo da poter accedere localmente mediante minicom sulla porta seriale/console e da remoto mediante SSH, quindi disabilitando telnet.

Codice: Seleziona tutto

ip ssh version 2
ip ssh stricthostkeycheck
ip ssh pubkey-chain
  username realnot
   key-hash ssh-rsa 1A40ED979A3B288D42E41F43AB4E realnot@venus
La VTY e' configurata nel seguente modo:

Codice: Seleziona tutto

line vty 0 4
 password 7 124F534E405F5D5D7272
 login local
 transport input ssh
Durante la connessione, il client SSH riporta le seguenti infomazioni:

Codice: Seleziona tutto

realnot@venus ~ $ ssh -v sun
OpenSSH_6.6, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /home/realnot/.ssh/config
debug1: /home/realnot/.ssh/config line 7: Applying options for sun
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to sun [192.168.1.2] port 22.
debug1: Connection established.
debug1: identity file /home/realnot/.ssh/sun_rsa type 1
debug1: identity file /home/realnot/.ssh/sun_rsa-cert type -1
debug1: identity file /home/realnot/.ssh/jupiter_rsa type 1
debug1: identity file /home/realnot/.ssh/jupiter_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6p1-hpn14v4
debug1: Remote protocol version 2.0, remote software version Cisco-1.25
debug1: no match: Cisco-1.25
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes256-cbc'
debug1: kex: server->client aes256-cbc hmac-sha1 none
debug1: REQUESTED ENC.NAME is 'aes256-cbc'
debug1: kex: client->server aes256-cbc hmac-sha1 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA a2:20:a3:8a:55:32:8e:45:ce:1c
debug1: Host 'sun' is known and matches the RSA host key.
debug1: Found key in /home/realnot/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent                                                                                                                                     
debug1: SSH2_MSG_SERVICE_ACCEPT received                                                                                                                                  
debug1: Authentications that can continue: publickey,keyboard-interactive,password                                                                                        
debug1: Next authentication method: publickey                                                                                                                             
debug1: Offering RSA public key: /home/realnot/.ssh/sun_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to sun ([192.168.1.2]:22).
debug1: Final hpn_buffer_size = 2097152
debug1: HPN Disabled: 0, HPN Buffer Size: 2097152
debug1: channel 0: new [client-session]
debug1: Enabled Dynamic Window Scaling
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_COLLATE = C
debug1: Sending env LANG = en_US.utf8
Welcome to SUN. You are connected via SSH to line #132 on sun.unknowndomain.com. 
The access is restricted for personal purpose only. All activity are monitored 
and logged for secirity reasons.
sun#
Quello che non mi convince e' questa riga:

debug1: Authentications that can continue: publickey,keyboard-interactive,password
questo significa che se per qualche motivo non vi e' il match tra la pubkey del client/server l'autenticazione passa in keyboard-interactive e poi in password. Sostanzialmente il router e' esposto ad attacchi brute-force, ma non ho ancora capito disabilitare questa cosa. L'autenticazione dovrebbe essere permessa solo mediante pubkey e disabilitando le altre forme (come e' possibile fare mediante /etc/ssh/ssshd_config su un qualsiasi sistema unix-like.

Qualcuno ha qualche idea?
Rispondi