Forum Debian Users Gang

Hostem dla wirtualnej jest:

$ cat /etc/hosts
127.0.0.1    localhost  debian
127.0.1.1    debian.Ptohos    debian

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Po zmianie restart komputera i dałem polecenie:

$  qemu-system-x86_64 -m 2048 -enable-kvm -net nic -net user,hostfwd=tcp::4444-:22 -hda /home/ptohos/test.qcow2

Zalogowałem się. I z drugiego terminala (z hosta) kolejne polecenie i informacja zwrotną tego polecenia:

ssh pto@localhost -p 4444
ssh_exchange_identification: read: Connection reset by peer

Tak to wygląda.

Ostatnio edytowany przez Ptohos (2020-01-19 01:16:34)

Jacekalex napisał(-a):

Przy net nic na pewno VM nie będzie na localhoście,

U mnie działa sposób jawojxa.

Loguję się bez problemu w taki sposób.

ilin napisał(-a):

Jacekalex napisał(-a):

Przy net nic na pewno VM nie będzie na localhoście,

U mnie działa sposób jawojxa.

Loguję się bez problemu w taki sposób.

Wcześniej podałem ważną informacje przy instalacji pakietu --> openssh-server

Zainstalowałem na wirtualnym Debianie --> openssh-server:
# dpkg -l openssh-server
Wybór:U=nieznany/I=instalacja/R=usunięcie/P=wyczyszczenie/H=zatrzymanie
| Stan:N=brak/I=zainstalowany/C=skonfigurowany/U=rozpakowany/
|/  F=częśc. skonfigurowany/H=częśc. zainstalowany/W=wyzw. czek./T=wyzw. zapl.
|| Błędy?=(brak)/R-do pon. inst. (duże litery w "Stan" i "Błędy"=problemy)
||/ Nazwa          Wersja       Architektura Opis
+++-==============-============-============-=================================================================
ii  openssh-server 1:8.1p1-5    amd64        secure shell (SSH) server, for secure access from remote machines

Jest to Debian testing, była informacja o jednym pakiecie z błędem, że będzie zainstalowany.

Myślę, że tu jest cały problem u mnie tej niemocy w konfiguracji. Jak poprawić instalacje tego pakietu? Była chyba tam informacja z złymi zależnościami, ale zgodziłem się na instalacje. Myślałem, że to przejdzie w konfiguracji.

Przeinstalowałem pakiet --> openssh-server
Zrobiłem restart komputera.
Po wydaniu polecenia na wirtualnej maszynie mam taki wynik:

$ cat /etc/hosts --> maszyna wirtualna
127.0.0.1    localhost
127.0.1.1    debian.Debian    debian

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Po poleceniu na hoście mam taką informacje:

$ cat /etc/hosts --> maszyna rzeczywista
127.0.0.1    localhost  debian
127.0.1.1    debian.Ptohos    debian

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Czy te polecenia Jawojx, które mam zrobić są prawidłowe przy tych aktualnych ustawieniach?
Dobrze zrobię i te informacje podam.
Obrazu ISO Debiana live nie mam.
Po wydaniu polecenia --> $ ssh -4 -vvv pto@localhost -p 4444 podaje wynik:
http://wklejaj.pl/pto4444

Ostatnio edytowany przez Ptohos (2020-01-19 11:25:34)

jawojx napisał(-a):

Jak będzie błąd, korzystaj z takiego.

Kod:

ssh -4 pto@localhost -p 4444

Przepraszam teraz mogłem usiąść przed komputerem.
Próbowałem korzystać z tego połączenia --> ssh -4 pto@localhost -p 4444
Informację zwrotną mam taką samą jak bez (-4):

$ ssh  pto@localhost -p 4444
ssh: connect to host localhost port 4444: Connection refused
i kolejne polecenie:
pto@debian:~$ ssh -4 pto@localhost -p 4444
ssh: connect to host localhost port 4444: Connection refused

i polecenie --> z dysku wirtualnego

$ ip a 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic ens3
       valid_lft 84571sec preferred_lft 84571sec
    inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic mngtmpaddr 
       valid_lft 86216sec preferred_lft 14216sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

polecenie --> z maszyny wirualnej:

# dhclient
RTNETLINK answers: File exists

następne polecenie z maszyny wirtualnej:

# lsof -i -P -n | grep 22
sshd       858        root    4u  IPv4  18694      0t0  TCP 10.0.2.15:22->10.0.2.2:53204 (ESTABLISHED)
sshd       864         pto    4u  IPv4  18694      0t0  TCP 10.0.2.15:22->10.0.2.2:53204 (ESTABLISHED)
sshd       900        root    3u  IPv4  19126      0t0  TCP *:22 (LISTEN)
sshd       900        root    4u  IPv6  19137      0t0  TCP *:22 (LISTEN)

