1

У меня на desktop два пользователя - root и user . У меня есть bastion и protected хозяин. При запуске ssh protected с root на desktop , я подключаюсь нормально. Когда я запускаю ssh protected как user на desktop , я не получаю вывод - просто пустая строка, как будто она чего-то ждет. Тем не менее, user может войти непосредственно на хост- bastion и оттуда на protected хост.

И root и user имеют одинаковое содержимое в своих каталогах .ssh (#cp -r ~/.ssh /home/user; chown -R user:user /home/user/.ssh).

Похоже, что bastion хост переадресовывает должным образом - при запуске $(which sshd) -Ddp 10222 (по адресу https://unix.stackexchange.com/a/128910/9583) отображается тот же debug1: channel 0: connected to protected port 22 линии защищенного порта 22 на обоих.

Запуск того же самого на protected показывает тот же вывод до:

debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]

Вторая строка не отображается при подключении от user на desktop .

ssh -vvv protected как user на desktop показывает:

OpenSSH_7.9p1, OpenSSL 1.1.1  11 Sep 2018                                                                                                                       
debug1: Reading configuration data /home/user/.ssh/config                                                                                                     
debug1: /home/user/.ssh/config line 1: Applying options for *                                                                                                
debug1: /home/user/.ssh/config line 10: Applying options for protected                                                                                            
debug1: Reading configuration data /etc/ssh/ssh_config                                                                                                          
debug1: Executing proxy command: exec ssh bastion -W protected:22                                                                                                
debug1: identity file /home/user/.ssh/id_protected type 0                                                                                                         
debug1: identity file /home/user/.ssh/id_protected-cert type -1                                                                                                   
debug1: Local version string SSH-2.0-OpenSSH_7.9                                                                                                                
debug1: ssh_exchange_identification: \033[3g
\033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H     \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H    \033H
SSH-2.0-Op
debug1: ssh_exchange_identification: enSSH_7.9


debug1: ssh_exchange_identification:
debug1: ssh_exchange_identification: 6,diffie-hellman-group14-sha1
debug1: ssh_exchange_identification: aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com                                                       
debug1: ssh_exchange_identification: 2-256,hmac-sha2-512,hmac-sha1

От имени пользователя root на desktop все остается неизменным вплоть до первой строки ssh_exchange_identification .

Моя конфигурация ssh:

Host *
ServerAliveInterval 60
IdentitiesOnly yes

Host           bastion
HostName       bastion.host
IdentityFile   ~/.ssh/id_protected
User           user

Host          protected
IdentityFile   ~/.ssh/id_protected
Hostname       protected
User           user
ProxyCommand   ssh bastion -W %h:%p

Я также пробовал https://askubuntu.com/a/976226/427339, но я считаю, что это не относится к двум причинам:1. очистка моего ~/.config/fish/fish.config имела никакого значения, и , Я могу войти в систему к тому же user на protected от root на desktop .

Все три системы работают под управлением Arch Linux. protected и desktop используют fish раковину.

Редактировать:

user @ bastion 's ~/.ssh/config:

Host *
ServerAliveInterval 60

Host protected
User user
IdentityFile ~/.ssh/id_protected

Это, как уже упоминалось выше, отлично работает для входа в защищенный. /etc/hosts есть запись для protected указания на локальный IP-адрес - 10.xxx

Изменить 2:

Моя проблема очень похожа на эти:

Я еще не пробовал обходной путь MTU, и я недостаточно знаком с анализаторами протоколов, чтобы его настроить и использовать прямо сейчас.

Изменить 3:

Добавление -v к ProxyCommand (теперь это ProxyCommand ssh -v bastion -W %h:%p), полный вывод user@desktop$ ssh protected:

OpenSSH_7.9p1, OpenSSL 1.1.1  11 Sep 2018
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug1: /home/user/.ssh/config line 5: Applying options for bastion
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to bastion [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_protected type 0
debug1: identity file /home/user/.ssh/id_protected-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.8
debug1: match: OpenSSH_7.8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to bastion:22 as 'user'
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: expecting SSH2_MSG_KEX_ECDH_REPLY                                                                                                                       
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:HfDmNOGgLrPLMsnCbyZuEuJapj+T6wrSTTiFSd+37ag                                                                 
debug1: Host 'bastion' is known and matches the ECDSA host key.                                                                                           
debug1: Found key in /home/users/.ssh/known_hosts:3                                                                                                           
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: Will attempt key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent                                   
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent                                
debug1: Server accepts key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent                                 
debug1: Authentication succeeded (publickey).
Authenticated to bastion ([x.x.x.x]:22).
debug1: channel_connect_stdio_fwd protected:22
debug1: channel 0: new [stdio-forward]
debug1: getpeername failed: Bad file descriptor
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/user/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/user/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
--- very long delay; from `root` everything is the same till here, but the next line is `Last login: ...`, etc - a successful connection ---
debug1: channel 0: FORCE input drain
ssh_exchange_identification: Connection closed by remote host
debug1: channel 0: free: direct-tcpip: listening port 0 for protected port 22, connect from 127.0.0.1 port 65535 to UNKNOWN port 65536, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Killed by signal 1.
|источник

2 ответа2

0

Поскольку ваш защищенный хост находится за хостом-бастионом, вам все равно нужно пройти через хост-бастион, чтобы получить к нему доступ как от имени пользователя root, так и от учетной записи обычного пользователя .

Просто скопируйте корневую конфигурацию ssh на пользовательскую конфигурацию ssh, и все будет в порядке, но добавьте ForwardAgent yes в каждом разделе Host для пользователя root и обычного пользователя на рабочем столе.

Host *
ServerAliveInterval 60
IdentitiesOnly yes

Host           bastion
HostName       bastion.host
IdentityFile   ~/.ssh/id_protected
User           user
ForwardAgent   yes

Host          protected
IdentityFile   ~/.ssh/id_protected
Hostname       protected
User           user
ForwardAgent   yes
ProxyCommand   ssh bastion -W %h:%p

Файл sshd_config на бастионе, а также на защищенном хосте, обычно в /etc/ssh/sshd_config , должен иметь AllowAgentForwarding yes который обычно используется по умолчанию, но его стоит проверить. Если вам нужно изменить, перезапустите sshd после сохранения.

Надеемся, что закрытые ключи одинаковы для пользователя root и обычного пользователя, но если нет, убедитесь, что соответствующие открытые ключи находятся в файле .ssh/authorized_keys на хосте бастиона, а также на защищенном хосте. Другими словами, в файле .ssh/authorized_keys пользователей бастиона есть запись (однострочные, 2 или 3 разделенных пробелами поля), содержащая открытые ключи соответствующих закрытых ключей, используемых на вашем рабочем столе, и защищенный хост.

Если у вас больше нет открытых ключей, вы можете получить их с помощью этой команды:

ssh-keygen -l -f /path/to/private_key
|источник
0

Я столкнулся с очень похожей проблемой обстрела с laptop (не упомянутого в вопросе - у меня также есть pi и несколько других компьютеров, не относящихся к данной проблеме) на desktop - который настроен очень похоже на protected . Симптом:

user@laptop$ ssh desktop "echo foo" | xxd
00000000: 1b5b 3367 0d1b 4820 2020 201b 4820 2020  .[3g..H    .H
00000010: 201b 4820 2020 201b 4820 2020 201b 4820   .H    .H    .H
00000020: 2020 201b 4820 2020 201b 4820 2020 201b     .H    .H    . 
00000030: 4820 2020 201b 4820 2020 201b 4820 2020  H    .H    .H
00000040: 201b 4820 2020 201b 4820 2020 201b 4820   .H    .H    .H
00000050: 2020 201b 4820 2020 201b 4820 2020 201b     .H    .H    .
00000060: 4820 2020 201b 4820 2020 201b 4820 2020  H    .H    .H
00000070: 201b 4820 2020 201b 4820 2020 0d66 6f6f   .H    .H   .foo
00000080: 0a

Это легко исправить, изменив вкладки строки tabs -4 на status --is-interactive; and tabs -4 в /home/user/.config/fish/config.fish на desktop . Это изменение я уже сделал некоторое время назад на protected .

Тем не менее - изменение /home/user/.config/fish/config.fish на desktop видимому, исправило вход в систему с user @ desktop на user @ protected . Я публикую это как ответ, так как чувствую, что разрешение несколько нововато - https://askubuntu.com/a/976226/427339, на который я ссылаюсь в вопросе, гласит, что мне нужно проверить команды, выдающие выходные данные на protected, и я решил эту проблему, изменив команду, которая производит вывод на desktop .

Тем не менее, я хотел бы отметить принятый ответ, который объясняет, как и почему моя конфигурация оболочки на локальном компьютере влияла на канал ssh, а не на прямые соединения ssh.

До этого я пришел к предварительному выводу, что tabs - это опасная программа, и к ней следует относиться с большой осторожностью, если помещать ее в файл запуска оболочки.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .