← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-tunnel / use-cases / ssh

SSH s Access for Infrastructure

Access for Infrastructure poskytuje podrobnou kontrolu nad tím, jak se uživatelé mohou připojovat k vašim SSH serverům. Stejně jako self-managed SSH klíče metody se na zařízeních uživatelů používá Cloudflare One Client a na serveru Cloudflare Tunnel, čímž vzniká zabezpečené soukromé připojení přes síť Cloudflare. Access for Infrastructure přidává zásady na úrovni aplikace s ovládacími prvky pro jednotlivé cíle a uživatelská jména, a to včetně protokolování příkazů SSH.

Access for Infrastructure navíc nahrazuje tradiční SSH klíče krátkodobými certifikáty, které se uživatelům vydávají na základě tokenu vygenerovaného při přihlášení přes Access. V tradičních modelech si uživatelé vygenerují pár SSH klíčů a administrátoři udělují přístup k jednotlivým SSH serverům nasazením veřejných klíčů uživatelů na tyto servery. Tyto SSH klíče pak na serverech zůstávají beze změny měsíce i roky. Cloudflare Access uživatele zbavuje starosti se správou SSH klíčů a zároveň zvyšuje zabezpečení tím, že dlouhodobé SSH klíče nahrazuje krátkodobými efemérními SSH certifikáty.

1. V Cloudflare dashboardu přejděte na Sítě > Tunnels.

   Přejděte na Tunnels ↗

2. Vytvořit nový tunel nebo upravit existující cloudflared tunel.

3. V Cloudflare dashboardu přejděte na Sítě > Trasy.

   Přejděte na Trasy ↗

4. Vyberte Vytvořit trasu > Tunnel CIDR. Vyberte právě vytvořený tunel, zadejte IP adresu nebo adresu CIDR svého serveru (obvykle jde o privátní IP adresu, povoleny jsou ale i veřejné) a vyberte Vytvořit trasu.

Chcete-li připojit svá zařízení ke Cloudflare:

1. Nasaďte Cloudflare One Client na vašich zařízeních v režimu Traffic and DNS.
2. Povolte proxy Gateway pro TCP.
3. Vytvořit pravidla registrace zařízení určit, která zařízení se mohou zaregistrovat do vaší organizace Zero Trust.

WARP ve výchozím nastavení vylučuje provoz směřující na Prostor RFC 1918 ↗, což jsou IP adresy, které se obvykle používají v privátních sítích a nejsou dostupné z internetu. Aby mohl Cloudflare One Client odesílat provoz na váš SSH server, musíte nakonfigurovat Split Tunnels tak, aby IP/CIDR vašeho serveru SSH směrovala přes Cloudflare One Client.

1. Nejprve zkontrolujte, zda váš Režim Split Tunnels je nastaveno na Vyloučit nebo Include režimu.

2. Upravte trasy Split Tunnel podle režimu:

   Pokud používáte Vyloučit režimu:

   a. Odstraňte trasu obsahující rozsah IP/CIDR vašeho SSH serveru. Pokud například vaše síť používá výchozí rozsah AWS 172.31.0.0/16, smažte 172.16.0.0/12.

   b. Znovu přidat rozsahy IP/CIDR které váš server SSH výslovně nepoužívá. Pro výše uvedený příklad AWS byste přidali nové položky pro 172.16.0.0/13, 172.24.0.0/14, 172.28.0.0/15, a 172.30.0.0/16. Tím se zajistí, že pouze provoz na 172.31.0.0/16 tras přes Cloudflare One Client.

   K určení, které IP adresy je třeba znovu přidat, můžete použít následující kalkulačku:

   Base CIDROdečtené rozsahy CIDR

   Vypočítat

   Pokyny ke kalkulačce

   1. V Base CIDR, zadejte rozsah RFC 1918, který jste odstranili ze Split Tunnels.
   2. V Odečtené rozsahy CIDR, zadejte rozsah IP/CIDR používaný vaším serverem SSH.
   3. Znovu přidejte výsledky kalkulačky do seznamu režimu Split Tunnel Exclude.

   Zúžením rozsahu privátních IP adres zahrnutých v Cloudflare One Client snížíte riziko narušení uživatelova přístup k místním prostředkům.

   Pokud používáte Include režimu:

   1. Přidejte požadované Domény Zero Trust nebo IP adresy do seznamu Split Tunnel include.
   2. Přidejte trasu tak, aby to zahrnovalo rozsah IP/CIDR vašeho SSH serveru.

