SSH con authorized_keys su un sistema Ubuntu con homedir crittografato?


38

Di recente ho creato un nuovo server con Ubuntu karmic 9.10 e quando ho creato la mia directory home ho scelto di renderlo crittografato. Ora, dopo aver caricato il mio file authorized_keys in ~ / .ssh, non viene riconosciuto perché la mia directory home non viene decifrata fino a dopo il mio accesso. Esiste un modo per far funzionare le chiavi SSH con le home directory crittografate sotto Ubuntu?


Sono stati accolti suggerimenti di tag migliori, non è stato possibile trovare corrispondenze davvero valide nei tag suggeriti.
Josh,

1
penso che quelli siano esatti, in realtà. c'è un ubuntutag ma non credo che questo problema sia specifico di un particolare sistema operativo.
Quack Quixote,

Un sintomo di questo problema per me in Ubuntu 11.10 è che il primo tentativo di accedere alla macchina è che è richiesta l'autenticazione della password (poiché authorized_keysnon è ancora accessibile). Se lancio un'altra connessione ssh, l'autenticazione con chiave funziona.
mindless.panda,

Risposte:


39

Cambia questa riga nel tuo file sshd_config:

AuthorizedKeysFile /etc/ssh/%u/authorized_keys

E quindi spostare il file authorized_keys su / etc / ssh / your-username / authorized_keys

Questo post documenta un altro modo di risolverlo.


1
Ho pensato che la prima soluzione suonasse perfetta ma non ha funzionato per me. Non so perché. Ma il post a cui ti sei collegato ha funzionato alla grande. Grazie!
Josh,

3
Josh - l'utente target è il proprietario di quei file e le autorizzazioni 600 (700 per la directory)?
NVRAM

1
Vedi questo link per le istruzioni complete: Chiavi SSH su Ubuntu . Scorri verso il basso fino alla sezione di risoluzione dei problemi.
jjeaton,

8

Questa soluzione è stata ispirata da questo post . IMHO è molto meglio che modificare il tuo / etc / ssh / sshd_config poiché non richiede affatto l'accesso root.

# Make your public key accessible
mkdir -m 700 /home/.ecryptfs/$USER/.ssh
echo $YOUR_PUBLIC_KEY > /home/.ecryptfs/$USER/.ssh/authorized_keys
ln -s /home/.ecryptfs/$USER/.ssh/authorized_keys ~/.ssh/authorized_keys
ecryptfs-umount-private
chmod 700 $HOME
mkdir -m 700 ~/.ssh
ln -s /home/.ecryptfs/$USER/.ssh/authorized_keys ~/.ssh/authorized_keys

# Make it auto-mount with first login.
# Note: it can cause problems with automated login.
echo /usr/bin/ecryptfs-mount-private > ~/.profile
echo cd >> ~/.profile
echo source .profile >> ~/.profile
ecryptfs-mount-private

3
Potete fornire una dichiarazione sommaria di ciò che effettivamente fa?
mindless.panda,

Ho fatto una modifica a spiegare cosa accade: si salva la chiave pubblica (s) con cui si desidera accedere alla macchina di authorized_keysa /home/**.ecryptfs**/$USERsenza crittografia e link ad esso da crittografati casa così come la vostra casa in chiaro. Il nuovo .profilenella tua casa non crittografata dovrebbe montare la tua home directory crittografata, "cd" in essa e procurarti il ​​tuo vero .profile.
LiveWireBT

Funziona come previsto su una nuova installazione 16.04. Poche osservazioni: la casa non crittografata non era scrivibile (il che ha senso, non si desidera che gli utenti sovvertano tutto archiviando accidentalmente i dati lì), quindi modificare temporaneamente le autorizzazioni. Inoltre, è necessario eseguire tutto ciò dal terminale, disconnesso dalla GUI e da lightdm o dal DM che si sta utilizzando. ecryptfs-mount-privaterichiede la password dell'utente ogni volta che l'accesso avviene correttamente tramite chiavi pubbliche a meno che non si sia effettuato l'accesso alla GUI. La mia modifica sostituisce alcuni echi con un documento qui, è meno ripetitivo da digitare, non essere confuso da quello.
LiveWireBT

2

Ho appena passato un po 'di tempo a scherzare con questo, e la risposta è che è praticamente impossibile. E ' è possibile impostare senza password account di accesso autenticati-chiave pubblica via ssh, in modo da non dover digitare la password per il login , ma che non ottiene da nessuna parte, perché la vostra directory home è ancora crittografato.

