Witaj na Forum Linuxiarzy
Zanim zalogujesz się, by pisać na naszym forum, zapoznaj się z kilkoma zasadami savoir-vivre'u w dziale Administracja.
Wiadomości z problemami zamieszczone w wątku "Przywitaj się" oraz wszelkie reklamy na naszym forum będą usuwane.

problem z przekierowaniem X11

Zaczęty przez microsofter, Sierpień 22, 2021, 11:23:43 AM

Poprzedni wątek - Następny wątek

microsofter

Do poduszki uruchomilem jedno z dobrodziejstw Solarisa, czyli zones. Juz rozumiem jak to dziala, nie moge tylko uruchomic GUI.

Cala dokumentacja mowi o przekletym SSH (ktorego dotad nie uzywalem, korzystam z Telnetu). Przy probie przekierowania grafiki po SSH, otrzymuje komunikat:
Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
Zrobilem wszystko wedlug tego poradnika https://phoenixnap.com/kb/ssh-permission-denied-publickey+ zezwolenie na root i brak hasla. Dalej nie dziala, nie wiem, co robie zle. To moje pierwsze kroki z SSH.

Co gorsza, nie dziala takze klasyczne przekierowanie DISPLAY={iP}. Otrzymuje standardowy komunikat Error: Can't open display: 192.168 .......

Ma ktos pomysl jak, to rozwiklac?

Jeszcze dodam, ze gdy loguje sie zdalnie przez SSH, samo logowanie przebiega pomyslnie. Ale uruchomienie czegos z GUI jest juz niemozliwe. Zwracany jest taki komunikat:
X11 connection rejected because of wrong authentication.
X connection to z1:10.0 broken (explicit kill or server shutdown).
były: MS Windows, Sun Solaris, Oracle Solaris; jest: OpenSolaris + m0n0wall + Solaris powered NAS

robson75

#1
Gdy jakieś GUI nie działa to uruchamiam to przez terminal, wtedy dostaje informacje co jest nie tak.

Edit.
Jeżeli używasz telnetu, to może konieczne jest uruchomienie usługi
systemctl enable telnet.socket
systemctl start telnet.socket
Arch Linux Xfce - 64Bit Linux User #621110

microsofter

Cytat: robson75 w Sierpień 22, 2021, 11:57:34 AM
Gdy jakieś GUI nie działa to uruchamiam to przez terminal, wtedy dostaje informacje co jest nie tak.
Wtedy otrzymuje ten ostatni komunikat:
X11 connection rejected because of wrong authentication.
X connection to {nazwa}:10.0 broken (explicit kill or server shutdown).

Cos jest nie tak z poswiadczeniami.

CytatJeżeli używasz telnetu, to może konieczne jest uruchomienie usługi
systemctl enable telnet.socket
systemctl start telnet.socket
Nie dziala. To pewnie musi byc linuksowy odpowiednik svcadm. Ale Telnet dziala u mnie sprawnie. Dotychczas uzywalem go jedynie Unix<->Windows, natomiast pomiedzy zonami, takze dziala ok. SSH do zone tez dziala, ale X juz nie.

Co za nonsens, zmuszac kogos do uzywania z SSH w systemie, do ktorego nikt niepowolany nie ma dostepu!
były: MS Windows, Sun Solaris, Oracle Solaris; jest: OpenSolaris + m0n0wall + Solaris powered NAS

robson75

Arch Linux Xfce - 64Bit Linux User #621110

microsofter

Zgodnie z ta instrukcja, uzylem ssh-keygen do utworzenia nowych kluczy. Ale juz ssh-copy-id nie, bo nie mam takiego narzedzia. Po recznym skopiowaniu kluczy, Telnet SSH calkowicie odmowil polaczenia, ostrzegajac mnie o zmianie klucza i prawdopodobnym ataku. Po usunieciu known_hosts, jest po staremu - tak jak przy kluczach utworzonych automatycznie. Poddaje sie.
były: MS Windows, Sun Solaris, Oracle Solaris; jest: OpenSolaris + m0n0wall + Solaris powered NAS