Cíl představuje jeden konkrétní prostředek ve vaší infrastruktuře (například server, cluster Kubernetes, databázi nebo kontejner), ke kterému se uživatelé připojují prostřednictvím Cloudflare.

Cíle jsou nezávislé na protokolu, což znamená, že pro každý protokol běžící na serveru není nutné definovat nový cíl. Postup vytvoření nového cíle:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/infrastructure/targets" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"hostname": "infra-access-target",
		"ip": {
				"ipv4": {
						"ip_addr": "187.26.29.249",
						"virtual_network_id": "c77b744e-acc8-428f-9257-6878c046ed55"
				},
				"ipv6": {
						"ip_addr": "64c0:64e8:f0b4:8dbf:7104:72b0:ec8f:f5e0",
						"virtual_network_id": "c77b744e-acc8-428f-9257-6878c046ed55"
				}
		}
	}'

Dále vytvořte aplikaci Access k zabezpečení cíle.

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Example infrastructure app",
		"type": "infrastructure",
		"target_criteria": [
				{
						"target_attributes": {
								"hostname": [
										"infra-access-target"
								]
						},
						"port": 22,
						"protocol": "SSH"
				}
		],
		"policies": [
				{
						"name": "Allow a specific email",
						"decision": "allow",
						"include": [
								{
										"email": {
												"email": "[email protected]"
										}
								}
						],
						"connection_rules": {
								"ssh": {
										"usernames": [
												"root",
												"ec2-user"
										]
								}
						}
				}
		]
	}'

Cíle v této aplikaci jsou nyní zabezpečeny vašimi zásadami infrastruktury.

Provoz z Cloudflare One Client k cílům vaší infrastruktury je filtrován oběma Síťové zásady Gateway a zásady Access specifické pro aplikaci.

Abyste uživatelům Cloudflare One Client zabránili v přístupu k celé vaší privátní síti, doporučujeme vytvořit obecná bloková zásada Gateway pro váš soukromý IP prostor. Poté můžete přidat zásady Povolit s vyšší prioritou (v Access nebo Gateway), které uživatelům udělí přístup ke konkrétním aplikacím nebo IP adresám.

Cloudflare ve výchozím nastavení vyhodnotí zásady aplikace Access až po vyhodnocení všech Síťové zásady Gateway. Chcete-li vyhodnocovat aplikace Access před nebo po konkrétních zásadách Gateway:

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Zásady provozu > Zásady brány firewall. V Síť, vytvořit síťovou zásadu s následující konfigurací:

   Selektor	Operátor	Hodnota	Akce
   Access Infrastructure Target	je	Present	Allow

2. Aktualizujte zásady pořadí priority pomocí dashboardu nebo API.

Tato zásada Gateway se použije na všechny cíle Access for Infrastructure, včetně RDP a SSH.

Dále nakonfigurujte svůj SSH server tak, aby důvěřoval Cloudflare SSH CA. To umožní Access ověřovat pomocí krátkodobých certifikátů namísto tradičních SSH klíčů.

Chcete-li vygenerovat Cloudflare SSH CA a získat její veřejný klíč:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/gateway_ca" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/gateway_ca" \
	--request GET \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

1. Pomocí následujícího příkazu přejděte do adresáře konfigurace SSH na vzdáleném cílovém počítači:

   cd /etc/ssh

2. Jakmile se tam dostanete, můžete pomocí následujícího příkazu vygenerovat soubor a zároveň otevřít textový editor pro zadání nebo vložení veřejného klíče.

   vim ca.pub

3. V ca.pub soubor a vložte veřejný klíč bez jakýchkoli úprav.

   ca.pub

   ecdsa-sha2-nistp256 <redacted> [email protected]

   ca.pub soubor může obsahovat více klíčů, každý na samostatném řádku. Prázdné řádky a komentáře začínající # jsou také povoleny.