Ostatnio edytowany przez Ptohos (2020-01-19 19:59:16)

ilin napisał(-a):

Pokaż

Kod:

iptables -L

z systemu na wirtualu.

Proszę:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Ptohos napisał(-a):

...

Kod:

# lsof -i -P -n | grep 22
sshd       858        root    4u  IPv4  18694      0t0  TCP 10.0.2.15:22->10.0.2.2:53204 (ESTABLISHED)
sshd       864         pto    4u  IPv4  18694      0t0  TCP 10.0.2.15:22->10.0.2.2:53204 (ESTABLISHED)
sshd       900        root    3u  IPv4  19126      0t0  TCP *:22 (LISTEN)
sshd       900        root    4u  IPv6  19137      0t0  TCP *:22 (LISTEN)

Coś chyba źle pokazujesz, bo tu jest prawidłowo ustanowione połączenie, przy takiej sytuacji, uruchomiona maszyna wirtualna

qemu-system-x86_64 -m 2048 -enable-kvm -net nic -net user,hostfwd=tcp::4444-:22 -hda /home/ptohos/test.qcow2

i połączenie do niej tak

ssh -4  pto@localhost -p 4444

pokaż z hosta (z roota).

lsof -i -P -n | grep 4444

Jak się nie połączy to z debugowaniem.

ssh -4 -vvv pto@localhost -p 4444

I wklej gdzieś info, jak poprzednio z połączonego prawidłowo, interesuje mnie nieprawidłowe połączenie.

A ty tu, to czasami  nie próbujesz już z wirtualnej na wirtualną, się logować.

pto@debian:~$ ssh -4 pto@localhost -p 4444
ssh: connect to host localhost port 4444: Connection refused

Edycja: No sprawdzałem teraz i tak to wygląda, bo na host-e masz ptohos@debian. Zmień sobie kolory prompt-a to nie będziesz się mieszał, albo nazwę wirtualnego, chociaż inny login już wystarcza. Pomału i uważnie bo się zamieszasz.

Ostatnio edytowany przez jawojx (2020-01-19 21:34:13)

jawojx napisał(-a):

pokaż z hosta (z roota).

Kod:

lsof -i -P -n | grep 4444

A ty tu, to czasami  nie próbujesz już z wirtualnej na wirtualną, się logować.

Wynik z hosta:

# lsof -i -P -n | grep 4444
qemu-syst 1771      ptohos   14u  IPv4  33819      0t0  TCP *:4444 (LISTEN)

Nie logowałem się z wirtualnej maszyny na wirtualną :).

Wynik polecenia --> $ ssh -4 -vvv pto@localhost -p 4444

$ ssh -4 -vvv pto@localhost -p 4444
OpenSSH_7.9p1 Debian-10+deb10u1, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "localhost" port 4444
debug2: ssh_connect_direct
debug1: Connecting to localhost [127.0.0.1] port 4444.
debug1: Connection established.
debug1: identity file /home/ptohos/.ssh/id_rsa type -1
debug1: identity file /home/ptohos/.ssh/id_rsa-cert type -1
debug1: identity file /home/ptohos/.ssh/id_dsa type -1
debug1: identity file /home/ptohos/.ssh/id_dsa-cert type -1
debug1: identity file /home/ptohos/.ssh/id_ecdsa type -1
debug1: identity file /home/ptohos/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ptohos/.ssh/id_ed25519 type -1
debug1: identity file /home/ptohos/.ssh/id_ed25519-cert type -1
debug1: identity file /home/ptohos/.ssh/id_xmss type -1
debug1: identity file /home/ptohos/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u1
ssh_exchange_identification: read: Connection reset by peer

jawojx napisał(-a):

Zmień sobie kolory prompt-a to nie będziesz się mieszał...

Nie rozumiem jak mam to zmienić i gdzie?

Ostatnio edytowany przez Ptohos (2020-01-19 22:27:41)

jawojx napisał(-a):

I teraz spróbuj połączyć się z hosta.

Kod:

ssh -4  pto@localhost -p 4444

Zrobiłem tak jak napisałeś wyżej.
Podaje wynik polecenia:

$ ssh -4  pto@localhost -p 4444
ssh_exchange_identification: read: Connection reset by peer

jawojx napisał(-a):

i po tych wszystkich próbach z wirtualnego pokaż wynik tego (cały, z roota lub z sudo).

Kod:

systemctl status ssh

Wynik polecenia --> http://wklejaj.pl/sshdeb
Wirtualna maszyna bez zalogowania (zamknięta exit)

