Forum Debian Users Gang

Moze ja cos zle rozumiem..

root@192.168.11.111's password:

W powyzszym oprogramowanie domaga sie odemnie zebym sie uwiarygodnil haslem zeby korzystac z tunelu SSH.

Tutaj:

ssh: connect to host 127.0.0.1 port 22: Connection refused

Odmawia mi polaczenia, dlaczego ?

Wyedytowalem plik konfigu.
PORT NA 5522.
PermitRootLogon yes

#    $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 5522
#AddressFamily any
#ListenAddress 0.0.0.0
# ListenAddress 192.168.11.111

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile    .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem    sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server

Przeladowalem:

sudo systemctl restart ssh.service

Wylaczylem firewalla:

systemctl status netfilter-persistent
● netfilter-persistent.service - netfilter persistent configuration
   Loaded: loaded (/lib/systemd/system/netfilter-persistent.service; enabled; ve
   Active: inactive (dead) since Tue 2022-04-26 10:42:04 IST; 24s ago
  Process: 275 ExecStart=/usr/sbin/netfilter-persistent start (code=exited, stat
  Process: 19283 ExecStop=/usr/sbin/netfilter-persistent stop (code=exited, stat
 Main PID: 275 (code=exited, status=0/SUCCESS)
      CPU: 7ms

root@debian:~# ssh -p 5522 debian@127.0.0.1
debian@127.0.0.1's password: 
Permission denied, please try again.

root@debian:~# ssh debian@192.168.11.111 -p 5522
debian@192.168.11.111s password: 
Permission denied, please try again.
debian@192.168.11.111's password: 
Permission denied, please try again.
debian@192.168.11.111's password: 
debian@192.168.11.111: Permission denied (publickey,password)

Lista zajetych portow:

netstat -tunlep | grep LISTEN | awk '{print $4}'
127.0.0.53:53
127.0.0.1:8118
127.0.0.1:631
127.0.0.1:25
0.0.0.0:5355
0.0.0.0:5522
::1:8118
::1:631
::1:25
:::5355
:::5522

Dlaczego mam odmowe polaczenia i dlaczego na porcie 22 ?

root@debian:~# ssh -f -N -D 0.0.0.0:1080 localhost
ssh: connect to host localhost port 22: Connection refused

Jezeli otwieram tunel bedac zalogowany jako root - to podaje haslo roota, tak?
Jezeli otwieram tunel bedac zalogowany jako user - to podaje haslo usera, tak?
Kiedy podaje haslo utworzone podczas tworzenia kluczy RSA ?

Napiszcie prosze ze 2 madre zdania zeby mi sie to ulozylo w glowie.
Moze ktos podesle plik konfigu sshd, moglbym sobie analizowac na spokojnie.

Ostatnio edytowany przez Karoll (2022-04-26 12:54:40)

@rulezdc
Moglem dodac reguly protokolu tcp zeby przepuszczal SSH np.

iptables -A INPUT -s 192.168.1.111 -m state --state NEW -p tcp --dport 5522 - j ACCEPT

Wylaczylem go jednak calkowicie zeby nie bylo watpliwosci.
Link ktory podales jest wartosciowy ale kompletnie nie odpowiada na moje pytania.
Nadal nie rozumiem kiedy uzywac:
- hasel uzytkownikow systemu (roota i usera)
- kiedy uzywac hasla utworzonego przy okazji kreacji kluczy RSA ?

No tam połączenie było debian@127.0.0.1 czyli próbujesz się logować na użytkownika debian a nie root. Więc hasło od konta debian powinieneś wpisać, jeśli takie w ogóle masz.

Po wydaniu polecenia ssh, hasło wpisujesz do tego systemu (i jego użytkownika), do którego się łączysz, a nie hasło do systemu (i jego user'a), z którego to polecenie wydajesz, przykład:

maszyna lokalna z klientem ssh > odpalasz na niej terminal i widzisz prompt (nie musi być z roota, może być ze zwykłego user'a) > chcesz się zalogować, np. na użytkownika root, na maszynie co ma w sieci adres IP 192.168.1.120 > wpisujesz ssh root@192.168.1.120 > wyskakuje ci prośba o podanie hasła > podajesz hasło do root'a (bo root stoi przed @), który jest skonfigurowany na zdalnej maszynie.

Tu masz info o tym adresie 0.0.0.0.

A co do samego polecenia to wygląda na jakiś SSH port forwarding. Tutaj masz przykład użytkowy z zastosowania tego mechanizmu. xD

Nie działa bo to był jedynie przykład zastosowania SSH port forwarding'u.

Tam miałeś w tekście wyjaśnienie co to polecenie robi.

-L 12345:localhost:80 -- Jeden koniec tunelu będzie na interfejsie pętli zwrotnej naszego komputera na porcie 12345 . Natomiast drugi koniec na pętli zwrotnej routera, z tym, że na porcie 80 .
root@192.168.1.235 -- user root, adres 192.168.1.235 serwera SSH
-p 22 -- port serwera SSH.

Masz to opisane w man ssh:

-L [bind_address:]port:host:hostport
     -L [bind_address:]port:remote_socket
     -L local_socket:host:hostport
     -L local_socket:remote_socket
             Specifies that connections to the given TCP port or Unix socket on the local (client) host are to
             be forwarded to the given host and port, or Unix socket, on the remote side.  This works by allo‐
             cating a socket to listen to either a TCP port on the local side, optionally bound to the speci‐
             fied bind_address, or to a Unix socket.  Whenever a connection is made to the local port or
             socket, the connection is forwarded over the secure channel, and a connection is made to either
             host port hostport, or the Unix socket remote_socket, from the remote machine.

             Port forwardings can also be specified in the configuration file.  Only the superuser can forward
             privileged ports.  IPv6 addresses can be specified by enclosing the address in square brackets.

             By default, the local port is bound in accordance with the GatewayPorts setting.  However, an ex‐
             plicit bind_address may be used to bind the connection to a specific address.  The bind_address
             of “localhost” indicates that the listening port be bound for local use only, while an empty ad‐
             dress or ‘*’ indicates that the port should be available from all interfaces.

To ssh -L 12345:localhost:80 root@192.168.1.235 -p 22 jest całe polecenie. Frazę użytkownika, adres i port wpisujesz zawsze, by system wiedział gdzie słać pakiety sieciowe (do jakiej maszyny w sieci). Flaga -L precyzuje korzystanie z forwarding'u. Jak zostanie użyta, to np. w netstat będziesz miał taki wpisy na maszynie, na której to polecenie wydasz:

╰─[0] < > #  netstat -napletu  | egrep -i "12345"
tcp        0      0 127.0.0.1:12345         0.0.0.0:*               LISTEN      1000       10978332   1181627/ssh
tcp        0      0 127.0.0.1:55326         127.0.0.1:12345         ESTABLISHED 1000       11338123   1211196/firefox
tcp        0      0 127.0.0.1:12345         127.0.0.1:55326         ESTABLISHED 1000       11338760   1181627/ssh     -

Teraz po wpisaniu w przeglądarce w pasku adresu 127.0.0.1:12345, ta przeglądarka będzie przesyłać pakiety do lokalnego demona ssh, bo w parametrze -L było 12345:localhost (ten drugi port, tj. :80 nas póki co nie interesuje). W ten sposób wszystkie pakiety z maszyny lokalnej przeznaczone na 127.0.0.1:12345, polecą do lokalnego demona ssh, bo to on na tym adresie i porcie nasłuchuje. Tam na maszynie zdalnej, pakiety zostaną odebrane przez demona ssh (na adresie 192.168.1.235 i na porcie 22), po czym zostaną przez demona ssh przekierowane (w oparciu o parametr -L, tj. localhost:80), tak, by te pakiety trafiły do celu, tj. na adres 127.0.0.1:80, na którym np. może nasłuchiwać panel webowy routera, którego nie chcemy udostępniać w sieci każdemu. Na tej maszynie zdalnej będziesz miał dodatkowe wpis w postaci:

root@RedViper:~# netstat -napletu | egrep -i ":80"

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2616/uhttpd
tcp        0      0 :::80                   :::*                    LISTEN      2616/uhttpd
tcp        0      0 ::1:43594               ::1:80                  ESTABLISHED 14485/dropbear
tcp        0      0 ::1:80                  ::1:43594               ESTABLISHED 2616/uhttpd

Ten dropbear to taki serwer ssh dla routerów. xD Tutaj masz połączenie dropbear'a z uhttpd, czyli serwerem www, na którym jest panel webowy routera.

Jak byś zerwał tunel (zamknął terminal po wydaniu ssh -L 12345:localhost:80 root@192.168.1.235 -p 22), to wtedy znikną te dodatkowe wpisy z netstat, i próba odwiedzenia adresu 127.0.0.1:12345 na lokalnej maszynie zwróci błąd, bo lokalnie nic na tym adresie i porcie już nie nasłuchuje i nie ma co przekazać tych pakietów do zdalnego serwera SSH, gdzie mogłyby zostać odebrane i przetworzone zgodnie z ustalonymi instrukcjami

To chyba tyle. xD

Ostatnio edytowany przez morfik (2022-04-28 20:09:35)

Popatrz sobie po portach w netstat, np. firefox miał połączenie o lokalnej końcówce 127.0.0.1:55326 (ten duży port jest dobierany losowo przy zestawianiu połączenia przez aplikację inicjującą połączenie), zaś zdalna końcówka to 127.0.0.1:12345 (tu port jest tym co stało w parametrze -L w poleceniu ssh). Z kolei w netstat wpis z ssh ma porty odwrotne, tj. jako lokalną końcówkę połączenia ma 127.0.0.1:12345, a zdalną 127.0.0.1:55326 i między tymi procesami odbywa się wymiana informacji via pakiety sieciowe TCP/IP w obrębie jednej maszyny, na jej pętli zwrotnej. Jak już do demona ssh dotrą pakiety od firefox'a (na tej lokalnej maszynie), to potem demon ssh przesyła te pakiety do zdalnej maszyny i tam po odebraniu ich przez zdalnego demona ssh, ten proces jest odwracany, co widać po analogicznych wpisach w netstat na zdalnej maszynie.

Włącz logowanie na root w konfiguracji serwera ssh co było podane w jednym z pierwszych postów...

Mam nadzieje, ze dla mojego laptopa dzialajacego glownie w sieci WiFi,w sieciach publicznych, takie zabezpieczenie:
HTTPS + SSH (np)

ssh root@192.168.0.45 -D 8888

plus oczywiscie odpowiednia konfiguracja ustawien sieciowych Firefoxa
dla trafficu: bank, office, email - bedzie wystarczajacym zabezpieczeniem.

Poczytalem sporo, majac nadzieje, ze nie bede musial naduzywac Waszej uprzejmosci, ale nie jestem pewien czy do konca dobrze rozumiem, jakie sa przyczyny i skutki uzycia na koncu komendy otwierajacej tunel 2 nastepujacych sformulowan:

localhost

oraz

127.0.0.1

Dlaczego sam adres IP nie wystarcza ?

Nieporozumienie, wiem, ze 127.0.0.1 to tzw adres zwrotny, loopback, gdzie uslugi "gadaja ze soba" jest virtualny, opowiada zakres adresów ::1/128, czyli wyłącznie jeden adres,
ip addr show dev lo

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

1 Pytanie: czy dla komendy,

ssh .......

jest bez znaczenia czy zastosuje w niej ?
adresacje

127.0.0.1

czy verbalnie

localhost

Jezeli obydwa rozwiazania dzialaja, to dlaczego sa 2 rozwiazania a nie jedno ?