SSH Security for PCI

The Bottom Line on SSH Security and PCI

If you just received a PCI compliance questionnaire from your payment processor and you’re seeing questions about SSH security, take a deep breath. For most small businesses, securing SSH for PCI compliance is simpler than it sounds. SSH (Secure Shell) is just a way to remotely access your systems — and if you’re not using it, you can often mark those requirements as “not applicable.” If you are using SSH, this guide will show you exactly what PCI requires and how to fix common SSH security issues that might be flagged during your compliance assessment.

What Is PCI Compliance (In Plain English)

PCI DSS (Payment Card Industry Data Security Standard) exists to protect credit card data from theft. If you accept credit cards — whether through a terminal, online, or over the phone — these security standards apply to you. The major card brands (Visa, Mastercard, American Express, and Discover) created these standards through the PCI Security Standards Council, but it’s your payment processor or acquiring bank that enforces them.

Here’s what matters: if you’re not compliant, your payment processor can fine you, you could be liable for fraud losses if there’s a breach, and in extreme cases, you might lose the ability to accept credit cards. The good news? Most small businesses qualify for the simplest compliance requirements, and many SSH-related controls won’t even apply to your environment.

Your payment processor sent you that compliance questionnaire because they’re required to verify that every merchant accepting cards meets these security standards. They’re not trying to make your life difficult — they’re protecting both you and your customers from credit card fraud.

Do You Need to Be PCI Compliant?

Simple answer: if you accept credit cards in any form, yes. It doesn’t matter if you’re a Fortune 500 company or a food truck — accepting card payments means PCI compliance applies to you.

Most small businesses fall into Merchant Level 4 (processing fewer than 20,000 e-commerce transactions or up to 1 million total transactions annually). Your merchant level determines how you validate compliance — Level 4 merchants complete a self-assessment questionnaire (SAQ) rather than hiring an external assessor.

Your payment processor expects you to:

Complete the right SAQ for your business type annually
Run quarterly vulnerability scans if required
Fix any critical security issues
Submit your compliance documentation on time

That questionnaire they sent? It’s your starting point for demonstrating you’re protecting cardholder data appropriately.

Which SAQ Do You Need?

The type of Self-Assessment Questionnaire (SAQ) you complete depends entirely on how you accept and process credit cards. Here’s the breakdown in plain language:

How You Accept Cards	Your SAQ Type	Number of Questions	SSH Typically Required?
Redirect to payment processor (PayPal, Stripe Checkout)	SAQ A	~20	No
E-commerce with payment fields on your site	SAQ A-EP	~190	Sometimes
Standalone terminal only (Square, Clover)	SAQ B	~40	No
Terminal connected to your network	SAQ B-IP	~80	Sometimes
Phone orders processed through virtual terminal	SAQ C-VT	~80	Sometimes
You store, process, or transmit card data	SAQ D	~330	Yes

If you’re using a simple payment terminal like Square or Clover that’s not connected to your computer network, you’re likely SAQ B — and SSH PCI and won’t apply to you at all.

If you have an e-commerce website that redirects to a hosted payment page (like Shopify or WooCommerce with Stripe Checkout), you’re probably SAQ A — again, no SSH requirements.

If you process payments through your own systems or have terminals connected to your network, that’s when SSH security becomes relevant to your PCI compliance.

not sure which SAQ applies? PCICompliance.com’s free SAQ Wizard asks a few simple questions about your payment setup and tells you exactly which questionnaire you need.

SSH Security Requirements in PCI

SSH comes up in PCI compliance because it’s a common way to remotely access servers and network devices. If you or your IT team use SSH to manage systems that touch cardholder data, PCI wants to ensure those connections are secure.

Here’s what PCI requires for SSH:

Strong encryption: Use SSH protocol version 2 (SSH-1 is prohibited)
Strong authentication: Passwords alone aren’t enough — you need key-based authentication or multi-factor authentication
Access control: Only authorized personnel should have SSH access
Configuration security: Disable root login, use non-standard ports, restrict source IP addresses
Logging and monitoring: Track who’s accessing systems via SSH

Common SSH issues flagged during PCI scans:

Default SSH port (22) is open to the internet
Weak encryption ciphers enabled
Root login permitted
Password authentication without additional factors
No IP address restrictions

How to Fix Common SSH Security Issues

When your ASV scan flags SSH vulnerabilities, here’s how to fix them:

1. Disable Weak Ciphers

Your scan might show “SSH Server Supports Weak Encryption.” Fix this by editing your SSH configuration (usually `/etc/ssh/sshd_config`):

Remove any ciphers using DES, 3DES, or RC4
Enable only strong ciphers like AES256-CTR or AES128-GCM

2. Implement Key-Based Authentication

Replace password-only authentication with SSH keys:

Generate key pairs for authorized users
Disable password authentication
Implement proper key management procedures

3. Restrict SSH Access

Don’t leave SSH open to the entire internet:

Use firewall rules to limit source IP addresses
Consider using a VPN for remote access instead
Change from the default port 22 to reduce automated attacks

4. Secure SSH Configuration

Additional hardening steps:

Disable root login (`PermitRootLogin no`)
Set login grace time to 60 seconds or less
Limit authentication attempts
Enable logging of all SSH connections

5. Implement Multi-Factor Authentication

For any SSH access to systems in your cardholder data environment (CDE):

