Dotaz: SSH - přihlášení pomocí klíče

[Petr Maleček]

Ahoj, vím, že se to tu už řešilo nespočetněkrát, ale pořád si nevím rady, přestože v minulosti se mi to už povedlo několikráte rozběhnout.

Chci používat Tortoise Git na správu repozitářů. Jako přihlašovací "prvek" jsem zvolil přihlašování pomocí SSH a privátního klíče.

Takto vypadá moje nastavení /etc/ssh/sshd_config:

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes

Vesměs asi skorem defaultní konfig, který se instaluje společně s balíčkem.

Další kroky, které dělám jsou následující:

-- spustím puttygen
-- kliknu na Generate a jezdím v prázdném poli myší pro vygenerování klíče
-- poté přejmenuji komentář klíče na git@********.cz
-- poté kliknu na save public key, uložím jako git-public.key, a pak na save private key, uložím jako git-private.ppk
-- určitě jste si všimli, že jsem nezadal heslo pro privátní klíč, předpokládám, že to není nutností, ani když jsem ho vyplnil, tak se změna nedostavila
-- teď překopíruji text (klíč) který se zobrazil v puttygenu a vložím ho na serveru, do složky /home/git/.ssh do souboru authorized_keys (uživatele jsem vytvořil, bez hesla) a uložím.
-- nyní spustím znovu Putty, vyplním adresu a přiložím klíč git-private.ppk

A výsledek ?

login as: git
Server refused our key
git@********-server.pilsfree.czf's password:

Vygenerovaný klíč, který vkládám do authorized_keys vypadá zhruba takto:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAlFcudIV3/Wgkefzo/n/xy9zsD/AVb1zXXocG5W32wW5qZdzxo/8sHd14467yx....blablablabla...BYW3ay1+xJKF5mqtVqqNmdnkEUQViH/KCdxB6WZjvsezq8XqxdZ2ms+G2h9ThvlsWtfSXYNVuBXtHGIR/EHYFPYLqh6tWrO46DJF5q2jOGyYtP0bAVg4v51lcCJW6oZruW9XiU+vtCIB5TLesnvhhIWOhwK9XSmTWSleBNgOfKr+tZvE9r0oTfFQIVKnLmTIsz6AtiFcn7VQBm56KOVIg5CxwKAKZzYGJ1Ezhi+Yl1rgsVzdv7NhmENWY7JraOZ8J1v8AQ== git@********.cz

Nemáte někdo ponětí, co dělám zase špatně ? Bohužel se mi nepodařilo ani nic vyčmuchat v logu, co by mi pomohlo. Případně pokud potřebujete ještě soubor /etc/ssh/ssh_config, tak jej mohu dodatečně přiložit, ale myslím si, že v tom nehraje roli.

Díky.

---

---

Odpovědi

[Petr Maleček]

Tak se moc omlouvám, za zbytečný dotaz, vše je v pořádku, jen jsem musel znovu nastavit práva pro zápis/čtení adresáře uživatele, nějak jsem se "za-chmod-oval". Nastavil jsem tedy:

$ chmod 700 /home/git -R

a už je vše v pořádku. Můžete to tedy brát jako takový nový návod :D

[Petr Maleček]

Ještě doplním jaká by měla být práva k adresářům:

/home/git - drwxr-xr-x
/home/git/.ssh - drwxr-xr-x
/home/git/.ssh/authorized_keys - -rw-r--r--

[Ash]

maximálně

[pht]

$ chmod 700 /home/git -R

Tohle bych jako bernou minci nebral, protože to nastaví 700 i na všech souborech v tom adresáři. Úplně stačí to použít bez toho -R.

Jinak je pravda že pokud sshd odmítá klíč a všechno se zdá býti v pořádku tak jsou za tím téměř vždy nesprávná práva na domovský adresář.

[Ash]

...i na všech adresářích a podadresářích a souborech v podadresářích...

[Petr Maleček]

O tom vím, vzhledem k tomu, že byl domovský adresář prázdný, tak jsem pro jistotu přidal -R parametr, ale je pravda, že zbytečně

[pht]

Mohly v něm být soubory typu .bashrc, které se normálně při výpisu nezobrazují.

[Oskar]

Jinak je pravda že pokud sshd odmítá klíč a všechno se zdá býti v pořádku tak jsou za tím téměř vždy nesprávná práva na domovský adresář.

Ne na celý adresář, ale jen na soubor ~/.ssh/authorized_keys

Jde o to, že kdyby tento soubor byl zapisovatelný pro skupinu, nebo dokonce pro svět, mohl by si tam kdokoli přidat klíč a následně se přihlásit jménem uživatele.

[pht]

Ne na celý adresář, ale jen na soubor ~/.ssh/authorized_keys

Bohužel ve světe UNIXu tohle nestačí. Pokud nemáte právo zápisu k .ssh/authorized_keys ale máte právo zápisu na adresáři .ssh, můžete provést:

rm .ssh/authorized_keys
cat mujkey >.ssh/authorized_keys

Pokud nemáte možnost zápisu do adresáře .ssh (ergo ke smazání toho souboru), ale máte zápis do /home/user můžete provést zase jiný trik:

mv /home/user/.ssh /home/user/.ssh-nasrat
mkdir /home/user/.ssh
cat mujkey >.ssh/authorized_keys

Jo, UNIX je radost...

Proto sshd kontroluje práva všech adresářů od toho souboru až nahoru a nejlepší, co můžete udělat je nechat si svůj home privátní.

chmod 700 $HOME

[Oskar]

Pravda, testoval jsem to a odvolávám svůj předchozí post. Nicméně tyhle postupy:

rm .ssh/authorized_keys
cat mujkey >.ssh/authorized_keys

...

mv /home/user/.ssh /home/user/.ssh-nasrat
mkdir /home/user/.ssh
cat mujkey >.ssh/authorized_keys

by vedly k vytvoření souboru/adresáře s jiným jménem vlastníka (za předpokladu, že na adresářích není SUID/SGID), takže to by sshd mělo stačit zkontrolovat, zda authorized_keys má odpovídající práva a zda je vlastněn majitelem účtu. Ale skutečně nestačí.

Proto sshd kontroluje práva všech adresářů od toho souboru až nahoru a nejlepší, co můžete udělat je nechat si svůj home privátní.

Až nahoru ne, práva na adresář /home mohou být libovolná (aspoň u mě).

[pht]

by vedly k vytvoření souboru/adresáře s jiným jménem vlastníka (za předpokladu, že na adresářích není SUID/SGID), takže to by sshd mělo stačit zkontrolovat, zda authorized_keys má odpovídající práva a zda je vlastněn majitelem účtu.

Až nahoru ne, práva na adresář /home mohou být libovolná (aspoň u mě).

Teoreticky máte pravdu, proč je to v opensshd zrovna takto je asi otázka do mail listu

[Cuda]

Tu bych přidal i já malou zkušenost a to s puttygen, když jsem uložil public key a ten dal do authorized_keys tak to nefungovalo. Ale když jsem vzal do clipboardu zobrazený public key ve vrchní části puttygen a vložil do autohorized_keys tak OK. Blíže jsem to nezkoumal, od té doby to vždy dělám takto