robson75

Cytat: microsofter w Sierpień 22, 2021, 02:59:59 PM
Zgodnie z ta instrukcja, uzylem ssh-keygen do utworzenia nowych kluczy. Ale juz ssh-copy-id nie, bo nie mam takiego narzedzia.
Nie potrzeba żadnego narzędzia
https://www.youtube.com/watch?v=5Fcf-8LPvws
Arch Linux Xfce - 64Bit Linux User #621110

microsofter

Bardzo dziekuje za filmik Oszczedza duzo czytania. Ale juz doszedlem do tego samego. Stoje w miejscu, bo nie mam komendy potrzebnej w 2:25:
# ssh-copy-id
ssh-copy-id: not found


Nie ma innego sposobu?
były: MS Windows, Sun Solaris, Oracle Solaris; jest: OpenSolaris + m0n0wall + Solaris powered NAS

robson75

Prawidłowo powinno to tak wyglądać
# ssh-copy-id nazwa_hosta@Twój_adres_serwera_dns
Arch Linux Xfce - 64Bit Linux User #621110

microsofter

A nie tak?
# ssh-copy-id root@IP_mojego_serwera/zony
Teraz to bez znaczenia, wcale nie mam tego narzedzia.

Czy moja instalacja SSH jest kompletna? Tak to wyglada w dodaj/usun elementy systemu (czy tam menadzeze pakietow, czy jak to sie zwie w Uniksie ...).


Ciagle mam wrazenie, ze u mnie nastapilo pelne sparowanie klienta z serwerem SSH w czasie pierwszego polaczenia, a przyczyna braku tunelowania X lezy gdzie indziej. Loguje sie przez SSH bez podawania loginu ani czegokolwiek, tylko IP serwera. Przy pierwszym polaczeniu bylem pytany, czy chce autoryzowac ten serwer. Albo inne bylo to pytanie, pamietam ze musialem odpowiedziec pelnym ,,yes". Wtedy wyswietlily sie jakies dlugie klucze. Juz nie moge tego powtorzyc, bo teraz loguje sie automatycznie. Tylko X11 nie dziala. (Zreszta przy cron tez nie dziala, o czym jest moj temat ciut nizej.)

Czy moze by jak przypuszczam, ze klucze sa ok, a cos blokuje X? Np zla konfiguracja w sshd_config.
były: MS Windows, Sun Solaris, Oracle Solaris; jest: OpenSolaris + m0n0wall + Solaris powered NAS

robson75

#9
U mnie na Arch-u gdy konfigurowałem ssh wystarczyły dwa polecenia
ssh-keygen -t rsa
ssh-copy-id robson@192.167.7.100
I wszystko działa jak należy.
Oczywiście konieczne było uruchomienie usługi sshd



EDIT.
Nie wiem jak w Solaris, ale u mnie aby zresetować wszystkie ustawienia ssh wystarczy uruchomić managera plików, wyświetlić ukryte pliki, i usunąć katalog .ssh



I od początku skonfigurować ssh.
Arch Linux Xfce - 64Bit Linux User #621110

microsofter

Wczoraj usuwalem zawartosc .ssh. Nic nie wnosilo do sprawy.

Znalazlem chwile czasu na googlowanie. O ile dobrze zrozumialem:
W Linuxie sa uslugi ssh oraz sshd. Pierwsza to klient a druga serwer. W Solarisie nie znajdziemy nic takiego, jak sshd. Szukalem i nie ma. Jest wylacznie usluga ssh. Wniosek - jedna usluga odpowiada za funkcje klienta i serwera.
Ta usluga u mnie dziala:
# svcs -v ssh
STATE          NSTATE        STIME    CTID   FMRI
online         -             sier_18     169 svc:/network/ssh:default

