Igen sok rövidítés került a címbe. Ezek egy része algoritmus, más része hash függvény vagy protokoll. A teljesség igénye nélkül vegyük sorra őket, hiszen ezekkel találkozhatunk a mindennapi életben.
A DES (Data Encryption Standard) illetve a Triple DES és az AES (Advanced Encryption Standard) ún. szimmetrikus kulcsú vagy “titkos kulcsú” algoritmusok. Ez azt jelenti, hogy minden félnek ismernie kell a kulcsot, mind a titkosításhoz, mind a dekódoláshoz. Ez a fő hibájuk egyébként. A DES már történelem. Több mint 20 éve feltörték. 🙂 Az AES algoritmus a WPA2-ben (Wi-Fi Protected Access) használatos, még ma is biztonságosan működik. A Blowfish pedig az egyik első biztonságos blokk-kódoló – szimmetrikus – algoritmus. Ma már az AES népszerűbb.
Vannak az előzőekkel szemben az ún aszimmetrikus kulcsú vagyis nyilvános kulcsú titkosító algoritmusok. Ez a korszerű és a biztonságos(abb) egyébként. Itt kulcspárt generálunk, és a fogadó fél a privát kulcsommal kódolt üzenetemet a rendelkezésére bocsájtott nyilvános kulcsommal tudja elolvasni, és vica versa. Ilyen megoldások az RSA (Rivest–Shamir–Adleman) és a DSA (Digital Signature Algorithm) algoritmusok. Az RSA széles körben elterjedt titkosított adatátvitelhez.
Aztán nézzük meg az MD4-et illetve az MD5-öt (Message-Digest algorithm 5). Ezek egyirányú kódoló algoritmusok. Mára elavultak, ezért az SHA-2 (Secure Hash Algorithm 2) váltotta ki őket. Linux alatt a jelszók kódolására használják ezt a fajta titkosítást. Csak azt lehet ellenőrizni, hogy a két kódolt karaktersorozat egyezik-e, ezért nem lehet egy elfelejtett jelszót “megmondani”. 🙂 A bitcoin kriptovaluta pl. a SHA-2 családba tartozó SHA-256 kriptografikus hash függvényt használja többek között blokk-láncai kódolásához is. A hash függvény matematikai fogalom, egy értékkészletet képez le egy szignifikánsan (jelentősen) kisebb értéktartományra.
És akkor még itt van az RC4 (Rivest Cipher 4). Ez folyam kódoló, de sajnos olyan törhető titkosításokhoz használták, mint a WEP (Wired Equivalent Privacy). Ezt ma már nem használjuk még véletlenül sem. Volt még ilyen gyermekbetegség-kódolás, a TKIP (Temporal Key Integrity Protocol). Azt sem fejlesztették tovább. 🙂
A TSL-t az a bizonyos “https://” kezdetű rész használja a böngészőnkben a weszerverrel való kommunikációban – fontos eleme a “kézfogás” (handshaking) -, a PGP pedig egy titkos levelezésnél hasznos. 🙂
Egy informatikai biztonsággal foglalkozó kollégám mondta egyszer nekem, hogy informatikai biztonság nem létezik. Csak a vasbeton trezorban a konnektorból is kihúzott számítógép, fegyveres őrrel az ajtóban. És valóban. Mit ér mindez, ha a felhasználó hibájából van a notebook-ban egy cetli a jelszóval. 🙂
A mentés a nagyon fontos gyakorlati rendszergazdai teendő. Az informatika egyik alaptétele a következő: ha egy adat csak egy helyen van meg, az nincsen (!).
Ezért fontos mentési stratégiát kialakítani egy szerver, de akár a desktop gépünk, illetve hordozható eszközünk esetében is! Tiszteljük meg annyira saját magunkat, hogy saját munkáinkat, adatainkat, leveleinket, kapcsolatainkat, etc. legalább lementjük egy fizikailag különböző helyre időközönként! Erre szolgál egyébként a felhő is. Azonban nem minden esetben kifizetődő a használata! Egyébként pl. az ownCloud felhőt mi is telepíthetjük. Lehet saját felhőnk is!
Nézzük azonban a klasszikus backup-ot, mondjuk egy kódolt hálózatit.
A szeptember 16-ai írásomban az SSH-ról leírtam a publikus kulccsal hitelesített jelszó nélküli kapcsolatot. Ez tökéletes alap egy hálózati mentéshez. Hirtelen két stratégia is eszembe jut.
A távoli szerveren fut egy ún. cron job, a felhasználói crontab-ban – ez egy ütemezett feladatot jelent – mondjuk naponta. Egy script. ami ún. .tar.gz vagy .tgz tömörített állományt (archívumot) hoz létre – ez a Linux/UNIX rendszerek saját ZIP megoldása – a menteni kívánt könyvtárból, természetesen rekurzívan. Futhat pl. hajnai 3-kor. Hajnali fél négykor pedig a helyi gépünkön, ahova mentünk, lefut egy másik script, ami scp-vel, jelszó nélküli átvitelben átmásolja, “letölti” a tömörített állományt. 🙂
A második megoldásban az “ssh” parancs segítségével a távoli gépen – amiről a mentést készítjük – egy scriptet futtatunk, amiben tömörítjük a menteni kívánt könyvtárat a “tar czvf <archívum_időbélyeg.tgz> <könyvtár>” paranccsal vagy a tar és a gzip parancsok kombinációjával (tar cvo <könyvtár> | gzip – > <archívum_időbélyeg.tar.gz>), ezt követően pedig scp-vel átmásoljuk a helyi gépünkre. Ezt elég lesz helyileg ütemeznünk, de akár kézzel is indíthatjuk. 🙂
Látható, hogy nem ördöngősség a mentés. Jóllehet azért nagyon nagy mennyiségű adat mentésénél már több eszközre van szükségünk, mint egy-két Linux parancs. 🙂
Meg kell említsem még a bzip2-t, mint egy újabb, és hatékonyabb tömörítő algoritmust használó tömörítő programcsomagot (https://www.sourceware.org/bzip2/). Általában igaz, hogy a tar archivál, a gzip és a bzip2 pedig tömörítenek. Ma már a bzip2 is alapból telepítve van egy Linux-on, sőt tar-ból is elérhető a “-j, –bzip2” kapcsolóval. Az alábbi linken található még néhány hasznos információ az archiválásról.
A Linux gépeken már régi téma a tűzfal. A tűzfal arra való, hogy védelmet nyújtson a magánhálózatoknak illetve a számítógépeknek az Interneten garázdálkodó rosszakaratú támadók ellen. Éppen ezért beszélhetünk hálózat-biztonságról – erről nálam itthon a router-en lévő tűzfal gondoskodik -, illetve hoszt-biztonságról, ami a Linux notebookom-on van telepítve. Ma már általában egyszerűek a beállítások, mind hálózati, mind hoszt szinten. Debian 10 alatt már automatikus az alap tűzfal-konfiguráció.
Régebben az ipchains volt, ma már az ún. iptables van használatban. Nézzük meg a Linux-unkat!
root@gergo1:~# iptables -L -v Chain INPUT (policy DROP 590 packets, 93015 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh 256 20230 ACCEPT all -- lo any anywhere anywhere 6008 2038K ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 ACCEPT tcp -- any any 192.168.0.0/24 anywhere state NEW tcp dpt:netbios-ns 0 0 ACCEPT tcp -- any any 192.168.0.0/24 anywhere state NEW tcp dpt:netbios-dgm 0 0 ACCEPT tcp -- any any 192.168.0.0/24 anywhere state NEW tcp dpt:netbios-ssn 0 0 ACCEPT tcp -- any any 192.168.0.0/24 anywhere state NEW tcp dpt:microsoft-ds 0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-request 6 336 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 6272 packets, 1041K bytes) pkts bytes target prot opt in out source destination 256 20230 ACCEPT all -- any lo anywhere anywhere
Látható, hogy a bemeneten (INPUT) az SSH szerver, a Samba szerver (Microsoft hálózathoz) és a HTTP szerver van engedélyezve + az ICMP ping (leírása később), továbbá természetesen a már létrejött kapcsolatok is. Forward szinten semmi sincs “átengedve”. Nem továbbítunk adatot hálózatok között. Kimeneten (OUTPUT) pedig mindent “kiengedünk”.
Hogy hol van beállítva? Van egy pici konfigurációs file a /etc alatt.
root@gergo1:~# cat /etc/network/iptables.up.rules # Generated by iptables-save v1.6.0 on Sat Aug 26 03:40:19 2017 *filter :INPUT DROP [9:1026] :FORWARD DROP [0:0] :OUTPUT ACCEPT [22:3482] -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -o lo -j ACCEPT # # added by gvamosi on 2019-06-07 # -A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 137 -j ACCEPT -A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 138 -j ACCEPT -A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 139 -j ACCEPT -A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 445 -j ACCEPT -A INPUT -p icmp --icmp-type echo-request -j ACCEPT # # added by gvamosi on 2019-09-22 # -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT # COMMIT # Completed on Sat Aug 26 03:40:19 2017
És hogyan “töltődik be”? Az ún. init script-ek között kell keresnünk a választ (leírásuk később).
Ez a kicsi init script tölti be a rendszer elindulásakor a tűzfal konfigurációját az iptables-restore parancs segítségével. Ennyi az egész. 🙂
Írhatnánk még az ún. DMZ (Demilitarizált Zóna) fogalmáról is. Ez egy olyan terület egy cégnél pl., ahonnan szerverek “kifelé”, a nagyvilágba, azaz az Internet felé is látszódhatnak. Határzóna a belső, védett, és a külső, védtelen hálózat között.
Telepítettem a napokban régi jó szoftvercsomagomat, az nmap-et is. Beszéltünk róla, hogy Linux alatt 0-65535-ig (2^16-1) számozottak a portok. Egy port lehet TCP (Transmission Control Protocol – kapcsolatorientált, byte-stream jellegû, megbízható protokoll, pl. “on-demand” kép- és hangátvitel, letöltés, mivel a TCP egy megbízható protokoll, újra küldi az “elveszett” csomagokat) vagy UDP (User Datagram Protocol – összeköttetésmentes protokoll, pl. élő kép- és hangátvitel, online játékok – hibaellenőrzés és csomag újraküldés nélküli “kis adatcsomagocskák”).
Miután kapcsolódtunk a böngészőnkkel pl. a HTTP 80-as szerverportra, egy ún. “socket” nyílik a szerveren, és a kliens egy 1024-nél magasabb portszámmal kapcsolódik. Ez minden hálózati szolgáltatásnál ugyanígy működik.
Felmerülhet a kérdés, hogy mennyi kliens-szerver kapcsolat lehetséges. Egy kliens max. 65535 kapcsolatot nyithat egy szerverre, de egy szerver 65535 kapcsolatot tarthat fent kliensenként! Határ a memória és a cpu! 🙂
Az alábbiakban egy nem teljeskörű lista látható az alapvető Linux (UNIX) portokról. Az 1024-nél alacsonyabb portszámok a root (rendszergazda) felhasználóhoz kötöttek. A portok többsége TCP.
20 – FTP Data (FTP adatátvitel) 21 – FTP Control (FTP kapcsolat indítása) 22 – SSH (biztonságos távoli adminisztráció, SSL-lel kódolt csatornán) 23 – Telnet (kódolatlan távoli adminisztráció) 25 – SMTP (Mail Transfer Agent, e-mail szerver, mint pl. SEND mail) 53 – DNS (TCP és UDP is) 67 – Bootp 68 – DHCP 69 – TFTP (Trivial file transfer protocol, UDP, "kapcsolat nélküli" adatátvitel) 80 – HTTP/WWW(Apache) 88 – Kerberos 110 – POP3 (Mail delivery Agent) 123 – NTP (Network time protocol idő szinkronizálásra, UDP) 137 – NetBIOS (nmbd) 139 – SMB-Samba (smbd) 143 – IMAP 161 – SNMP (hálózatfelügyelet) 389 – LDAP (központi adminisztráció) 443 – HTTPS (HTTP+SSL biztonságos web elérés) 514 – Syslogd (UDP port) 636 – ldaps (TCP és UDP is) 873 – rsync 989 – FTPS-data 990 – FTPS 993 – IMAPS 1194 – openVPN 1812 – RADIUS 995 – POP3s 2049 – NFS (nfsd, rpc.nfsd, rpc, portmap) 2401 – CVS server 3306 – MySql 3690 – SVN 6000-6063 – X11
A hálózatokat leíró ún. ISO-OSI referenciamodellről az alábbi linkek alatt olvashatunk részleteket. Jól látható az a bizonyos hét réteg, melyen keresztül minden hálózati kapcsolat megvalósul. Az SSH szolgáltatás – ahogy a többi is – az alkalmazási (7-es) réteg része, de minden bitje átmegy a fizikai (1-es) rétegen!
Az nmap segítségével egy szerverről kideríthető, hogy mely portokon vannak szolgáltatások telepítve. Eresszünk rá egy egyszerű scan-t a localhost-ra! 🙂
gvamosi@gergo1:~$ nmap -A -T4 localhost Starting Nmap 7.70 ( https://nmap.org ) at 2019-09-19 10:09 CEST Nmap scan report for localhost (127.0.0.1) Host is up (0.00013s latency). Other addresses for localhost (not scanned): ::1 Not shown: 996 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.9p1 Debian 10 (protocol 2.0) | ssh-hostkey: | 2048 5f:9c:30:d8:aa:23:5a:d2:8b:52:ff:22:cf:c0:ae:6d (RSA) | 256 3e:25:ef:3e:78:88:07:47:8d:76:67:ce:91:dc:8d:d4 (ECDSA) |_ 256 d6:8f:00:80:43:8a:c7:05:dc:b4:2b:de:96:c3:12:fb (ED25519) 80/tcp open http Apache httpd 2.4.38 ((Debian)) |_http-server-header: Apache/2.4.38 (Debian) |_http-title: Apache2 Debian Default Page: It works 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 4.9.5-Debian (workgroup: WORKGROUP) Service Info: Host: GERGO1; OS: Linux; CPE: cpe:/o:linux:linux_kernel Host script results: |clock-skew: mean: -40m00s, deviation: 1h09m16s, median: 0s |_nbstat: NetBIOS name: GERGO1, NetBIOS user: , NetBIOS MAC: (unknown) | smb-os-discovery: | OS: Windows 6.1 (Samba 4.9.5-Debian) | Computer name: gergo1 | NetBIOS computer name: GERGO1\x00 | Domain name: \x00 | FQDN: gergo1 | System time: 2019-09-19T10:10:03+02:00 | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb2-security-mode: | 2.02: |_ Message signing enabled but not required | smb2-time: | date: 2019-09-19 10:10:03 |_ start_date: N/A Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.11 seconds
Látható, hogy a 22-es, 80-as, 139-es és 445-ös portokon találhatóak “nyílt” portok. Ezt tudhatom fejből is, mivel SSH szervert, HTTP szervert, és Windows-os ún. Samba szervert telepítettem, a hálózaton lévő Windows-os gépekkel való adatátvitelhez. 🙂
Végül nézzünk meg egy még egyszerűbb portszkent! (Figyelem: bizonyos szkenek – pl. UDP – root hozzáférést igényelnek.) 🙂
gvamosi@gergo1:~$ nmap localhost Starting Nmap 7.70 ( https://nmap.org ) at 2019-09-19 10:39 CEST Nmap scan report for localhost (127.0.0.1) Host is up (0.00013s latency). Other addresses for localhost (not scanned): ::1 Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 139/tcp open netbios-ssn 445/tcp open microsoft-ds Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds
Végül nézzük meg a netstat parancs kimenetelét (miután a net-tools-t felinstalláltuk). A netstat minden hálózati kapcsolatot feltérképez. Jól láthatóak a https kapcsolatok és az ún. ephemeral portok kliens (gergo1) oldalon. Ezek magasabb portszámok – és nálam sok tab van nyitva a Chrome-ban. 🙂
root@gergo1:~# apt-get install net-tools .. root@gergo1:~# logout gvamosi@gergo1:~$ netstat Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 gergo1:44450 13.94.251.244:https ESTABLISHED tcp 0 171 gergo1:44860 109.233.153.16:https FIN_WAIT1 tcp 0 0 gergo1:57636 ws-in-f188.1e100.n:5228 ESTABLISHED tcp 0 1 gergo1:58322 40.68.210.8:https FIN_WAIT1 tcp 0 1 gergo1:50668 wo-in-f188.1e100.n:5228 FIN_WAIT1 tcp 0 0 gergo1:56840 104.16.190.66:https ESTABLISHED tcp 0 1 gergo1:44206 13.94.251.244:https FIN_WAIT1 tcp 0 1 gergo1:52762 13.94.112.175:https FIN_WAIT1 tcp 0 0 gergo1:40996 68.232.34.200:https ESTABLISHED tcp 0 0 gergo1:60478 e1-ha.ycpi.via.ya:https ESTABLISHED tcp 0 0 gergo1:48022 52.114.158.92:https TIME_WAIT tcp 0 1 gergo1:51022 13.107.3.128:https FIN_WAIT1 .. tcp 0 0 gergo1:59514 edge-star-shv-01-:https ESTABLISHED tcp 0 0 gergo1:51986 xx-fbcdn-shv-01-v:https ESTABLISHED tcp6 0 0 192.168.0.109:45541 13.69.158.96:https ESTABLISHED tcp6 0 74 192.168.0.109:41903 13.69.158.96:https FIN_WAIT1 udp 0 0 gergo1:40680 prg02s12-in-f10.1e1:443 ESTABLISHED udp 0 0 gergo1:40731 bud02s28-in-f8.1e10:443 ESTABLISHED udp 0 0 gergo1:41421 bud02s26-in-f14.1e1:443 ESTABLISHED udp 0 0 gergo1:33400 wn-in-f189.1e100.ne:443 ESTABLISHED udp 0 0 gergo1:41687 bud02s27-in-f2.1e10:443 ESTABLISHED udp 0 0 gergo1:33916 bud02s26-in-f14.1e1:443 ESTABLISHED udp 0 0 gergo1:54408 wb-in-f189.1e100.ne:443 ESTABLISHED udp 0 0 gergo1:38164 muc03s07-in-f99.1e1:443 ESTABLISHED udp 0 0 gergo1:47052 muc03s07-in-f110.1e:443 ESTABLISHED udp 0 0 gergo1:52313 ham02s13-in-f14.1e1:443 ESTABLISHED Active UNIX domain sockets (w/o servers) Proto RefCnt Flags Type State I-Node Path unix 2 [ ] DGRAM 32111 /var/lib/samba/private/msg.sock/1547 unix 2 [ ] DGRAM 31112 /var/lib/samba/private/msg.sock/1602 unix 3 [ ] DGRAM 11603 /run/systemd/notify unix 19 [ ] DGRAM 11622 /run/systemd/journal/dev-log unix 7 [ ] DGRAM 11635 /run/systemd/journal/socket unix 2 [ ] DGRAM 11664 /run/systemd/journal/syslog unix 2 [ ] DGRAM 23637393 /run/wpa_supplicant/p2p-dev-wlp2s0 ..
Sőt, így a végére még UNIX domain socket-ek is jutnak. 🙂 Ezek file alapú IPC (inter-process communication) socket-ek. 🙂
Két Linux/UNIX alapú számítógép között a biztonságos kapcsolatot, titkosított adatátvitelt az úgynevezett secure shell, azaz ssh kapcsolat jelenti. Alapvetően kliens-szerver kapcsolat, és rémesen egyszerű, ha az ember egyszer ráérez.
Először is felfedeztem, hogy az sshd, ssh daemon – vagyis a szerver – nincs installálva a Debian 10-em alatt. No ezen könnyű volt segíteni. Debian alatt alapvetően az apt-get install paranccsal lehet valamit telepíteni (rendszergazdaként). Kapásból legenerálja a szükséges kulcsokat, úgyhogy nem sok dolog van vele. 🙂
root@gergo1:~# apt-get install ssh Reading package lists… Done Building dependency tree Reading state information… Done The following additional packages will be installed: openssh-server openssh-sftp-server Suggested packages: molly-guard monkeysphere rssh ssh-askpass ufw The following NEW packages will be installed: openssh-server openssh-sftp-server ssh 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 599 kB of archives. After this operation, 1,829 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://cdn-fastly.deb.debian.org/debian buster/main amd64 openssh-sftp-server amd64 1:7.9p1-10 [44.6 kB] Get:2 http://cdn-fastly.deb.debian.org/debian buster/main amd64 openssh-server amd64 1:7.9p1-10 [352 kB] Get:3 http://cdn-fastly.deb.debian.org/debian buster/main amd64 ssh all 1:7.9p1-10 [202 kB] Fetched 599 kB in 2s (388 kB/s) Preconfiguring packages … Selecting previously unselected package openssh-sftp-server. (Reading database … 488002 files and directories currently installed.) Preparing to unpack …/openssh-sftp-server_1%3a7.9p1-10_amd64.deb … Unpacking openssh-sftp-server (1:7.9p1-10) … Selecting previously unselected package openssh-server. Preparing to unpack …/openssh-server_1%3a7.9p1-10_amd64.deb … Unpacking openssh-server (1:7.9p1-10) … Selecting previously unselected package ssh. Preparing to unpack …/ssh_1%3a7.9p1-10_all.deb … Unpacking ssh (1:7.9p1-10) … Setting up openssh-sftp-server (1:7.9p1-10) … Setting up openssh-server (1:7.9p1-10) … Creating config file /etc/ssh/sshd_config with new version Creating SSH2 RSA key; this may take some time … 2048 SHA256:dOGw/PajE/BBgatmagHg384uQbysjJY2wr6m8WCkfus root@gergo1 (RSA) Creating SSH2 ECDSA key; this may take some time … 256 SHA256:j8q+pBRwTqbiAvP1X4pL+pHUj7G4aoojCBGv7FYqWIE root@gergo1 (ECDSA) Creating SSH2 ED25519 key; this may take some time … 256 SHA256:yn8li9pazT1UXV3T+gmo44boWeJU1S6HA7bKDgVpKc0 root@gergo1 (ED25519) Created symlink /etc/systemd/system/sshd.service → /lib/systemd/system/ssh.service. Created symlink /etc/systemd/system/multi-user.target.wants/ssh.service → /lib/systemd/system/ssh.service. rescue-ssh.target is a disabled or a static unit, not starting it. Setting up ssh (1:7.9p1-10) … Processing triggers for man-db (2.8.5-2) … Processing triggers for systemd (241-5) …
Aztán az első “belépés” OS X-ről az ssh paranccsal. A Linux gép ip címe 192.168.0.109, lekérdezni command prompt-ból OS X alatt az “ifconfig“, Debian alatt az “ip addr“, illetve az “ip a” paranccsal lehet. Természetesen a hálózatban “belső ip címeket” használunk, az összes gép “tűzfal mögött” van. 🙂
Mac-mini:~ gvamosi$ ssh 192.168.0.109 The authenticity of host '192.168.0.109 (192.168.0.109)' can't be established. ECDSA key fingerprint is SHA256:j8q+pBRwTqbiAvP1X4pL+pHUj7G4aoojCBGv7FYqWIE. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.109' (ECDSA) to the list of known hosts. gvamosi@192.168.0.109's password: Linux gergo1 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Sep 4 07:08:30 2019 gvamosi@gergo1:~$
Ezek után a w (who is) paranccsal megnézhetjük a bejelentkezetteket.
gvamosi@gergo1:~$ w 18:21:32 up 2 days, 7:36, 2 users, load average: 0.33, 0.60, 0.61 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT gvamosi tty2 tty2 Sat10 2days 1:24m 0.64s /opt/google/chrome/chrome --type=renderer --field-trial-handle=15503761646981189628,17074726826077816693,131072 --lang=en-US --enable-auto-reload gvamosi pts/1 192.168.0.113 18:21 10.00s 0.00s 0.00s -bash
Látható, hogy a pts/1-en a 192.168.0.113-as IP címről van egy belépett “távoli” felhasználónk. 🙂
És akkor nézzük meg azt a trükköt, hogy ne kérjen többet jelszót, és másoljunk át scp-vel egy file-t. Ezt ezután akár egy automatikus processz (tipikusan egy script) is elvégezheti, pl. mentés – backup – céljából. Ezekről a későbbiekben írok majd bővebben. 🙂
Mac-mini:~ gvamosi$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/Users/gvamosi/.ssh/id_rsa): /Users/gvamosi/.ssh/id_rsa already exists. Overwrite (y/n)? y Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/gvamosi/.ssh/id_rsa. Your public key has been saved in /Users/gvamosi/.ssh/id_rsa.pub. The key fingerprint is: SHA256:8DpEyLqQO78UnwTlsbdhjxklU7o459DqmUC84Pc6jVs gvamosi@Mac-mini.local The key's randomart image is: +---[RSA 2048]----+ | o o.o | | + + = | | . = O | | o o * @ | |+ = = O S | |.= * O . | |o.=.*E+ | | +.=o+ . | | o+B. | +----[SHA256]-----+ Mac-mini:~ gvamosi$ less .ssh/id_rsa.pub Mac-mini:~ gvamosi$ ssh 192.168.0.109 gvamosi@192.168.0.109's password: Linux gergo1 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Sep 16 17:40:12 2019 from 192.168.0.113 gvamosi@gergo1:~$ vi .ssh/authorized_keys gvamosi@gergo1:~$ logout Connection to 192.168.0.109 closed. Mac-mini:~ gvamosi$ ssh 192.168.0.109 Linux gergo1 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Sep 16 17:42:13 2019 from 192.168.0.113 gvamosi@gergo1:~$ logout Connection to 192.168.0.109 closed. Mac-mini:~ gvamosi$ scp ownCloud/Photos/San\ Francisco.jpg 192.168.0.109: San Francisco.jpg 100% 211KB 211.0KB/s 00:00 Mac-mini:~ gvamosi$
Mi is történik? Először kulcsot kenerálunk OS X alatt az ssh-keygen paranccsal. Aztán a publikus rsa kulcsot (RSA: Rivest-Shamir-Adleman – titkosítási rendszer nyilvános kulcsú titkosításhoz, bemutatása később) átmásoljuk a Linux “szerverre” az authorized_keys file-ba.
Utána csodák csodája már nem kér jelszót. 🙂
Ezután scp-vel átmásoljuk a “San Francisco.jpg” file-t.
Keress pénzt Linux-szal - Vámosi Gergely TechBlog - Alkoss Linux alatt :) 
Hozzászóláshoz be kell jelentkezni!