S SH от EC2 к себе другим пользователем, не являющимся пользователем ec2

Question

Я новичок ie в AWS и мне нужна помощь. Я создал пользователя (ronen) в своем экземпляре EC2 (в дополнение к ec2-пользователю) командой adduser. Затем я создал открытый / закрытый ключ с помощью следующей команды:

ssh-keygen -b 1024 -f my-cmd-gen-keys -t dsa

Были созданы следующие файлы:

my-cmd-gen-keys
my-cmd-gen-keys.pub

Я скопировал содержимое файла publi c в /home/ronen/.ssh/authorized_keys. Затем я попытался выполнить команду и получил отказ в разрешении:

**

> ssh -i ronen-key-pair ronen@ip-172-31-19-13 
> Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

**

(Я должен признаться, что он работал для меня несколько дней за go до того, как я остановил экземпляр, возможно, что-то упустил)

ниже указана команда с параметром -v

> [ronen@ip-172-31-19-13 ~]$ ssh -i ronen-key-pair ronen@ip-172-31-19-13 -v

> OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017 debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config
    > line 58: Applying options for * debug1: Connecting to ip-172-31-19-13
    > [172.31.19.13] port 22. debug1: Connection established. debug1:
    > identity file ronen-key-pair type 2 debug1: key_load_public: No such
    > file or directory debug1: identity file ronen-key-pair-cert type -1
    > debug1: Enabling compatibility mode for protocol 2.0 debug1: Local
    > version string SSH-2.0-OpenSSH_7.4 debug1: Remote protocol version
    > 2.0, remote software version OpenSSH_7.4 debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000 debug1: Authenticating to
    > ip-172-31-19-13:22 as 'ronen' debug1: SSH2_MSG_KEXINIT sent debug1:
    > SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256
    > debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex:
    > server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit>
    > compression: none debug1: kex: client->server cipher:
    > chacha20-poly1305@openssh.com MAC: <implicit> compression: none
    > debug1: kex: curve25519-sha256 need=64 dh_need=64 debug1: kex:
    > curve25519-sha256 need=64 dh_need=64 debug1: expecting
    > SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256
    > SHA256:gQm7jn7pje2jeEY+LrwW2BIWuS/7qF+QfI6HQ9JZ5Jw debug1: Host
    > 'ip-172-31-19-13' is known and matches the ECDSA host key. debug1:
    > Found key in /home/ronen/.ssh/known_hosts:1 debug1: rekey after
    > 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting
    > SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after
    > 134217728 blocks debug1: SSH2_MSG_EXT_INFO received debug1:
    > kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
    > debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that
    > can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Next
    > authentication method: gssapi-keyex debug1: No valid Key exchange
    > context debug1: Next authentication method: gssapi-with-mic debug1:
    > Unspecified GSS failure.  Minor code may provide more information No
    > Kerberos credentials available (default cache:
    > KEYRING:persistent:1001)
    > 
    > debug1: Unspecified GSS failure.  Minor code may provide more
    > information No Kerberos credentials available (default cache:
    > KEYRING:persistent:1001)
    > 
    > debug1: Next authentication method: publickey debug1: Offering DSA
    > public key: ronen-key-pair debug1: Authentications that can continue:
    > publickey,gssapi-keyex,gssapi-with-mic debug1: No more authentication
    > methods to try. Permission denied
    > (publickey,gssapi-keyex,gssapi-with-mic).

Ниже приведено разрешение этого пользователя на каталог / файлы:

[ronen@ip-172-31-19-13 ~]$ ls -lrtaR
.:
total 24
-rw-r--r-- 1 ronen ronen  231 Jul 27  2018 .bashrc
-rw-r--r-- 1 ronen ronen  193 Jul 27  2018 .bash_profile
-rw-r--r-- 1 ronen ronen   18 Jul 27  2018 .bash_logout
drwxr-xr-x 4 root  root    35 Jan 27 17:42 ..
-rw-r--r-- 1 ronen ronen  641 Jan 27 17:44 ronen-key-pair.pub
-rw------- 1 ronen ronen  672 Jan 27 17:44 ronen-key-pair
drwxrwxr-x 2 ronen ronen   48 Jan 27 17:49 .ssh
-rw-rw-r-- 1 ronen ronen    0 Jan 27 18:56 client
-rw-rw-r-- 1 ronen ronen    0 Jan 27 18:56 server
drwx------ 3 ronen ronen  171 Jan 27 18:56 .
-rw------- 1 ronen ronen 3539 Jan 27 18:58 .bash_history

./.ssh:
total 8
-rw-rw-r-- 1 ronen ronen 641 Jan 27 17:45 authorized_keys
drwxrwxr-x 2 ronen ronen  48 Jan 27 17:49 .
-rw-r--r-- 1 ronen ronen 380 Jan 27 17:55 known_hosts
drwx------ 3 ronen ronen 171 Jan 27 18:56 ..
[ronen@ip-172-31-19-13 ~]$

Спасибо за помощь, Ронен

Answer 1

Meta: это не проблема программирования и, вероятно, относится к суперпользователю или unix .SX, или, возможно, security.SX. Но в прошлый раз я пытался перенести что-то, что доставляло больше хлопот, чем стоило.

https://man.openbsd.org/sshd.8#FILES (упрощенное форматирование)

~ / .ssh / authorized_keys

Если этот файл, каталог ~ / .s sh или домашний каталог пользователя доступны для записи другим пользователям, то этот файл может быть изменен или заменен неавторизованными пользователями. В этом случае sshd не позволит использовать его, если для параметра StrictModes не установлено значение «no».

У вас есть оба .s sh (drwxrwxr-x) и .ssh / author_keys (-rw-rw-r--) доступный для записи группой. В современных Linux системах идентификаторы пользователей часто помещаются в свои собственные группы, так что «групповой» доступ фактически не разрешает доступ другим пользователям, но OpenS SH практически не может обнаружить это (особенно в возможном Kerberos, LDAP, или среды YP / NIS) и должен предполагать, что «групповой» доступ разрешает другим пользователям и небезопасен.

Кроме того, последние версии OpenS SH (начиная с 7.0, включая ваш 7.4) больше не поддерживают ключи DSA по умолчанию. Это можно исправить, см .:
https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication
https://unix.stackexchange.com/questions/247612/ssh-keeps-skipping-my-pubkey-and-asking-for-a-password
https://security.stackexchange.com/questions/112802/why-openssh-deprecated-dsa-keys

но если у вас нет веской причины использовать DSA специально, я предлагаю заменить либо на rsa-2048 (совместимый со всем и достаточно защищенным), либо на ecdsa (-any) или ed25519 (теперь широко распространенный, но не универсальный, более эффективный и немного более высокий запас прочности) ).