wszystkie zaleznosci tez:
# svcs -dv ssh
STATE          NSTATE        STIME    CTID   FMRI
online         -             sier_17       - svc:/network/loopback:default
online         -             sier_17       - svc:/network/physical:default
online         -             sier_17      21 svc:/system/cryptosvc:default
online         -             sier_18       - svc:/system/filesystem/local:default
online         -             sier_18     160 svc:/system/utmp:default
online         -             sier_18     166 svc:/system/filesystem/autofs:default

ogolnie zadna usluga nie zglasza problemow (mam wylaczone drukowanie):
# svcs -xv
svc:/application/print/server:default (LP print server)
State: disabled since 17 sierpnia 2021 08:37:25 CEST
Reason: Disabled by an administrator.
   See: http://sun.com/msg/SMF-8000-05
   See: man -M /usr/share/man -s 1M lpsched
Impact: 1 dependent service is not running:
        svc:/application/print/rfc1179:default


I teraz najwazniejsze: znalazlem wlasciwy PDF o SSH. Wspolczesne wydania Solarisa to juz nie to samo, co generacja 2.x. OS jest o wiele bardziej skomplikowany i rozbudowany, dokumtacja rowniez. Coraz trudniej poruszac sie w gaszczu informacji, jakie przynosza PDFy - co wydanie, to wieksza ich liczba. Naprawde kiepsko widzialbym przesiadke np. z Windows 7 na Solaris 10. Ktos nadal uwaza, ze nie warto stawiac pierwszych krokow, na starych wersjach??

Teraz musze zostawic temat i jechac do pracy. Odezwe sie, gdy tylko posune sprawe do przodu.
były: MS Windows, Sun Solaris, Oracle Solaris; jest: OpenSolaris + m0n0wall + Solaris powered NAS

microsofter

Zrobione! Moja instalacja SSH jest kompletna, a rozwiazanie okazlo sie trywialne. Tak jak przypuszczalem, to pliki konfiguracyjne mialy zle ustawienia. Korzystajac z poradnika w pierszym poscie, tylko namieszalem i rowalilem tunelowanie X11. Dzisiaj wgralem oryginalne ssh_config i sshd_config, po czym zmienilem w sshd_config, na serwerze, tylko dwa ustawienia na yes: PermitRootLogin i PermitEmptyPasswords (uzywam root bez hasla). Xeyes uruchomilo sie od strzala, wiec wszysko inne tez powinno dzialac!

Komenda ssh-copy-id jest specyficzna dla GNU. W Solarisie nie istnieje, poniewaz tu wysylamy klucze w nieco inny sposob:
scp /.ssh/id_rsa.pub remotehost:/.ssh/authorized_keys2
lub
cat /.ssh/id_rsa.pub | ssh remotehost 'cat >>/.ssh/authorized_keys2'
Ktos powie, co w sytuacji, gdy nie mozemy skorzystac z tych polecen? Odpowiedz na to znajdziemy w dokumentacji:
CytatFor hosts where users are unable to place their public keys, such as bastion hosts, public keys may be emailed to the IT support staff. Have the staff verify out of band the key fingerprint.
Jak widac, w GNU mamy rozwiazanie bardziej poreczne, a w Solarisie bezpieczne.

I teraz najciekawsze. Zupelnie niepotrzebnie drazylem temat o kluczach. Z punktu widzenia problemu, bowiem ta wiedza z pewnoscia zaowocuje w przyszlosci. Jednak obecnie, zarowno automatyczne logowanie SSH, jak i X11, dzialaja mi bez kluczy w folderze /.ssh. Nie mam pojecia, jak to sie dzieje. Moge tylko wysnuc hipoteze, ze klucze sa uzywanie w fizycznych serwerach. Natomiast przy pracy z zonami, Solaris ma swiadomosc, ze operujemy na jednym hoscie i jakos automatyzuje caly proces autoryzacji.

No to mamy juz dwoch userow, ktorzy ogarniaja SSH. Piatka Robson i dzieki, ze walczyles u mojego boku!
były: MS Windows, Sun Solaris, Oracle Solaris; jest: OpenSolaris + m0n0wall + Solaris powered NAS

Zobacz najnowsze wiadomości na forum