4. Uložte ca.pub soubor. V některých systémech může být podle vašich oprávnění nutné použít následující příkaz k vynucení uložení souboru:

   :w !sudo tee %
   :q!

Nakonfigurujte svůj server SSH tak, aby důvěřoval Cloudflare SSH CA, a to úpravou sshd_config soubor na vzdáleném cílovém počítači.

1. Když se nacházíte v /etc/ssh adresář na vzdáleném počítači otevřete sshd_config .

    sudo vim /etc/ssh/sshd_config

2. Stiskněte i přejít do režimu vkládání a poté přidat následující řádky na začátek souboru, nad všechny ostatní direktivy:

   PubkeyAuthentication yes
   TrustedUserCAKeys /etc/ssh/ca.pub

3. Stiskněte esc a poté zadejte :x a stiskněte Enter a uložit a ukončit.

Jakmile upravíte svůj sshd konfiguraci restartujte službu SSH na vzdáleném počítači, aby se změny projevily.

sudo systemctl reload ssh

sudo systemctl reload sshd

Před připojením k serverům SSH můžete od uživatelů vyžadovat ověření klíčem PIV nebo FIDO2. Při konfiguraci vlastního MFA vyberte Klíč PIV, Klíč FIDO2, nebo obojí.

Chcete-li nakonfigurovat nezávislé MFA pro SSH, více informací najdete v Vynuťte MFA pro infrastrukturní aplikace.

Než se uživatelé budou moci připojit se zapnutým MFA, musí zaregistrovat svůj klíč a nakonfigurovat svého SSH klienta.

• U klíčů PIV, zaregistrovat klíč a nakonfigurovat klienta SSH.
• U klíčů FIDO2, zaregistrovat klíč a nakonfigurovat klienta SSH.

Když uživatel spustí ssh <username>@<target IP>, SSH proxy zkontroluje, zda odpovídající zásada vyžaduje MFA. Pokud ano, uživatel se ověří pomocí svého hardwarového klíče. To, zda klíč vyžádá dotyk, PIN, nebo obojí, závisí na vámi nakonfigurovaných zásadách klíče PIV nebo na vlastní konfiguraci klíče FIDO2. Proxy poté dokončí připojení.

Uživatelé mohou při přihlášení do Cloudflare One Client použít jakéhokoli klienta SSH. Pokud cíl používá virtuální síť, připojit se k této virtuální síti nejprve.

ssh <username>@<target IP>

Access for Infrastructure také podporuje scp, sftp, a rsync příkazy. Podívejte se na Známá omezení pro seznam nepodporovaných příkazů a funkcí SSH.

Chcete-li se dozvědět více o připojeních uživatelů, přečtěte si Dokumentace k Access for Infrastructure.

Protokoly příkazů SSH obsahují skutečné příkazy SSH, které uživatel spustil na cílovém zařízení. Zákazníci na všech tarifech mohou protokoly SSH ukládat na Cloudflare a stahovat je z dashboardu. Protokoly ke stažení jsou šifrovány veřejným klíčem poskytnutým zákazníkem a nejsou viditelné pro Cloudflare. Doručení stažitelných protokolů SSH probíhá v režimu best effort; pro zaručené doručení mohou zákazníci s plánem Enterprise nakonfigurovat úlohu Logpush k odesílání protokolů SSH do cílových úložišť. Payloady Logpush nejsou šifrovány veřejným klíčem poskytnutým zákazníkem.

Podle těchto pokynů zašifrujte a stáhněte protokoly příkazů SSH ze Zero Trust.

Chcete-li zaznamenávat příkazy SSH, budete muset vygenerovat pár klíčů HPKE a nahrát veřejný klíč do Cloudflare.

1. Stáhnout ↗ Cloudflare ssh-log-cli nástroj.

2. Pomocí ssh-log-cli nástroje vygenerujte pár veřejného a soukromého klíče.

   ./ssh-log-cli generate-key-pair -o sshkey
   ls

   README.md    ssh-log-cli    sshkey    sshkey.pub

   Tento příkaz vypíše dva soubory, sshkey.pub veřejný klíč a odpovídající sshkey soukromý klíč.

3. V Cloudflare dashboard ↗, přejděte na Zero Trust > Zásady provozu > Nastavení provozu.

