Аутентификация Открытого ключа SSH только работает, если активная сессия существует прежде

Когда домашняя директория пользователя зашифрована с ecryptfs sshd не может прочитать файл authorized_keys из домашней директории пользователя до того, как домашняя директория была смонтирована.

Во время входа в систему sshd будет использовать pam для аутентификации пользователя, а pam будет использовать пароль, введенный пользователем для монтирования зашифрованной домашней директории.

Это проблематично, если вы хотите ограничить sshd только разрешением аутентификации с помощью открытого ключа.

Однако вы можете поместить нешифрованный файл authorized_keys также и на сервер. Это позволит пользователю войти, используя ключ, но так как это не вызывает pam, домашний каталог не будет смонтирован, и монтирование домашнего каталога без знания пароля также не будет работать.

Так как незашифрованный домашний каталог скрывается зашифрованным домашним каталогом, размещение незашифрованного файла authorized_keys в первую очередь может быть немного хитроумным. Помочь в этом может крепление базовой файловой системы.

Если, например, /home - это просто каталог в корневой файловой системе, то можно сделать следующее:

mkdir /mnt/rootfs
mount --bind / /mnt/rootfs

А затем создать /mnt/rootfs/home/$USER/.ssh/authorized_keys

Можно сделать еще что-нибудь. Так как зашифрованная и нешифрованная версия authorized_keys - это два разных файла, вы можете поместить в них разное содержимое. Например, незашифрованная версия может вызвать скрипт для монтирования зашифрованного домашнего каталога:

command="/usr/local/bin/ecryptfs-mount-from-ssh" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDM1Ot12ThbTcPOGpfh7AiRqp3P4BMm3DNo4mDg7gDFPwCmM9rKRHTH0fBVSqkSGlXm84q29bckDukg7vfqkbTpbkP3e2YmTkP6p1J2SoX2QMUnBRRgL9It/ZiAfA2I4QzUrcywVvokO1F2DqcRLy5e5wKTUFfvIm6D2QfBmGbnW2Kkpn16hQyLT1ClXjFC1qXUhazePv0cAtWUCUGjRcLr/ipOphS7eOB46cGhYqtbMkKx0t93ZG4f6jM0o32cYy3RqprpZpTmCeG1gDyG+IlSLBYXYggr72iwTKsTZ9pMDTCBQ8Pb7l317TPOcJzTtDxnpgpGE3x4Vu/Ww+zhsIeT kasperd 2014 May 24

Важной частью является команда , указанная перед ключом. Она вызывается вместо оболочки командной строки. Но это происходит только при использовании этого конкретного открытого ключа, и только если домашний каталог пользователя не смонтирован.

Если домашний каталог пользователя уже смонтирован, то этот authorized_keys файл скрыт, а вместо него используется зашифрованная версия. Зашифрованная версия файла authorized_keys не имеет команды , так что скрипт для монтирования домашнего каталога не запущен.

Итак, что происходит в скрипте. Вот моя версия:

#!/bin/bash -e

if [ $# = 1 ]
then
    PUBKEY="$(
        grep "$1" "$HOME/.ssh/authorized_keys" |
            sed -e 's/.* ssh-rsa //;s/ .*//')"
    /usr/local/bin/ssh-agent-ecryptfs-decryption.py "$PUBKEY" "$1" |
        ecryptfs-unwrap-passphrase "$HOME/.ecryptfs-ssh-wrapped/$1" - |
        ecryptfs-add-passphrase --fnek
fi
ecryptfs-mount-private
cd "$HOME"

if [ "$SSH_ORIGINAL_COMMAND" != "" ]
then
    exec /bin/bash -c "$SSH_ORIGINAL_COMMAND"
fi

exec /bin/bash -l

В примере выше, файл authorized_keys вызывается без аргументов, так что первый if блок пропускается. Таким образом, команда ecryptfs-mount-private запросит пароль пользователя. Но для этого не требуется sshd, чтобы была включена аутентификация паролем, и таким образом будет работать на sshd только с аутентификацией открытым ключом.

Следующая команда изменится на зашифрованную домашнюю директорию пользователя (до тех пор скрипт будет выполняться внутри незашифрованной домашней директории).

