html

The authorized_keys file in SSH serves as more than just a list of public keys - it's a powerful configuration tool with various security and access control options. Here's a deep dive into the available parameters:

from="192.168.1.*,example.com"
no-port-forwarding
no-X11-forwarding
no-agent-forwarding
no-pty

The from option supports:
• IP addresses (192.168.1.100)
• CIDR notation (192.168.1.0/24)
• Hostnames (*.example.com)
• Multiple entries (comma-separated)

command="/usr/bin/monitoring-script.sh",no-pty ssh-rsa AAAAB3NzaC1yc2E...

When combined with no-pty, this creates restricted access perfect for automated tasks. The command receives original input via SSH_ORIGINAL_COMMAND environment variable.

Backup server access with forced directory chroot:

command="rsync --server --sender -vlogDtpr . /backup/",no-pty,no-port-forwarding ssh-ed25519 AAAAC3NzaC...

Git deployment key with read-only repository access:

command="git-upload-pack '/repos/project.git'",no-pty,no-port-forwarding ssh-rsa AAAAB3NzaC...

environment="APP_ENV=production" ssh-rsa AAAAB3NzaC1yc2E...

Available environment options include:
• environment="KEY=value"
• permitlisten="host:port"
• permitopen="host:port"

For OpenSSH 7.2+:

restrict,port-forwarding,pty ssh-ed25519 AAAAC3NzaC...

The restrict keyword enables whitelist-style permissions, while cert-authority supports CA-signed certificates.

Check authorized_keys parsing with:

ssh-keygen -lf /path/to/authorized_keys

This validates syntax and displays fingerprint information for debugging.

The authorized_keys file in SSH is a powerful tool for managing secure access to your systems. While most developers are familiar with basic public key authentication, the advanced options available in this file are often underutilized.

Here are the fundamental options you can specify before a public key in your authorized_keys file:

from="domain.example.com" ssh-rsa AAAAB3NzaC...
command="/usr/local/bin/restricted_backup.sh" ssh-rsa AAAAB3NzaC...
no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB3NzaC...
no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC...

Beyond the basics, OpenSSH supports several advanced options:

# Restrict to specific source IP ranges
from="192.168.1.0/24,10.0.0.5" ssh-rsa AAAAB3NzaC...

# Set environment variables
environment="LANG=en_US.UTF-8" ssh-rsa AAAAB3NzaC...

# Force specific command with arguments
command="rsync --server --sender -vlogDtpr . /",no-pty,no-agent-forwarding ssh-rsa AAAAB3NzaC...

# Certificate-specific options
cert-authority,principals="dbadmin,backup" ssh-rsa AAAAB3NzaC...

Here's how you might implement these in real-world scenarios:

# Backup server access - only allows rsync operations
command="/usr/bin/rrsync /backups/",no-pty,no-agent-forwarding,no-port-forwarding ssh-rsa AAAAB3NzaC...

# Deployment key - restricted to git operations only
command="/usr/bin/git-shell -c \"$SSH_ORIGINAL_COMMAND\"",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC...

# Jump host restriction - only from corporate VPN
from="10.10.0.0/16",command="/bin/false",no-pty,no-port-forwarding ssh-rsa AAAAB3NzaC...

When using these options:

• Always test restrictions in a non-production environment first
• Combine multiple options for defense in depth
• Remember that command restrictions can sometimes be bypassed if not properly implemented
• Use certificate-based authentication for additional flexibility when needed

If your restrictions aren't working as expected, add this to your sshd_config:

LogLevel DEBUG3

Then check your auth logs to see exactly which restrictions are being applied during connection attempts.