Ostatnio edytowany przez Ptohos (2020-01-20 01:11:16)

Ptohos napisał(-a):

Błąd był taki iż w drugiej linijce tekstu było:
...
Teraz to poprawiłem. Był restart komputera i powtórzyłem całą procedure, żeby się połączyć z wirtualną maszyną przez ssh. Ale też się nie udało.

To nie był błąd, na jednym było tak, a na drugim inaczej, to nie jest błąd. My zajmowaliśmy się pierwszą linią, nie drugą.

Wynik polecenia --> http://wklejaj.pl/sshdeb

Z lokalnego się zalogowałeś, po trzech próbach, hasła nie pamiętasz? :), ale o dziwo na użytkownika ptohos, a na wirtualnym miałeś pto, no to gdzie ty tą próbę robiłeś. A próbowałeś z hosta, bo nie ma śladu po tym, są tylko lokalne.

Ja mam taką propozycję, zrobiłem livecd z serwerem ssh, iso ma 316MB, jak masz internet 100Mb/s, pobierze w mniej niż minutę, a jak masz internet około 10Mb/s to pobierze w mniej niż 5 min.

Pobierz i przetestuj na nim. Sprawdź czy masz zainstalowane wget i curl.

apt install wget curl

Pozostałe polecenia nie na root-e.
Pobierze i od razu sprawdzi sumę kontrolną po pobraniu. Zmieniają ciągle id pliku, dlatego takie pogmatwane pobieranie, a wole tak, bo obawiam się że będziesz próbował uruchomić iso w innym miejscu niż pobrałeś. Skopiuj dokładnie całe polecenie.

wget -O sshpto.iso `curl  adresisousunienty | grep sshpto.iso?t | awk 'NR==1{print $2}' | awk -F '"' '{print $2}'` ; sha512sum sshpto.iso

Jak suma kontrolna będzie się zgadzała z tym ciągiem liczb,

551b16fa3523c9f17eeaf09b14ec81a03abe3d856eecb0264a264c3c891883f227bb6e4a3682ddd8d5825d7749186600cbdfca1932104fe1919d8f0a4da6b48e

to uruchom, na minimalnie innym porcie, to nie będzie "strasznego" ostrzeżenia o innym kluczu i mniej wyjaśniania, i przydzieliłem mniej pamięci. (nie uruchamiaj jak będzie inna suma kontrolna)

qemu-system-x86_64  -m 1024   -enable-kvm  -net nic -net user,hostfwd=tcp::4445-:22 -cdrom sshpto.iso

Nie loguj się tam na wirtualnym, zostawiłem podgląd byś widział co się dzieje, poczekaj jak się uruchomi i tyle. Po uruchomieniu powiedzmy odczekaj 5s. dla przyzwoitości i z innego terminala zaloguj się przez ssh, może z wymuszeniem ip4 (nie jest to potrzebne, ale nic nie zepsuje)

ssh -4 ptossh@localhost -p 4445

hasło to dugnet

Edycja: Po skasowaniu iso z serwera usunąłem adres do niego, dla bezpieczeństwa, nie chciałem zostawiać adresu którego już nie używam i nie mam nad nim kontroli.

Ostatnio edytowany przez jawojx (2020-01-21 09:48:18)

Dobrze, skasowałem sshpto.iso z serwera.

Ptohos napisał(-a):

Jak powtórzyć pierwsze logowanie, żeby można zatwierdzić yes i podać jeszcze raz hasło. (Chce to wszystko jeszcze raz sprawdzić, czy dobrze to wcześniej zrobiłem).

To usunie wszystkie zapamiętane.

rm ~/.ssh/known_hosts

Po usunięciu będzie ponowne pytanie, tylko że to nie to, chyba że robiłeś coś poza tym, o czym tu pisaliśmy. Tylko ty wiesz co tam robiłeś na tej wirtualnej maszynie. Było sprawdzane chyba już wszystko, chyba że źle podałeś informacje, o które byłeś pytany.

Błędów przy uruchamianiu wirtualnego nie ma, widziałem na zrzutkach. Internet na wirtualnym jest, serwer ssh działa prawidłowo i nie jest blokowany na firewallu, dopuszczony na hosts.allow (na wszelki wypadek, bo przy normalnych ustawieniach nie jest to wymagane, na iso tego nie było), dodane zostały wpisy do hosts, by nie było problemu z localhost. Usługa jest dostępna na 22 wirtualny i prawidłowo przekierowana na hosta port 4444, sam widziałeś że to działa. Chyba nic nie gmerałeś w configu serwera ssh?, mało prawdopodobne nic o tym nie było pisane.