Il semplice fatto è che la tua home directory crittografata è crittografata con una password *, quindi l'unico modo per decrittografarla è con quella password.

E se stai pensando che in teoria dovrebbe essere possibile usare la tua chiave ssh per decrittografare la passphrase di mount all'accesso, ciò non funzionerà perché la tua chiave privata non viene mai inviata al server.

Quindi, fondamentalmente, se si desidera la crittografia, è necessario utilizzare le password. Le home directory crittografate non sono compatibili con gli accessi alle impronte digitali per lo stesso motivo.


* So che è più complicato di una singola password, ma manteniamolo semplice per ora.


Bene, la risposta di djhowell ha funzionato perfettamente, quindi presumibilmente la mia directory home è crittografata con una chiave del sistema operativo ed è in grado di usarla per decrittografarla. Inoltre, quando SSH entra, sshd non sa come decifrare la mia direttrice domestica, quindi questo non spiega perché funziona con l'autenticazione con password.
Josh,

Aspetta, quindi quando accedi tramite ssh senza digitare alcuna password, la tua directory home crittografata viene effettivamente montata?
Ryan C. Thompson,

Sì, lo fa. E smontato quando esco.
Josh,

Bene, è strano. Ricevo il comportamento che descrivo nella mia risposta. La mia directory privata viene montata solo se il mio login comportava una password (in particolare, la mia password di accesso). Mi chiedo cosa hai fatto diversamente per farlo funzionare con le chiavi pubbliche.
Ryan C. Thompson,

@Ryan Thompson stai usando Ubuntu 9.10?
Josh,

1

Se non ti piace modificare l'impostazione predefinita (non mi piace, mi piace che i miei file siano dove mi aspetto che si trovino), potresti dare un'occhiata al mio post su come farlo:

http://www.enetworkservices.net/wordpress/ssh-public-keys-with-encrypted-home-directory.html

In breve. Inserisci le tue chiavi nella versione crittografata del tuo utente ~/.sshe collega simbolicamente la versione crittografata ~/.sshall'altra. In questo modo è sempre lì.

Per le persone pigre come me, ecco una sceneggiatura per farlo per te. Basta eseguirlo come l'utente normale. Nessun accesso root o autorizzazioni necessarie e nessuna modifica alla configurazione del server richiesta. Impostazioni utente normali pure.

#!/bin/bash
#
# Encrypted Home DIR SSH Key fix.
# Requires modification to sshd_config
#  AuthorizedKeys /etc/ssh/authorized_keys/%u/authorized_keys
# sudo mkdir /etc/ssh/authorized_keys -m 777
# for existing users run from home directory when login.
# for new users modify /etc/skel to include .bashrc to call script.
#
# Author: Benjamin Davis <bdavis@enetworkservices.net>

# Check if directory exists.
if [ ! -d "/etc/ssh/authorized_keys/$LOGNAME" ]
then
    # Make directory with restricted permissions.
    echo "Creating user ssh directory."
    mkdir /etc/ssh/authorized_keys/$LOGNAME -m 700
fi

# Check real users home .ssh folder
if [ -d "/home/$LOGNAME/.ssh" ]
then
    # Check if dir is symlink
    if [ ! -h /home/$LOGNAME/.ssh ]
    then
        echo "Moving configs."
        mv /home/$LOGNAME/.ssh/. /etc/ssh/authorized_keys/$LOGNAME/.
        rm -rf /home/$LOGNAME/.ssh/
        ln -s -T /etc/ssh/authorized_keys/$LOGNAME /home/$LOGNAME/.ssh
        clear
    fi
else
    # Does not exist so link it.
    if [[ $EUID -ne 0 ]]
    then
        echo "User ssh config folder does not exist. Creating."
        mkdir /home/$LOGNAME/.ssh -m 700
        ln -s -T /etc/ssh/authorized_keys/$LOGNAME /home/$LOGNAME/.ssh
    fi
fi

0

È possibile utilizzare la chiave pubblica più sicura per accedere, quindi eseguire quanto segue per montare la directory dopo aver digitato la password:

ecryptfs-mount-private

Leggi il ~/README.txtfile dopo aver effettuato l'accesso tramite SSH, scoprirai che non hai i tuoi file perché la directory crittografata non è montata.

Non dovresti usare comunque chiavi pubbliche senza password per accedere. Guarda ssh-agent per un modo migliore.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.