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