Több SSH-kulcs kezelése

Nyugodtan mondhatjuk, hogy a webes szféra legtöbb fejlesztője valamikor találkozott az SSH-val. Az SSH az egyik leggyakrabban használt protokoll a biztonságos adatcseréhez. Az SSH-t használja a távoli szerverekhez való csatlakozáshoz, amely magában foglalja a kód kezelését a Git használatával és a szinkronizálást a távoli tárházakkal is.

Annak ellenére, hogy bevett gyakorlatnak számít, ha eszközönként egy magán-nyilvános kulcs pár van, néha több kulcsot is használnia kell, és / vagy unortodox kulcsnevekkel rendelkezik.

Lehet, hogy egy SSH kulcskapcsolót használ a vállalata belső projektjeihez, de előfordulhat, hogy egy másik kulcsot használ egyes vállalati szerverek eléréséhez. Lehet, hogy még egy másik kulcsot is használ a saját privát kiszolgáló eléréséhez.

Az SSH kulcsok kezelése nehézkessé válhat, amint egy második kulcsot kell használnia. Remélem, hogy ez a cikk mindenkinek segítséget nyújt, akinek problémái vannak az SSH kulcskezeléssel.

Feltételezem, hogy az olvasónak alapvető ismeretei vannak a Gitről és az SSH-ról. A cikkben a legtöbb példa a Git használatát fogja használni. Természetesen mindez bármilyen más SSH kommunikációra is érvényes lesz. Ennek ellenére van néhány Git-specifikus trükk.

Szíj be, tessék!

Egy SSH-kulcs kezelése

Először is nézzük meg, milyen lehet a munkafolyamat, mielőtt több kulcsot kellene aggódnunk.

Egy privát kulcs van tárolva ~/.ssh/id_rsaa megfelelő nyilvános kulccsal ~/.ssh/id_rsa.pub.

Képzeljük el, hogy a kódváltozásokat egy távoli Git-kiszolgálóra akarja tolni / húzni - mondja GitHub, miért ne. Ehhez először hozzá kell adnia nyilvános kulcsát a GitHubhoz.

Nem lépem át ezt a lépést, elég könnyűnek kell lennie, hogy megtudja, hogyan kell ezt megtenni. Azt is feltételeztem, hogy a neved Steve, és egy szigorúan titkos projekten dolgozol, amely Raspberry Pies-t használ a hálózati forgalom szippantására.

A munka megkezdéséhez klónoznia kell egy git adattárat az SSH használatával:

git clone [email protected]:steve/raspberry-spy.git

Ebben a pillanatban a GitHub olyan lesz, mint: „Igen, ez egy privát adattár! Titkosítanunk kell a forgalmat az itt lévő nyilvános kulcsom és a magánkulcsod használatával.

Hozzáadta a nyilvános kulcsot a GitHub profiljához, de az SSH-nak valahogy ki kell találnia, hogy hol található a megfelelő magánkulcs.

Mivel fogalmunk sincs, melyik magánkulcsot kell használni az SSH-ra való belépéskor [email protected], az SSH kliens megpróbálja megtalálni a kulcsot az alapértelmezett helyen, ami ~/.ssh/id_rsa- ez a legjobb tippje. Ha az adott helyen nincs fájl, akkor hibaüzenetet kap:

Cloning into 'raspberry-spy'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

Ha van néhány magánkulcs fájlban tárolva ~/.ssh/id_rsa, az SSH kliens ezt a titkos kulcsot használja a kommunikáció titkosításához. Ha ez a kulcs jelszóval rendelkezik (ahogy annak lennie kell), akkor a rendszer jelszót kér, például:

Enter passphrase for key '/Users/steve/.ssh/id_rsa':

Ha a helyes jelszót adja meg, és ha ez a magánkulcs valóban megfelel annak a nyilvános kulcsnak, amelyet a profiljához csatolt, akkor minden rendben lesz, és az adattárat sikeresen klónozzuk.

De mi lenne, ha másképp nevezné el a kulcsát (pl. ~/.ssh/_id_rsa)? Az SSH kliens nem fogja tudni meghatározni, hogy hol tárolják a magánkulcsot. Ugyanazt a Permission denied ...hibát kapja, mint korábban.

Ha másként megnevezett magánkulcsot szeretne használni, manuálisan kell hozzáadnia:

ssh-add ~/.ssh/_id_rsa

A jelszó beírása után végrehajtással ellenőrizheti, hogy a kulcs hozzá lett-e adva az ssh-agent(SSH klienshez) ssh-add -l. Ez a parancs felsorolja az SSH-kliens számára jelenleg elérhető összes kulcsot.

Ha most megpróbálja klónozni az adattárat, az sikeres lesz.

Eddig jó?

Ha élénk szemű, elkezdhet észrevenni néhány lehetséges kérdést.

Először is, ha újraindítja a számítógépet, ssh-agentakkor újraindul, és hozzá kell adnia a nem alapértelmezett nevű kulcsokat az ssh-addegész újbóli felhasználásával, a jelszavak és az összes unalmas dolog beírásával.

Automatizálhatjuk-e a kulcsok hozzáadását, vagy valamilyen módon meghatározhatjuk, melyik kulcsot használjuk bizonyos szerverek elérésekor?

