Не вдалося пройти автентифікацію SSH-ключа

Я намагаюся вторгнутись у сервер CentOS, над яким я не маю ніякого контролю. Адмін додав мій відкритий ключ до сервера і наполягає на тому, що вина лежить в мені, але я не можу зрозуміти, що не так.

Налаштування .ssh:

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

Дозвіл на мої файли ключів:

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

Журнал підключень, який я не можу мати жодного сенсу:

tim@tim-UX31A:~$ ssh -vvv root@10.0.12.28
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.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
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,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: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
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
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
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
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
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
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
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Зазвичай це дозволить вирішити більшість дозволених дозволів SSH для ключів на стороні сервера , припускаючи, що хтось не вносив додаткових змін у дозволи.

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

Якщо ваш адміністратор створив файл .ssh / каталог або .ssh / avtor_keys як корінь (що найчастіше це відбувається), то мати файл, який належить іншому користувачеві (навіть якщо root!), Заборонено.

Userify (відмова від відповідальності: співзасновник) автоматично робить це точно так само .. https://github.com/userify/shim/blob/master/shim.py#L285

У мене була однакова проблема на двох серверах: Linux, який працює з розтяжкою Debian і в NAS (Synology DS715)

виявилося, що в обох випадках дозволи домашнього каталогу на сервері були помилковими

auth.log на сервері був дуже корисним

Authentication refused: bad ownership or modes for directory /home/cyril

в Linux був увімкнений біт write / group (drwxrwxr - x), тому мені довелося видалити принаймні запис на групі (chmod gw ~ /), а потім він працював

на Synology, з будь-якої причини, був клейкий шматочок

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

Мені довелося це змінити

chmod -t ~/

і я міг потім підключитися без пароля

Під час використання CentOS 7, і я впевнений, це стосується і інших ОС Linux, що використовують sshd. За допомогою кореневого доступу ви можете дізнатися більше про те, чому автентифікація може бути невдалою. Зробити це:

1. Увімкнути журнал для sshd: vi /etc/ssh/sshd_config
2. Під коментарем увімкнення:

SyslogFacility AUTH LogLevel INFO

1. Змініть LogLevel INFO на LogLevel DEBUG
2. Збережіть і вийдіть
3. Перезавантажте sshd systemctl restart sshd
4. Перегляньте файл повідомлень tail -l /var/log/messages
5. Спробуйте скористатися іншим терміналом, з'єднавшись з ssh
6. Спроба підключитися до ssh
7. Перегляньте журнал аутентифікації для точної причини

Наприклад, у мене виникли ті ж самі проблеми, що й вище.

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

Використовуючи ці кроки, я зміг підтвердити, що проблема - це дозволи на файл санкціонованих файлів. Встановивши chmod на 644 у файлі авторизованих ключів мого користувача, проблему було виправлено.

Схоже, дозволи у вашій .sshпапці не копіювали + вставляли правильно. Не могли б ви додати його ще раз?

Якщо ввімкнено суворий режим, ми маємо переконатися .sshв правильності дозволу:

