Mac os ssh forwarding

How to enable SSH Forwarding on Mac OS X Snow Leopard

The other day I was toying with Rubber to deploy a Rails3 app to Amazon EC2. I host the project code in a private Github repository, accessible only with my own SSH key.

In order to checkout your code an any EC2 instance you can do one of two things:

Copy your private SSH key to the instance — This sounds easy enough, but has serious security implications. You do not want to be sending out your private SSH key, do you? That leaves you with option 2.

Let SSH forward the authentication request to your local machine. This is call Forwarding and requires ssh-agent to be running on your system. You’re in luck, ssh-agent is started automatically on your mac.

Now, the problem is that in Leopard (10.5) SSH Forwarding was enabled by default. You guessed it, in Snow Leopard it has been disabled by default. So, it’s up to you to enable SSH Forwarding manually. Here goes:

1. Open Terminal.app.
2. sudo vi /etc/ssh_config
   You will be asked for your password now. Feel free to use your preferred editor here.
3. Add the following two lines to the top of the file:
   Host *
   ForwardAgent yes
4. Save the file and exit your editor.

All right sparky, you now have enabled SSH Forwarding. Have fun!

PS. If you have enabled “Remote Login” under Sharing Preferences, make sure to stop and start that service to notify it of the changes you just made.

My site is free of ads and trackers. I record privacy-respecting usage statistics with Fathom.

Was this post helpful to you? Why not ☕ Buy me a coffee or use Brave Browser to send a tip.

Copyright © 1999-2021 Ariejan de Vroom

Live now; make now always the most precious time. Now will never come again.
– Jean-Luc Picard

Источник

Using SSH agent forwarding

To simplify deploying to a server, you can set up SSH agent forwarding to securely use local SSH keys.

SSH agent forwarding can be used to make deploying to a server simple. It allows you to use your local SSH keys instead of leaving keys (without passphrases!) sitting on your server.

If you’ve already set up an SSH key to interact with GitHub, you’re probably familiar with ssh-agent . It’s a program that runs in the background and keeps your key loaded into memory, so that you don’t need to enter your passphrase every time you need to use the key. The nifty thing is, you can choose to let servers access your local ssh-agent as if they were already running on the server. This is sort of like asking a friend to enter their password so that you can use their computer.

Check out Steve Friedl’s Tech Tips guide for a more detailed explanation of SSH agent forwarding.

Setting up SSH agent forwarding

Ensure that your own SSH key is set up and working. You can use our guide on generating SSH keys if you’ve not done this yet.

You can test that your local key works by entering ssh -T git@github.com in the terminal:

We’re off to a great start. Let’s set up SSH to allow agent forwarding to your server.

Using your favorite text editor, open up the file at

/.ssh/config . If this file doesn’t exist, you can create it by entering touch

/.ssh/config in the terminal.

Enter the following text into the file, replacing example.com with your server’s domain name or IP:

Warning: You may be tempted to use a wildcard like Host * to just apply this setting to all SSH connections. That’s not really a good idea, as you’d be sharing your local SSH keys with every server you SSH into. They won’t have direct access to the keys, but they will be able to use them as you while the connection is established. You should only add servers you trust and that you intend to use with agent forwarding.

Testing SSH agent forwarding

To test that agent forwarding is working with your server, you can SSH into your server and run ssh -T git@github.com once more. If all is well, you’ll get back the same prompt as you did locally.

If you’re unsure if your local key is being used, you can also inspect the SSH_AUTH_SOCK variable on your server:

If the variable is not set, it means that agent forwarding is not working:

Troubleshooting SSH agent forwarding

Here are some things to look out for when troubleshooting SSH agent forwarding.

You must be using an SSH URL to check out code

SSH forwarding only works with SSH URLs, not HTTP(s) URLs. Check the .git/config file on your server and ensure the URL is an SSH-style URL like below:

Your SSH keys must work locally

Before you can make your keys work through agent forwarding, they must work locally first. Our guide on generating SSH keys can help you set up your SSH keys locally.

Your system must allow SSH agent forwarding

Sometimes, system configurations disallow SSH agent forwarding. You can check if a system configuration file is being used by entering the following command in the terminal:

In the example above, the file

/.ssh/config is loaded first, then /etc/ssh_config is read. We can inspect that file to see if it’s overriding our options by running the following commands:

In this example, our /etc/ssh_config file specifically says ForwardAgent no , which is a way to block agent forwarding. Deleting this line from the file should get agent forwarding working once more.

