Kann ssh via tunnel vom root aus, kann nicht vom Benutzerkonto
760
Iiridayn
Ich habe zwei Benutzer auf desktop- rootund user. Ich habe einen bastionund einen protectedGastgeber. Wenn er ausgeführt wird, ssh protectedwie rootauf desktop, schließe ich in Ordnung. Wenn ich laufen ssh protectedwie userauf desktop, bekomme ich keine Ausgabe - nur eine Leerzeile, wie sie für etwas wartet. Sie userkönnen sich jedoch direkt beim bastionHost und von dort beim protectedHost anmelden .
Beide rootund userhaben den gleichen Inhalt in ihren .sshVerzeichnissen ( #cp -r ~/.ssh /home/user; chown -R user:user /home/user/.ssh).
Es bastionscheint, dass der Host ordnungsgemäß weitergeleitet wird $(which sshd) -Ddp 10222(durch https://unix.stackexchange.com/a/128910/9583 ) wird debug1: channel 0: connected to protected port 22in beiden Fällen dieselbe Zeile angezeigt .
Wenn Sie dasselbe auf protectedausführen, wird dieselbe Ausgabe angezeigt, bis:
debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth]
Die zweite Zeile wird nicht angezeigt, wenn von der Verbindung userauf desktop.
Wie rootauf desktopalles ist bis auf die erste ssh_exchange_identificationZeile alles gleich .
Meine ssh config ist:
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
Ich habe auch versucht, https://askubuntu.com/a/976226/427339, aber ich glaube, dass dies aus zwei Gründen nicht gilt - 1. meine Entleerung ~/.config/fish/fish.configkeinen Unterschied gemacht, und 2. ich auf den gleichen anmelden kann userauf protectedausroot auf desktop.
Alle drei Systeme laufen mit Arch Linux. protectedund verwenden desktopbeide die fishShell.
Bearbeiten:
user@ bastion's ~/.ssh/config:
Host * ServerAliveInterval 60 Host protected User user IdentityFile ~/.ssh/id_protected
Wie oben erwähnt, funktioniert dies gut, um sich geschützt einzuloggen. /etc/hostshat einen Eintrag zum protectedVerweisen auf die netzlokale IP - 10.xxx
Edit 2:
Meine Ausgabe scheint diesen sehr ähnlich zu sein:
Ich habe die MTU-Problemumgehung noch nicht ausprobiert, und ich bin mit Protokollanalysatoren nicht vertraut, um jetzt einen einzurichten und handlich zu haben.
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.
Nur für den Fall, um das Offensichtliche zu überprüfen: Die Berechtigungen für `.ssh` und deren Inhalt sind gleich (Sie haben` cp -r` verwendet, nicht `cp -a`)? Sie haben überprüft, ob der Besitzerwechsel korrekt funktioniert hat?
dirkt vor 5 Jahren
0
@dirkt Ja, ich habe die Befehle als eingefügt eingefügt, außer in zwei Zeilen anstatt mit einem ";". Ich hätte einen anderen Fehler erhalten, wenn das Verzeichnis die falschen Berechtigungen hatte - ich erinnere mich nicht daran, aber ich habe es schon gesehen. Die visuelle Prüfung bestätigt gerade jetzt - die Dateien gehören `user: user`,` config` und `id_protected` sind` 0600` und `id_protected.pub` und` known_hosts` sind `0644`. Das Verzeichnis `/ home / user / .ssh` ist` 700` und ebenfalls im Besitz von `user: user`.
Iiridayn vor 5 Jahren
0
Ich brauche wahrscheinlich mindestens einen 'ForwardAgent yes' in jedem `Host'-Abschnitt, und ich benutze 'nc` als Proxy.
strobelight vor 5 Jahren
0
@strobelight hat das versucht - weder einen Unterschied, noch voneinander getrennt. `root` @` desktop` kann sich weiterhin über `bastion` anmelden,` user` @ `desktop` kann sich immer noch nicht anmelden. Normalerweise lehne ich die Verwendung von "nc" als Proxy ab, da er dazu neigt, "nc" -Prozesse auf "bastion" auszuführen. Ich füge `` .sh / config` von `user` @` bastion` zum Post hinzu - es ist so eingerichtet, dass es sich direkt anmelden kann, also brauche ich keine Agent-Weiterleitung (beide Wege haben keinen Unterschied gemacht) obwohl).
Iiridayn vor 5 Jahren
0
Ist der private Schlüssel für root und user gleich? Sie müssen nicht sein, aber der entsprechende öffentliche Schlüssel muss in den Dateien .ssh / authorised_keys liegen.
strobelight vor 5 Jahren
0
Ihr Benutzer ssh config verwendet nicht den Bastion-Host. Duplizieren Sie also den Bastion-Eintrag und verwenden Sie ihn im geschützten Eintrag. Um geschützt zu werden, müssen Sie die Bastion durchlaufen, unabhängig davon, ob Sie root oder user sind.
strobelight vor 5 Jahren
0
@strobelight Vielleicht sollte ich `user` umbenennen - die zweite ssh config ist _on` bastion`_, nicht auf `desktop`. Der private Schlüssel _is_ ist für "root" @ "desktop" und "user" @ "desktop" derselbe, da das gesamte Verzeichnis kopiert wird. Der private Schlüssel für `user` @` bastion` ist jedoch anders. Dennoch - `user` @` bastion` _can_ log in, `root` @` desktop` _can_ und `user` @` desktop` _cannot_ - mit demselben privaten Schlüssel und derselben Konfiguration wie `root` @ `desktop`.
Iiridayn vor 5 Jahren
0
Haben Sie versucht, die Option -v in ProxyCommand zu ssh hinzuzufügen und deren Ausgabe zu überprüfen?
Tomek vor 5 Jahren
0
@Tomek nein, hatte ich nicht :). Ausgabe zur Frage hinzugefügt. Scheint kein zusätzliches Licht zu werfen.
Iiridayn vor 5 Jahren
0
Eigentlich tut es. Das Problem liegt bei der Proxy-Verbindung zur Bastion. Können Sie sich als Benutzer bei Bastion mit ssh vom Benutzer auf dem Desktop anmelden? Wenn ja, würde ich anfangen, Ihre Shell-Init-Dateien zu untersuchen, wenn sie auf SSH_ * -Umgebungsvariablen angewiesen sind. Ein Blick auf die Konfiguration von pam und sshd kann auch lohnend sein.
Tomek vor 5 Jahren
0
@Tomek Ich erwähne in Block 12 (beginnend mit "Ich habe auch versucht ..."), dass ich das ausprobiert habe - weiter kommt es durch "Bastion", wenn durch "Bastion" von "root" @ "Desktop" eine Verbindung hergestellt wird . Ich habe im fünften Satz meines ersten Absatzes erwähnt, dass ich mich auch von "user" @ "bastion" zu "protected" einloggen kann. Wenn Sie `.bashrc` und` .bash_profile` auf `user` @` bastion` überprüfen, wird vor der Zeile [[$ -! = * I *]] && nichts angezeigt.
Iiridayn vor 5 Jahren
0
1 Antwort auf die Frage
0
strobelight
Da sich Ihr geschützter Host hinter einem Bastion-Host befindet, müssen Sie immer noch den Bastion-Host durchlaufen, um ihn zu erreichen, entweder über einen Root- Benutzer oder über ein normales Benutzerkonto .
Duplizieren Sie einfach die root ssh config auf den Benutzer ssh config und Sie sollten sich gut damit auskennen, aber fügen Sie ForwardAgent yesin jedem HostAbschnitt für den root-Benutzer und Ihren normalen Benutzer auf Ihrem Desktop ein.
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
Die sshd_configDatei auf der Bastion sowie der geschützte Host (in der Regel in) /etc/ssh/sshd_configmüssen AllowAgentForwarding yesdie Standardeinstellung haben, die sich jedoch lohnt. Wenn Sie Änderungen vornehmen müssen, starten Sie sshd nach dem Speichern erneut.
Hoffentlich stimmen die privaten Schlüssel zwischen root und normalem Benutzer überein. Wenn dies nicht der Fall ist, stellen Sie sicher, dass sich die entsprechenden öffentlichen Schlüssel in der .ssh/authorized_keysDatei auf dem Bastion-Host sowie auf dem geschützten Host befinden. Mit anderen Worten, die Bastion-Benutzerdatei .ssh/authorized_keysenthält einen Eintrag (einzeilig, zwei oder drei durch Leerzeichen getrennte Felder), der die öffentlichen Schlüssel der entsprechenden privaten Schlüssel enthält, die von Ihrem Desktop verwendet werden, und der geschützte Host.
Wenn Sie die öffentlichen Schlüssel nicht mehr haben, können Sie sie über diesen Befehl erhalten:
ssh-keygen -l -f /path/to/private_key
Genau das habe ich in meiner Frage im zweiten Absatz gesagt.
Iiridayn vor 5 Jahren
0
Mein Verständnis ist, dass Sie zwei Konten auf * desktop *, * root * und * user * haben und Sie versuchen, direkt von Ihrem Desktop zum geschützten Host * user * -Konto zu gelangen, unabhängig davon, ob Sie als * root * oder als * user * angemeldet sind. . Sudo -i summe .ssh / config sum ~ user / .ssh / config # oberhalb von zwei Zahlen sollte mit summe .ssh / id_protected übereinstimmen. Summe ~ user / .ssh / id_protected # oberhalb von zwei Zahlen sollte `s s config auf der Bastion sein Nur sinnvoll, wenn Sie sich zuerst bei der Bastion anmelden.
strobelight vor 5 Jahren
0
1) Ich habe zwei Konten auf "Desktop", richtig. 2) Ich versuche direkt von `desktop` zu` protected` zu gehen, egal ob als 'user'- oder `root'-Benutzer angemeldet, richtig. 3) `sudo -i sum /root/.ssh/config ~ user / .ssh / config` sind beide gleich, richtig. 4) `sudo -i sum /root/.ssh/id_protected ~ user / .ssh / id_protected 'sind beide gleich, richtig. Dies wurde jedoch in Abschnitt 2 meiner Frage gezeigt, jedoch habe ich diese Schritte für Sie wiederholt und festgestellt, dass ich mich immer noch von `root` @ `desktop` anmelden kann und nicht von` user` @ `desktop`. Ich werde die Bastion-Konfiguration vorerst verlassen, da sie jemand anderem helfen könnte.
Iiridayn vor 5 Jahren
0
"AllowAgentFowarding" ist standardmäßig auf "protected" und "bastion" in "/ etc / ssh / sshd_config" gesetzt. Ich habe jetzt 3 Mal gezeigt, dass die privaten Schlüssel zwischen "root" und "user" @ "desktop" gleich sind. Ich habe _again_ `ForwardAgent yes` in beide Einträge von` / root / .ssh / config` gestellt und dann / chilled `/ root / .ssh` nach` / home / user / .ssh` und den `protected`-Host kopiert zeigt dasselbe Ergebnis - `` `` `` `` `` meldet sich gut an, `user` @` desktop` stoppt bei 'debug1: SSH2_MSG_KEXINIT gesendet [preauth] `. Ich bin frustriert, dass Sie mich jetzt aufgefordert haben, die gleichen Schritte 2 und 3 zu machen.
Iiridayn vor 5 Jahren
0