Você pode alterar a configuração assim:
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
PermitEmptyPasswords yes
PasswordAuthentication no
Eu tenho dois servidores Oracle Linux 7.1 setup (devapp e subversion são os nomes de host). O que eu quero fazer é ssh no subversion do devapp sem ter que digitar uma senha. Eu segui este guia: link
Tudo funcionou com sucesso no guia, mas quando faço "ssh @subversion", ele ainda pede uma senha. O que estou perdendo?
[bzerbe@devapp ~]$ ssh -vvv bzerbe@subversion
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/bzerbe/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to subversion [172.20.50.214] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/bzerbe/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/bzerbe/.ssh/id_rsa type 1
debug1: identity file /home/bzerbe/.ssh/id_rsa-cert type -1
debug1: identity file /home/bzerbe/.ssh/id_dsa type -1
debug1: identity file /home/bzerbe/.ssh/id_dsa-cert type -1
debug1: identity file /home/bzerbe/.ssh/id_ecdsa type -1
debug1: identity file /home/bzerbe/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/bzerbe/.ssh/id_ed25519 type -1
debug1: identity file /home/bzerbe/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "subversion" from file "/home/bzerbe/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/bzerbe/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected]@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected]@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup [email protected]
debug1: kex: server->client aes128-ctr [email protected] none
debug2: mac_setup: setup [email protected]
debug1: kex: client->server aes128-ctr [email protected] none
debug1: kex: [email protected] need=16 dh_need=16
debug1: kex: [email protected] need=16 dh_need=16
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 6d:cd:e2:d2:3d:61:1c:9c:3e:7d:91:4b:36:65:4c:a8
debug3: load_hostkeys: loading entries for host "subversion" from file "/home/bzerbe/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/bzerbe/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "172.20.50.214" from file "/home/bzerbe/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/bzerbe/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'subversion' is known and matches the ECDSA host key.
debug1: Found key in /home/bzerbe/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/bzerbe/.ssh/id_rsa (0x7fbd227eb4d0),
debug2: key: /home/bzerbe/.ssh/id_dsa ((nil)),
debug2: key: /home/bzerbe/.ssh/id_ecdsa ((nil)),
debug2: key: /home/bzerbe/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/bzerbe/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/bzerbe/.ssh/id_dsa
debug3: no such identity: /home/bzerbe/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/bzerbe/.ssh/id_ecdsa
debug3: no such identity: /home/bzerbe/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/bzerbe/.ssh/id_ed25519
debug3: no such identity: /home/bzerbe/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
bzerbe@subversion's password:
Eu segui todas as recomendações de configurar as permissões de diretório também. Exemplo:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
No servidor subversion, meu / etc / ssh / sshd_config se parece com isto:
# $OpenBSD: sshd_config,v 1.90 2013/05/16 04:09:14 dtucker 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.
# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#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
# Ciphers and keying
#RekeyLimit default none
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
PermitRootLogin yes
StrictModes no
#MaxAuthTries 6
#MaxSessions 10
AllowGroups root sysadmins appl
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
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser 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 yes
# 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 Red Hat Enterprise Linux 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 sandbox # Default for new installations.
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum 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 server
Arquivos do servidor Devapp:
[bzerbe@devapp .ssh]$ ls -la
total 20
drwx------. 2 bzerbe appl 67 Oct 7 10:50 .
drwx------. 9 bzerbe bzerbe 4096 Oct 7 10:49 ..
-rw-r--r--. 1 bzerbe appl 89 Oct 6 10:48 config
-rw-------. 1 bzerbe appl 1675 Oct 7 10:50 id_rsa
-rw-r--r--. 1 bzerbe appl 408 Oct 7 10:50 id_rsa.pub
-rw-r--r--. 1 bzerbe appl 186 Oct 7 10:50 known_hosts
Arquivos do servidor Subversion:
[bzerbe@subversion .ssh]$ ls -la
total 12
drwx------. 2 bzerbe appl 46 Oct 7 10:51 .
drwx------. 6 bzerbe bzerbe 4096 Oct 7 11:10 ..
-rw-------. 1 bzerbe appl 408 Oct 7 10:50 authorized_keys
-rw-r--r--. 1 bzerbe appl 182 Oct 7 10:51 known_hosts
[bzerbe@subversion .ssh]$ ls -lZ ~/.ssh/authorized_keys
-rw-------. bzerbe appl unconfined_u:object_r:home_root_t:s0 /home/bzerbe/.ssh/authorized_keys
Alguma idéia?
Você pode alterar a configuração assim:
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
PermitEmptyPasswords yes
PasswordAuthentication no
O problema persiste quando você confirma que o servidor subversion tem o arquivo /home/bzerbe/.ssh/authorized_keys contendo a chave pública de devapp ? E esse arquivo tem o modo 0600?
Seu comando ssh -vvv indica:
debug1: Offering RSA public key: /home/bzerbe/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Quando eu executo um comando ssh -vvv similar em um host bem-sucedido, recebo uma entrada de log diferente:
debug1: Offering DSA public key: /home/vagrant/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Authentication succeeded (publickey).
Parece que você está oferecendo a chave, e o servidor do subversion está sem a chave pública no arquivo correto.
Sua pergunta diz: "Eu segui todas as recomendações de configuração das permissões do diretório também", mas não está claro se você definiu essas opções em devapp ou subversion .
No servidor subversion , sua configuração sshd está esperando que a chave pública esteja em /home/bzerbe/.ssh/authorized_keys
# 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
Espero que ajude.
Ele diz que está oferecendo a chave pública. Portanto, sua configuração no lado do cliente provavelmente está correta. O lado do servidor (subversão), por algum motivo, não aceita a chave. Para descobrir por que dar uma olhada no log do sshd no lado do servidor. Você provavelmente encontrará em /var/log/secure em seu sistema.
Descobri isso ... Eu segui este artigo e executou estas linhas:
restorecon -R -v /home/bzerbe
restorecon reset /home/bzerbe/.ssh context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/bzerbe/.ssh/authorized_keys context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:ssh_home_t:s0
É porque o seu / etc / ssh / sshd_config tem PasswordAuthentication yes em vez de PasswordAuthentication no .
Tags ssh authentication linux