4. V Veřejný klíč pro šifrování protokolů SSH, vložte obsah sshkey.pub a vyberte Save.

Všechny proxované příkazy SSH se okamžitě šifrují pomocí tohoto veřejného klíče. K zobrazení protokolů je potřeba odpovídající soukromý klíč.

Chcete-li vypnout protokolování příkazů SSH, odstraňte svůj nahraný veřejný klíč:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/audit_ssh_settings" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"public_key": ""
	}'

Protokoly příkazů SSH nejsou viditelné přímo v dashboardu, je nutné je exportovat a dešifrovat.

Chcete-li ručně načíst protokoly:

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Insights > Protokoly.
2. Vyberte Protokoly příkazů SSH.
3. Filtrujte protokoly pomocí názvu vaší Aplikace SSH.
4. Vyberte SSH relaci, pro kterou chcete exportovat protokoly příkazů.
5. V bočním panelu přejděte dolů na Protokoly SSH a vyberte Stáhnout.

6. Chcete-li dešifrovat protokol, postupujte podle pokynů v Repozitář SSH Logging CLI ↗. V následujícím příkladu sshkey je soukromý klíč odpovídající veřejnému klíči nahranému do Cloudflare.

   ./ssh-log-cli decrypt -i sshlog -k sshkey

   Tento příkaz vypíše sshlog-decrypted.zip soubor s dešifrovanými protokoly.

Cloudflare umožňuje odesílat protokoly příkazů SSH do cílových úložišť nakonfigurovaných v Logpush, včetně cílů třetích stran. Seznam dostupných datových polí najdete v Datová sada protokolů SSH.

Informace o nastavení úlohy Logpush najdete v Integrace Logpush.

Následující funkce SSH nejsou podporovány:

• Lokální a vzdálené přesměrování portů
• ProxyJump
• Přeposílání agenta SSH
• Přesměrování X11

Relace SSH mají očekávanou maximální délku 10 hodin. Další informace najdete v Odstraňování problémů s Access.

Pokud se nelze připojit k vašemu SSH endpointu, může to mít více příčin. Pomocí následujících kroků zjistíte a odstraníte příčinu problému s připojením.

1. Ověřte, že vaše zásady Access umožňují uživateli přístup k cíli.
2. Zkontrolujte Cloudflare Tunnel stav.
3. Ověření existence uživatele na serveru.
4. Zkontrolujte svůj sshd_config soubor na nesprávnou konfiguraci.

Uživateli může zásada Access zabránit v přístupu k vašemu serveru, pokud neexistuje žádná explicitní zásada Access s akcí allow a Access je nastaveno tak, aby uživatele ve výchozím stavu odmítalo.

Jako koncový uživatel spusťte warp-cli target list k ověření, že máte přístup k cíli.

warp-cli target list

╭──────────────────────────────────────┬──────────┬───────┬───────────────────────┬──────────────────────┬────────────╮
│ Target ID                            │ Protocol │ Port  │ Attributes            │ IP (Virtual Network) │ Usernames  │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 0193f22a-9df3-78e3-b5bb-7ab631903306 │ SSH      │ 22    │ hostname: do-target   │ 10.116.0.3 (a1net)   │ alice      │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 0193f22a-9df3-78e3-b5bb-7ab631903306 │ SSH      │ 23    │ hostname: do-target   │ 10.116.0.3 (a1net)   │ root       │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 01943cff-6130-7989-8bff-cbc02b59a2b1 │ SSH      │ 80    │ hostname: az-target   │ 172.16.0.0 (b1net)   │ alice, bob │
╰──────────────────────────────────────┴──────────┴───────┴───────────────────────┴──────────────────────┴────────────╯

• Pokud se cíl v seznamu zobrazuje, ověřte, že uživatelské jméno, se kterým se pokoušíte připojit, je zobrazeno ve výstupu. Pokud uživatelské jméno zobrazeno není, musí administrátor najít zásadu Access přiřazenou k danému cíli a přidat do ní toto uživatelské jméno. Administrátor měl vytvořit zásadu Access v dílčí krok 9 kroku 5: Přidání infrastrukturní aplikace. Pokud se zobrazí uživatelské jméno, znamená to, že by zásada Access měla udělovat přístup, a měli byste ověřit, že je tunel v pořádku (healthy) v krok 2.