Valahogy elmenthetjük a jelszavakat, hogy ne kelljen minden alkalommal beírnunk őket? Ha csak lenne valami kulcstartó a jelszóval védett SSH kulcsok mentésére?.

Nyugodjon meg, minden kérdésre megvannak a válaszok.

Enter, SSH config

Mint kiderült, az SSH konfigurációs fájl egy olyan dolog, amely segíthet nekünk. Ez egy felhasználónkénti konfigurációs fájl az SSH kommunikációhoz. Hozzon létre egy új fájlt: ~/.ssh/configés nyissa meg szerkesztésre.

Egyéni nevű SSH kulcsok kezelése

Első dolog, amit a configfájl használatával megoldunk, az az , hogy ne kelljen egyedi nevű SSH kulcsokat hozzáadnunk a használatához ssh-add. Ha feltételezzük, hogy az SSH kulcs meg van nevezve ~/.ssh/_id_rsa, adja hozzá a következőt a configfájlhoz:

Host github.com HostName github.com User git IdentityFile ~/.ssh/_id_rsa IdentitiesOnly yes

Most ellenőrizze, hogy ~/.ssh/_id_rsaez nincs- ssh-agente végrehajtva ssh-add -D. Ez a parancs eltávolítja az összes kulcsot az aktív ssh-agentmunkamenetből. A munkamenet minden alkalommal kijelentkezik, amikor kijelentkezik vagy újraindít (vagy ha ssh-agentmanuálisan megöli a folyamatot). „Szimulálhatjuk” az újraindítást az említett parancs végrehajtásával.

Ha most megpróbálja klónozni a GitHub-adattárat, az ugyanaz lesz, mintha manuálisan adtuk volna hozzá a kulcsot (mint korábban). Kérni fogja a jelszót:

git clone [email protected]:steve/raspberry-spy.git Cloning into 'raspberry-spy'... Enter passphrase for key '/Users/steve/.ssh/_id_rsa':

Észrevette, hogy az a kulcs, amelynek jelszavát kérjük, ugyanaz a kulcs, amelyet a fájlunkban adtunk meg config. A helyes SSH kulcs jelszó megadása után a tárat sikeresen klónozzuk.

Megjegyzés: ha a sikeres klónozás után megpróbálja git pull, akkor újra meg kell adnia a jelszót. Ezt később megoldjuk.

Fontos, hogy az URI- Host github.comból configés github.comonnan induljon [email protected]:steve/raspberry-spy.git. Azt is megváltoztathatja config, hogy Host mygithubés klón URI [email protected]:steve/raspberry-spy.git.

This opens the floodgates. As you are reding this, your mind is racing and thinking about how all your troubles with SSH keys are over. Here are some useful configuration examples:

Host bitbucket-corporate HostName bitbucket.org User git IdentityFile ~/.ssh/id_rsa_corp IdentitiesOnly yes

Now you can use git clone [email protected]:company/project.git

Host bitbucket-personal HostName bitbucket.org User git IdentityFile ~/.ssh/id_rsa_personal IdentitiesOnly yes

Now you can use git clone [email protected]:steve/other-pi-project.git

Host myserver HostName ssh.steve.com Port 1111 IdentityFile ~/.ssh/id_rsa_personal IdentitiesOnly yes User steve IdentitiesOnly yes

Now you can SSH into your server using ssh myserver. How cool is that? You do not need to enter port and username manually every time you execute ssh command.

Bonus: Per-repository settings

You can also define which specific key should be used for certain repository, overriding anything in SSH config. Specific SSH command can be defined by setting sshCommand under core in /.git/config. Example:

[core] sshCommand = ssh -i ~/.ssh/id_rsa_corp

This is possible with git 2.10 or later. You can also use this command to avoid editing the file manually:

git config core.sshCommand 'ssh -i ~/.ssh/id_rsa_corp'

Password managemet

Last piece of the puzzle is managing passwords. We want to avoid having to enter password every time when SSH connection is initiating. To do so, we can utilize keychain management software that comes with MacOS and various Linux distributions.

Start by adding your key to the keychain by passing -K option to the ssh-add command:

ssh-add -K ~/.ssh/id_rsa_whatever

Now you can see your SSH key in the keychain. On MacOS it looks something like this:

Keychain Access

If you remove the keys from ssh-agent via ssh-add -D (this will happen when you restart your computer, as mentioned before) and try SSH-ing, you will be prompted for password again. Why? We just added the the key to the keychain. If you check Keychain Access again, you will notice that the key you added using ssh-add -K is still in the keychain. Weird, huh?

It turns out there is one more hoop to jump through. Open your SSH config file and add the following:

Host * AddKeysToAgent yes UseKeychain yes

Now, SSH will look for key in keychain and if it finds it you will not be prompted for password. Key will also be added to ssh-agent. On MacOS this will work on MacOS Sierra 10.12.2 or later. On Linux you can use something like gnome-keyring and it might work even without this last modification to SSH config. As for Windows - who knows, right?

I hope someone found this useful. Now go and configure your SSH config file!

Learn more about SSH:

  • The ultimate guide to SSH keys
  • A top-down introduction to SSH