Titkosítás, DES, AES, Blowfish, MD4, MD5, SHA-2, RSA, DSA, RC4, TKIP, WEP, WPA, WPA2, TLS, SSL, PGP, SSH

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.

https://en.wikipedia.org/wiki/Symmetric-key_algorithm

https://en.m.wikipedia.org/wiki/Blowfish_(cipher)

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.

https://en.wikipedia.org/wiki/Public-key_cryptography

https://en.wikipedia.org/wiki/RSA_(cryptosystem)

https://en.wikipedia.org/wiki/Digital_Signature_Algorithm

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.

https://hu.wikipedia.org/wiki/MD5

https://en.wikipedia.org/wiki/SHA-2

É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. 🙂

https://en.wikipedia.org/wiki/RC4

https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy

https://hu.wikipedia.org/wiki/TKIP

Ma nyilvános kulcsú algoritmusból legalább 2048 bites RSA kulcsokat, szimmetrikusból AES-t, illetve egyirányúból SHA-2-t használunk. 🙂

RSA titkosítást használunk a TLS (Transport Layer Security), SSL (Secure Sockets Layer) és SSH (Secure Shell) protokollokban, illetve PGP (Pretty Good Privacy) folyamán.

https://hu.wikipedia.org/wiki/PGP

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. 🙂

https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/

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. 🙂

Reklámok

Mentés (backup)

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!

https://owncloud.org/

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.

  1. 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. 🙂
  2. 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. 🙂

https://www.shellhacks.com/ssh-execute-remote-command-script-linux/

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.

https://www.thomas-krenn.com/en/wiki/Archive_under_Linux_(tar,_gz,_bz2,_zip)

Tűzfal (firewall)

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).

root@gergo1:~# cat /etc/init.d/iptables
#!/bin/sh
echo -n "Applying firewall rules.."
/sbin/iptables-restore < /etc/network/iptables.up.rules
echo "done."

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.

Portszkennelés (Port Scan) Linux alatt – nmap, hálózati kapcsolatok – netstat

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”).

https://support.holmsecurity.com/hc/en-us/articles/212963869-What-is-the-difference-between-TCP-and-UDP-

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.

http://www.steves-internet-guide.com/tcpip-ports-sockets/

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! 🙂

https://serverfault.com/questions/533611/how-do-high-traffic-sites-service-more-than-65535-tcp-connections

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!

https://hu.wikipedia.org/wiki/OSI-modell

https://www.studytonight.com/computer-networks/complete-osi-model

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. 🙂

Secure Shell – biztonságos távkapcsolat két számítógép között – ssh, scp egy Mac mini OS X és egy Linux között

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ésbackup – 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 Linuxszerverre” 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.