• Pokud se cíl v seznamu nezobrazuje, musí administrátor zkontrolovat zásady Access pro daný cíl v Cloudflare One a zjistit případnou chybnou konfiguraci, která by mohla blokovat připojení.

Jako správce místo spouštění warp-cli target list na zařízení koncového uživatele můžete pomocí protokolů Access zjistit, zda potíže s připojením nezpůsobuje zásada Access. Kontrola protokolů se hodí při řešení problémů s připojením jménem koncového uživatele.

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Insights > Protokoly.

2. Vyberte Protokoly ověřování Access.

3. Vyberte aplikaci, kterou testujete, nebo filtrujte Infrastruktura jako App Type.

4. Zkontrolujte Rozhodnutí. Pokud Rozhodnutí je Access denied, vyberte aplikaci a zkopírujte její název ve sloupci App.

   Pokud je rozhodnutí Access granted, zásady Access nezasahují do vašich pokusů o připojení a že problém s připojením způsobuje Cloudflare Tunnel (krok 2), server SSH (krok 3), nebo sshd_config soubor (krok 4).

5. Přejděte na Řízení přístupu > Aplikace.

6. Do vyhledávacího pole zadejte název aplikace a aplikaci vyberte.

7. Vyberte Konfigurovat.

8. Přejděte na Zásady a zjistit, jaká kritéria mohou uživatele blokovat.

Přidáním Access zásada a povolte uživatele, problém s připojením by se tím měl vyřešit. Po uložení změn zásady se pokuste připojit k serveru.

Pokud máte i po kontrole zásad Access stále problémy s připojením, zkontrolujte stav tunelu v následujícím kroku.

Pokud se koncový uživatel nemůže připojit k cíli, tunel, který jste nastavili v Krok 1: Připojte server ke Cloudflare může být nedostupný nebo neaktivní.

Chcete-li zkontrolovat stav vašeho tunelu:

1. V Cloudflare dashboardu přejděte na Sítě > Trasy.

   Přejděte na Trasy ↗

2. Vyhledejte svou IP adresu a zjistěte trasu a přidružený tunel.

   Tato IP adresa bude viditelná v warp-cli target list výstup v předchozí krok. Pokud jste správcem, můžete také přejít do Sítě > Cíle a najděte IP adresu vedle svého hostitelského názvu.

3. Vyberte název tunelu v Connector sloupec a otevřete stránku podrobností tunelu.

4. Zkontrolujte, že Stav tunelu uvádí Active, a ne Down, Degraded, nebo Inactive.

Podrobné kroky k řešení potíží najdete v Dokumentace k odstraňování problémů s Tunnel. Zkontrolujte Dokumentace k tunelu s firewallem zajistit, že je vaše síť správně nakonfigurována tak, aby umožňovala cloudflared připojení.

Po ověření, že stav tunelu nevykazuje žádné problémy, potvrďte v následujícím kroku existenci uživatele na serveru.

Chcete-li ověřit existenci uživatele na serveru UNIX, spusťte id <USERNAME> příkaz na serveru a ověřte, že uživatelské jméno existuje. Pokud neexistuje, musíte uživatele na server přidat.

Pokud uživatel na serveru existuje, laďte své sshd_config soubor v následujícím kroku.

Jedním z důvodů, proč se uživateli nedaří připojit k vašemu SSH endpointu, může být nesprávně nakonfigurovaný sshd_config soubor. Podle níže uvedených kroků zkontrolujte svůj sshd_config soubor kvůli nesprávné konfiguraci.

sshd protokoly mohou potvrdit, zda se uživatel k serveru dostává, či nikoli. Umístění vašich sshd protokolů je definováno ve vašem sshd_config. Umístění protokolů bude pravděpodobně journalctl -u ssh na Ubuntu a tail /var/log/auth.log pro Red Hat.

Pomocí sshd protokolech ověřte, že se pokusy o připojení SSH k serveru dostávají.

Chcete-li vyloučit případné problémy ve své sshd_config soubor, porovnejte svůj stávající sshd_config soubor s příkladem níže a ověřte, zda některé direktivy nezpůsobují problémy s ověřováním. Následující příklad sshd_config soubor povede k úspěšnému ověření:

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