• .ssh/ повинні мати хімічні речовини 0700/rwx------
• .ssh/*.pub файли повинні бути 644/rw-r--r--
• .ssh/* (інші файли у .ssh) 0600/rw-------

Як все виглядає на вас, якщо вам дозволено?

На всякий випадок, коли хтось натрапить на цю відповідь - жодна з рекомендацій не працювала за моїм сценарієм. Зрештою, проблема полягала в тому, що я створив обліковий запис без пароля. Одного разу я встановив пароль за допомогою, usermod -p "my password" usernameа потім примусово розблокував обліковий запис, usermod -U usernameвсе було пристрасно.

У мене була подібна проблема , коли ssh-з'єднання намагається виконати ключ, ~/.ssh/id_rsaперш ніж несподівано зупинитися:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

У моєму випадку це було пов’язано зі старим файлом відкритого ключа, що лежав у .sshкаталозі:

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Переміщення / видалення файлу id_rsa.pubз .sshкаталогу вирішило проблему.

З того, що я розумію: коли на стороні клієнта присутній відкритий ключ, SSH 1st перевіряє приватний ключ щодо нього. Якщо це не вдасться, він не намагатиметься використовувати приватний ключ для віддаленого підключення.

Я надіслав електронний лист до відкритого списку розсилки: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Ми зіткнулися з цією проблемою. Дозволи та право власності на .ssh файли були правильними. В / var / log / повідомлення ми знайшли:

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

Так, рішенням для vm для розробника, де нас не хвилює безпека, є відключення selinux. Редагувати / etc / sysconfig / selinux та змінити SELINUX = вимкнено та перезавантажити.

Про всяк випадок це також когось рятує. Я намагався скопіювати ключ з моєї машини Ubuntu 18.04 на 2 сервери CentOS 7. Я ssh-copy-idїх передавав. Один працював, інший ні. Тож я пройшов всі налагодження дозволів і нічого не знайшов. Отже, нарешті, я витягнув файл /etc/ssh/sshd_configна обох серверах і переходив по черзі через них. Нарешті я знайшов це, певно, щось, що хтось змінив задовго до того, як я взявся за роботу.

Один читав: AuthorizedKeysFile .ssh/authorized_keys

І ще прочитано:, AuthorizedKeysFile ~/.ssh/authorized_keysщо було на сервері, який не приймав мої ключі. Очевидно, переглядаючи між двома файлами та відзначаючи коментар, у якому зазначено, що шаблони пошуку за замовчуванням не включають провідних, які ~/я видалив, і перезапустив sshd. Проблема вирішена.

Також зіткнувся з цією проблемою. setroubleshoot, здається, не працює в моєму середовищі, тому таких записів журналу в / var / log / messages не було. Відключення SELinux не було для мене варіантом, тому я і зробив

restorecon -Rv ~/.ssh

Після цього вхід ключем rsa спрацював нормально.

Причиною в моєму випадку стала спеціально встановлена ​​опція AuthorizedKeysFileу файлі /etc/ssh/sshd_config. Він був встановлений у домашньому режимі dir ( /home/webmaster/.ssh/authorized_keys), тому користувач, якого я намагався увійти, не мав доступу до цього файлу / каталогу.

Після його зміни та перезавантаження ssh-server ( service ssh restart) все прийшло в норму. Я можу зараз увійти за допомогою свого приватного ключа.

У нашому випадку проблеми були пов'язані з тим, що наші брандмауері та правила NATING не були налаштовані правильно.

порт 22, було спрямовано на неправильний сервер, де наші ключі та користувач не розпізнавали.

Якщо хтось дістанеться до цього моменту. tcpdump і telnet можуть стати вашим другом

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

Ви помітите, що ці два сервери мають різні версії opensh. Це допомогло мені помітити проблему досить швидко. Якщо ваші хости використовують ті самі версії ssh, вам доведеться спробувати зробити упакований слід у пункті призначення, щоб побачити, чи трафік фактично надходить до пункту призначення.

Ssh може генерувати багато трафіку, що ускладнює пошук tcpdump, щоб знайти те, що ви шукаєте.

Це мені допомогло

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

Спробуйте запустити телнет з трьох різних серверів, а не з вашого поточного комп’ютера @ [mylocalip]. Ви хочете побачити, який трафік насправді досягає вашого сервера.

Журнал помилок на стороні клієнта закінчується так:

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
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
root@x.x.x.x's password:

може бути викликано обмеженням на вхід на кореневому сервері (віддаленим), коли файл конфігурації sshd містить:

PermitRootLogin: no

Пропозиція JonCav щодо включення журналу була корисною для налагодження такої проблеми. Незважаючи на те, що пошук налагодження на стороні клієнта був надзвичайно корисним, розмістивши у файлі sshd_config сервера sshd :

SyslogFacility AUTH
LogLevel DEBUG

нарешті створили корисні повідомлення журналу:

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

У випадку, коли не вдається лише кореневе вхід, і якщо за допомогою вашої політики безпеки дозволено використовувати лише автентифікацію на основі ключа для кореневого входу, зміна файлу sshd_config може допомогти:

 PermitRootLogin without-password

Ваш пробіг може відрізнятися, хоча це часто допомагає, якась інша конфігурація все-таки може заважати відповідно до коментарів, знайдених у деяких файлах sshd_config :

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

Навіть якщо ви не можете легко змінити конфігурацію віддаленого сервера для налагодження таким чином, ви можете довести конфігурацію на стороні клієнта певною мірою, використовуючи ті самі файли посвідчень, щоб ssh в не-root акаунт на тому ж віддаленому сервері.

Я бачу, чому безпека може турбувати людей. У мене ssh won't use my keyзнову була проблема. Я вирішив це, увійшовши на віддалений сервер і запустивши

/usr/sbin/sshd -sDp 23456

а потім із мого робочого столу, (намагаюся перенести ssh на сервер)

ssh -vvvv server -p 23456

На сервері я потрапив Authentication refused: bad ownership or modes for directory /

Якийсь новий sysadmin зіпсував дозвіл та право власності, які я виправив із:

chmod 0755 / ; chown root:root /

(Я звик, chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubале перевірка / пошук кореневих дозволів sshd - це для мене нове.) Зараз я збираюся перевірити rootkit, а потім все-таки витерти і знову встановити.

У моєму випадку проблеми полягали у неправильному виконанні оболонки.

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

Змінено / etc / passwd файл для цього користувача

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....

У мене була ця проблема в CentOS 7. Я звичайний користувач Linux, що базується на Debian, тому я був рибою з води. Я помітив, що на деяких серверах він працював, а лише в одному - не. Audit.log не сказав нічого корисного, а безпечний.лог також нічого не дав. Я виявив, що єдиною реальною різницею були деякі розбіжності в контексті безпеки файлів і каталогів між тими, що працювали, і тими, які не працювали. Отримайте безпеку за допомогою

sudo ls -laZ <user-home>/.ssh

каталогу (я припускаю, що на sshd_config багато за замовчуванням).

Ви повинні побачити деякі ssh_home_tі user_home_tатрибути. Якщо ви цього не зробите, використовуйтеchcon командою, щоб додати відсутні атрибути.

Наприклад

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

У моєму випадку я підозрюю, що користувач був створений нестандартним чином. Його домом був каталог в/var/lib .

Більше інформації: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/