Последняя часть скрипта выполнит команду, данную в качестве аргумента к команде ssh, если она есть, или пользователи войдут в оболочку, если команда не была дана.

Одно из предостережений заключается в том, что это не работает с переадресацией X11, потому что домашняя директория еще не доступна, когда будет сохранен куки-файл. Но любой другой сеанс, открытый в то время, как домашний каталог уже смонтирован, сможет работать с переадресацией X11.

Использование ~/.ssh/rc вместо этого, возможно, решит проблему переадресации X11. Это то, что я еще не рассматривал.

Первый блок if немного хакерский, который я придумал, чтобы позволить монтировать домашнюю директорию пользователя без необходимости пароля. Вместо этого он использует переадресованный ssh-agent для монтирования домашнего каталога пользователя. Эта часть поставляется с оговорками об отсутствии экспертной оценки, так что доверять криптографии в ssh-agent-ecryptfs-decryption.py вы можете на свой страх и риск.

Питоновый скрипт выглядит следующим образом:

#!/usr/bin/env python

from sys import argv
from os import environ
import socket

s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.connect(environ['SSH_AUTH_SOCK'])

def encode_int(v):
    return ('%08x' % v).decode('hex')

def encode_string(s):
    return encode_int(len(s)) + s

def encode_mpint(v):
    h = '%x' % v
    if len(h) & 1: h = '0' + h
    return ('%04x%s' % (len(h) * 4, h)).decode('hex')

key_blob = argv[1].decode('base64')
msg = 'ecryptfs-decrypt ' + argv[2]

s.send(encode_string(chr(13) +
                     encode_string(key_blob) +
                     encode_string(msg) +
                     encode_int(0)))

response = s.recv(1024)

assert response == encode_string(chr(14) + response[5:]), argv[1]

passphrase = response[-48:].encode('base64').replace('\n', '')

print passphrase

Так как же работает дешифровка? Прежде всего, аргумент к скрипту, предоставленный authorized_keys - это любое случайное значение. uuid, генерируемый с помощью uuidgen, может работать. Скрипт оболочки использует grep для нахождения соответствующей строки в файле authorized_keys для извлечения открытого ключа.

Открытый ключ в кодировке base64, а также uuid предоставляются питоновому скрипту. Используется именно тот публичный ключ, которым аутентифицировался пользователь. Питоновый сценарий запрашивает у переадресованного агента подпись на определённом сообщении, используя указанный открытый ключ (поскольку подпись сообщений - это именно то, что может сделать ssh-agent). Часть подписи затем шифруется с помощью base64 для получения пароля.

Этот пароль используется для расшифровки обернутого файла паролей ecryptfs, но основной файл шифруется с помощью пароля для входа пользователя в систему. Этот файл зашифрован с помощью пароля, сгенерированного с помощью ключа ssh

Вчера я так вдохновился идеей Касперда, что сделал вот это:

https://github.com/bjornnorman/decryptfs-ssh

Я уже немного опробовал его, и он, кажется, работает блестяще. Это делает действительно простым добавление/удаление ключей для безпассовой расшифровки домашних папок ecryptfs при использовании SSH....

Как и оригинал Касперда, он не был подвергнут экспертной оценке - но так как он находится на github сейчас, любой может внести свой вклад. :)

Вы все еще должны переместить свои ключи вне вашей домашней папки, но с этим вы можете, по крайней мере, избежать неприятного входа в пароль...

Наслаждайтесь!

Вот простое решение но кажется не изящным.

Поскольку ваша домашняя папка зашифрована, просто поместите файл authorized_keys в незашифрованное место.

Затем вам нужно указать ssh, где authorized_keys есть. В / etc / ssh / sshd_config добавьте:

Match User [your_user_name]
AuthorizedKeysFile [new_path_to_authorized_keys]

ПРИМЕЧАНИЕ. Обязательно поместите Match в конец файла. Match остается действительным до конца файла или пока не будет выполнено другое Match .

Теперь вы можете войти в систему через ssh, и вам не нужно сначала входить локально. Но после входа в систему по ssh вам нужно запустить:

ecrypts-mount-private

и ввести пароль, чтобы смонтировать вашу домашнюю папку, а затем вручную cd в ваш дом.