SFTP - Couldn't canonicalise: Permission denied

Noh akkor mai érdekes esetem a következő:
Tisztelt user a gépre gond nélkül be tud SSH-val jelentkezni:

p1ngw1n@Twitchy-Thinkpad:~$ ssh client_user@sftp_server
client_user@sftp_server's password:
[client_user@sftp_server:/home/client_user]

Csak hogy kerek legyen a kép: nézzük az SSH számára használt file-okat/mappákat is:

[client_user@sftp_server:/home/client_user] ls -ld ~
drwxr-xr-x 9 client_user staff 512 Jun 28 15:43 /home/client_user
[client_user@sftp_server:/home/client_user] ls -ld ~/.ssh
drwx------ 2 client_user staff 512 Jun 28 15:46 /home/client_user/.ssh
[client_user@sftp_server:/home/client_user] ls -l ~/.ssh
total 8
-rw------- 1 client_user staff 2428 Jun 27 11:26 authorized_keys
[client_user@sftp_server:/home/client_user] ls -la ~/.ssh
total 24
drwx------ 2 client_user staff 512 Jun 28 15:46 .
drwxr-xr-x 9 client_user staff 512 Jun 28 15:43 ..
-rw------- 1 client_user staff 2428 Jun 27 11:26 authorized_keys

A home mappa 755ön (ez jó: csak az ownernek van írási joga), a .ssh mappa 700 (perfect) és az alatta lévő authorized_keys file pedig 600as jogokkal ott is van, ami szintén teljesen megfelel a számunkra. A felhasználó igénye viszont az, hogy az SSH kapcsolat mellett még secure filetransfert is tudjon csinálni (SFTP), ami viszont (hiába megy a bejelentkezés) a jelek szerint nem akar menni:

p1ngw1n@Twitchy-Thinkpad:~$ sftp client_user@sftp_server
Connecting to sftp_server...
client_user@sftp_server's password:
Couldn't canonicalise: Permission denied
Need cwd

User persze minket piszkál, hogy Wattafák, mert ilyet még ő se látott.. Megnézve az SSH konfigot szépen látszik, hogy az sftp-server a /etc/ssh/sshd_config alatt engedélyezve van:

[root@sftp_server:/home/root] grep sftp /etc/ssh/sshd_config
Subsystem sftp /usr/sbin/sftp-server

Illetve az még rátesz egy lapáttal, hogy mi pedig szépen és hiba nélkül tudunk SFTP-zni a szerverre (ergo tűzfal, és hasonló mókák kilőve). Tekintve, hogy az SFTP is a 22 portot használná csak a kommunikációra (mint az SSH), így a felhasználó esetében is elvileg adott minden lehetőség arra, hogy belépjen.. Ehhez képest mégse ez a helyzet a jelek szerint....

Az már csak fokozza a "fun" faktort, hogy a verbose login szerint az authentikáció sikeres, ergo a user be tud lépni, de aztán az SFTP eldobja a kapcsolatot:

p1ngw1n@Twitchy-Thinkpad:~$ sftp -v client_user@sftp_server
Connecting to sftp_server...
OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to sftp_server [10.1.0.230] port 22.
debug1: Connection established.
debug1: identity file /home/p1ngw1n/.ssh/id_rsa type -1
debug1: identity file /home/p1ngw1n/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'sftp_server' is known and matches the RSA host key.
debug1: Found key in /home/p1ngw1n/.ssh/known_hosts:370
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/p1ngw1n/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/p1ngw1n/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
client_user@sftp_server's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.utf8
debug1: Sending subsystem: sftp
Couldn't canonicalise: Permission denied
Need cwd
client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Transferred: sent 2224, received 2248 bytes, in 0.3 seconds
Bytes per second: sent 6468.5, received 6538.3
debug1: Exit status 0

A hibaüzenet egyértelműen permission denied-ot mond, viszont a fenti listából is látszik, hogy az összes SSH/SFTP által használt file ownere maga a user, és az összes file-nak jók a jogosultságai, ergo itt valami megint nem kóser.

Megnézve az SFTP kliens forrását (sftp-client.c) láthatjuk, hogy az alábbi kódrészlet felelős a hibaüzenetért, illetve az ellenőrzésért

do_realpath(struct sftp_conn *conn, char *path)
{
Buffer msg;
u_int type, expected_id, count, id;
char *filename, *longname;
Attrib *a;

expected_id = id = conn->msg_id++;
send_string_request(conn->fd_out, id, SSH2_FXP_REALPATH, path,
strlen(path));

buffer_init(&msg);

get_msg(conn->fd_in, &msg);
type = buffer_get_char(&msg);
id = buffer_get_int(&msg);

if (id != expected_id)
fatal("ID mismatch (%u != %u)", id, expected_id);

if (type == SSH2_FXP_STATUS) {
u_int status = buffer_get_int(&msg);

error("Couldn't canonicalise: %s", fx2txt(status));
return(NULL);
} else if (type != SSH2_FXP_NAME)
fatal("Expected SSH2_FXP_NAME(%u) packet, got %u",
SSH2_FXP_NAME, type);

count = buffer_get_int(&msg);
if (count != 1)
fatal("Got multiple names (%d) from SSH_FXP_REALPATH", count);

filename = buffer_get_string(&msg, NULL);
longname = buffer_get_string(&msg, NULL);
a = decode_attrib(&msg);

debug3("SSH_FXP_REALPATH %s -> %s", path, filename);

xfree(longname);

buffer_free(&msg);

return(filename);
}