Your server must allow SSH agent forwarding on inbound connections

Agent forwarding may also be blocked on your server. You can check that agent forwarding is permitted by SSHing into the server and running sshd_config . The output from this command should indicate that AllowAgentForwarding is set.

Your local ssh-agent must be running

On most computers, the operating system automatically launches ssh-agent for you. On Windows, however, you need to do this manually. We have a guide on how to start ssh-agent whenever you open Git Bash.

To verify that ssh-agent is running on your computer, type the following command in the terminal:

Your key must be available to ssh-agent

You can check that your key is visible to ssh-agent by running the following command:

If the command says that no identity is available, you’ll need to add your key:

On macOS, ssh-agent will «forget» this key, once it gets restarted during reboots. But you can import your SSH keys into Keychain using this command:

Help us make these docs great!

All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.

Источник

Про SSH Agent

Введение

SSH-agent является частью OpenSSH. В этом посте я объясню, что такое агент, как его использовать и как он работает, чтобы сохранить ваши ключи в безопасности. Я также опишу переадресацию агента и то, как она работает. Я помогу вам снизить риск при использовании переадресации агента и поделюсь альтернативой переадресации агента, которую вы можете использовать при доступе к своим внутренним хостам через bastion’ы.

Что такое SSH-agent

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

Агент SSH хранит секретные ключи в безопасности из-за того, что он не делает:

• Он не записывает никакой информации о ключах на диск.
• Он не позволяет экспортировать ваши личные ключи.

Секретные ключи, хранящиеся в Агенте, могут использоваться только для одной цели: подписания сообщения.

Но если агент может только подписывать сообщения, как SSH шифрует и расшифровывает трафик?

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

Например, вот как проверяется ключ пользователя во время SSH-соединения, с точки зрения сервера:

• Клиент предоставляет серверу публичный ключ.
• Сервер генерирует и отправляет короткое случайное сообщение, прося клиента подписать его с помощью приватного ключа.
• Клиент просит агента SSH подписать сообщение и пересылает результат обратно на сервер.
• Сервер проверяет подпись, используя публичный ключ клиента.
• Теперь у сервера есть доказательство того, что клиент владеет приватным ключом.

Позже в процессе соединения генерируется набор новых, эфемерных и симметричных ключей, которые используются для шифрования трафика сеанса SSH. Эти ключи могут даже не длиться весь сеанс; событие «rekey» происходит через регулярные промежутки времени.

Протокол агента

SSH использует сокет домена Unix для общения с агентом по протоколу SSH agent. Большинство людей используют ssh-agent , который поставляется с OpenSSH, но есть множество альтернатив с открытым исходным кодом.

Протокол агента настолько прост, что можно было бы написать базовый SSH-agent за день или два. Он имеет только несколько основных операций:

• Добавить обычную пару ключей (публичный и расшифрованный приватный ключи)
• Добавить ограниченную пару ключей (публичный и расшифрованный приватный ключи)
• Добавить ключ (обычный или ограниченный) из смарт-карты (только публичный ключ)
• Удалить ключ
• Вывод списка ключей, хранящихся в агенте
• Подпись сообщения ключом, хранящимся в агенте
• Блокировка или разблокировка всего агента с помощью пароля

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

Команда ssh-add — это ваш шлюз к агенту SSH. Он выполняет все эти операции, кроме подписи. Когда вы запускаете ssh-add без каких-либо параметров, он будет сканировать ваш домашний каталог на наличие некоторых стандартных ключей и добавлять их в ваш агент. По умолчанию он ищет:

/.ssh/id_ecdsa

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

ssh-агент и macOS Keychain
ssh-agent , поставляемый вместе с macOS, может хранить парольную фразу для ключей в macOS Keychain, что делает еще более простым повторное добавление ключей к агенту после перезагрузки. В зависимости от настроек Keychain вам все равно может потребоваться разблокировать его после перезагрузки. Чтобы сохранить ключевые парольные фразы в Keychain, выполните команду ssh-add -K [имя файла ключа] . Парольные фразы обычно хранятся в «Local Items». ssh-agent будет использовать эти сохраненные парольные фразы автоматически по мере необходимости.

Что такое переадресация агента

Функция переадресации агента позволяет вашему локальному агенту SSH связаться через существующее SSH-соединение и прозрачно аутентифицироваться на более удаленном сервере. Например, предположим, что вы входите по SSH в инстанс EC2 и хотите клонировать оттуда приватный репозиторий GitHub. Без переадресации агента вам придется хранить копию вашего приватного ключа GitHub на хосте EC2. При переадресации агента SSH-клиент на EC2 может использовать ключи на вашем локальном компьютере для аутентификации на GitHub.