Add MFA using tools like Google Authenticator
Require both SSH key AND one-time password
Document your MFA implementation for your SAQ

What If You Don’t Use SSH?

Good news: if you don’t use SSH, you can mark all SSH-related requirements as “Not Applicable” on your SAQ. Many small merchants fall into this category — if you’re using:

Standalone payment terminals not connected to any network
Cloud-based point-of-sale systems accessed through web browsers
Hosted e-commerce platforms that handle all the technical infrastructure

Then you probably don’t have SSH enabled anywhere in your environment. When completing your SAQ, select “N/A” for SSH-related questions and briefly explain that SSH is not used in your payment environment.

How to Complete Your SAQ

Your SAQ is a questionnaire with yes/no questions about your security practices. Here’s what to expect:

“Yes” means you’ve implemented that security control and can prove it. You’ll need documentation like configuration files, policies, or screenshots.

“No” means you haven’t implemented it yet. You’ll need to either implement the control or explain why it doesn’t apply.

“N/A” means the requirement doesn’t apply to your environment. For SSH requirements, this is often the right answer for small merchants.

Documentation you’ll need:

Network diagram showing your payment flow
List of any systems that handle card data
Security policies and procedures
Configuration files for any SSH servers
Scan reports from your quarterly ASV scans

The quarterly ASV scan is required for most SAQ types. It’s an automated vulnerability scan of your internet-facing systems. Schedule these every 90 days, fix any failing issues, and keep your passing scan reports for compliance records.

What It Costs

Compliance platform fees typically range from $20-100 per month for small merchants, including:

SAQ questionnaire tools
Compliance tracking dashboard
Basic support

Quarterly ASV scanning usually costs $30-50 per scan or $120-200 annually for all four required scans.

If you need a QSA (only required for larger merchants or if you’ve had a breach), expect $15,000-50,000 for a full assessment.

The cost of NON-compliance far exceeds these amounts:

Monthly fines from your processor ($25-100 for small merchants)
Breach liability (average small business breach costs $150,000+)
Loss of card processing privileges

For most small merchants, annual compliance costs less than a single month of non-compliance fines.

Staying Compliant Year-Round

PCI compliance isn’t a one-time checkbox — it’s an annual requirement with quarterly obligations. Here’s how to stay on track:

Set up reminders for:

Annual SAQ completion (due date varies by processor)
Quarterly ASV scans (every 90 days)
Security update installations
Employee security training

What triggers a new assessment:

Changing payment processors
Adding new payment channels
Significant network changes
Moving to a different SAQ type

PCICompliance.com’s compliance dashboard tracks all these dates for you, sends automatic reminders, and maintains your compliance history in one place.

FAQ

Do I need to worry about SSH if I only use Square?

No, if you’re using a standalone Square terminal that’s not connected to your network, SSH requirements don’t apply to you. You’ll complete SAQ B, which doesn’t include SSH security controls. The SSH questions only matter if you have servers or network devices that handle card data and allow remote access.

My web hosting company handles SSH – am I still responsible?

It depends on your level of access. If you have SSH access to the server hosting your e-commerce site, you’re responsible for securing that access according to PCI standards. If only your hosting provider has SSH access and you interact through a control panel, the SSH security responsibility typically falls on them as your service provider.

Can I just disable SSH entirely to avoid these requirements?

Yes, if you don’t need remote access, disabling SSH entirely is often the simplest solution. Many small businesses can manage their systems through vendor-provided interfaces without ever needing SSH. Just ensure you have alternative ways to maintain and update your systems that don’t compromise security.

How do I know if my SSH configuration is PCI compliant?

Run a vulnerability scan through an Approved Scanning Vendor (ASV) – they’ll identify any SSH security issues. The scan will flag weak ciphers, insecure protocols, and configuration problems. Fix any HIGH or CRITICAL vulnerabilities related to SSH, then run a rescan to confirm compliance.

What’s the difference between SSH and SSL in PCI compliance?

SSH secures remote server access while SSL/TLS secures web traffic – both are important but serve different purposes. SSH questions relate to how administrators access systems, while SSL/TLS requirements cover how your website protects cardholder data in transit. Most merchants need to address both.

I got an SSH vulnerability on my scan but I don’t use SSH – what do I do?

First, verify that SSH is actually running on the flagged system – sometimes it’s enabled by default even if unused. If SSH is running but not needed, disable the service entirely. If it’s a false positive, work with your ASV to dispute the finding with evidence that SSH isn’t present or is properly secured.

Conclusion

SSH security for PCI compliance might sound technical, but for most small businesses, it’s either not applicable or straightforward to address. If you use standalone payment terminals or hosted payment pages, you likely don’t need to worry about SSH at all. If you do have systems with SSH access, focusing on strong authentication, encryption, and access controls will get you compliant.

The key is understanding which requirements actually apply to your business. PCICompliance.com makes this simple — our free SAQ Wizard identifies exactly which questionnaire you need based on your payment setup, our ASV scanning service handles your quarterly vulnerability scans including any SSH security checks, and our compliance dashboard keeps you on track throughout the year. Whether you need help interpreting scan results, securing SSH configurations, or just figuring out if these requirements even apply to you, start with our SAQ Wizard or talk to our compliance team. We’ve guided thousands of merchants through PCI compliance, and we’ll make sure you’re focusing on what actually matters for your business.