A kód tényleges analizálása nélkül felhívnám a figyelmet egy fontos tényezőre, amit az SFTP csinál: A valós útvonalat (SSH2_FXP_REALPATH) ellenőrzi, nem pedig azt, hogy a file-ok amivel dolgozik valóban elérhetőek e.. Ez esetben ez azért is okozhatott gondot, mivel a user home-ja egy külön FS volt ->
Mint kiderült az SSH ezt a realpath ellenőrzést annyira komolyan veszi, hogy (szokásához híven) megy a saját feje után, és a mount point eredeti attributumait lekérve vizsgálja meg, hogy az vajon jó lesz e majd neki..
Csak hogy érthető is legyen a probléma:

[root@sftp_server:/var/adm] ls -ld ~client_user
drwxr-xr-x 9 client_user staff 512 Jun 28 15:43 /home/client_user
[root@sftp_server:/var/adm] mount |grep client_user
/dev/lv00 /home/client_user jfs Aug 02 03:51 rw,log=/dev/loglv00
[root@sftp_server:/var/adm] umount /home/client_user
[root@sftp_server:/var/adm] ls -ld /home/client_user
drw------- 2 root system 256 Dec 3 2009 /home/client_user
[root@sftp_server:/var/adm] chmod 755 /home/client_user
[root@sftp_server:/var/adm] mount /home/client_user

Pontosan - Az eredeti mount point-ra az adott usernak tényleg nincs semmiféle joga.. Miután átraktuk 755-re (root owner maradt!) nézzük az újjab tesztet:

p1ngw1n@Twitchy-Thinkpad:~$ sftp client_user@sftp_server
Connecting to sftp_server...
client_user@sftp_server's password:
sftp> quit

Aham.. Szóval így már megy -> szimpla reader jog kellett csak neki.. OpenSSH, én így szeretlek..

5.8p1 OpenSSH forgatása AIX-re (gcc)+ csomag készítés (bff)

Sikerült belefutni egy elég idegesítő bugba..
Az AIX-hoz jelenleg elérhető legfrissebb OpenSSH (5.4p1) sajna egy elég pofátlan buggal érkezett - a csomagban lévő sftp-ből kiszedték az mput parancsot, amit 1-2 team nem fogadott őszínte mosollyal.
Az OpenSSH Changelogját elnézegetve látszik is, hogy ez tényleg nem azért történt, mert a funkció bugos lett volna, vagy hasonló, hanem szimplán "elveszett", ám az 5.6os verzióba már vissza került.. Ám mivel hivatalosan csak 5.4 állt rendelkezésre, így gondoltam nem szöszölök, nyomban forgatok egy latest-et (5.8p1)
Hozzávalók:
A forrás: http://ftp.fsn.hu/pub/OpenBSD/OpenSSH/portable/openssh-5.8p1.tar.gz
Némi kis dokumentáció: ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/INSTALL
Zlib (A forgatáshoz): http://zlib.net/zlib-1.2.5.tar.gz
Illetve OpenSSL >=0.9.6
#Note - A forgatáshoz gcc-t választottam (ezt szoktam meg :)), de persze ha igazi IBM-es akarnék lenni, akkor XlC-t használnék.. Én úgy éreztem, hogy már így is kékebb a vérem mint kéne, így inkább nem teszek még rá még1 lapáttal :)
Mivel az 5.4-el szállított OpenSSL alapból is 0.9.8-al jött, így hála az égnek azzal nem kellett szöszöljek. A zlib viszont sajna ilyen állatfaj, úgy hogy a forrás leszedése után az a standard ./configure, make, make install triumvirátussal fel is kerül a helyére.
Az OpenSSH viszont érdekesebb állatfaj..
Az első problémája, hogy ha csak simán felrakja az ember a zlibet, akkor nem akaródzik megtalálni.. Nem baj, van --with-zlib kapcsolója a configure-nak.
Ami viszont már nagyobb fejfájást okozott az az alábbi jelenség volt:

ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1136) in object clientloop.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.

Némi kis nyomozás után kiderül mi a ludas: Hőn "szeretett" gcc-m: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
Ez a bug eddig még így nálam nem jött elő, de akkor innentől megjegyzem magamnak, hogy ezek után minden gcc-vel AIX-ra forgatott parancsnál ezt kötelezően használni illik:

