Tisztelt user a gépre gond nélkül be tud SSH-val jelentkezni:
p1ngw1n@Twitchy-Thinkpad:~$ ssh client_user@sftp_serverCsak 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's password:
[client_user@sftp_server:/home/client_user]
[client_user@sftp_server:/home/client_user] ls -ld ~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:
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
p1ngw1n@Twitchy-Thinkpad:~$ sftp client_user@sftp_serverUser 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:
Connecting to sftp_server...
client_user@sftp_server's password:
Couldn't canonicalise: Permission denied
Need cwd
[root@sftp_server:/home/root] grep sftp /etc/ssh/sshd_configIlletve 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....
Subsystem sftp /usr/sbin/sftp-server
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_serverA 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.
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
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)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 ->
{
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);
}
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_userPontosan - 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:
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
p1ngw1n@Twitchy-Thinkpad:~$ sftp client_user@sftp_serverAham.. Szóval így már megy -> szimpla reader jog kellett csak neki.. OpenSSH, én így szeretlek..
Connecting to sftp_server...
client_user@sftp_server's password:
sftp> quit