Как работает переадресация агента

Во-первых, немного предыстории. SSH-соединения могут иметь несколько каналов. Вот распространенный пример: интерактивное соединение с bastion-host (jump box) выполняется на одном канале. Когда для соединения включена переадресация агента (обычно с использованием ssh -A ), в фоновом режиме открывается второй канал для переадресации любых запросов агента обратно на ваш локальный компьютер.

С точки зрения ssh , нет никакой разницы между удаленным и локальным ssh-agent . SSH всегда смотрит на переменную окружения $SSH_AUTH_SOCK , чтобы найти доменный сокет Unix для агента. При подключении к удаленному хосту с включенной переадресацией агента SSHD создаст удаленный доменный сокет Unix, связанный с каналом переадресации агента, и экспортирует $SSH_AUTH_SOCK , указывающий на него.

Переадресация агента связана с определенным риском

Когда вы переадресовываете доменный сокет ssh-agent Unix на удаленный хост, это создает угрозу безопасности: любой человек с root доступом на удаленном хосте может незаметно получить доступ к вашему локальному SSH-agent’y через сокет. Они могут использовать ваши ключи, чтобы выдавать себя за вас на других машинах в сети.

Вот пример того, как это может выглядеть:

Как снизить свой риск при переадресации агента

Вот несколько способов сделать переадресацию агента более безопасной:

• Не включайте ForwardAgent по умолчанию.

Заблокируйте свой ssh-агент, когда вы используете переадресацию агента. ssh-add -x блокирует агент паролем, а ssh-add -X разблокирует его. Когда вы подключены к удаленному хосту с переадресацией агента, никто не сможет проникнуть в ваш агент без пароля.

Или используйте альтернативный агент SSH, который запрашивает вас, когда он используется. Sekey использует Touch ID на macOS для хранения ключей в анклаве безопасности MacBook Pro.

Или вообще не используйте переадресацию агента. Если вы пытаетесь получить доступ к внутренним хостам через bastion, ProxyJump — гораздо более безопасная альтернатива для этого варианта использования. (смотреть ниже)

Используйте ProxyJump : более безопасная альтернатива

Когда вы хотите пройти через bastion-host (jumpbox), вам действительно не нужна переадресация agent’a. Лучший подход — использовать директиву ProxyJump .

Вместо того чтобы перенаправлять agent’a по отдельному каналу, ProxyJump перенаправляет стандартный вход и выход вашего локального SSH-клиента через bastion и далее на удаленный хост. Вот как это работает:

1. Запустите ssh -J bastion.example.com cloud.computer.internal для подключения к cloud.computer.internal через ваш bastion хост — bastion.example.com . cloud.computer.internal — это имя хоста, которое можно найти с помощью поиска DNS на bastion.example.com .
2. Ваш SSH клиент использует ключи от вашего агента для подключения к bastion.example.com .
3. После подключения SSHD к bastion подключается к cloud.computer.internal и передает это соединение вашему локальному SSH-клиенту.
4. Ваш локальный SSH-клиент снова проходит через соединение, на этот раз с cloud.computer.internal

Вы можете думать об этом как о SSH в сеансе SSH; за исключением того, что ssh никогда не запускается на bastion. Вместо этого sshd подключается к cloud.computer.internal и дает контроль над этим соединением (стандартный вход и выход) обратно в ваш локальный SSH, который затем выполняет второе соединение.

Скажем bastion-host это bastion.example.com . Я могу настроить свой

Затем я просто запускаю ssh cloud.computer.internal для подключения к внутреннему назначению через bastion — без переадресации агента.

Если ProxyJump не работает…

Более старые версии SSH и SSHD (до версии 7.2, выпущенной в 2016 году) не поддерживают ProxyJump . Но вы можете выполнить эквивалентную операцию, используя ProxyCommand и netcat. Вот вам пример:

Магия здесь заключается в том, что SSH сам по себе является прокси-сервером, который вы используете для SSH. Часть nc %h %p просто открывает необработанное соединение сокета к cloud.computer.internal на порте 22. Стандартный ввод-вывод родительской команды ssh передается прямо в ProxyCommand , чтобы родительский ssh мог аутентифицироваться на внутреннем хосте через прокси-соединение.

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя онлайн-курсы SkillFactory:

Источник