--with-cflags=-g0

/* Az mondjuk külön vicc, hogy így a forgatás kb az alábbi módon fog kinézni:

gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wno-pointer-sign -fno-strict-aliasing -fno-builtin-memset -g0 -I. -I.. -I. -I./.. -I/usr/local/include/ -DHAVE_CONFIG_H -c bsd-arc4random.c

Láthatólag a -g0 simán felülbírálja a -g-t a gcc-nél,de ha neki megfelel, akkor ki vagyok én, hogy ellenkezzek.. */
Így már hőn szeretett OpenSSH-nk is simán lefordul
[/i]/* A teljesség igénye nélkül: Az alábbi forgatási funkciókat használtam:

./configure --prefix=/usr --sysconfdir=/etc/ssh --with-cflags=-fno-builtin-memset --with-cflags=-DBROKEN_GETADDRINFO --with-cflags=-g0 --with-zlib=/usr/local/include/

*/[/i]
Amint készen vagyunk ezzel, nyomban make install-t is nyomhatunk, vagy ha lusták vagyunk, akkor nyomban a csomagban lévő script-el telepíthető bff csomagot készíthetünk az alábbi módon:

AIX_SRC=yes contrib/aix/buildbff.sh

Viszont én kicsit többre vágytam, így úgy gondoltam, hogy kicsit ragaszkodjunk is az eddigi csomagoknál használt naming convention-höz is, meg had legyen ez már tényleg olyan, amilyennek én szeretném :)
A választott célezközöm pedig az mkinstallp alkalmazás volt (bos.adt.insttools csomag része)
Első kör:
A make install-ból, vagy a forgatott file-jainkból állítsuk össze a szükséges mappa struktúrát (file jogosultságokra figyeljünk! )

# [/tmp/openssh/5.8p1/package:] find . -type f
./usr/openssh/README
./usr/openssh/license_ssh.txt
./usr/openssh/ChangeLog
./usr/sbin/ssh-rand-helper
./usr/sbin/ssh-keysign
./usr/sbin/sftp-server
./usr/sbin/sshd
./usr/bin/ssh-add
./usr/bin/ssh-keygen
./usr/bin/ssh-agent
./usr/bin/ssh-keyscan
./usr/bin/scp
./usr/bin/sftp
./usr/bin/ssh
./etc/ssh/moduli
./etc/ssh/ssh_prng_cmds
./etc/ssh/ssh_config
./etc/ssh/sshd_config
./etc/ssh/ssh_config.default
./etc/ssh/sshd_config.default
./etc/rc.d/rc2.d/Ssshd
./etc/rc.d/rc2.d/Ksshd

Második kör:
Hozzuk létre a szükséges pre/post install/uninstall scripteket (kicsit szöszölős meló). Én személy szerint úgy voltam vele, hogy szeretem elszeparálni a különböző taszkokat, így az alábbi file-okat dobtam össze:

# [/tmp/openssh/scripts:] find . -type f -ls
18780 1 -rw------- 1 root system 786 Mar 4 15:30 ./openssh.base.client.unpost_i
18775 4 -rw------- 1 root system 3221 Mar 7 17:47 ./openssh.base.server.post_i
18778 1 -rw------- 1 root system 803 Mar 4 15:30 ./openssh.base.server.pre_i
18777 1 -rw------- 1 root system 871 Mar 4 15:30 ./openssh.base.server.unpost
18779 1 -rw------- 1 root system 537 Mar 4 15:30 ./openssh.base.server.unpre_i

Harmadik kör:
A végére pedig dobjuk össze a template file-t ami alapján az mkinstallp majd dolgozni is tud:

# [/tmp/openssh/5.8p1/.info:] cat openssh.template*

*Katt az openssh.template alatt elérhető pastebin.com-os linkre
/* Személy szerint nem nagyon vagyok oda a licensz file-okért, de azért adjuk már meg a módját, ha nem kerül sok erőfeszítésbe */
Ha minden kész, akkor a célmappánkból indítva az alábbi parancsot kedves kis bff csomag vár majd minket a tmp/ alatt:

mkinstallp -d /tmp/openssh/5.8p1/package/ -T /tmp/openssh/5.8p1/.info/openssh.template

/* Ami a lustaságom miatt hiányzik: Nincs dependency check - azért azt az OpenSSL-t tényleg nézni kéne */
Ami előny ebből kijött:
- Saját csomag
- Ha nem is hivatalosan, de ismét helyreállt az mput funkció az sftp-n belül (legalább is amíg hivatalos csomag nem lesz helyette)
- A debug flag kikapcsolása miatt (-g0) az elkészült binárisok közel fele akkor lettek, mint a hivatalos csomagban elérhetőek (debugolni meg nem nagyon óhajtom ezt amúgy se)
- Ez kis howto a közösségnek :)