PubkeyAuthentication yes
TrustedUserCAKeys /etc/ssh/ca.pub

Include /etc/ssh/sshd_config.d/*.conf

# When systemd socket activation is used (the default), the socket
# configuration must be re-generated after changing Port, AddressFamily, or
# ListenAddress.
#
# For changes to take effect, run:
#
#   systemctl daemon-reload
#   systemctl restart ssh.socket
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
LogLevel DEBUG3

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10



# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile    .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

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

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

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

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin yes
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

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

# override default of no subsystems
Subsystem    sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server

Pokud váš sshd protokoly ukazují, že certifikát byl přijat jako podepsaný CA, ale připojení přesto selhává, účet pravděpodobně neautorizuje subjekt (principal) certifikátu. sshd to hlásí jako:

Certificate invalid: name is not a listed principal

Zkontrolujte efektivní konfiguraci účtu, ke kterému se připojujete, protože tyto direktivy bývají často nastavené v Match blok:

sudo sshd -T -C user=<USERNAME> | grep -i principals

Pokud authorizedprincipalsfile nebo authorizedprincipalscommand je nastaveno na jinou hodnotu než none, ověřte, že se uživatelské jméno SSH nachází v daném souboru nebo ve výstupu příkazu. Pokud chybí, přidejte je a ověřte konfiguraci pomocí sudo sshd -t, poté znovu načíst server SSH.

Následující kroky vás provedou postupem řešení problémů. Dočasně nahradíte stávající sshd_config soubor s poskytnutým příkladem, abyste vyloučili problémy s konfigurací. Než budete pokračovat, pečlivě zkontrolovat a porovnat oba soubory a identifikovat případné protichůdné direktivy.

1. Zálohujte stávající sshd_config .

   mv /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

2. Vytvořte nový sshd_config .

   vi /etc/ssh/sshd_config

3. Do režimu vkládání přejdete stisknutím i klávesu na klávesnici.

4. Vložte do ukázkový soubor.

5. Režim vkládání ukončíte stisknutím klávesy Escape (esc) klíč.

6. Zadejte :x a uložit a ukončit.

7. Znovu načíst server SSH.

   Jakmile upravíte svůj sshd konfiguraci restartujte službu SSH na vzdáleném počítači, aby se změny projevily.

   Pro Debian/Ubuntu:

   sudo systemctl reload ssh

   Pro CentOS/RHEL 7 a novější:

   sudo systemctl reload sshd

Po dokončení všech čtyř kroků řešení problémů byste měli mít vyřešené veškeré problémy s připojením způsobené nesprávnou konfigurací SSH serveru. Pokud problémy přetrvávají, znovu zkontrolovat sshd protokoly. Příklad sshd_config sdílené výše zapíná ladicí protokolování a může odhalit podrobnější problémy.

Aby bylo řešení problémů co nejrychlejší, uveďte v žádosti o podporu co nejpodrobnější informace. Čím více souvislostí poskytnete, tím rychleji lze problém identifikovat a vyřešit.

Aby bylo zajištěno efektivní přeložení, když kontaktování podpory, uveďte ve svém ticketu co nejvíce relevantních podrobností:

• Kontext: Stručně popište scénář nebo případ použití (například kde uživatel byl a o co se pokoušel).

• Kroky pro reprodukci: Popište kroky, kterými jste problém během řešení potíží reprodukovali.

• Časová razítka: buďte konkrétní a uveďte přesný čas a časové pásmo, kdy problém nastal.

• Pokusy o řešení potíží: popište kroky nebo změny, které jste už k vyřešení problému vyzkoušeli.

• sshd protokoly na úrovni debug: Připojte příznak sshd protokoly, které jste shromáždili v Krok 4: Ladění sshd_config nesprávná konfigurace souboru.

• sshd_config soubor: Přiložte kopii svého serveru sshd_config a pomoci identifikovat případné nesprávné konfigurace nebo protichůdné direktivy.

• Výstup SSH na straně klienta: Spusťte selhávající příkaz SSH s podrobnými příznaky (-vvv) a zahrňte úplný výstup terminálu, který ukazuje pokusy o připojení a ověření ze strany klienta.