Может SSH через туннель из корня, не может из учетной записи пользователя

191
Iiridayn

У меня есть два пользователя на 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линию на обоих.

Запуск того же самого 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не имеет никакого значения, и 2. Я могу войти в ту же самом 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. 
1
На всякий случай, чтобы проверить очевидное: разрешения как для `.ssh`, так и для их содержимого одинаковы (вы использовали` cp -r`, а не `cp -a`)? Вы дважды проверили, что смена владельца работала правильно? dirkt 1 год назад 0
@dirkt Да, я ввел команды как вставленные, за исключением двух строк вместо `;`. Я получил бы другую ошибку, если бы у каталога были неправильные разрешения - я не помню это, но я видел это раньше. Визуальный осмотр только сейчас подтверждает - файлы, принадлежащие `user: user`,` config` и `id_protected`, являются` 0600`, а `id_protected.pub` и` known_hosts` равны `0644`. Каталог `/ home / user / .ssh` находится в` 700` и ​​также принадлежит `user: user`. Iiridayn 1 год назад 0
вероятно, в каждом разделе `Host` нужен хотя бы` ForwardAgent yes`, плюс я использую `nc` в качестве прокси. strobelight 1 год назад 0
@strobelight попробовал это - не имело никакого значения, отдельно или вместе. `root` @` desktop` все еще может войти в систему через `bastion`,` user` @ `desktop` по-прежнему не может. Я обычно не люблю использовать `nc` в качестве прокси, так как он обычно оставляет запущенные процессы` nc` на `bastion`. Я добавлю к сообщению `user` @` bastion` `.ssh / config` - он настроен так, что может входить напрямую, так что мне не понадобится переадресация агента (в любом случае ничего не изменилось) хоть). Iiridayn 1 год назад 0
является ли личный ключ одинаковым для пользователя root и пользователя? они не должны быть, но соответствующий открытый ключ каждого должен быть в файлах .ssh / authorized_keys. strobelight 1 год назад 0
Ваша пользовательская конфигурация ssh не использует хост бастиона, поэтому продублируйте запись бастиона и используйте ее в защищенной записи, поскольку для доступа к защищенной вы должны пройти через бастион, независимо от того, являетесь ли вы пользователем root или пользователем. strobelight 1 год назад 0
@strobelight, может быть, мне следует переименовать `user` - вторая конфигурация ssh - _on` bastion`_, а не на `desktop`. Закрытый ключ _is_ одинаков как для `root` @` desktop`, так и для `user` @` desktop` - поскольку копируется весь каталог. Однако закрытый ключ для `user` @` bastion` отличается. Тем не менее - `user` @` bastion` _can_ залогиниться, `root` @` desktop` _can_ залогиниться и `user` @` desktop` _cannot_ - с тем же секретным ключом и конфигурацией, что и `root` @` desktop`. Iiridayn 1 год назад 0
Вы пытались добавить параметр -v к ssh в ProxyCommand и проверить его вывод? Tomek 1 год назад 0
@ Томек нет, у меня не было :). Добавлен вывод к вопросу. Кажется, не проливает дополнительного света, к сожалению. Iiridayn 1 год назад 0
На самом деле это так. Проблема с подключением прокси к бастиону. Можете ли вы войти как пользователь на бастионе, используя ssh от пользователя на рабочем столе? Если да, я бы начал изучать ваши файлы инициализации оболочки, если в них есть что-то, зависящее от переменных среды SSH_ *. Также стоит рассмотреть поиск конфигурации pam и sshd для любых ограничений. Tomek 1 год назад 0
@Tomek Я упоминаю в блоке 12 (начиная с «Я также пытался ...»), что я пробовал это - далее, он проходит через `bastion` при подключении через` bastion` с `root` @` desktop` , Я упомянул в 5-м предложении моего первого абзаца, что я также могу войти из `user` @` bastion` в `protected`. Проверка `.bashrc` и` .bash_profile` для `user` @` bastion` снова ничего не показывает перед строкой `[[$ -! = * I *]] && return`. Iiridayn 1 год назад 0

1 ответ на вопрос

0
strobelight

Поскольку ваш защищенный хост находится за хостом-бастионом, вам все равно нужно пройти через хост-бастион, чтобы получить к нему доступ как от имени пользователя 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 
Это именно то, что я сказал, что я сделал в своем вопросе во втором абзаце. Iiridayn 1 год назад 0
Насколько я понимаю, у вас есть две учетные записи на * desktop *, * root * и * user *, и вы пытаетесь перейти непосредственно к защищенной учетной записи host * user * со своего рабочего стола, независимо от того, вошли ли вы в систему как * root * или * user * , `sudo -i sum .ssh / config sum ~ user / .ssh / config # выше двух чисел должны совпадать с sum .ssh / id_protected sum ~ user / .ssh / id_protected # выше двух чисел должны совпадать с` конфигурацией ssh ​​на бастионе полезно только в том случае, если вы сначала войдете в бастион. strobelight 1 год назад 0
1) У меня два аккаунта на `desktop`, правильно. 2) Я пытаюсь перейти прямо к `protected` с` desktop`, вошли ли вы как `user` или` root`, правильно. 3) `sudo -i sum /root/.ssh/config ~ user / .ssh / config` одинаковы, правильно. 4) `sudo -i sum /root/.ssh/id_protected ~ user / .ssh / id_protected` являются одинаковыми, правильно. Это было продемонстрировано, однако, в пункте 2 моего вопроса, однако, я повторил эти шаги для вас и подтвердил, что я все еще могу войти в систему с `root` @` desktop` и не могу с `user` @` desktop`. Я пока оставлю конфигурацию бастиона, так как это может помочь кому-то еще. Iiridayn 1 год назад 0
`AllowAgentFowarding` по умолчанию` yes` для `protected` и` bastion` в `/ etc / ssh / sshd_config`. Я уже 3 раза показал, что закрытые ключи одинаковы между `root` и` user` @ `desktop`. Я _again_ поместил `ForwardAgent yes` в обе записи` / root / .ssh / config`, а затем скопировал / chowned `/ root / .ssh` в` / home / user / .ssh` и на хост `protected` показывает тот же результат - `root` @` desktop` регистрируется нормально, `user` @` desktop` останавливается на `debug1: SSH2_MSG_KEXINIT sent [preauth]`. Я разочарован тем, что вы попросили меня сделать те же шаги 2 и 3 раза соответственно. Iiridayn 1 год назад 0