Eu tenho uma instância do EC2 em funcionamento com vários usuários, alguns dos quais estão chroot em seus diretórios pessoais, alguns dos quais são apenas FTP e não têm acesso ao shell, etc... ec2-user é a conta de administrador principal, embora outros também tenham acesso root e logins SSH completos. Tudo funciona muito bem na instância em execução.
Posso tirar uma imagem instantânea da instância e iniciar novas instâncias a partir do instantâneo. Não importa o que eu selecione em termos do par de chaves associado à nova instância (use o par de chaves original para ec2-user, crie um novo par de chaves ou não use nenhum par de chaves), uma vez que a nova instância é iniciada e executada, não consigo ssh no servidor usando ec2-user ou qualquer outro usuário habilitado para ssh. ftp funciona bem, no entanto.
Os grupos de segurança não são um problema, pelo que sei, o tráfego de entrada é permitido (e é o mesmo grupo de segurança da instância original, de qualquer maneira).
O /var/log/secure das tentativas de login me dá:
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method none
sshd[1739]: debug1: attempt 0 failures 0
sshd[1738]: debug1: user ec2-user does not match group list sftponly at line 142
sshd[1738]: debug1: PAM: initializing for "ec2-user"
sshd[1738]: debug1: PAM: setting PAM_RHOST to "..."
sshd[1738]: debug1: PAM: setting PAM_TTY to "ssh"
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method publickey
sshd[1739]: debug1: attempt 1 failures 0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: Failed publickey for ec2-user from xx.xx.xx.xx port 60597 ssh2
sshd[1739]: Connection closed by xx.xx.xx.xx
sshd[1739]: debug1: do_cleanup
É o mesmo erro para todos os usuários habilitados para ssh. Como você pode ver no log, alterei meu sshd_config na instância original para que ele procure as chaves públicas na pasta /etc/ssh/keys.
Montei as instâncias com falha como volumes na instância em funcionamento. As chaves estão na pasta, com as mesmas permissões e os mesmos valores de chave, tudo conforme o esperado. Aqui está ls -al da pasta de chaves (.) e do arquivo ec2-user.
drwxr-xr-x. 2 root root 4096 Dec 1 16:59 .
-rw-------. 1 ec2-user ec2-user 388 Jul 25 13:27 ec2-user
O que poderia estar causando este problema? Gostaria de resolver o problema ao salvar e iniciar um instantâneo ou ao configurar a instância original, mas sem montar a instância problemática e fazer alterações manuais para que funcione, mas não resolva o problema maior.
ATUALIZAÇÃO: Aqui estão as configurações ativas no arquivo sshd_config:
#...
Protocol 2
#...
SyslogFacility AUTHPRIV
LogLevel DEBUG
#...
AuthorizedKeysFile /etc/ssh/keys/%u
#...
PasswordAuthentication no
#...
ChallengeResponseAuthentication no
#...
GSSAPIAuthentication yes
#...
GSSAPICleanupCredentials yes
#...
UsePAM yes
#...
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
#...
X11Forwarding yes
#...
Subsystem sftp internal-sftp -f AUTH -l VERBOSE
#...
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp -l VERBOSE -f AUTH
#...
Responder1
Eu suspeito que este seja um problema do SELinux. Verifique o contexto da pasta que você está usando, espero que não seja correto para segurar chaves.
Receio não ter mais acesso a uma caixa Redhat para estabelecer exatamente qual deveria ser o contexto. Dito isto, tente isto:
ls -lZ /root/.ssh
Isso produzirá o contexto selinux que sua nova pasta precisa ter. Se bem me lembro, deveria ser algo como system_u:system_r:sshd_t
Em seguida, precisamos aplicar esse contexto de segurança ao local da sua nova chave autorizada:
semanage fcontext -a -t system_u:system_r:sshd_t “/etc/ssh/keys(/.*)?”
Que associou o contexto correto à nova localização das chaves. Finalmente, podemos aplicar o contexto ao novo local
restorecon -Rv /etc/ssh/keys
Responder2
A diretiva 'AllowUsers' está definida em sshd_config? Talvez esteja definido para um usuário específico no servidor original e o ssh ainda não tenha sido reiniciado, então ainda aceita todos os usuários?
Ah, acabei de ver isso na depuração: "usuário ec2-user não corresponde à lista de grupos sftponly na linha 142" verifique sshd_config, você pode ter proibido um grupo ou permitido apenas sftp?