Okoun

U adresare to muze byt proto, aby neprivilegovany uzivatel (treba agent monitoringu) mohl zjistit volne misto.

getfacl v tom systemu nemaji ... predelal jsem to na 0700 a ssh uz je OK ... je vsak otazka co jineho jsem si tim ted rozdrbkal ...

A jeste getfacl user1?
Samostatne "x" se pouziva pri exportu domovskych adresaru pres apache, treba.

To jsou nejake divne permissions ...

# ls -l|grep user1
drwx--x--x+ 1 user1 users 50 Dec 9 11:38 user1

Ech ... pomohlo spustit si na NAS z console jeste jednu instanci /bin/sshd -d -p 220 ...

...
Authentication refused: bad ownership or modes for directory /volume1/homes/user1

SELinux tam nahodou neoperuje?
A prava jsou opravdu 600 na /home/user1/.ssh i home/user1/.ssh/id_rsa ?
Pripadne mu zkusit vnutit klic pres ssh -i .ssh/id_rsa user1@nas.

V sshd_config PermitRootLogin yes ... nic jineho jsem nenastavoval ... ten bezny uzivatel se tam s pouzitim hesla prihlasi taky, ale pres klic ani prd...

A roota povolil jakoze "permit root login" nebo "allowed users" ?

Mam synology NAS na ktere jsem si povolil v /etc/ssh/sshd_config vzdalene prihlaseni uzivatele root. Nahral jsem si tam /root/.ssh/authorized_keys a jak by se delo ocekavat, tak kdyz v linuxu napisu # ssh root@nas , tak se bez problemu tim rsa klicem prihlasim.

Nyni se tam potrebuju pres ssh prihlasit i jako bezny user - kvuli rsync, takze jsem jen z /root zkopiroval .ssh do domovskeho adresare toho usera a upravil vlastnika a permissions ... # ssh user1@nas vsak pres rsa autorizaci neprojde. Nenapada mne proc...

Takhle vypada v debugu misto, kde se mi ty dve prihlaseni od sebe lisi:

# ssh root@nas
...
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp SHA256:SmBcP5EIrWB/+ammgMUX+fHmwLRFBjNs4ASfmv9HAGo
debug3: sign_and_send_pubkey: RSA SHA256:SmBcP5EIrWB/+ammgMUX+fHmwLRFBjNs4ASfmv9HAGo
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to nas1 ([192.168.167.17]:22).


# ssh user1@nas
...
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ecdsa
debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ed25519
debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

co toto? http://www.tug.dk/FontCatalogue/typewriterfonts.html

Na Fedore mam Nimbus Mono nebo Courier, ktere by to mohly splnovat.

Hledam font (bezne dostupnej v linuxu), kterej co nejvice pripomina a nebo presne kopiruje pismo psaciho stroje. Nevedel by takhle nekdo z hlavy nazev?

Ono obecne rozsekat pravidla FW do chainu podle toho co kam jde (nebo co se testuje) je velke dobro - jednak to je prehlednejsi a lip se to udrzuje a druhak se nemusi kvuli kazdemu packetu prochazet vsechny pravidla. IPSec funguje tak, ze se strany po tech udp portech 500,4500 domluvi co a jak bude a pak si to posilaji zapouzdrene v esp nebo ipencap, ktere prijde na verejnou ip stroje. Tam si to ipsec rozbali a posle do forward retezce s oznacenim policy ipsec a uz konkretnima left/right adresama.

Díky. Ale moc tomu nerozumím. Když nad tím tak přemýšlím, tak vlastně nevím, kdy a jak se ten ipsec k tomu paketu dostane. Podle těch pravidel, cos napsal, usuzuju, že paket normálně procestuje FORWARDem, v ten okamžik ho chytí ipsec, zruší jeho další "normální" cestu a (místo POSTROUTINGU) zabalí ho do nového paketu, který pošle přes OUTPUT (do OUTPUT by se ten původní paket IMHO jinak vůbec nedostal). Je to tak?
Já totiž řeším problém, že nám na ipsecu, který už dlouho běžel, něco přestalo fungovat (nevím kdy, protože to nepotřebujeme často) a mám podezření, že se do toho nějak zamotala před pár měsíci přidaná pravidla pro SNAT, která se ipsecu vůbec neměla týkat (respektive nás nenapadlo, že se s tím ipsec může svézt). Jenže s tím moc teď už experimentovat nejde, tak se to nejdřív snažím pochopit, než do něčeho sáhnu víc. FORWARDy ipsec provozu přesměrované do extra chainů nemáme, já jsem to tehdy kdysi splácal jen tak z hlavy, seč mi znalosti a googlení stačilo. Takže možná je tohle (extra chainy) správná cesta, jak ipsecovou komunikaci vyřešit (já jsem momentálně přidal (-I) pro ty dané lokální adresy do SNATu jen RETURN a zdá se, že to pomohlo, ale i kdyby to bylo tím, tak to uspokojivé (správné) řešení není).

JA vim, zkousel jsem tam dat SSD, ale na to, ze se tam budou cpat jen zalohy zaloh je to zbytecny luxus. Flashka postaci.

Dik, právě ta flash mne vcera nakonec napadla.

Tak do toho DELL FX 160 si muzes dat jakykoliv 2.5 disk.

Tak si tam nech ty 2GB pro OS a data dej externi hdd / flash.

standardne to v iptables vypada nejak takto, aby se ti strany spolu domluvily:
/sbin/iptables -A OUTPUT -p udp -s $LOCAL_PUBLIC_IP -d $REMOTE_IP -m multiport --dports 500,4500 -j ACCEPT
/sbin/iptables -A OUTPUT -p esp -s $LOCAL_PUBLIC_IP -d $REMOTE_IP -j ACCEPT
/sbin/iptables -A OUTPUT -p ipencap -s $LOCAL_PUBLIC_IP -d $REMOTE_IP -j ACCEPT
+ (analogicky INPUT)

Co ti pak leze tim tunelem uvnitr si vyfiltrujes do zvlastnich chainu takto:
/sbin/iptables -A FORWARD -i $LOCAL_PUBLIC_IF -o $LOCAL_LAN_IF -s $IPSEC_NET -d $LOCAL_LAN_NET -m policy --pol ipsec --dir in -j ipsecnet-to-lan
/sbin/iptables -A FORWARD -i $LOCAL_LAN_IF -o $LOCAL_PUBLIC_IF -s $LOCAL_LAN_NET -d $IPSEC_NET -m policy --pol ipsec --dir out -j lan-to-ipsecnet